Website: http://moblock.berlios.de/ I've tried to install it from source, and to install it from deb package, with no success. So, please make an ebuild for this! It might be difficult to verify that the kernel has been compiled with the needed modules...
I have managed to make it working! It needs these kernel modules: nfnetlink_queue 8768 1 nfnetlink 4888 2 nfnetlink_queue xt_tcpudp 2944 2 iptable_filter 2432 1 ip_tables 10696 1 iptable_filter xt_state 1792 3 xt_NFQUEUE 1792 3 x_tables 10244 4 xt_tcpudp,ip_tables,xt_state,xt_NFQUEUE Ang a start script from: http://moblock-deb.sourceforge.net/ In the deb you can find a cron script too, to update the ip blocklists. However it is important to remove the "Microsoft" list, because, it won't enable logging in to an MSN account with it.
Done. The ebuild is available in the Gentoo Sunrise Overlay. You can get it directly here: http://gentoo-sunrise.org/svn/reviewed/net-misc/moblock . (It can take a couple of hours until the ebuild gets reviewed. In the meantime, replace "reviewed" with "sunrise" in the URL above.) The initd/confd scripts aren't perfect yet (no documentation, etc.). If you have corrections, post them here or join us on irc on #gentoo-sunrise. Note: the ebuild needs some other packages available only in the gentoo sunrise overlay, so it's probably a good idea to get the complete overlay via layman.
Created attachment 94168 [details] moblock-0.8.ebuild
Created attachment 102477 [details] moblock update script
Thank you, for this ebuild. However i've found an update script, that you should include.
*** Bug 170646 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > The initd/confd scripts aren't perfect yet (no documentation, etc.). If you > have corrections, post them here or join us on irc on #gentoo-sunrise. in files/initd: 73c73 < start-stop-daemon --stop --pidfile ${PID} --- > start-stop-daemon --stop --pidfile ${PIDFILE} also, you should put a warning for the ones that have ipt_NFQUEUE built-in in the kernel (and not as a module) to change line 18: 18c18 < modprobe ipt_NFQUEUE --- > # modprobe ipt_NFQUEUE otherwise start() would fail
Thanks for the ebuild, it works well. Please consider the following changes to the init script. 5a6,7 > opts="${opts} reload" > 73c75 < start-stop-daemon --stop --pidfile ${PID} --- > start-stop-daemon --stop --pidfile ${PIDFILE} 93a96,101 > > reload() { > ebegin Reloading moblock lists > kill -HUP $(<${PIDFILE}) > eend $? > } By sending SIGHUP, we tell moblock to reload its block lists. This is more secure than restarting the service, as unauthorized connections can be established while the iptables rules are being deleted. I'll also upload an updating script I wrote, as it's a little more in the gentoo style of things than the previous one on this bug. Feel free to use it however you see fit. It probably needs some modification before it's fit to be included in the package.
Created attachment 123081 [details] gentooified update script Update script with gentoo-ish output.
(In reply to comment #9) This is good because the scripts from the Debian MoBlock project mentioned in comment #1 are moving to use lsb scripts, and that opens a big can of worms if we want to use that on Gentoo. > Ang a start script from: > http://moblock-deb.sourceforge.net/
Created attachment 129597 [details] update script - added mirror support We should get this stuff integrated into the ebuild
Created attachment 129601 [details] /etc/conf.d/moblock with lists and mirrors This is my /etc/conf.d/moblock that contains all (at least I think all) of the lists and all of the servers I could find. Some of the servers don't have all of the files, and worse yet, wont give you a true 4xx response (letting wget think it worked).
Created attachment 129602 [details] script to extract lists/mirrors from p2g conf
Created attachment 129660 [details] Proposed 0.8-r1 ebuild (with new scripts) Proposed 0.8-r1 ebuild (with new scripts) * Improved upon previously posted update script * Fixed bug in init.d script (changed PID to PIDFILE in stop function) * Added script to extract stats from MoBlock daemon * Updated conf.d file, added blocklist servers, and the lists with descriptions * Moved compiled block list to /var/db/moblock * Downloaded (pre-merging) blocklists now go in /var/cache/moblock * Removed /etc/moblock dir
Created attachment 129824 [details] Revised 0.8-r1 ebuild w/ files I updated the ChangeLog and did a little bit more cleanup. This should be ready to check in (I don't have those privs)
I came across a few problems when I was attempting to use the moblock ebuild in the latest tarball. * There's no moblock-0.8-makefile.patch in the tarball, but the ebuild attempts to use it. It is, however, provided in the previous one. * By default conf.d/moblock sets BLOCKLISTFILE to /var/db/moblock/p2p.p2p, however, the ebuild installs /var/db/moblock/p2p.p2b. This causes the init script to fail complaining there is no configuration file. * There needs to be a message in the ebuild that you need to run moblock-update before running the init script. Or perhaps the init script could run this if BLOCKLISTFILE is not found? * There's no DEPEND on iptables even though it is used in the init script. * The ebuild needs to check that the right kernel options are enabled.I had to enable NETFILTER_XTABLES, NETFILTER_XT_TARGET_NFQUEUE, IP_NF_IPTABLES, and IP_NF_FILTER. * Is the modprobe in the init script necessary? From what I see, iptables takes care of loading the needed modules when it's run. Also, I couldn't find an option for ipt_NFQUEUE, is this supposed to be xt_NFQUEUE?
(In reply to comment #16) Sorry for my slow response, I'm working on another revision now. I greatly appreciate your testing and feedback! Here are my responses to your issues: * I didn't include moblock-0.8-makefile.patch since it hadn't changed, but I'll include it in the next one. svn should see that it hasn't changed and not update it. * I actually fixed the p2b/p2p issue few days after I posted the 9/2 ebuild, but it looks like I forgot to post the fix. * For moblock-update, I totally agree. I'll have the init script run this automatically if it discovers a zero-length or non-existing p2p file. I'm a bit hesitant about doing this without having first made sure that the user knew what was going on and configured their blocklists in /etc/confd/moblock, but as I consider it more, it occurs to me that most people will probably use it to protect themselves while sharing files, so the default values will be fine for that. If they install and run it without any reading and it doesn't behave as they expected, then I suppose they can figure it out themselves. * Added iptables to DEPENDS. * Added checks for kernel config options. * But as far as calling modprobe, I really don't know -- I hadn't changed that part of the init script. I'm going to comment it out and defer to your assessment and test results. Thanks for your help! moblock-0.8.ebuild was a pretty big pain in the hindquarters. Maybe we can get it cleaned up enough to have it put in the main tree.
There are some pretty well cleaned up debian packages, perhaps we should use those rather than creating our own? http://moblock-deb.sourceforge.net/
(In reply to comment #18) I looked at this very closely, experimented with it and spoke with the maintainer. The problem is that it depends upon the LSB script library (Linux Standard Base - http://www.linux-foundation.org/en/LSB) which Gentoo does not use. Gentoo's own /sbin/functions.sh, et. al. overlap with LSB a good deal, in fact. So using the Debian version would require pulling in LSB (i.e., creating ebuilds for LSB as well) which seems like quite a large effort. On the bright side, our blocklist and a few other config things are cleaner than the more mature debian-moblock.
Created attachment 135230 [details] Revised 0.8-r1 ebuild w/ files * Addresses issues raised in comment #16 - Checks for needed kernel config options - init.d script runs moblock-update when starting if p2p file is missing or empty - p2p/p2b problem fixed - iptables added to DEPENDS - call to modprobe in init.d script removed * Corrected issue in init.d script that left iptables incorrectly configured if moblock failed to start. * More cleanup/enhancements to moblock-update (better logging, better Gentoo-ification, etc.)
(In reply to comment #8) One more silly little glitch on this sending SIGHUP to moblock; if you are using the level1 list (or possibly others), you can't do updates anyway because some of the mirrors that contain the updates are hosted by companies who do business with other companies who are on some blacklists, and are thus, blacklisted (funny huh?). So it may sometimes be required to stop moblock before updating anyway. On the bright side, if you aren't using these block lists, you can still get continuous protection during an update. For instance, I use moblock on my server with the bogon, trojans, etc as a first line of defense against the most common spam/attacks. Why should my sshd even respond to their requests when I can just never get them. If we wanted to get really fancy, we could (at some point) rebuild a blocklist that doesn't include our mirrors, have moblock reload this list and then perform the update. I don't know why the mirrors aren't in the standard whitelist however.
I submitted r1 to sunrise, but it hasn't been reviewed yet. I made a few more minor changes since the last tarball I posted (mostly comments in the ebuild), but you can get the latest from http://overlays.gentoo.org/svn/proj/sunrise/sunrise/net-misc/moblock/moblock-0.8-r1.ebuild until it gets reviewed.
moblock-0.8-r1 the sunrise overlay. You can find it at: http://overlays.gentoo.org/svn/proj/sunrise/reviewed/net-misc/moblock (or update your layman)
(In reply to comment #20) > Created an attachment (id=135230) [edit] > Revised 0.8-r1 ebuild w/ files > > * Addresses issues raised in comment #16 > - Checks for needed kernel config options > - init.d script runs moblock-update when starting > if p2p file is missing or empty > - p2p/p2b problem fixed > - iptables added to DEPENDS > - call to modprobe in init.d script removed Great to see my problems addressed :) I did come across one more kernel config that needs to be checked for: "state" match support. The kernel config for this is NETFILTER_XT_MATCH_STATE. Looking at the ebuild on sunrise you can probably also remove NETFILTER, NETFILTER_XTABLES and IP_NF_IPTABLES. As the other features depend on these in order for them to be enabled.
addressing bug #12156 of moblock http://developer.berlios.de/bugs/?func=detailbug&bug_id=12156&group_id=2509 you should consider to comment out line 505 in MoBlock.c: 503: if (nfq_unbind_pf(h, AF_INET) < 0) { 504: fprintf(logfile, "error during nfq_unbind_pf()\n"); 505: //exit(-1); 506: } note that this is only a temporary workaround for the ones that aren't able to get moblock working with kernel 2.6.23
(In reply to comment #25) > addressing bug #12156 of moblock > http://developer.berlios.de/bugs/?func=detailbug&bug_id=12156&group_id=2509 Please discuss this on bug #204154 as this problem is unrelated to this (current) bug. If you like, submit a patch :)
*** Bug 204154 has been marked as a duplicate of this bug. ***
Created attachment 140004 [details] moblock-0.8-r2 ebuild & files (In reply to comment #27) > *** Bug 204154 has been marked as a duplicate of this bug. *** OK, my mistake (I didn't realize we weren't supposed to open bugs for packages in Sunrise). So here is my proposed patch. In addition to fixing the problem that occurs with 2.6.23 kernels, it has the following enhancements/changes as previous discussed here and elsewhere: * moblock-update doesn't clobber old blocklist files when download of new files starts and subsequently fails * moblock-update no longer tries to add the exclusions list into the blocklist (exclusions.gz is now specified with WHITELISTS in conf.d. * /var/log/MoBlock.stats changed to /var/log/moblock.stats * conf.d changed to allow incoming ssh and outgoing ftp, http and https by default
Downloading blocklists (especially level1) frequently fails. We need a more robust update script that can retry later when it fails.
moblock-{stats,update} should source /etc/init.d/functions.sh (which is valid of baselayout 1 and 2). /sbin/functions.sh is only valid for baselayout-1. This is already fixed in sunrise.
Also confd should have a comment for every variable.
I'm not sure if this is considered lazy or not but I found this suggested on the Phoenixlabs forums or somewhere similar from a user to add IP whitelisting to MoBlock, so you didn't have to do it on port basis and so you could have all of it in one file. they suggested this change to the init.d/moblock file, and I later decided I needed a way to blacklist single ip's that weren't blocked, so I adapted their code slightly to work to blacklist single ip's as well. The change in init.d/moblock is; 62a63,83 > # IP Blacklisting > for IP in ${BLACK_IP_IN}; do > iptables -I MOBLOCK_IN --source ${IP} -j DROP > done > for IP in ${BLACK_IP_OUT}; do > iptables -I MOBLOCK_OUT --source ${IP} -j DROP > done > for IP in ${BLACK_IP_FORWARD}; do > iptables -i MOBLOCK_FORWARD --source ${IP} -j DROP > done > # IP whitelisting > for IP in ${WHITE_IP_IN}; do > iptables -I MOBLOCK_IN --source ${IP} -j RETURN > done > for IP in ${WHITE_IP_OUT}; do > iptables -I MOBLOCK_OUT --destination ${IP} -j RETURN > done > for IP in ${WHITE_IP_FORWARD}; do > iptables -I MOBLOCK_FW --source ${IP} -j RETURN > iptables -I MOBLOCK_FW --destination $IP -j RETURN > done and then of course you're supposed to add these entries to the config file in conf.d/moblock # This is an example to whitelist the range 192.168.178.1-192.168.178.255: # WHITE_IP_OUT="192.168.178.0/24" WHITE_IP_IN="" WHITE_IP_OUT="" WHITE_IP_FORWARD="" BLACK_IP_IN="" BLACK_IP_OUT="" BLACK_IP_FORWARD="" I figured I'd mention it because they're a couple of simple changes that make moblock feel more full featured. I really don't need the gui that anyone's come up with for it, editing the conf.d file to whitelist and blacklist addresses is easy enough for me, tailing it's logfile lets me know what's going on. (Although I'd love it if someone could come up with a way to modify MoBlock.c so it dumps the ports involved, that's extra information I'd like to know if possible. I tried to write it in myself and failed however.)
Created attachment 143160 [details] ebuild and patches Updated ebuild with changes suggested in comment #32. I added a similar exclusion manually in my system, much better with a generic interface.
Hi, I can't get either of the ebuilds provided here working. I always get a nfq_unbind_error (which is solved by the patch which is applied), but the strange thing is that I also get an nfq_bind_error (which is not patched) and so my moblock exits ungracefully and all connections are blocked because the iptables rules are still active but moblock is no longer running. Does anyone have a clue why I get an "nfq_bind_error" after the "nfq_unbind_error" (which seems to be normal with the new conntrack module), or what could be causing it. Plus, can anyone post the output of "lsmod" maybe one module (which is not marked as required in the ebuild) is missing. Thanks for your help.
(In reply to comment #34) If nfq_unbind_pf() fails and so does nfq_bind_pf(), this may be an -EBUSY problem: cat /proc/net/netfilter/nf_queue to see whether this protocol family (AF_INET) hasn't been bound already. For example, if ip_queue (OBSOLETE) is still enabled in your kernel, it will bind there and thus block any nfq_bind_pf() attempts. Disable it to get moblock to work. > Hi, > > I can't get either of the ebuilds provided here working. I always get a > nfq_unbind_error (which is solved by the patch which is applied), but the > strange thing is that I also get an nfq_bind_error (which is not patched) and > so my moblock exits ungracefully and all connections are blocked because the > iptables rules are still active but moblock is no longer running. > > Does anyone have a clue why I get an "nfq_bind_error" after the > "nfq_unbind_error" (which seems to be normal with the new conntrack module), or > what could be causing it. > > Plus, can anyone post the output of "lsmod" maybe one module (which is not > marked as required in the ebuild) is missing. > > Thanks for your help. >
(In reply to comment #35) > If nfq_unbind_pf() fails and so does nfq_bind_pf(), this may be an -EBUSY > problem: cat /proc/net/netfilter/nf_queue to see whether this protocol family > (AF_INET) hasn't been bound already. For example, if ip_queue (OBSOLETE) is > still enabled in your kernel, it will bind there and thus block any > nfq_bind_pf() attempts. Disable it to get moblock to work. Thank you very much for this hint. cat /proc/net/netfilter/nf_queue showed that ip_queue was indeed running. So I removed the kernel option, recompiled and now moblock-0.8-r3 works like a charm.
I think, we need a logrotate config file too, since moblock grows really big. E.g.: /var/log/moblock.* { weekly rotate 7 compress delaycompress missingok create 644 root root postrotate /etc/init.d/moblock restart endscript }
(In reply to comment #37) > I think, we need a logrotate config file too, since moblock grows really big. > E.g.: > /var/log/moblock.* { > weekly > rotate 7 > compress > delaycompress > missingok > create 644 root root > postrotate > /etc/init.d/moblock restart > endscript > } > I'm not so familiar with logrotate scripts, but won't this start moblock because of the /etc/init.d/moblock if the log is rotated. I think the rotate script should check if moblock was running or not. Is this possible? I'm thinking about sending HUP to moblock but I'm not sure if this would also reopen the logs, or if it will only reload the block list. Does anyone have better ideas or am I mistaken about the "restart" command?
(In reply to comment #38) > (In reply to comment #37) > > I think, we need a logrotate config file too, since moblock grows really big. > > E.g.: > > /var/log/moblock.* { > > weekly > > rotate 7 > > compress > > delaycompress > > missingok > > create 644 root root > > postrotate > > /etc/init.d/moblock restart > > endscript > > } > > > > I'm not so familiar with logrotate scripts, but won't this start moblock > because of the /etc/init.d/moblock if the log is rotated. I think the rotate > script should check if moblock was running or not. Is this possible? I'm > thinking about sending HUP to moblock but I'm not sure if this would also > reopen the logs, or if it will only reload the block list. Does anyone have > better ideas or am I mistaken about the "restart" command? >
disregard previous post (paste error) >>> Emerging (3 of 3) net-misc/moblock-0.8-r1 to / * MoBlock-0.8-i586.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking MoBlock-0.8-i586.tar.bz2 ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/2.6.26-rc9/build * Found sources for kernel version: * 2.6.26-rc9 * Checking for suitable kernel configuration options... [ ok ] >>> Unpacking source... >>> Unpacking MoBlock-0.8-i586.tar.bz2 to /var/tmp/portage/net-misc/moblock-0.8-r1/work * Applying moblock-0.8-makefile.patch ... [ ok ] >>> Source unpacked. >>> Compiling source in /var/tmp/portage/net-misc/moblock-0.8-r1/work/MoBlock-0.8 ... x86_64-pc-linux-gnu-gcc -O2 -march=core2 -mtune=core2 -pipe -Wall -D_GNU_SOURCE -DNFQUEUE -L/usr/include/libipq -c -o MoBlock.o MoBlock.c x86_64-pc-linux-gnu-gcc -O2 -march=core2 -mtune=core2 -pipe -Wall -D_GNU_SOURCE -DNFQUEUE -L/usr/include/libipq -c -o rbt.o rbt.c In file included from MoBlock.c:35: /usr/include/linux/netfilter_ipv4.h:53: error: 'INT_MIN' undeclared here (not in a function) /usr/include/linux/netfilter_ipv4.h:63: error: 'INT_MAX' undeclared here (not in a function) make: *** [MoBlock.o] Error 1 make: *** Waiting for unfinished jobs.... * * ERROR: net-misc/moblock-0.8-r1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2868: Called die * The specific snippet of code: * emake CC=$(tc-getCC) || die "emake failed" * The die message: * emake failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/net-misc/moblock-0.8-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-misc/moblock-0.8-r1/temp/environment'. * This ebuild is from an overlay: '/usr/local/portage/layman/sunrise/'
(In reply to comment #1) > I have managed to make it working! > It needs these kernel modules: > nfnetlink_queue 8768 1 > nfnetlink 4888 2 nfnetlink_queue > xt_tcpudp 2944 2 > iptable_filter 2432 1 > ip_tables 10696 1 iptable_filter > xt_state 1792 3 > xt_NFQUEUE 1792 3 > x_tables 10244 4 xt_tcpudp,ip_tables,xt_state,xt_NFQUEUE > > Ang a start script from: > http://moblock-deb.sourceforge.net/ > > In the deb you can find a cron script too, to update the ip blocklists. > However it is important to remove the "Microsoft" list, because, it won't > enable logging in to an MSN account with it. > Hi all, i'm new here with a fresh-installed gentoo. After many and many retries i finaly got moblock working. The problem was that probably the ebuild is missing some checks (both in 0.8-r1 from sunrise overlay and in 0.8-r4 here). I followed the http://gentoo-wiki.com/Moblock how to, but when moblock starts i receive tre errors from iptables: "iptables: No chain/target/match by that name" error". This is because in the how to isn't specified that we need the module xt_state, and it isn't checked by the ebuilds. Sorry for my english, i hope you can understand what i'm writing. Thanks for the ebuils. Regards, Zorzo Luca
Created attachment 162794 [details] Moblock-08-r1/2/3 ebuilds and files fixed Moblock-08-r1/2/3 ebuilds and files, with updated module check and function.sh's path fixed
Has there been any work on creating an ebuild for Moblock 0.9? They've made some significant architectural changes with this version, most notably by simply marking good and bad packets, rather than accepting or dropping them. This allows for more complex management using iptables rules.
(In reply to comment #43) > Has there been any work on creating an ebuild for Moblock 0.9? I only see 0.8 on their site, have they moved? Where's that 0.9?
(In reply to comment #42) > Created an attachment (id=162794) [edit] > Moblock-08-r1/2/3 ebuilds and files fixed > > Moblock-08-r1/2/3 ebuilds and files, with updated module check and > function.sh's path fixed > Hi! Thanks for you ebuilds, I am now using them but I still get some errors at start and stop. At start: * Starting MoBlock ... iptables: Invalid argument iptables: Invalid argument iptables: Invalid argument [ ok ] At stop: * Stopping MoBlock ... [ ok ] iptables: No chain/target/match by that name iptables: No chain/target/match by that name iptables: No chain/target/match by that name Does anybody know where could be the problem? I have: net-firewall/iptables-1.4.0-r1 USE="-extensions -imq -ipv6 -l7filter -static" Thanks
Seems that they are produced by: if [ ${ACTIVATE_CHAINS} -eq 1 ]; then iptables -I INPUT -p all -m state --state NEW -j MOBLOCK_IN iptables -I OUTPUT -p all -m state --state NEW -j MOBLOCK_OUT iptables -I FORWARD -p all -m state --state NEW -j MOBLOCK_FW fi and: if [ ${ACTIVATE_CHAINS} -eq 1 ]; then iptables -D INPUT -p all -m state --state NEW -j MOBLOCK_IN iptables -D OUTPUT -p all -m state --state NEW -j MOBLOCK_OUT iptables -D FORWARD -p all -m state --state NEW -j MOBLOCK_FW fi In /etc/init.d/moblock
For those looking to create a 0.9 ebuild, I'd suggest drawing heavily from the <a href="http://moblock-deb.sourceforge.net/">moblock-deb</a> project; they provide a .deb package for the current moblock, but more importantly they also provide moblock-control, a set of scripts for managing moblock. These scripts are far more powerful than those included in the above ebuilds. I'll take a look myself later to see what can be brought over, but their work can be found <a href="http://moblock-deb.svn.sourceforge.net/viewvc/moblock-deb/moblock/moblock-0.9~rc2/moblock-0.9~rc2/debian/">here</a> if others would like to take a look.
Hi, @46.. Did you read http://gentoo-wiki.com/Moblock ? I think your problem is because your kernel is not well configured, probably some config check is missing in the ebuild. You need to reconfigure your kernel (see http://gentoo-wiki.com/Moblock) and remember to add "state match support" as module. Summarizing i have moblock working with this config (gentoo-sources 2.6.25-r7): Networking ---> Networking Option ---> [*] Network packet filtering framework (Netfilter) ---> [*] Advanced netfilter configuration Core Netfilter Configuration ---> <*> Netfilter NFQUEUE over NFNETLINK interface <*> Netfilter connection tracking support [*] Connection tracking flow accounting [*] Connection mark tracking support -*- Netfilter Xtables support (required for ip_tables) <M> "NFQUEUE" target Support <M> "state" match support IP: Netfilter Configuration ---> <*> IPv4 connection tracking support (required for NAT) <*> IP tables support (required for filtering/masq/NAT) <M> Packet filtering <M> Full NAT <M> MASQUERADE target support <M> REDIRECT target support <M> NETMAP target support (i think it will work without last four modules, i only copied my config).
Seems that: IPv4 connection tracking support (required for NAT) is the one how was giving me errors but now, even when starting and stopping seems to work ok, when I start moblock I lose network connection (I cannot ping to my router for example, only to myself works) :-(
Adding its IP to white list fixed the problem, sorry for the inconvenience and thanks a lot for your help
(In reply to comment #1) > In the deb you can find a cron script too, to update the ip blocklists. > However it is important to remove the "Microsoft" list, because, it won't > enable logging in to an MSN account with it. > For this, I am simply adding "443 1863" to WHITE_TCP_OUT, then, mine moblock conf.d file looks like: WHITE_TCP_OUT="ftp http https 443 1863"
Still getting this: In file included from MoBlock.c:36: /usr/include/linux/netfilter_ipv4.h:53: error: ‘INT_MIN’ undeclared here (not in a function) /usr/include/linux/netfilter_ipv4.h:63: error: ‘INT_MAX’ undeclared here (not in a function) make: *** [MoBlock.o] Błąd 1
Apropos to what I mentioned earlier, the maintainers of moblock-deb have now split off their excellent script collection as moblock-control, available from https://sourceforge.net/project/showfiles.php?group_id=162910 . If someone here is a init script wizard, it shouldn't be too hard to modify their init script to our format; I think everything else should pretty much work out of the box. To be fair, it's possible that moblock-control should be a separate package (which is how they've started distributing their software on Debian and Ubuntu); if consensus agrees with this, I'll open a new bug.
this is mainly a worksforme / please bump 0.9 comment: - running 8-r3 here amd64, worksforme fine. - a issue / request for moblock-control: i can't find out why a flash-stream ( http://www.tagesschau.de/multimedia/livestreams/index.html ) is beeing blocked - it works using peerguardian under xp, and its hard to debug with no logfiles, so 0.9 & moblock-control is what i'm looking for.
Ok, I put an updated (0.9_rc2) ebuild in my overlay. It'd be great if somebody else could take care of moblock-control... (GitWeb-Address: http://git.overlays.gentoo.org/gitweb/?p=dev/dev-zero.git;a=tree;f=net-misc;hb=HEAD)
i just upgraded to your ebuild; emerging works, but i get iptables: No chain/target/match by that name messages when trying to start.
ok, i had to add the "state" iptables module,now 0.9 works here fine (amd64) thanks for your ebuild, now i'm trying a gui for it
Hi, in this day it seems that the file level2.gz is distribuited like level2.zip, so i've changed my /usr/sbin/moblock-update adding this line: mv `find /var/cache/moblock/ -type f -iname '*.zip'` `find /var/cache/moblock/ -type f -iname '*.zip' | sed -e 's/.zip/.gz/g'` into mergeFiles() section. So please verify if the problem is real (cat /var/log/moblock-update.log), because if it is so the list used is quite old. Another thing: i notice that there is no bandwith usage when moblock-update is running... Is it really downloading the new lists? Or simply using old ones? For moblock-control i tested it and it is working "as is";i never made an ebuild, but i'll try to learn because this kind must be very simple to do :) For ending i'd like to write a little tip/question: there is any way for checking if kernel is compiled with or without the modules autoload option? And if not there is a way for making moblock able to load the needed modules? This is because i think all the problems came from here.. Even with a write configuration if you don't load the modules it will never work ;). Maybe a new user does not know this thing. Sorry for my english, Thanks
I'm getting strange error on the end of log file /var/log/moblock.log: Error during nfq_bind_pf() Does somebody have the same problem or does somebody know how to fix it?
The moblock-deb team (http://moblock-deb.sourceforge.net/) has further generalized their moblock-control scripts, making them work with either moblock or nfblock as a backend (and renaming their package to blockcontrol to reflect this) as well as generalizing the scripts to work on any distro. It would be a really good idea to migrate their scripts into a ebuild which automatically installs moblock and blockcontrol at the same time.
Created attachment 187672 [details] New revision of moblock 0.8 This is moblock-0.8-r4 that fix undeclared variables and lists to download. I've to do this because with 0.9_rc2 there are some problems: 1: ebuild needs to check IP_NF_TARGET_REJECT if you want to keep "REJECT" lines in conf.d 2: if moblock logs into system log i've 100% cpu (need to verify) 3: sometimes moblock doesn't quit 4: moblock-stats was very useful.
Created attachment 202755 [details] Preliminary 0.8-r5 I apologize for not posting this sooner as I fixed missing header file bug that Zorzo addressed in his patch, but hadn't shared it yet, sorry. This flaw was apparently exposed in some recent version of glibc or linux-headers or some such. So I've merged Zorzo's changes (checking for IP_NF_TARGET_REJECT) and made several other enhancements. This is preliminary and I haven't updated the ChangeLog yet. 1. moblock-update to spend less time on servers that are down (happens a lot) 2. Modified the overall scheme that moblock-update uses so we can include iblocklist.org as a mirror, which likes to prepends "bt_" to their file names. 3. Added a "network-cron" use flag which installs a link to moblock-update in /etc/cron-weekly 4. Added a "paranoid" use flag that changes the cron job to daily and the settings in /etc/conf.d/moblock to parinoid. I'm not actually sure if this is worthwhile and maybe we should just install the files moblock.paranoid (paranoid p2p protection), moblock.normal (normal p2p protection) and moblock.minimal (no p2p protection, but keeps out all of the other crap: ads-trackers-and-bad-pr0n, bogon, dshield, hijacked, iana-*, spyware and trojans) instead of having a USE flag configure the defaults for you. I'll take opinions on this one please. 5. Added a "logrotate" USE flag that installs an /etc/logrotate/moblock file. This postrotate script that sends SIGUSR1 to moblock which causes it to write stats to the log file (which I don't care about really) and also re-open the log file (which we need). This flag also pulls in app-admin/logrotate and I hope that's acceptable. 6. Modified moblock-stats slightly because in some cases tail is claiming it can't find file - (dash) when redirecting that file to it. I'm not sure of the cause, but this modification fixes it. 7. Modified ebuild so it no longer removes /var/cache/moblock because this was just a pain. Instead it tells you to remove it yourself if you want to. 8. Modified ebuild to restart moblock after install if moblock is running. If you unmerge moblock when it's in memory, it doesn't try to stop it. This is because I have no way of knowing from pkg_postrm rather the unmerge is due to an upgrade or removal and we want to air on the side of protecting the user. I still have some change the README file that I'm working on (to better clarify the effect of various signals) so that's going to change as well as the ChangeLog, which hasn't been updated or had Zorzo's entries added yet. Finally, once I'm done with this and had some other people try it out, I'm going to try to get my sunrise account reactivated (it was apparently deactivated due to inactivity) and push this through, although I'll be calling it -r2 since nothing beyond -r1 was ever released on sunrise. Thanks in advance for assistance. As far as 0.9, I'll take Zorzo's word on it and let it be until it's actually better than 0.8. =)
Created attachment 202771 [details] Conf.d for moblock-0.8-r5. Hi, good work with this new r5. But you need to change "piranoid" with "paranoid" in ebuild. Attached here there is a little different conf.d: it has lists in alphabetical order, with two more lists (gnutella and spam forums: gnutella is commented because it gives to me problems in some sites). It also adds the ip of gentoo's rsync main server into the withelist, because many times it is blocked.
(In reply to comment #63) ooh, thanks for the updated conf.d! Hehe, I typoed "paranoid" and then copy/pasted it, that's funny. =) Thanks for reviewing! After thinking about it more, I think that I will definitely install multiple conf.d files for paranoid, normal and minimal as discussed above. Without adding anit-p2p ranges, MoBlock becomes something very nice on the router of a network that connects windows machines to the internet, keeping users from harming themselves by hitting bad web sites and such. For now, I'm going to leave the "paranoid" USE flag (properly spelled of course). What MoBlock really needs is a whitelist ability, so that exclusions.tgz can actually be used. Also, as far as Gentoo's rsync server, that's probably because it's hosted by an a hosting company that is also a customer to an anti-p2p company. More paranoid lists just block the entire range of said hosting providers. But individual IPs can also be white-listed via iptables directly.
Created attachment 202826 [details] Proposed update for moblock Ok, I've merged Zorzo's changes and reorganized the conf.d into 3 different files for paranoid, normal and minimal -- the default is normal unless you use the "paranoid" flag. The "minimal" implementation removes the whitelisting for ssh, ftp, http and https protocols because it shouldn't (generally) block anything you would want to surf anyway and is intended for general-purpose use (as opposed to anti-p2p protection). I tweaked moblock-update again, moving the timeout and retry values to the conf.d file and improving the logging and output so it tells you if a file was updated, skipped because it was already up to date, etc. I still need to run repoman and update the ChangeLog and will try to get it through, again as 0.8-r2.
(In reply to comment #60) > The moblock-deb team (http://moblock-deb.sourceforge.net/) has further > generalized their moblock-control scripts, making them work with either moblock > or nfblock as a backend (and renaming their package to blockcontrol to reflect > this) as well as generalizing the scripts to work on any distro. It would be a > really good idea to migrate their scripts into a ebuild which automatically > installs moblock and blockcontrol at the same time. > Gabriel, sorry I missed this before. The last time I reviewed Debian's moblock-control scripts, it was unfeasible because the sheer volume of Debian-specific scripts that would be required and the fact that their standard installation wasn't distro-neutral. I remember trying it by installing what at first seemed a very innocuous dependency script. However, this ended up having other Debian-specific dependencies, which in turn had still more dependencies. If this has changed, I would gladly review it again, but it was impossible before.
I finally got the above changes (modified even further) into sunrise as 0.8-r2, hurray! Please give it a try and post any problems you have here. Maybe we can get it into the main portage tree if everything goes well with it. Everybody who contributed to this is mentioned in the ChangeLog, thanks all!!!
Thanks to you Daniel for your work. Can you attach here the same package that is in sunrise? Is it the proposed-final one?
Created attachment 203869 [details] Final moblock-0.8-r2.tgz (from sunrise tree) Sure, but it's available via subversion or from layman now, but here it is.
This new moblock is working really good. About logrotate the packed file does not have the .gz extension.
Re: Comment #59 If this is the same as the problem and solution I just found... you likely have IP_NF_QUEUE set to Y (or M and the associated module called, I think, 'ip_queue' loaded). Solution: Compile a kernel with IP_NF_QUEUE NOT set to Y and/or make sure the ip_queue module isn't loaded.
**CRITICAL BLOCKLIST CHANGES** Sorry for the all-caps, but this has a fairly serious affect on users who use moblock for P2P sharing of copyrighted material. As of mid-October 2011, changes to blocklists and domain ownership results in moblock's blocklist not updating at all. The following blocklists have been changed by bluetack.co.uk (in brief patch format): - BLOCKLISTS+="trojan " + BLOCKLISTS+="proxy " - BLOCKLISTS+="webexploit-forumspam " + BLOCKLISTS+="webexploit " + BLOCKLISTS+="forumspam " This would normally not cause moblock-update to fail to update the blocklist, but the domain bluetack.info has changed ownership causing HTTP "GET" requests on those URLs to return a 200 status, but not the blocklist. This resulted in gunzip failing and the blocklist not updating (looks like the script needs some more work to be "fail-proof"). Thus, please remove the following URL from your BLOCKLISTURLS: BLOCKLISTURLS=" http://www.bluetack.co.uk/config/BLOCKLIST.SUFFIX http://www.bluetack.nl/bluetack/BLOCKLIST.SUFFIX http://list.iblocklist.com/?list=bt_BLOCKLIST - http://www.bluetack.info/temp/BLOCKLIST.SUFFIX " To clarify, this problem hasn't caused moblock to stop blocking, it just caused the updater to no longer update the blocklist (/var/db/moblock/guarding.p2p by default), so that IP ranges added since mid-October won't be blocked. < End of critical info > While I'm writing, there are some other things that need updating in this package. For completeness, I'll include the issues discussed above as well. 1. Blocklist changes need to go into the default and example /etc/conf.d/moblock files 2. The update script needs to be changed to not fail to update when a blocklist is successfully downloaded (i.e., HTTP status 200) but is not a gzip file. 3. Better notification of moblock update problems needs to be implemented to let the user know when their blocklist doesn't contain everything they want (or isn't fully updated). 4. There's a new version of moblock (v0.9) that fixes some bugs and has a few minor enhancements. 5. The exclusions file has yet to be used (not sure if that can be done without patching the C sources or not. 6. We should consider separating blocklist management into a separate package (that moblock depends upon). There are several reasons for this: * Some apps (like KTorrent) can directly use a blocklist file. These apps could benefit from moblock-update's ability to manage and merge multiple blocklists. * There may be other GNU/Linux port blocker apps. * There may be other GNU/Linux blocklist manager apps. I'll try to get the first two issues addressed and committed in the next few days.
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
