General MoBlock thread

[sleepyenglish]

Has anyone got it running on jaunty?

[sleepyenglish]

Well i was going to install iplist instead but it needs to remove moblock, blockcontrol and mobloqer. moblock and mobloqer remove ok but again blockcontrol halted the progress by staying at stopping blockcontrol indefinitely.

[iamnotthemessiah]

same issues as the ppl above. cant get it working

[lovinglinux]

Has anyone got it running on jaunty?

Running perfectly here, but I don't download the lists using moblock. I download them using a script, then I merge then using peerguardian and moblock only uses one merged list from local source.

[sleepyenglish]

Anything and everything i try ends up in * Stopping IP block daemon moblock

hanging indefinitely. If i under stood correctly the setting INIT=0 means it wont auto start so how come everything i try starts with it hanging on stopping ip block daemon moblock? Is this daemon a file i can just delete because this is starting to :( me.

[lovinglinux]

Anything and everything i try ends up in

hanging indefinitely. If i under stood correctly the setting INIT=0 means it wont auto start so how come everything i try starts with it hanging on stopping ip block daemon moblock? Is this daemon a file i can just delete because this is starting to :( me.

I had that problem and solved it after manually adding the custom scripts.

[sleepyenglish]

Care to share :popcorn:

[lovinglinux]

Care to share :popcorn:

Do you want the explanation or the scripts?

I basically use moblock with a series of "profiles", depending on what I'm doing on the network. These profiles are activated by scripts that copy the files blockcontrol.conf, blocklists.list, iptables-custom-insert.sh and iptables-custom-remove.sh from a backup folder into /etc/blockcontrol/ directory every time I activate them. All my lists included in blocklists.list are stored locally, so moblock never stall when trying to download. These lists are a compilation of moblock's lists, downloaded via wget and merged into a single list for each profile, using peerguardian.

[talz13]

I was able to get around the lockup on Starting... or Stopping... by copying my old startup/shutdown scripts from my previous install of moblock (yay for backing up /etc before formatting!)

Maybe it will help others, so I attached the necessary scripts here. Just download them, copy them to /etc/blockcontrol/ and make sure they are owned by root and executable:
cd /etc/blockcontrol/
sudo chown root.root iptables-custom-*
sudo chmod 755 iptables-custom-*

I am not responsible if you screw anything up, just take this as advice from what worked for me.

[sleepyenglish]

Do you want the explanation or the scripts?

I basically use moblock with a series of "profiles", depending on what I'm doing on the network. These profiles are activated by scripts that copy the files blockcontrol.conf, blocklists.list, iptables-custom-insert.sh and iptables-custom-remove.sh from a backup folder into /etc/blockcontrol/ directory every time I activate them. All my lists included in blocklists.list are stored locally, so moblock never stall when trying to download. These lists are a compilation of moblock's lists, downloaded via wget and merged into a single list for each profile, using peerguardian.

Thats a pretty cool way to do things its a shame moblock cant handle profiles out of the box.

I was able to get around the lockup on Starting... or Stopping... by copying my old startup/shutdown scripts from my previous install of moblock (yay for backing up /etc before formatting!)

Maybe it will help others, so I attached the necessary scripts here. Just download them, copy them to /etc/blockcontrol/ and make sure they are owned by root and executable:
cd /etc/blockcontrol/
sudo chown root.root iptables-custom-*
sudo chmod 755 iptables-custom-*

I am not responsible if you screw anything up, just take this as advice from what worked for me.

Talz13 thats seem to have have fixed the issue, thanks a bunch. Anyone know how i can start the first run set up again?

[jre]

Sorry for the inconvenience, these things seem to happen whenever I have no time :-/

I have fixed it in blockcontrol_1.4.1-1~jaunty. I'm just uploading the package, it should be available in a few minutes.
During the update from the current broken jaunty package this one will hang again. So you have to interrupt (press "control" + "c") the update in order to force the use of a new script. Then everything will work.

On updates from older, non-broken versions or on new installations everything will work flawless.

The problem was that the custom iptables scripts aren't installed to /etc/blockcontrol/ any more. Instead they go to /usr/share/doc/blockcontrol/examples and blockcontrol will execute every ...insert.sh or ...remove.sh script that is in /etc/blockcontrol/. This might be useful for a future mobloquer release, which might allow easy whitelisting of IP+port combinations.
Unfortunately my last version was broken if none such script existed.

[sleepyenglish]

Jre could you please tell me how i could run the setup gui that appears on initial installation.

[jre]

Jre could you please tell me how i could run the setup gui that appears on initial installation.
Just confirm everything. See here:
https://help.ubuntu.com/community/MoBlock#I%20tried%20to%20install%20MoBlock%20but%2 0I%27m%20stuck%20on%20a%20screen%20with%20a%20Mobl ock%20warning

[spockrock]

I am having issue where it seems that blockcontrol is not using the /etc/blockcontol/blockcontrol.conf configuration file. The result is that all my network traffic is getting blocked. Where do I go to tell blockcontrol to use the blockcontrol.conf??

[jre]

I am having issue where it seems that blockcontrol is not using the /etc/blockcontol/blockcontrol.conf configuration file. The result is that all my network traffic is getting blocked. Where do I go to tell blockcontrol to use the blockcontrol.conf??

You have to "blockcontrol restart" after changing the configuration.

Check "blockcontrol show_config" to see if your changes are seen by blockcontrol.

[spockrock]

You have to "blockcontrol restart" after changing the configuration.

Check "blockcontrol show_config" to see if your changes are seen by blockcontrol.


I did the show_config and it was showing my changes, but doing a blockcontrol reload and a blockcontrol restart fixed it. I am assuming that blockcontrol stop and blockcontrol start is not the equivalent to blockcontrol restart???

[jre]

I am assuming that blockcontrol stop and blockcontrol start is not the equivalent to blockcontrol restart???
Nope, it's exactly the same.
Further, on a restart all steps should be done that are done on reload.

[Jerriy]

Hi jre - I have a question:

How do you customize/add your own ip blocks? I noticed that in Mobloquer one of my Blocklists, the one called custom-blocklist, is disabled by default. I enabled it and then moblock tried to restart but failed. I had to "detick" the Enable box for that blocklist in order to restore the program. So then, how do I customize/add my own ip blocks? Apparently it involves creating a file in a particular folder called "custom-blocklist.p2p or something, right? The question is how on earth do I do that on Mobloquer?

[jre]

How do you customize/add your own ip blocks? I noticed that in Mobloquer one of my Blocklists, the one called custom-blocklist, is disabled by default. I enabled it and then moblock tried to restart but failed. I had to "detick" the Enable box for that blocklist in order to restore the program. So then, how do I customize/add my own ip blocks? Apparently it involves creating a file in a particular folder called "custom-blocklist.p2p or something, right? The question is how on earth do I do that on Mobloquer?

It's not possible (yet) to add your own block-ranges in mobloquer. But it's possible manually.

Step 1:
You need an entry in /etc/blockcontrol/blocklists.list that points to your custom blocklist, that starts with "locallist", e.g.
locallist /etc/blockcontrol/custom-blocklist.p2p

When you enabled the local blocklist in mobloquer just that line was enabled in blocklists.list (per default it's commented with a hash (#), so it's not used).

Step 2:
You need that list. So create /etc/blockcontrol/custom-blocklist.p2p, or perhaps it's better to use a file in your home directory, so that you don't need root rights to edit your own blocklist and of course you have to fill that list with entries, e.g.:
My first blocked range:123.123.123.123-123.234.234.234


Step 3:
Restart blockcontrol (or press restart in mobloquer). Verify in the logfile /var/log/blockcontrol.log if everything works.

I guess you had such an entry:
Building blocklist... Updating /etc/blockcontrol/custom-blocklist.p2p... * Error 9: /etc/blockcontrol/custom-blocklist.p2p not available. Aborting!
This happens if you do step 1, but don't actually create that list.

[dj_flx]

I see that Moblock is reporting Tor being blocked every so often in the logs.

Is it possible to run Moblock and Tor at the same time? Or are these not "real" Tor nodes it's blocking?

[iamnotthemessiah]

is there a simple way to get the number of blocked ranges? i like to have that in my conky but it doesent seem to work anymore the way i did it before. i used to add to the updater script something like:grep 'Ranges loaded' /var/log/moblock.log | awk '{print $8}' | tail -n 1 > /home/XXX/various/scripts/misc/various/moranges.txt - and let conky read that (yes i know its a different logfile now - still doesent work)

there should be a simple 'blockcontrol -ranges' or something. maybe it is and i just didnt find it

[jre]

I see that Moblock is reporting Tor being blocked every so often in the logs.

Is it possible to run Moblock and Tor at the same time? Or are these not "real" Tor nodes it's blocking?

Solution 1:
Per default this list is enabled:
http://www.bluetack.co.uk/config/proxy.gz

This list has been compiled from a list of Tor servers and various other proxy servers.
See https://help.ubuntu.com/community/MoBlock#How%20do%20I%20choose%20what%20blocklists% 20to%20include%20in%20the%20update%20function?

Solution 2:
Or allow the tor port (I guess for in and out traffic, or is it forward!?) Just allow it for all TCP traffic: WHITE_TCP_FORWARD="9001 9030 9050"
WHITE_TCP_IN="9001 9030 9050"
WHITE_TCP_OUT="9001 9030 9050"

See
https://help.ubuntu.com/community/MoBlock#Some applications cannot connect to the internet any more! and http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

Solution 3:
You may choose some IPs of tor servers and especially whitelist them. But I doubt that this is practical and good for the tor community, because you will miss most. Still you could do that together with solution 1 for the rest of the tor servers if they should be in any other list.

[Dawa]

i just installed the latest blockcontrol update. not only did it remove most of my blocklists, but when i tried to add one mobloquer crashed and now will not start again.

jre, is there any way to provide updates without resetting the blocklists? that would be ideal.

edit: once again, a complete uninstall in synaptic of all things moblock and then a re-install solved the problem. it seems like mobloquer has trouble whenever moblock/blockcontrol updates on my system.

[jre]

i just installed the latest blockcontrol update. not only did it remove most of my blocklists, but when i tried to add one mobloquer crashed and now will not start again.

jre, is there any way to provide updates without resetting the blocklists? that would be ideal.

edit: once again, a complete uninstall in synaptic of all things moblock and then a re-install solved the problem. it seems like mobloquer has trouble whenever moblock/blockcontrol updates on my system.

Which blocklists were removed? You mean your configuration? Of course that shouldn't happen and I've never observed this. Can you provide further information? Your old and new blocklists.list would be interesting, if they still exist.

Did you stop mobloquer before the update? I might add code to the package that kills mobloquer before an update and starts it again afterwards, if this is usefull.

EDIT:
The blocklsist settings are in /etc/blockcontrol/blocklists.list. If you have changed your blocklist configuration (whether manually or in mobloquer), then this file gets changed. During updates you are asked, whether you want to install a new version of /etc/blockcontrol/blocklists.list. If you say "Yes", then my version gets installed. If you say "No", then your version with your configuration settings keeps installed.
So you have to make sure not to say "Yes".

This is the general handling of configuration files in Debian packages. I doubt that I have broken this.

[iamnotthemessiah]

started getting errors today
Removing the following lines from Bluetack_proxy:
* Error: grep exited with 1

so the update doesent finish... dunno what more info u need. let me know

[jre]

Please post the output of
blockcontrol show_config | grep IP_REMOVE

[iamnotthemessiah]

IP_REMOVE="Norwegian Broadcasting Corporation;BBC;LeaseWeb B.V;netdirekt;Easy Online Solutions;America Online;Hetzner Online AG"

[jre]

I just investigated that a bit. For some reason the bt_proxy list was downloaded today with 0 bytes. This causes the problems. This is not related to the blockcontrol update!
Just disable the bt_proxy list for now in /etc/blockcontrol/blockcontrol.conf.

I'll try to change blockcontrol, so that it doesn't break if this happens.

[iamnotthemessiah]

ah that explains it. thanks, i should have checked the files.
but yeah hope you can fix this :)

edit: you probably mean /etc/blockcontrol/blocklists.list

[lovinglinux]

I just investigated that a bit. For some reason the bt_proxy list was downloaded today with 0 bytes. This causes the problems. This is not related to the blockcontrol update!
Just disable the bt_proxy list for now in /etc/blockcontrol/blockcontrol.conf.

I'll try to change blockcontrol, so that it doesn't break if this happens.

I don't know if this info is useful or not, but I have downloaded bt_proxy from iblocklist source yesterday using wget and it was normal. The only odd thing was that while most lists were update on May 5th, this one was updated on May 1st, together with the templist and spyware.

I have downloaded it again today from iblocklist and from bluetack and both downloads were normal. The file was updated today.

Nevertheless, I have experienced a strange behavior on merging the lists manually with peerguardian before, exactly for the same reason.

[jre]

Thanks. For me bt_proxy was 0 bytes with blockcontrol, wget and the manual web download yesterday. I contacted the iblocklist maintainer. The list is now back to normal again:
http://iblocklist.com/list.php?list=bt_proxy

badpeers (templist) and spyware currently download fine (but they are not in the default blockcontrol configuration).

I have a blockcontrol update ready, which checks the file size before doing the IP_REMOVE stuff.

[iamnotthemessiah]

yep it all works again now :)

got another question jre, with previous versions i used to get an email sent to my system mailbox after an update. this doesent seem to happen anymore since jaunty. keeping in mind i used a rather old version of moblock/moblock-control (not blockcontrol) in intrepid. any way to get that back?

[jre]

You can specify the recipient for the cron job results. E.g. the default setting
CRON_MAILTO="root"
means that this mail is deliverd locally to root. You may specify any email address if you have configured your local mail system appropriately.
This is new since 1.3-1. Before this mail was sent by anacron. If the old worked, then the new should work, too. Please check /var/mail. Do you get other local mail delivered?
Do you have the executable /usr/sbin/sendmail or /usr/lib/sendmail on your system?

[iamnotthemessiah]

ur right a all the messages got sent to root, i want it to my own user

thats in blockcontrol.conf yeah?
i just add
CRON_MAILTO="my_username" ?

[jre]

Yes, either do it this way or generally forward root's mail to your user.

[c.b.simas]

I realize that a lot of posts have been made on this subject so I feel bad asking the question over but I need to.

For starters, I'm using the mobloque GUI (and I'm ignorant about linux :) ).

Just as many people have had the problem where MoBlock wants to keep one from signing into Pidgin accounts; I had the same problem.

I looked at the log and saw when it was blocking Google or Microsoft, told MoBlock to not block the IP anymore, went under Settings > Whitelist IPs, highlighted the IP and clicked Whois to find the IP range for that host. I then copy/pasted the range, replaced the " - " with "/", clicked Add and restarted MoBlock. No problems thus far.

But, after whitelisting those IP ranges MoBlock is still blocking IPs that fall within those ranges. What am I doing wrong or not doing?

Thank you all in advance.

[jre]

The GUI mobloquer does not yet support whitelisting of IP ranges. 192.168.178.0-192.168.178.255 or 192.168.178.0/192.168.178.255 are not valid entries in mobloquer!

Possible solutions:
Please have a look at https://help.ubuntu.com/community/MoBlock#But why can I not just remove the IP address from the blocklist instead?
In this link you find under "1. Whitelist an IP range in allow.p2p" how to whitelist IP ranges in /etc/blockcontrol/allow.p2p.

If you want to stay with mobloquer you might add single IPs with subnetmasks.
See in the above link "2. Whitelist an IP" for examples (e.g. 192.168.178.0/24 for the IP range 192.168.178.0-192.168.178.255). 192.168.178.0/24 is a valid entry in mobloquer.

[SqRt7744]

I'm having trouble with Moblock interfering with Ekiga in Jaunty. With moblock running the ekiga PC-to-Phone account won't connect (or just the regular ekiga account for that matter). If I run "sudo blockcontrol stop" Ekiga can connect and I can place my calls.

Ekiga uses the SIP protocol.


grep sip < /etc/services


returns


sip 5060/tcp # Session Initiation Protocol
sip 5060/udp
sip-tls 5061/tcp
sip-tls 5061/udp


the contents of /etc/blockcontrol/blockcontrol.conf

WHITE_TCP_OUT="http https 465 587 993 1863 3478:3479 5000:5100 5190 5222 5353 7070 16382 22020:22025 35129"
WATCHDOG="0"
WHITE_IP_IN="192.168.1.0/24"
WHITE_IP_OUT="192.168.1.0/24"


I'll try adding WHITE_UDP_OUT="5000:5100" as well and see if that helps. It didn't. :(

[c.b.simas]

Thank you for the help! So I'm having a problem: am I supposed to save allow.p2p once I'm done with it? I try to save it and I get: (see attachment)

I've had this problem before when trying to permanently disable my PC speaker.

How do I save the file?

[jre]

@SqRt7744: That should do it. Don't forget the "restart" afterwards.

@c.b.simas: You need root rights. So start it with "sudo", as described in the link.

[c.b.simas]

Look, I'm sorry, I'm ignorant about this. After I entered the IP ranges into allow.p2p I opened up the terminal and entered "sudo blockcontrol restart", entered my password and the IP block daemon moblock restarted.

So I close the terminal and try to close the allow.p2p file but it asks me if I want to save the changes, I click yes and I encounter my previously mentioned problem.

Am I supposed to enter "sudo" in another location? I tried it in various locations in the allow.p2p file but that did nothing. I also tried entering that command line into that file but that did nothing (like I said, I'm ignorant about this so I'm just testing stuff out to learn).

Am I missing the point of what you're saying or did you not fully understand my dilema?

[c.b.simas]

Good news for you: there's no need to answer another one of my questions at this time. :)

I didn't realize there was a difference between accessing that file with gksudo gedit ... vrs through the file browser.

Like I said: I'm new. :)

[SqRt7744]

Re. post #288 http://ubuntuforums.org/showpost.php?p=7259796&postcount=288

@jre: you said my changes should work, but they haven't... Ekiga still won't work unless I stop moblock first.

If I start ekiga with Moblock running I get the message:

"Ekiga did not manage to configure your network settings automatically. You can still use it, but you need to configure your network settings manually.

Please see http://wiki.ekiga.org/index.php/Enable_port_forwarding_manually for instructions"

----EDIT----
I have managed to solve it by adding the following entries to /etc/blockcontrol/blockcontrol.conf:


WHITE_TCP_IN="5000:5100"
WHITE_UDP_OUT="3478:3479 5000:5100"


----EDIT----

I was wrong, it still doesn't work. Neither the Echo test, nor a call to a landline.

[madHasher]

I recently installed moblock on Jaunty, following the instructions on https://help.ubuntu.com/community/MoBlock. I used aptitude and installed moblock blockcontrol and mobloquer. Everything seemed ok while installing and configuring white lists but when I run it I get this error message.
Required configuration file "/var/log/moblock.log" could not be found in the default path.
Please specify a different path.

while all the other .conf and .log files seem to exist that one is no where to be found. I've tried removing and reinstalling this time just moblock and blockcontrol.




sudo aptitude install moblock blockcontrol
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
The following NEW packages will be installed:
blockcontrol libnetfilter-queue1{a} libnfnetlink0{a} moblock p7zip{a}
0 packages upgraded, 5 newly installed, 0 to remove and 22 not upgraded.
Need to get 0B/487kB of archives. After unpacking 1708kB will be used.
Do you want to continue? [Y/n/?] y
Writing extended state information... Done
Preconfiguring packages ...
Selecting previously deselected package libnfnetlink0.
(Reading database ... 142187 files and directories currently installed.)
Unpacking libnfnetlink0 (from .../libnfnetlink0_0.0.39-1_amd64.deb) ...
Selecting previously deselected package libnetfilter-queue1.
Unpacking libnetfilter-queue1 (from .../libnetfilter-queue1_0.0.16-1_amd64.deb) ...
Selecting previously deselected package moblock.
Unpacking moblock (from .../moblock_0.9~rc2-23~pre2~jaunty_amd64.deb) ...
Selecting previously deselected package blockcontrol.
Unpacking blockcontrol (from .../blockcontrol_1.4.4-1~jaunty_all.deb) ...
Selecting previously deselected package p7zip.
Unpacking p7zip (from .../p7zip_4.58~dfsg.1-1_amd64.deb) ...
Processing triggers for man-db ...
Setting up libnfnetlink0 (0.0.39-1) ...

Setting up libnetfilter-queue1 (0.0.16-1) ...

Setting up moblock (0.9~rc2-23~pre2~jaunty) ...
Setting up blockcontrol (1.4.4-1~jaunty) ...

moblock will soon be started ...
If any blocklists are missing, they will be downloaded. This may take several
minutes. Please be patient and don't abort. If you want to follow the update
process, then do in another terminal a
tail -f /var/log/blockcontrol.log
The lists are saved to /var/spool/blockcontrol/.
The installation of blockcontrol will fail, if starting moblock fails. If this
happens, then in most cases downloading the blocklists failed temporarily. To
workaround this, you can turn the automatic starting of moblock off by setting
in /etc/blockcontrol/blockcontrol.conf:
INIT="0"




* Starting IP block daemon moblock invoke-rc.d: initscript blockcontrol, action "start" failed.
dpkg: error processing blockcontrol (--configure):
subprocess post-installation script returned error exit status 8
Setting up p7zip (4.58~dfsg.1-1) ...
Processing triggers for libc6 ...
ldconfig deferred processing now taking place
Errors were encountered while processing:
blockcontrol
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
Setting up blockcontrol (1.4.4-1~jaunty) ...

moblock will soon be started ...
If any blocklists are missing, they will be downloaded. This may take several
minutes. Please be patient and don't abort. If you want to follow the update
process, then do in another terminal a
tail -f /var/log/blockcontrol.log
The lists are saved to /var/spool/blockcontrol/.
The installation of blockcontrol will fail, if starting moblock fails. If this
happens, then in most cases downloading the blocklists failed temporarily. To
workaround this, you can turn the automatic starting of moblock off by setting
in /etc/blockcontrol/blockcontrol.conf:
INIT="0"

* Starting IP block daemon moblock invoke-rc.d: initscript blockcontrol, action "start" failed.
dpkg: error processing blockcontrol (--configure):
subprocess post-installation script returned error exit status 8
Errors were encountered while processing:
blockcontrol
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Writing extended state information... Donewhat shoudl I do?

[jre]

I think the first error about "moblock.log" resulted from an old invalid moblock-control installation. I think we can forget about that now.

With your new installation something goes wrong with the iptables command. Perhaps you find something more informative in /var/log/blockcontrol.log.

I guess that there are already some iptables rules inserted before the installation, so inserting them during installation fails, because they are already present.

You may check your iptables rules with
sudo iptables -L -nv
In the output there must not be anything regarding blockcontrol, moblock or NFQUEUE if MoBlock is not running.

Perhaps just rebooting and continuing the blockcontrol installation is enough.

Otherwise do a clean uninstall:
sudo aptitude purge moblock moblock-control mobloquer blockcontrol

Then completely clean up your iptables (this will break other firewalls):
sudo iptables -F
sudo iptables -X

Then install again:
sudo aptitude install moblock mobloquer blockcontrol.


If your problems continue, please post your blockcontrol.log and the output of
sudo blockcontrol status
dpkg -l moblock moblock-control mobloquer blockcontrol

[madHasher]

Thanks looks like that did the trick, not sure what went wrong with my first install but clearly I hadn't uninstalled thoroughly enough.

[SqRt7744]

OK this is getting really annoying. I thought I had Ekiga sorted out, but a few calls just failed. Finally I thought I'd turn off moblock one more time just to see if it could still be interfering even though I have whitelisted all relevant ports (I believe). ...and it was moblock that was preventing the calls!

I'm not doing anything unusual, I'm just using Ekiga to call 500@ekiga.net, and I have put money into the call-out feature so I can call home. Any ideas what it could be? I appreciate any help I can get...

/etc/blockcontrol/blockcontrol.conf

WHITE_TCP_OUT="http https 465 587 993 1863 3478:3479 5000:5100 5190 5222 5353 7070 16382 35129"
WHITE_UDP_OUT="3478:3479 5000:5100"
WHITE_TCP_IN="5000:5100"
WATCHDOG="0"
WHITE_IP_IN="192.168.1.0/24"
WHITE_IP_OUT="192.168.1.0/24"

[jre]

Set in /etc/blockcontrol/blockcontrol.conf
LOG_IPTABLES="LOG --log-level info"

Then do a "sudo tail -f /var/log/syslog" to see live what happens. You will see (source and destination) IP, (source and destination) port and protocol of every blocked packed.
For outgoing connections you have to look at the destination port and if the protocol is TCP or UDP for the whitelisting.

Unrelated: I see you have disabled the watchdog. Were there any errors or did it consume too much CPU?

[SqRt7744]

@jre, sorry I don't know why the watchdog was diabled, I've re-enabled it. In any case, thanks for the tip about adding LOG_IPTABLES="LOG --log-level info" to blocklist.conf. It helped me somewhat... after adding a bunch of ports and *still* not being able to connect, I added the IPs that I got from syslog for ekiga and diamondcard and it works now.

Would it be possible to integrate an 'allow common apps' checklist into the gui? Perhaps with a few things such as 'Pidgin' [msn, icq, etc] 'ekiga' (although I still haven't really figured out which ports this behemoth really needs) and others? Maybe also an "allow connections to 'some domain name'" ...because the way it is set up at the moment, although a great program, seems a tad too awkward for many.

thanks for your quick reply in any case :)

[jre]

Would it be possible to integrate an 'allow common apps' checklist into the gui? Perhaps with a few things such as 'Pidgin' [msn, icq, etc] 'ekiga' (although I still haven't really figured out which ports this behemoth really needs) and others? Maybe also an "allow connections to 'some domain name'" ...because the way it is set up at the moment, although a great program, seems a tad too awkward for many.

I would add this to the documentation. Especially the wiki at https://help.ubuntu.com/community/MoBlock might be a good place for that. (This is editable by everybody!!). At the moment I just give a link to the wikipedia overview of common ports. I didn't know that allowing ekiga is so complicated (I don't use it). So this would be a good candidate for extended documentation.
Further I could add suggestions for commonly used whitelistings to /usr/lib/blockcontrol/blockcontrol.defaults.
But I think whitelisting per domain name is not feasible, because this requires remote DNS lookups.

Ready made "click and go" solutions are only possible in the GUI mobloquer. I'm not the author of that, and I would prefer another implementations there, which is very general but still serves your purpose:
Let mobloquer show port, protocol and IP of blocked IPs (as you saw them in syslog), and allow whitelisting them by right-clicking (either per IP, or per port+protocol, or per port+protocol+IP. I've already got a patch for moblock, to get the necessary information and I think blockcontrol already allows the iptables implementation. So it's just a modification in mobloquer that has to be done.

[lovinglinux]

Hi jre,

Moblock is not updating /var/lib/blockcontrol/guarding.p2p when restarting.

As you know, I only use local lists and I update them using a script. After updating my lists today and restarting blockcontrol, I've noticed that there was a difference between the number of ranges loaded by moblock and the local list being used. Moblock ranges simply didn't change.

So I did a test. I changed the local list used by moblock and restarted it. The ranges in moblock were updated accordingly. Then I changed the local list used back to the previous one and restarted moblock. The ranges were updated correctly, according to the new number of ranges in the edited list. Then I added a new line in my scripts to delete /var/lib/blockcontrol/guarding.p2p before any list changes and it works now. So it seems that moblock is not updating /var/lib/blockcontrol/guarding.p2p if I do not change the list used or if I do not delete this file first.

I know my case is a particular one, but I think this is something that should be investigated, because other users might be affected too. They might be using the same list cache for days or even weeks if this also affects on-line lists.

I hope this helps.

[jre]

Thanks. First off, this affects only users with local blocklists. Users with online lists are not affected.

I designed blockcontrol the following way: MoBlock loads the master blocklist (/var/lib/blockcontrol/guarding.p2p). This gets built from the single blocklists, but MoBlock does not know about them. The master blocklist gets rebuilt from the single blocklists:

after "blockcontrol update" or "reload"
if there is no master blocklist on "start"/"restart"/"reload"
on "start"/"restart" if /etc/blockcontrol/blocklists.list or the variables BLOCKLIST_FORMAT or IP_REMOVE changed.

I decided against a rebuilt on every start, because I want to avoid this time consuming task if possible. For the same reason I don't want to check every single blocklist if it changed (this is not necessary because they only change on "update"). But I now realized that I still have to check local single blocklists for changes, because they can change without an "update".
This will slow down the "start" for the amount of time needed to get the locallist's md5sum. So this won't affect normal users, but guys like you.

Thanks for reporting this. It's good to know that some people really check my work.
jre

[lovinglinux]

Thanks. First off, this affects only users with local blocklists. Users with online lists are not affected.

I designed blockcontrol the following way: MoBlock loads the master blocklist (/var/lib/blockcontrol/guarding.p2p). This gets built from the single blocklists, but MoBlock does not know about them. The master blocklist gets rebuilt from the single blocklists:

after "blockcontrol update" or "reload"
if there is no master blocklist on "start"/"restart"/"reload"
on "start"/"restart" if /etc/blockcontrol/blocklists.list or the variables BLOCKLIST_FORMAT or IP_REMOVE changed.

I decided against a rebuilt on every start, because I want to avoid this time consuming task if possible. For the same reason I don't want to check every single blocklist if it changed (this is not necessary because they only change on "update"). But I now realized that I still have to check local single blocklists for changes, because they can change without an "update".
This will slow down the "start" for the amount of time needed to get the locallist's md5sum. So this won't affect normal users, but guys like you.

Thanks for reporting this. It's good to know that some people really check my work.
jre

Thanks for the explanation. It makes perfect sense now.

I don't use use the update feature, because I thought it was designed only to grab the lists from the net, which is unnecessary in my case. I also thought that the master list was updated on every "start"/"restart". I remember there was a message about guarding.p2p being built when running those commands through mobloquer. Did you changed this behavior when you introduced blockcontrol?

This really don't affect me that much, because I usually switch between local lists all the time, by replacing /etc/blockcontrol/blocklists.list with presets. Now that I know how it actually works I just need to delete the master list before starting moblock to make sure it will be updated. Not a big deal. It's already in my scripts.

[jre]

Well, years ago the master blocklist was always rebuilt on start, but then there was also a update on start. ;-)
Then the most time I had only point 1 and 2 from my last post. So at that time a "restart" was the wrong thing when you only made blocklist changes, instead a "reload" was necessary.
The actual behaviour (added the intelligent checking from point 3) is since moblock-control 1.2-1.
So no, I didn't change this behaviour in a not-so-good way since mobloquer exists (IIRC).

I'm not sure what mobloquer says, but mobloquer "might" be wrong, since it was written by someone else. Only believe what you see in /var/log/blockcontrol.log (you still can see this log in mobloquer. Most probably you were talking about this.). So I'm not sure if you don't remember correctly, or if there is a bug in mobloquer/blockcontrol, or if I don't remember correctly. Unless you insist I tend to believe everything is ok ;-)

BTW: Most feature changes happen(ed) independent of name changes. In the past even version numbers didn't tell, if there were big changes. But I try to change this in order to get more user friendly. If you are interested in the changes have a look at /usr/share/doc/blockcontrol/changelog.Debian.gz (this is the default place for every Debian package).

[lovinglinux]

So I'm not sure if you don't remember correctly, or if there is a bug in mobloquer/blockcontrol, or if I don't remember correctly. Unless you insist I tend to believe everything is ok ;-)

Don't worry, I'm probably wrong about this and I'm definitely not insisting :) . I was just curious. It is probably a confusion due to the way I update things and use multiple configuration setups. Anyways, it's all good now. ;)

Thanks for you help.

[chinaski]

I have a question:

I turned blockcontrol on after rebooting the router (new public IP address) and was checking /var/log/moblock.log to see if anything happens

amule is off (I use no other P2P apps)

nothing happens

but if I turn Skype on, blockcontrol start blocking

here's a log example:

Fri May 29 23:34:41| OUT: Skype,hits: 4,DST: 204.9.163.214
during those 4 minutes skype was off
Fri May 29 23:38:33| OUT: Skype,hits: 5,DST: 204.9.163.214
Fri May 29 23:38:35| OUT: Bogon,hits: 9,DST: 239.255.255.250
Fri May 29 23:38:35| OUT: Bogon,hits: 10,DST: 239.255.255.250
Fri May 29 23:38:35| OUT: Bogon,hits: 11,DST: 239.255.255.250
Fri May 29 23:38:35| OUT: Bogon,hits: 12,DST: 239.255.255.250
Fri May 29 23:38:35| OUT: Communications Networking Services,hits: 9,DST: 212.8.163.76
Fri May 29 23:38:35| OUT: Skype Technologies,hits: 1,DST: 194.165.188.76
Fri May 29 23:38:35| OUT: Skype,hits: 6,DST: 204.9.163.214
Fri May 29 23:38:35| OUT: Vodafone Omnitel N.V,hits: 1,DST: 93.150.84.252
Fri May 29 23:38:35| OUT: Vodafone Omnitel N.V,hits: 2,DST: 93.150.84.252
Fri May 29 23:38:35| OUT: University of New South Wales,hits: 1,DST: 149.171.92.172
Fri May 29 23:38:36| OUT: University of New Brunswick,hits: 1,DST: 131.202.34.5
Fri May 29 23:38:36| OUT: Videotron Telecom Ltee,hits: 1,DST: 207.253.162.42
Fri May 29 23:38:36| OUT: Vida Optics TVV,hits: 1,DST: 89.215.255.71
Fri May 29 23:38:37| OUT: Communications Networking Services,hits: 10,DST: 212.8.163.76
Fri May 29 23:38:37| OUT: Skype,hits: 7,DST: 204.9.163.214
Fri May 29 23:38:37| OUT: University of New South Wales,hits: 2,DST: 149.171.92.172
Fri May 29 23:38:38| OUT: Videotron Telecom Ltee,hits: 2,DST: 207.253.162.42
Fri May 29 23:38:38| OUT: University of New Brunswick,hits: 2,DST: 131.202.34.5
Fri May 29 23:38:38| OUT: PCCW Business Internet Access,hits: 4,DST: 220.241.188.220
Fri May 29 23:38:38| OUT: Oxford University,hits: 1,DST: 163.1.230.239
Fri May 29 23:38:38| OUT: XO Communications,hits: 1,DST: 66.237.19.176
Fri May 29 23:38:38| OUT: SURFnet bv,hits: 16,DST: 194.171.12.179
Fri May 29 23:38:38| OUT: Vida Optics TVV,hits: 2,DST: 89.215.255.71
Fri May 29 23:38:40| OUT: XO Communications,hits: 2,DST: 66.237.19.176
Fri May 29 23:38:40| OUT: Oxford University,hits: 2,DST: 163.1.230.239
Fri May 29 23:38:40| OUT: PCCW Business Internet Access,hits: 5,DST: 220.241.188.220
Fri May 29 23:38:40| OUT: SURFnet bv,hits: 17,DST: 194.171.12.179
Fri May 29 23:38:41| OUT: University of New South Wales,hits: 3,DST: 149.171.92.172
Fri May 29 23:38:42| OUT: University of New Brunswick,hits: 3,DST: 131.202.34.5
Fri May 29 23:38:42| OUT: Videotron Telecom Ltee,hits: 3,DST: 207.253.162.42
Fri May 29 23:38:42| OUT: Vida Optics TVV,hits: 3,DST: 89.215.255.71
Fri May 29 23:38:44| OUT: PCCW Business Internet Access,hits: 6,DST: 220.241.188.220
Fri May 29 23:38:44| OUT: Oxford University,hits: 3,DST: 163.1.230.239
Fri May 29 23:38:44| OUT: XO Communications,hits: 3,DST: 66.237.19.176
Fri May 29 23:38:44| OUT: SURFnet bv,hits: 18,DST: 194.171.12.179
Fri May 29 23:38:45| OUT: Skype,hits: 8,DST: 204.9.163.214
Fri May 29 23:38:46| OUT: Vida Optics TVV,hits: 4,DST: 89.215.255.71
Fri May 29 23:38:46| OUT: UNIVERSITY OF SOUTH FLORIDA,hits: 1,DST: 131.247.206.157
Fri May 29 23:38:46| OUT: Uninett,hits: 1,DST: 158.39.24.24
Fri May 29 23:38:46| OUT: CESNET,hits: 1,DST: 147.230.27.6
Fri May 29 23:38:48| OUT: Vida Optics TVV,hits: 5,DST: 89.215.255.71
Fri May 29 23:38:48| OUT: CESNET,hits: 2,DST: 147.230.27.6
Fri May 29 23:38:48| OUT: Uninett,hits: 2,DST: 158.39.24.24
Fri May 29 23:38:48| OUT: UNIVERSITY OF SOUTH FLORIDA,hits: 2,DST: 131.247.206.157
Fri May 29 23:38:52| OUT: Vida Optics TVV,hits: 6,DST: 89.215.255.71
Fri May 29 23:38:52| OUT: UNIVERSITY OF SOUTH FLORIDA,hits: 3,DST: 131.247.206.157
Fri May 29 23:38:52| OUT: Uninett,hits: 3,DST: 158.39.24.24
Fri May 29 23:38:52| OUT: CESNET,hits: 3,DST: 147.230.27.6
Fri May 29 23:38:55| OUT: Skype,hits: 9,DST: 204.9.163.214
here I stopped skype and the rest stopped too

does anyone knows why is this?

[lovinglinux]

I have a question:

I turned blockcontrol on after rebooting the router (new public IP address) and was checking /var/log/moblock.log to see if anything happens

amule is off (I use no other P2P apps)

nothing happens

but if I turn Skype on, blockcontrol start blocking


does anyone knows why is this?

It blocks because it is doing what it is supposed to do. When you start Skype it will try to connect to it's servers and they are currently on your blocklists.

Please notice that all blocked connections are outgoing, so they are probably all from Skype trying to connect to the Skype servers.

If you don't want to block Skype connections, then you need to add those blocked IPs to moblock allow list or setup moblock to ignore outgoing connections on the ports used by Skype.

[chinaski]

thank you

what I ask myself now is what those universities listed in the log have to do with Skype :)

[lovinglinux]

thank you

what I ask myself now is what those universities listed in the log have to do with Skype :)

I don't know if they could be hosting skype servers, but probably is just an issue with the ip range on your blocklists. The people who create the blocklists usually include larger IP ranges when they don't know exactly all the IP's used by a company or institution.

[chinaski]

I see

thank you very much for your replies, we never stop to learn :)

[lovinglinux]

I see

thank you very much for your replies, we never stop to learn :)

You are welcome.

You could also create a Skype whitelist and share with the community at I-BlockList (http://iblocklist.com). Users that publish lists gets a VIP account with additional lists access and features.

[jre]

If you want to know why an IP was blocked, a good start is blockcontrol's "search option.

So take this entry from your moblock.log:
Fri May 29 23:38:33| OUT: Skype,hits: 5,DST: 204.9.163.214

Type
blockcontrol search Skype
Note: for this command I recommend to use the description, not the IP, because you have to use an expression that is literally in the blocklists. So in most cases you cannot use an IP as search expression.

You will get this output:
Checking your currently used blocklists for "Skype" (case-insensitive):

TBG_Business_ISPs (http://list.iblocklist.com/?list=jcjfaxgyyshvdbceroxf)
Skype Sarl:80.90.46.152-80.90.46.167
Skype Vlora:80.91.122.96-80.91.122.127
Skype Vlora:80.91.124.64-80.91.124.255
Skype Technologies OU:80.235.29.32-80.235.29.39
Skype SA:81.7.226.204-81.7.226.207
Skype servers Hosting:82.101.61.0-82.101.61.255
SE-TELE2-SKYPE1:83.181.59.0-83.181.59.15
SE-TELE2-SKYPE2:83.181.59.16-83.181.59.23
Mobile Skype service:92.41.254.0-92.41.255.255
Skype:193.120.134.224-193.120.134.231
Skype Technologies:194.165.188.64-194.165.188.127
Skype Technologies OU:195.250.168.112-195.250.168.127
Skype:204.9.163.128-204.9.163.255
Skype:204.9.165.80-204.9.165.87
Skype Technologies OU:217.159.130.168-217.159.130.175
Skype Technologies OU:217.159.236.224-217.159.236.255

"Skype" was found in these lists:
TBG_Business_ISPs (http://list.iblocklist.com/?list=jcjfaxgyyshvdbceroxf)

If you don't want to block the above shown ranges, then you may add
"Skype" to IP_REMOVE in /etc/blockcontrol/blockcontrol.conf.
Or you may remove some of these lists from /etc/blockcontrol/blocklists.list.

So you learn that this was blocked by the TBG_Business_ISPs blocklist. Now have a look at /usr/share/doc/blockcontrol/README.blocklists.gz and judge if this list is of use for you.

[chinaski]

thansk a lot jre

very useful tip :)

[jimbo1]

I am getting the message:

number of blocked ip ranges: n/a

I noticed earlier in this thread that it was an issue with an earlier version of ubuntu. I have ubuntu Jaunty.

Any help would be appreciated :)

[jre]

If this is a temporary problem a "blockcontrol reload" or hitting the reload button in mobloquer will help (I guess the logfiles were rotated, so that mobloquer can't figure this out)

Otherwise check your version with
dpkg -l blockcontrol mobloquer

[jimbo1]

Thanks jre, no luck with the re-load though.

The output of the
dpkg -l blockcontrol mobloqueris:

ii blockcontrol 1.4.4-1~jaunty Manage IP blockers
ii mobloquer 0.6-2~pre1~jau GUI for MoBlock, an IP blocker for Linux

[jimbo1]

I have had to stop using mobloquer for the time being because when I am using deluge it blocks my active port.

If I start mobloquer and test my port in deluge it says it is closed, if I stop mobloquer it says it's active.

There is no IP address displayed in the log window when I try the test so I'm pretty sure it is not a blocklist related issue.

Does anyone have any ideas?

PS. I am also using firestarter and have opened the port on there which seems to work ok. Mobloquer appears to block my port with or without firestater running.

[jre]

First please make sure in /var/log/moblock.log if there is really no blocked IP. Perhaps your mobloquer installation is broken. Since mobloquer is just a GUI, everything that you see there cannot be taken for granted.

If there is really no blocked IP, then I guess your iptables setup is not correct. This might either be, because of a messed up blockcontrol setup, or because another firewall application messes up blockcontrol´s iptables. Please check/post "sudo blockcontrol status" when you experience the problems. In most cases a "sudo blockcontrol restart" fixes such problems.

In case of mobloquer/blockcontrol problems you may try a clean reinstall
sudo aptitude purge moblock moblock-control mobloquer blockcontrol
sudo aptitude install moblock moblock-control mobloquer blockcontrol

Check your version numbers with
dpkg -l moblock moblock-control mobloquer blockcontrol

[jimbo1]

jre, thanks for your help you pointed me in the right direction.

Although I had the port open in firestarter which seemed to work for Deluge, I needed to run this command in order to have the port open while using moblock (i'm not sure why as I'm no expert!).

iptables -I INPUT -p tcp --dport 12345 -j ACCEPT

It's all fine now, thanks again :D

[jimbo1]

Great GUI btw way cooler than PG2!

[jre]

iptables -I INPUT -p tcp --dport 12345 -j ACCEPT
Be careful! This way you disable moblock for incoming connection on port 12345. So if deluge is listening on 12345, then you disable moblock for deluge. Normally you don´t want that.

Generally, it is no problem if deluge says the port is closed, as long as only deluge´s specific test packet was blocked by moblock. So check again /var/log/moblock.log, and just allow the IP of deluge´s specific test packet (if it appears there).

Otherwise check/post your iptables. In most cases the problems with firestarter systems result, because firestarter purges blockcontrol´s iptables after every start/change of firestarter. As already mentioned, this can be fixed by an "blockcontrol restart" (or restart in mobloquer).

Do you have the current version of blockcontrol with the blockcontrol.watchdog installed? That should do exactly that task for you automatically.

[jimbo1]

Hi jre,

I purged all the programs and re-installed to ensure everything is the latest version then I found the IP for the port test in the log file as suggested, it was being blocked by the edu list so I whitelisted it everything is working fine now, thanks again

I'm still trying to get to grips with the whole linux iptables thing, I'll have to find a decent website and read up on it a some point

[lovinglinux]

I'm still trying to get to grips with the whole linux iptables thing, I'll have to find a decent website and read up on it a some point

https://help.ubuntu.com/community/IptablesHowTo
http://ubuntuforums.org/showthread.php?t=159661
http://bodhizazen.net/Tutorials/iptables/
http://iptables-tutorial.frozentux.net/iptables-tutorial.html (advanced stuff)

[TaiKar]

Hi, I am new to Ubuntu and I have a problem that I cannot seem to fix by following the instructions on various websites about how to install MoBlock. I have Ubuntu 9.06. I have installed MoBlock following all the instructions on the link on the first post, and I have in my Applications -> Internet the GUI MoBlock Mobloquer. But when I try to start it either from the GUI or command line it never starts and Mobloquer gives this error: Building blocklist... Updating /etc/blockcontrol/custom-blocklist.p2p... * Error 9: /etc/blockcontrol/custom-blocklist.p2p not available. Aborting! Does anyone know what the problem is? Thanks.

[jre]

Remove the line with the custom-blocklist.p2p entry in /etc/blockcontrol/blocklist.list
Or comment it by adding a hash # in front of this line.

[AlanPo]

Great GUI btw way cooler than PG2!

dpkg -l blockcontrol mobloquer
ii blockcontrol 1.4.4-1 Manage IP blockers
ii mobloquer 0.6-2~pre1~jau GUI for MoBlock, an IP blocker for Linux

but starting Mobloquer gives this:
Required configuration file "/var/log/moblock.log" could not be found in the default path.
Please specify a different path.

did uninstall, update install. when I google it got answer - it's because version. but I have correct one. what to do?

[jre]

dpkg -l blockcontrol mobloquer
ii blockcontrol 1.4.4-1 Manage IP blockers
ii mobloquer 0.6-2~pre1~jau GUI for MoBlock, an IP blocker for Linux

but starting Mobloquer gives this:
Required configuration file "/var/log/moblock.log" could not be found in the default path.
Please specify a different path.

did uninstall, update install. when I google it got answer - it's because version. but I have correct one. what to do?

Can you do "sudo blockcontrol start"?
If this works does /var/log/moblock.log exist?
Does mobloquer refuse to start, or is it just this message?

What´s in /var/log/blockcontrol.log?

Did you do a "purge" for the uninstall? A simple "remove" will not remove the config files, so any errors in there may persist!

[lordratner]

I was looking at some old documentation on MoBlock, and I was wondering if there is still a way to make MoBlock restart automatically after updating the block lists, or is this even necessary anymore?

EDIT: Actually, everything went all wonky with MoBlock, including replaceing my /etc/hosts with the default linux template. Apache didnt like that one. So I want to uninstall it so I can get eveything else going on the server first. I'm still learning linux, and moblock is a bit too much too fast.

Here's the problem... I cant seem to get rid of MoBlock. How do I uninstall it. I tried the basic apt-get remove, but that didnt seem to do much, even with --purge. in fact, I had to manually delete the script in init.d to get it to stop running and slowing things down, but it looks like all the other file remain.

How do I get rid of it?

[jre]

After the blocklist update MoBlock reloads automatically, no further actions necessary.

MoBlock doesn´t do anything with /etc/hosts.

To remove:
sudo aptitude purge moblock blockcontrol mobloquer

Simply removing the init script may produce other problems. If you do such a thing, don´t remove the file, but just rename it (or keep a backup).
If you encounter problems check /var/log/blockcontrol.log and post that here.

[lordratner]

Ok great, that got rid of it.

here's the problem I was having.

I got it all installed and running fine, but once I restarted the computer things were much slower. SSH into the server was at a crawl, with basic functions like logging in or changing directories taking up to 10 or 15 seconds.

I removed moblock, and it stopped.

I really want to use the program, but I'm afraid my newbness will keep me from it...

[jre]

I don´t know why anything should get slower. Either MoBlock blocks a connection completely, or it allows it, but nothing between.
Anyway, to see the blocked packets of MoBlock have a look at /var/log/moblock.log. You can then allow traffic for either some IPs or ports. Have a look at https://help.ubuntu.com/community/MoBlock

[peacewithall]

For anyone experiencing problems with moblock, and also having firestarter installed, I found a solution which helps me. I searched this thread and found no real solution, apart from starting moblock after firewall applications.

The solution is here,
http://henry.sage-vision.com/blog/

Basically it restarts moblock after each start of firestarter.

Edit firestarter.sh:

sudo gedit /etc/firestarter/firestarter.sh

Find the section:

# Start the firewall, enforcing traffic policy
start_firewall () {
lock_firestarter
source /etc/firestarter/firewall 2>&1
retval=$?
if [ $retval -eq 0 ]; then
echo “Firewall started”
else
echo “Firewall not started”
unlock_firestarter
exit $retval
fi
}

Paste this over that section:

# Start the firewall, enforcing traffic policy
start_firewall () {
lock_firestarter
source /etc/firestarter/firewall 2>&1
retval=$?
if [ $retval -eq 0 ]; then
echo “Firewall started”
if [ -x /etc/init.d/blockcontrol ]; then
/etc/init.d/blockcontrol restart
fi
else
echo “Firewall not started”
unlock_firestarter
exit $retval
fi
}

Click SAVE,

DONE.

So all I did was add this to that section (DO NOT add this, its just an example of what was added above), also this can be removed to reverse the changes applied above.

if [ -x /etc/init.d/blockcontrol ]; then
/etc/init.d/blockcontrol restart
fi

Hope this tip helps others too.

[jre]

Quite good, just one remark though:


if [ -x /etc/init.d/blockcontrol ]; then
/etc/init.d/blockcontrol restart
fi



Use this instead:
if [ -x /usr/bin/blockcontrol ] && [ "$(blockcontrol status)" = 0 ]; then
blockcontrol restart
fi

First I take blockcontrol directly - not the init script, which is based on blockcontrol.

More important, I first check if blockcontrol is actually running with "status". So this allows to turn off blockcontrol manually, while with your solution it is always (re-)started by firestarter.

[Jerriy]

Hi there - I have a question. I recently upgraded to Jaunty and (I suspect as a result of that) I get this message scrolling on the screen during boot:* Moblock is not runningDoesn't that mean that Blockcontrol is not starting automatically at system boot (which it should per default)?

[jre]

Yes, it should. INIT="1" must be set (check "blockcontrol show_config | grep INIT" for that. Then check /var/log/blockcontrol.log if the start was attempted (perhaps moblock crashed later).
Also check if "sudo blockcontrol start" works.

[Mariane]

Hi,

There are just 2 ip I wish o block
(google syndication and google analytics, which serve the adds and generate all the "addsense" trash, and doubleclick.net which won the big-brother award).

Google syndication is 64.233.161.99
doubleclick.net is 216.73.93.8

So I have a custom file
/etc/blockcontrol/custom-blocklist.p2p

Where I wrote

64.233.161.99-64.233.161.99
216.73.93.8-216.73.93.8


Mobloquer - Blocklists shows this file and it is set to enabled and local. I removed the others.

Mobloquer - Manage says "Moblock is up and running" but below it says "Number of blocked ip ranges: 0"

And I know it is not working because even on this forum I get the browser message that stuff is transfered between my computer and google-analytics :(.

What should I do, please?

Mariane

[Jerriy]

Yes, it should. INIT="1" must be set (check "blockcontrol show_config | grep INIT" for that. Then check /var/log/blockcontrol.log if the start was attempted (perhaps moblock crashed later).
Also check if "sudo blockcontrol start" works.To me it all seems strange - it seems to work but at the same time it seems to START by not working... then it starts, as you can see it in the log (the greyed out bit at the end is refering to what happened after I followed your instructions in your previous post):2009-08-09 18:47:11 CEST Begin: blockcontrol stop
Stopping blockcontrol.watchdog.
Deleting iptables ...

[74G[ OK ]
Executing /etc/blockcontrol/iptables-custom-remove.sh ...
[74G[ OK ]
Stopping moblock ...
[74G[ OK ]
2009-08-09 18:47:12 CEST End: blockcontrol stop
2009-08-09 18:48:08 CEST Begin: blockcontrol start
Inserting iptables ...
Allowing loopback traffic
[74G[ OK ]

[74G[ OK ]
Executing /etc/blockcontrol/iptables-custom-insert.sh ...
[74G[ OK ]
Starting moblock ...
[74G[ OK ]
Starting blockcontrol.watchdog
[74G[ OK ]
2009-08-09 18:48:09 CEST End: blockcontrol start
Allowing inbound LAN traffic for ###.###.#.## with subnetmask ###.###.###.# ...done.
Allowing outbound LAN traffic for ###.###.#.## with subnetmask ###.###.###.# ...done.
Allowing forwarded LAN traffic for ###.###.#.## with subnetmask ###.###.###.# ...done.
Allowing outbound traffic to DNS server ###.###.#.# ...done.
Allowing forwarded traffic to DNS server ###.###.#.# ...done.
2009-08-09 18:57:10 CEST Begin: blockcontrol stop
Stopping blockcontrol.watchdog.
Deleting iptables ...

[74G[ OK ]
Executing /etc/blockcontrol/iptables-custom-remove.sh ...
[74G[ OK ]
Stopping moblock ...
[74G[ OK ]
2009-08-09 18:57:11 CEST End: blockcontrol stop
2009-08-09 18:58:07 CEST Begin: blockcontrol start
Inserting iptables ...
Allowing loopback traffic
[74G[ OK ]

[74G[ OK ]
Executing /etc/blockcontrol/iptables-custom-insert.sh ...
[74G[ OK ]
Starting moblock ...
[74G[ OK ]
Starting blockcontrol.watchdog
[74G[ OK ]
2009-08-09 18:58:07 CEST End: blockcontrol start
Allowing inbound LAN traffic for ###.###.#.## with subnetmask ###.###.###.# ...done.
Allowing outbound LAN traffic for ###.###.#.## with subnetmask ###.###.###.# ...done.
Allowing forwarded LAN traffic for ###.###.#.## with subnetmask ###.###.###.# ...done.
Allowing outbound traffic to DNS server ###.###.#.# ...done.
Allowing forwarded traffic to DNS server ###.###.#.# ...done.
2009-08-09 08:23:28 PM CEST Begin: blockcontrol start
* moblock is already running, doing nothing.
2009-08-09 08:23:28 PM CEST End: blockcontrol start

[cvaty]

Hi,

There are just 2 ip I wish o block
(google syndication and google analytics, which serve the adds and generate all the "addsense" trash, and doubleclick.net which won the big-brother award).

Google syndication is 64.233.161.99
doubleclick.net is 216.73.93.8

since most likely youve whitelisted http traffic adding these to moblock wont prevent your computer from communicating with port 80 (your browser)

you can use the /etc/hosts file however to ignore them

sudo gedit /etc/hosts


127.0.0.1 64.233.161.99 # bloccks google-syndication
127.0.1.1 216.73.93.8 # blocks double-click.net


you might find this site of interest
http://someonewhocares.org/hosts/

[jre]

So I have a custom file
/etc/blockcontrol/custom-blocklist.p2p

Where I wrote

64.233.161.99-64.233.161.99
216.73.93.8-216.73.93.8



You need a description, otherwise it´s incorrect syntax:

google-syndication:64.233.161.99-64.233.161.99
double-click.net:216.73.93.8-216.73.93.8


But also have a look at cvaty´s post!




@Jerriy: Indeed everything seems to be ok.
I can´t find what´s going wrong. This ought to be the output of the function "status_of_proc". But I just verified that this output should normally not be not shown, because I have "> /dev/null 2>&1".
Still there are some exceptions, but then you should see a message before "Problematic daemon status:".

Anyway, please send me your /lib/lsb/init-functions.
Then try it with the setting LSB="" in /etc/blockcontrol/blockcontrol.conf
I´ll add this to BUGS, for the time being. Please tell me, if this problems gets solved somehow.

[Murimons]

Hello,

I've got a small issue with my moblock.
I'm using Ubuntu 9.04 and i've just started using it a little bit and don't have much linux knowledge.

i edited the moblock.conf file and added some IP adresses to allow OUT.
It worked the whole time but now it blocks a IP that should not be blocked.
I've changed nothing to the moblock.conf.

When i check /etc/init.d/blockcontrol .status, i don't see the allowed IP in there.
So apearently the .conf file allowed IPdoesn't get imported to the iptables or something.
Although some protocols i allowed in the .conf file ARE working and are also listed in the status.

Any idea how i can solve this?

Thanks!

[jre]

You have to edit /etc/blockcontrol/blockcontrol.conf (since half a year there is no more moblock.conf).
Check if the IP really made it to your configuration with "blockcontrol status".
BTW there´s no need for the prefix /etc/init.d.
When the IP is in your configuration you have to "sudo blockcontrol restart".

You may also use the GUI mobloquer.

[dj_flx]

Moblock won't stop anymore - I always get Stopping moblock... ...fail! every time, since the last update.

What's gone wrong?

2009-08-21 18:17:29 EDT Begin: blockcontrol restart

Stopping blockcontrol.wd

[fail]

Deleting iptables ...

iptables v1.3.8: Couldn't load target `blockcontrol_in':/lib/iptables/libipt_blockcontrol_in.so: cannot open shared object file: No such file or directory



Try `iptables -h' or 'iptables --help' for more information.

iptables v1.3.8: Couldn't load target `blockcontrol_out':/lib/iptables/libipt_blockcontrol_out.so: cannot open shared object file: No such file or directory



Try `iptables -h' or 'iptables --help' for more information.

iptables v1.3.8: Couldn't load target `blockcontrol_fw':/lib/iptables/libipt_blockcontrol_fw.so: cannot open shared object file: No such file or directory



Try `iptables -h' or 'iptables --help' for more information.

iptables: No chain/target/match by that name

iptables: No chain/target/match by that name

iptables: No chain/target/match by that name

iptables: No chain/target/match by that name

iptables: No chain/target/match by that name

iptables: No chain/target/match by that name



[fail]

* Don't worry! There occured some errors during the deletion of the iptables

* rules. The most common reason for this is that they did not exist, because

* moblock was not running.

* But if moblock was running there is some problem. Most probably you have

* installed another firewall application that did delete the iptables rules.

* A "blockcontrol restart" will then fix the situation.

Executing /etc/blockcontrol/iptables-custom-remove.sh ...

[ OK ]

Stopping moblock ...

[fail]

* moblock is already running, doing nothing.

2009-08-21 18:17:52 EDT End: blockcontrol restart

[jre]

Please post your "blockcontrol show_config".
Then set LSB="" in /etc/blockcontrol/blockcontrol.conf.
What´s your distribution?

[dj_flx]

blockcontrol current settings:

ACCEPT="1"

ACCEPT_MARK="20"

ALLOW_FW=""

ALLOW_IN="/etc/blockcontrol/allow.p2p"

ALLOW_OUT="/etc/blockcontrol/allow.p2p"

BLOCKLIST_FORMAT="p"

BLOCKLISTS_DIR="/var/spool/blockcontrol"

BLOCKLISTS_LIST="/etc/blockcontrol/blocklists.list"

CONTROL_CONF="/etc/blockcontrol/blockcontrol.conf"

CONTROL_LIB="/usr/lib/blockcontrol/blockcontrol.lib"

CONTROL_LOG="/var/log/blockcontrol.log"

CONTROL_NAME="blockcontrol"

CONTROL_SCRIPT="/usr/bin/blockcontrol"

CRON="1"

CRON_MAILTO="root"

CUSTOM_DAEMON_OPTS=""

DAEMON="/usr/bin/moblock"

DAEMON_LOG="/var/log/moblock.log"

DESC="IP block daemon"

E_BADARGS="2"

E_BLOCKLIST="9"

E_CONFIG="6"

E_IPTABLES="8"

E_NETWORK_DOWN="171"

E_NOTROOT="4"

E_XBIN="5"

E_XCD="66"

E_XEXTERNAL="170"

E_XFILE="7"

INIT="1"

IP_REMOVE=""

IPTABLES_ACTIVATION="1"

IPTABLES_CUSTOM_DIR="/etc/blockcontrol"

IPTABLES_SETTINGS="1"

IPTABLES_TARGET="NFQUEUE"

IPTABLES_TARGET_WHITELISTING="RETURN"

LOG_IPTABLES=""

LOG_SYSLOG="0"

LOG_TIMESTAMP="1"

LSB="/lib/lsb/init-functions"

MASTER_BLOCKLIST_DIR="/var/lib/blockcontrol"

MD5SUM_FILE="/var/spool/blockcontrol/MD5SUM"

NAME="moblock"

NFQUEUE_NUMBER="92"

NICE_LEVEL="5"

PATH="/usr/bin:/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin"

PIDFILE="/var/run/moblock.pid"

REJECT="1"

REJECT_FW="DROP"

REJECT_IN="DROP"

REJECT_MARK="10"

REJECT_OUT="REJECT"

STATFILE="/var/log/MoBlock.stats"

STDIFS=" "

TESTHOST="iblocklist.com"

VERBOSITY="1"

WD="1"

WD_NICE="19"

WD_PATHNAME="/usr/bin/blockcontrol.wd"

WD_PID="/var/run/blockcontrol.wd.pid"

WD_SLEEP="300"

WGET_OPTS="wget -q -t 5 -T 120 -w 5"

WHITE_IP_FORWARD="192.168.0.0/24 1.0.0.0/0"

WHITE_IP_IN=""

WHITE_IP_OUT=""

WHITE_LOCAL="1"

WHITE_TCP_FORWARD="9001 9030 9050"

WHITE_TCP_IN="9001 9030 9050 http https ftp pop3 smtp"

WHITE_TCP_OUT="9001 9030 9050 http https ftp pop3 smtp"

WHITE_UDP_FORWARD=""

WHITE_UDP_IN="2323 9050"

WHITE_UDP_OUT="2323 9050"



Using Debian LSB init-functions: /lib/lsb/init-functions.

Using start-stop-daemon.



The following blocklists are configured to be used:

http://list.iblocklist.com/?list=ijfqtofzixtwayqovmxn

http://list.iblocklist.com/?list=ecqbsykllnadihkdirsh

http://list.iblocklist.com/?list=jcjfaxgyyshvdbceroxf

http://list.iblocklist.com/?list=pfefqteoxlfzopecdtyw

http://list.iblocklist.com/?list=tbnuqfclfkemqivekikv

http://list.iblocklist.com/?list=ewqglwibdgjttwttrinl

http://list.iblocklist.com/?list=bt_level1

http://list.iblocklist.com/?list=bt_level2

http://list.iblocklist.com/?list=bt_level3

http://list.iblocklist.com/?list=bt_edu

http://list.iblocklist.com/?list=bt_ads

http://list.iblocklist.com/?list=bt_bogon

http://list.iblocklist.com/?list=bt_spyware

http://list.iblocklist.com/?list=bt_spider

http://list.iblocklist.com/?list=bt_proxy

http://list.iblocklist.com/?list=bt_hijacked

http://list.iblocklist.com/?list=bt_templist

http://list.iblocklist.com/?list=bt_rangetest

http://list.iblocklist.com/?list=bt_dshield

locallist

/etc/blockcontrol/custom-blocklist.p2p



I'm Xubuntu 8.04 LTS

[dj_flx]

Setting LSB="" seems to have fixed it... and let the update I just checked on work.

What did I just do, exactly?

[jre]

blockcontrol uses those LSB init-functions specified in LSB="..." to start/stop and get the status/pid of blockcontrol/moblock.
If the specified file does not exist, or none is specified, it uses its internal ones - that´s what you just did.

The syntax how to use the init-functions is specified by LSB, and I adhere to it (although some variations are possible). Unfortunately some (older) LSB init-functions don´t implement the specifications correctly. It´s one of the most time-consuming task for me to find out why something doesn´t work on another system, and how to workaround it.

(You don´t have to worry about that, but there are still problems when my internal functions are used on a system without start-stop-daemon in combination with mobloquer. But on your system start-stop-daemon is installed, so you are fine.)

EDIT: I just released a new version only for hardy which has LSB="" as default.

[dj_flx]

OK, thanks!

Though I don't know what to make of this:

W: GPG error: http://moblock-deb.sourceforge.net hardy Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B26B803358712F29

Did I lose something on my end?

[jre]

I´ve got a new key (58712F29) for the repository at moblock-deb.sf.net. My old key expired. Add my new key to your system:
gpg --keyserver wwwkeys.eu.pgp.net --recv 58712F29
gpg --export --armor 58712F29 | sudo apt-key add -

For all: Most people will probably use the launchpad PPA, they do not have to do anything.

[Philip550c]

Moblock won't stop anymore - I always get Stopping moblock... ...fail! every time, since the last update.

What's gone wrong?


I have the same issue on all 5 of my machines, I'm running Intrepid.

[jre]

I have the same issue on all 5 of my machines, I'm running Intrepid.

Have you updated to 1.6.6-1~intrepid? I just noticed yesterday, that this problem affects intrepid, too. So I released that version for hardy and intrepid.

Else, have you tried LSB="" ?

[Philip550c]

Have you updated to 1.6.6-1~intrepid? I just noticed yesterday, that this problem affects intrepid, too. So I released that version for hardy and intrepid.

Else, have you tried LSB="" ?

I have the update. I just modified the LSB="" located here /usr/lib/blockcontrol/blockcontrol.defaults and it worked, at least on my laptop. I'll try the rest when I get home. Thanks. How come it is not like that by default? Do most computers not have this issue? Because I have the problem on 5 very different machines, all intrepid though.

Edit: I have the update on some of the computers, I guess not on my laptop. I'm downloading currently, will see if it changes the LSB and if it messes up or not.

[jre]

The LSB init-functions (package lsb-base) are broken on hardy and intrepid.
Therefore on these systems you have to use the internal init-functions (by setting LSB=""). Exactly this is the change that I made for the newest hardy and intrepid packages (in /usr/lib/blockcontrol/blockcontrol.defaults). When you´ve updated to these, there is no more need to change this manually.

Most people are on other systems than hardy/intrepid, therefore most people had no problems. And since the distribution specific init-functions can be better than my internal ones, I´d like to stay with using these system wide init-functions. In the long run there will be no systems with broken init-functions (like hardy and intrepid), so in the long run, this is a good solution. In the time between it´s just pita - for you and for me.

[Philip550c]

The LSB init-functions (package lsb-base) are broken on hardy and intrepid.
Therefore on these systems you have to use the internal init-functions (by setting LSB=""). Exactly this is the change that I made for the newest hardy and intrepid packages (in /usr/lib/blockcontrol/blockcontrol.defaults). When you´ve updated to these, there is no more need to change this manually.

Most people are on other systems than hardy/intrepid, therefore most people had no problems. And since the distribution specific init-functions can be better than my internal ones, I´d like to stay with using these system wide init-functions. In the long run there will be no systems with broken init-functions (like hardy and intrepid), so in the long run, this is a good solution. In the time between it´s just pita - for you and for me.

Thanks for explaining that to me and thanks for creating moblock, it should come with some of the modified distros (linux mint, etc...).
I like using it much more than peergaurdian for winblows.

[lovinglinux]

I like using it much more than peergaurdian for winblows.

Me too. PeerGuardian always crashed on my system, but I never had a problem with moblock.=D>

[Philip550c]

Me too. PeerGuardian always crashed on my system, but I never had a problem with moblock.=D>

yeah and then you have to do that driver reset crap in the start menu

[lovinglinux]

yeah and then you have to do that driver reset crap in the start menu

Like many other Windows things... :lol:

[linuxology]

Block Control Won't start in 9.04....

Here is a view of my /var/log/blockcontrol.log

Starting moblock ... [ OK ]
Starting blockcontrol.wd ... OK ]
2009-08-28 09:37:12 AM CDT End: blockcontrol restart
sudo blockcontrol status
2009-08-28 09:37:47 AM CDT Begin: blockcontrol start
Problematic daemon status: 1
* moblock is not running

Starting blockcontrol.wd ... O

Can someone please help?

[jre]

(Please rework your original post. You mixed up command line operations, your question and the content of the logfile. Please copy&paste your logfile, but don´t write off its contents. The "O" in the blockcontrol.wd line seems strange.)

Do you have this problem always, also after a fresh reboot? Did it ever work?

status 1 means pidfile exists, but process is dead. So when you get this please check (and post):
ps aux | grep -E "moblock|blockcontrol"
ls -l /var/run/*block*.pid
blockcontrol show_config | grep -i lsb
dpkg -l moblock blockcontrol lsb-base

Then set
LSB=""
in /etc/blockcontrol/blockcontrol.conf and do a "sudo blockcontrol restart"

[linuxology]

test@test-laptop:~$ ps aux | grep -E "moblock|blockcontrol"
root 6553 0.0 0.0 4304 880 ? SN 08:56 0:00 /bin/sh /usr/bin/blockcontrol.wd
test 6579 0.0 0.0 7524 952 pts/0 S+ 08:56 0:00 grep -E moblock|blockcontrol
test@test-laptop:~$ ls -l /var/run/*block*.pid
-rw-r--r-- 1 root root 5 2009-08-29 08:56 /var/run/blockcontrol.wd.pid
-rw-r--r-- 1 root root 5 2009-08-29 08:56 /var/run/moblock.pid
test@test-laptop:~$ blockcontrol show_config | grep -i lsb
LSB=""
Using internal LSB init-functions.
test@test-laptop:~$ dpkg -l moblock blockcontrol lsb-base
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
pi blockcontrol 1.6-1~jaunty Manage IP blockers
ii lsb-base 4.0-0ubuntu0.9 Linux Standard Base 4.0 init script function
ii moblock 0.9~rc2-23~pre An IP blocker for Linux




sudo blockcontrol restart"sudo blockcontrol


This fails

[jre]

sudo blockcontrol restart"sudo blockcontrol

Come on, please take more care in writing your posts. Otherwise I can´t and don´t want to help you.

Anyway, this guy (http://forums.phoenixlabs.org/showthread.php?p=127315) has the same problem. So I just released 1.6.7 which should at least fix a part of the problem. (Removing the pidfile of a crashed daemon on stop). But I still don´t know why the moblock daemon crashed in the first time. So I´d need /var/log/moblock.log

[linuxology]

My apologies for the sloppy last post...... Is the problem OpenDNS?????

Here is more /var/log/moblock.log

more /var/log/moblock.log
Short guarding.p2p line <html>, skipping it...
Short guarding.p2p line <head>, skipping it...
Short guarding.p2p line <title>OpenDNS</title>, skipping it...
Short guarding.p2p line </head>, skipping it...
Short guarding.p2p line <body id="mainbody" onLoad="testforbanner();" st
yle="margin: 0px;">, skipping it...
Short guarding.p2p line <script language="JavaScript">, skipping
it...
Short guarding.p2p line function testforbanner() {, skip
ping it...
Short guarding.p2p line var width;, skipping it.
..
Short guarding.p2p line var height;, skipping it
...
Short guarding.p2p line var x = 0;, skipping it.
..
Short guarding.p2p line var isbanner = false;, s
kipping it...
Short guarding.p2p line var bannersizes = new Ar
ray(16), skipping it...
Short guarding.p2p line bannersizes[0] = '300x25
0';, skipping it...
Short guarding.p2p line bannersizes[1] = '250x25
0';, skipping it...
Short guarding.p2p line bannersizes[2] = '240x40
0';, skipping it...
Short guarding.p2p line bannersizes[3] = '336x28
0';, skipping it...
Short guarding.p2p line bannersizes[4] = '180x15
0';, skipping it...
Short guarding.p2p line bannersizes[5] = '468x60
';, skipping it...
Short guarding.p2p line bannersizes[6] = '234x60
';, skipping it...
Short guarding.p2p line bannersizes[7] = '88x31'
;, skipping it...
Short guarding.p2p line bannersizes[8] = '120x90
';, skipping it...
Short guarding.p2p line bannersizes[9] = '120x60
';, skipping it...
Short guarding.p2p line bannersizes[10] = '120x2
40';, skipping it...
Short guarding.p2p line bannersizes[11] = '125x1
25';, skipping it...
Short guarding.p2p line bannersizes[12] = '728x9
0';, skipping it...
Short guarding.p2p line bannersizes[13] = '160x6
00';, skipping it...
Short guarding.p2p line bannersizes[14] = '120x6
00';, skipping it...
Short guarding.p2p line bannersizes[16] = '300x6
00';, skipping it...
Short guarding.p2p line bannersizes[17] = '300x1
25';, skipping it...
Short guarding.p2p line bannersizes[18] = '530x3
00';, skipping it...
Short guarding.p2p line bannersizes[19] = '190x2
00';, skipping it...
Short guarding.p2p line bannersizes[20] = '470x2
50';, skipping it...
Short guarding.p2p line if(typeof(window.innerHe
ight) == 'number') {, skipping it...
Short guarding.p2p line height = window.
innerHeight;, skipping it...
Short guarding.p2p line width = window.i
nnerWidth;, skipping it...
Short guarding.p2p line } else if(typeof(documen
t.body.offsetHeight) == 'number') {, skipping it...
Short guarding.p2p line height = documen
t.body.offsetHeight;, skipping it...
Short guarding.p2p line width = document
.body.offsetWidth;, skipping it...
Short guarding.p2p line };, skipping it...
Short guarding.p2p line for (x=0; x<bannersizes.
length; x++) {, skipping it...
Short guarding.p2p line if(bannersizes[x
] == width + 'x' + height) {, skipping it...
Short guarding.p2p line isbanner
= true;, skipping it...
Short guarding.p2p line };, skipping it.
..
Short guarding.p2p line };, skipping it...
Short guarding.p2p line if(isbanner || width < 1
00 || height < 100) {, skipping it...


also sudo blockcontrol status
sudo blockcontrol status
Current IPv4 iptables rules (this may take a while):

Chain INPUT (policy ACCEPT 7 packets, 1542 bytes)
pkts bytes target prot opt in out source destination
6 624 blockcontrol_in all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 blockcontrol_fw all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14

Chain OUTPUT (policy ACCEPT 19 packets, 6010 bytes)
pkts bytes target prot opt in out source destination
4 1234 blockcontrol_out all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14

Chain blockcontrol_fw (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa
0 0 RETURN all -- * * 0.0.0.0/0 192.168.1.1
0 0 RETURN all -- * * 192.168.1.0/24 192.168.1.0/24
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Chain blockcontrol_in (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa
0 0 RETURN all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all -- * * 192.168.1.0/24 0.0.0.0/0
6 624 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Chain blockcontrol_out (1 references)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa reject-with icmp-port-unreachable
0 0 RETURN all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all -- * * 0.0.0.0/0 192.168.1.1
0 0 RETURN all -- * * 0.0.0.0/0 192.168.1.0/24
2 131 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
2 1103 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Please check if the above printed iptables rules are correct!

moblock is not running. ... failed!
blockcontrol.wd is running..
PID: 4950 CMD: /bin/sh /usr/bin/blockcontrol.wd

[jre]

(see also http://forums.phoenixlabs.org/showthread.php?p=127417#post127417)

Yes, it´s OpenDNS :-/ This is a known problem. I haven´t looked into it, but I got the same reports from 2 other people (this has nothing to do with any recent update, but is a permanent problem).

Only solution in the short run:
Don´t use OpenDNS + fix (remove) your broken downloads with "sudo blockcontrol force-update"

Sorry, I don´t run OpenDNS, but I´m sure that it´s something wothy to be supported, so I will try to get on that soon ...

[bgiannes]

i have the same problem, can't start blockcontrol anymore?


did a

sudo blockcontrol force-update

but 'she still no go'

notes:
i this machine i'm running desktop 9.04, i only use blockcontrol from time to time, everything worked up to about week ago, now it will not start? I havn't changed anything or install anything new.

[jre]

blockcontrol does not work with OpenDNS. Sorry for that.

So currently there´s only one solution:
1.) Disable OpenDNS
2.) Fix your blockcontrol installation with "force-update"

[Tachions]

Hi I am having a lot of trouble installing Moblock. I have followed all the how to threads to a t and still no luck. The most recent reply I have received is "The following packages are BROKEN:
moblock
The following NEW packages will be installed:
blockcontrol libaudio2{a} libmysqlclient15off{a} libqt4-dbus{a}
libqt4-designer{a} libqt4-network{a} libqt4-qt3support{a}
libqt4-script{a} libqt4-sql{a} libqt4-sql-mysql{a} libqt4-xml{a}
libqtcore4{a} libqtgui4{a} mobloquer mysql-common{a} qt4-qtconfig{a}
0 packages upgraded, 17 newly installed, 0 to remove and 0 not upgraded.
Need to get 11.6MB of archives. After unpacking 37.4MB will be used.
The following packages have unmet dependencies:
moblock: Depends: libnetfilter-queue1 (>= 0.0.15) which is a virtual package.
Depends: libnfnetlink0 (>= 0.0.33) which is a virtual package.
The following actions will resolve these dependencies:

Keep the following packages at their current version:
blockcontrol [Not Installed]
moblock [Not Installed]
mobloquer [Not Installed]

Score is -29743

Accept this solution? [Y/n/q/?] n

*** No more solutions available ***

The following actions will resolve these dependencies:

Keep the following packages at their current version:
blockcontrol [Not Installed]
moblock [Not Installed]
mobloquer [Not Installed]

Score is -29743"


***Please help I am not giving up but just a little frustrated with the whole situation...

I appreciate everyones help and Thanks in advance!!!

[jre]

Do you have the correct entries in /etc/apt/sources.list ?

E.g. if you are running Ubuntu 9.04 jaunty you should have

deb http://ppa.launchpad.net/jre-phoenix/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/jre-phoenix/ppa/ubuntu jaunty main

If you are unsure, check your other entries in /etc/apt/sources.list. They should all contain exactly one, and always exactly the same, of the following distribution names:

hardy
intrepid
jaunty
karmic


Which one of these is it (according to your profile it should be "jaunty)? Or do you run another distribution?


Last, but not least, when you have changed your sources.list, you have to do a
sudo aptitude update
Or better, issue this command in any case, just to be sure :-)

[Relysis]

I'm having another problem with 9.10 karmic. I added the correct sources, and installed blockcontrol, moblock, and mobloquer. I go through the installation dialogue and it finishes without problems. When I run it, however, I get:

Required configuration file "/var/log/moblock.log" could not be found in the default path.
Please specify a different path.

I read another thread about using incompatible versions of blockcontrol and mobloquer, but these were all installed from the karmic jre-pheonix repo. If it helps, I'm using blockcontrol 1.6.9-1~karmic, moblock .9~rc2-23~karmic, and mobloquer .6+svn20090812-1~hardy~karmic.

Thanks for any help, hopefully I just did something stupid.

[jre]

Seems as if mobloquer misses the daemon´s logfile. Probably moblock has never been running, because you disabled the automatic start during installation (which is absolutely ok)!?

In this case you might just create an empty logfile
sudo touch /var/log/moblock.log
or you might start moblock once manually
sudo blockcontrol start
(Don´t worry the first start takes quite long because the blocklists need to be downloaded).

[Relysis]

You're right, I had disabled automatic startup. I started moblock manually, and it made the logfile. Everything works perfectly now.

Thanks for the quick support.

[fulat2k]

Hi folks,

Installed moblock (recompiled from source due to the unbind_pf and bind_pf errors) and blockcontrol packages on Jaunty. The output of blockcontrol status shows that both moblock and blockcontrol are running fine. However, if I do a blockcontrol test, it shows the following:

# blockcontrol test
Testing moblock:

CAUTION: This is just a simple test to check if moblock blocks outgoing
connections. For this, an IP from the blocklist will be pinged. Then the test
checks if this IP appears in the logfile /var/log/moblock.log.

moblock marks packets to be blocked. This means you have to make sure that the
marked packets are also blocked later (with appropriate iptables rules). If you
are using the default configuration and moblock is started after other firewalls
this will be the case.

This test does not check if you have sane iptables rules or if your complete
blocklist is in the correct format. Therefore success doesn't imply that
everything is working as you expect it.

Also have a look at "blockcontrol status" and test manually with traceroute.

Trying to ping 4.17.193.127 from /var/lib/blockcontrol/guarding.p2p ...
moblock did not mark the IP to be blocked.
Was moblock already loaded completely? Wait some minutes and try again.

4.17.193.127 did not answer.

Maybe 4.17.193.127 is down/doesn't answer to pings
(this would still mean that moblock is not working)
or your firewall filtered the ping before moblock could check it
(then moblock may be working as desired, check your iptables rules).

Any idea if moblock is working correctly?


Thanks.

[jre]

You don't need to recompile. The jaunty packages are already patched.

First, as it is written in the message:
Was moblock already loaded completely? Wait some minutes and try again.

Then have a look at /var/log/moblock.log, and see if the IP is there. Perhaps logging took longer then the test (so that the test erroneously thought that there was nothing in the logfile.)

Then, third possibility:
your firewall filtered the ping before moblock could check it
(then moblock may be working as desired, check your iptables rules).
Paste your iptables (firewall) rules, so that I can check them. You get them with "sudo iptables -L -nv"

[fulat2k]

The Jaunty package doesn't seem to be patched when nfq_bind_pf is called. I only see the exit(-1) line commented out in the nfq_unbind_pf call. I've re-installed the moblock and blockcontrol packages from the repo and this is what I get from /var/log/moblock.log:

Mon Nov 30 02:31:07| error during nfq_unbind_pf()
Mon Nov 30 02:31:07| Error during nfq_bind_pf()

Doing a blockcontrol status yields the following (output summarized):

# blockcontrol status
Current IPv4 iptables rules (this may take a while):

Chain INPUT (policy ACCEPT 5335 packets, 6618K bytes)
pkts bytes target prot opt in out source destination
87 13186 blockcontrol_in all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 blockcontrol_fw all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14

Chain OUTPUT (policy ACCEPT 3209 packets, 293K bytes)
pkts bytes target prot opt in out source destination
0 0 blockcontrol_out all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14

[...]

* moblock is not running
* blockcontrol.wd is running
PID: 3744 CMD: /bin/sh /usr/bin/blockcontrol.wd

[chinaski]

Hi I noticed that if I start blockocntrol even without launching any p2p software I get some OUT connections blocked

Mon Nov 30 15:03:43| OUT: Telenet Operaties N.V.,hits: 1,DST: 84.198.112.144
Mon Nov 30 15:03:43| OUT: CHINANET fujian province network,hits: 1,DST: 59.57.229.179
Mon Nov 30 15:03:43| OUT: SC ROMPLUS COMPUTER CENTER SRL,hits: 1,DST: 89.41.77.179
Mon Nov 30 15:03:43| OUT: TeliaSonera AB,hits: 1,DST: 90.230.59.188
Mon Nov 30 15:03:43| OUT: TeliaSonera AB,hits: 1,DST: 217.210.178.78
Mon Nov 30 15:03:44| OUT: TeliaSonera AB,hits: 2,DST: 90.230.59.188
Mon Nov 30 15:03:44| OUT: SC ROMPLUS COMPUTER CENTER SRL,hits: 2,DST: 89.41.77.179
Mon Nov 30 15:03:45| OUT: Telenet Operaties N.V.,hits: 2,DST: 84.198.112.144
Mon Nov 30 15:03:45| OUT: CHINANET fujian province network,hits: 2,DST: 59.57.229.179
Mon Nov 30 15:03:45| OUT: SC ROMPLUS COMPUTER CENTER SRL,hits: 3,DST: 89.41.77.179
Mon Nov 30 15:03:45| OUT: TeliaSonera AB,hits: 3,DST: 90.230.59.188
Mon Nov 30 15:03:45| OUT: TeliaSonera AB,hits: 2,DST: 217.210.178.78
Mon Nov 30 15:03:46| OUT: TeliaSonera AB,hits: 4,DST: 90.230.59.188
Mon Nov 30 15:03:46| OUT: SC ROMPLUS COMPUTER CENTER SRL,hits: 4,DST: 89.41.77.179
Mon Nov 30 15:03:49| OUT: Telenet Operaties N.V.,hits: 3,DST: 84.198.112.144
Mon Nov 30 15:03:49| OUT: CHINANET fujian province network,hits: 3,DST: 59.57.229.179
Mon Nov 30 15:03:49| OUT: SC ROMPLUS COMPUTER CENTER SRL,hits: 5,DST: 89.41.77.179
Mon Nov 30 15:03:49| OUT: TeliaSonera AB,hits: 5,DST: 90.230.59.188
Mon Nov 30 15:03:49| OUT: TeliaSonera AB,hits: 3,DST: 217.210.178.78
Mon Nov 30 15:03:50| OUT: TeliaSonera AB,hits: 6,DST: 90.230.59.188
Mon Nov 30 15:03:50| OUT: SC ROMPLUS COMPUTER CENTER SRL,hits: 6,DST: 89.41.77.179
Mon Nov 30 15:03:54| OUT: University of Connecticut,hits: 1,DST: 137.99.87.242
Mon Nov 30 15:03:56| OUT: University of Connecticut,hits: 2,DST: 137.99.87.242
Mon Nov 30 15:03:59| OUT: Kearney State College,hits: 1,DST: 144.216.42.177
Mon Nov 30 15:04:00| OUT: University of Connecticut,hits: 3,DST: 137.99.87.242
Mon Nov 30 15:04:01| OUT: Kearney State College,hits: 2,DST: 144.216.42.177
Mon Nov 30 15:04:05| OUT: Kearney State College,hits: 3,DST: 144.216.42.177
Mon Nov 30 15:04:38| OUT: Tiscali SpA,hits: 1,DST: 94.38.7.109
Mon Nov 30 15:04:40| OUT: Tiscali SpA,hits: 2,DST: 94.38.7.109
Mon Nov 30 15:04:44| OUT: Tiscali SpA,hits: 3,DST: 94.38.7.109
Mon Nov 30 15:05:28| OUT: Tiscali SpA,hits: 4,DST: 94.38.7.109
Mon Nov 30 15:05:30| OUT: Tiscali SpA,hits: 5,DST: 94.38.7.109
Mon Nov 30 15:05:34| OUT: Tiscali SpA,hits: 6,DST: 94.38.7.109
Mon Nov 30 15:08:19| OUT: Northern Arizona University,hits: 1,DST: 134.114.231.17
Mon Nov 30 15:08:21| OUT: Northern Arizona University,hits: 2,DST: 134.114.231.17
Mon Nov 30 15:08:25| OUT: Northern Arizona University,hits: 3,DST: 134.114.231.17
Mon Nov 30 15:11:32| OUT: Politecnico di Torino,hits: 1,DST: 130.192.29.116
Mon Nov 30 15:11:34| OUT: Politecnico di Torino,hits: 2,DST: 130.192.29.116
Mon Nov 30 15:11:38| OUT: Politecnico di Torino,hits: 3,DST: 130.192.29.116
Mon Nov 30 15:14:54| OUT: Tiscali SpA,hits: 7,DST: 94.38.7.109
Mon Nov 30 15:14:56| OUT: Tiscali SpA,hits: 8,DST: 94.38.7.109
Mon Nov 30 15:15:00| OUT: Tiscali SpA,hits: 9,DST: 94.38.7.109
Mon Nov 30 15:15:44| OUT: Tiscali SpA,hits: 10,DST: 94.38.7.109
Mon Nov 30 15:15:46| OUT: Tiscali SpA,hits: 11,DST: 94.38.7.109
Mon Nov 30 15:15:50| OUT: Tiscali SpA,hits: 12,DST: 94.38.7.109btw my Internet provider is not even Tiscali...

is this normal or should I worry?

[jre]

The Jaunty package doesn't seem to be patched when nfq_bind_pf is called. I only see the exit(-1) line commented out in the nfq_unbind_pf call.

(I guess) you are talking about this bug:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=12156&group_id=2509
The fix for this was indeed to comment exit(-1). Nothing more is necessary. And this was done in upstream moblock 0.9rc2, so every package has this.

I can't remember that there was any other similar bug, do you know of any concrete other necessary patch?


What happens when you install moblock from source (which source? I guess the source from my repository (either moblock-deb.sf.net or the Ubuntu PPA)? Do you get a running "status" then? So that your only problem is "test".
This would indeed hint to the fact that something is wrong with the binary package. But again, this is quite strange since not anybody else reported this problem, and I made no changes to the moblock packages in the past months.


One thing that often helpds when you have problems with binding to NFQUEUE is to reboot. This is true, especially when you tried other applications (e.g. nfblock, iplist or pgl in the meantime).


BTW, I just uploaded a new jaunty package. But this was just to get the version number in sync. However, if there really was something stupid wrong with the old binary package, this should be solved now,


@chinaski:
On computers there are tons of connections happening, so you probably don't have to worry. You definitely don't have to worry about these concrete connections, since they were blocked.
But if you are really interested in what is happening you have to look at these packages with a package sniffer (wireshark).
An easier solution may be to look first at the port, that the packets were sent, too. In order to do this, set in /etc/blockcontrol/blockcontrol.conf:
LOG_IPTABLES="LOG --log-level info"
do a "blockcontrol restart" and then check /var/log/syslog

[fulat2k]

I purged the previous moblock and blockcontrol installations and have installed the new package from your repo (0.9~rc2-23+jaunty). moblock still dies upon startup. I get the same error lines like above:

Tue Dec 1 18:55:03| error during nfq_unbind_pf()
Tue Dec 1 18:55:03| Error during nfq_bind_pf()

I see the process starting itself up, but dies after it loads the blocklist. This is a fresh installation of Jaunty. I haven't installed any other apps you mentioned in your previous post. Here's what I get from blockcontrol status:

* moblock is not running
* blockcontrol.wd is running
PID: 3996 CMD: /bin/sh /usr/bin/blockcontrol.wd

[chinaski]

@ jre: thanks a lot for your kind, clear and professional reply. as usual ;)

cheers,
Cris

[jre]

@fulat2k:
But when you compile from source at least "status" says, that moblock is running (as you said in post #370). Right!?

Do you run a custom kernel? Some modules might be missing. The following command should show all relevant modules, please post yours:
$ lsmod | grep -E "^x|^nf|^ip" | grep -Ev "^ip6|^ipv6"| sort
iptable_filter 3776 1
ip_tables 17392 1 iptable_filter
ipt_REJECT 3248 1
nf_conntrack 70192 2 nf_conntrack_ipv4,xt_state
nf_conntrack_ipv4 15240 3
nf_defrag_ipv4 2288 1 nf_conntrack_ipv4
nfnetlink 5608 2 nfnetlink_queue
nfnetlink_queue 9076 1
x_tables 22440 10 ip6t_REJECT,ip6_tables,ipt_REJECT,xt_tcpudp,xt_ipr ange,xt_state,xt_mark,xt_NFQUEUE,xt_multiport,ip_t ables
xt_iprange 2640 23
xt_mark 2432 6
xt_multiport 3216 11
xt_NFQUEUE 2112 3
xt_state 2400 3
xt_tcpudp 3328 17


@chinaski: thanks

[fulat2k]

When I compiled from source earlier, I commented the exit(-1) call when nfq_bind_pf() is called. Hence moblock process didn't quit. I think I kinda know what's going on. I re-installed Jaunty and this is my output from lsmod:

# lsmod
Module Size Used by

Yup, nothing there :) Any pointers on what modules to install prior to installing moblock? The guide at https://help.ubuntu.com/community/MoBlock doesn't specify kernel modules :(


Thanks!

[jre]

Any pointers on what modules to install prior to installing moblock?

Yes, my last post :-) All modules mentioned that are shown there, should be available. You can either compile them directly in the kernel, or add them as modules (that still requires to recompile your kernel). Check your /boot/config-[kernel_version] to see what your current configuration is.

So did you install a custom kernel?

It is strange that you got no error message: pglcmd normally first looks, if the necessary modules are already loaded (or compiled in the kernel), if not it tries to load them, and if this fails, it exits. But in this case you should find an error message in /var/log/blockcontrol.log

[prem1er]

Will the peer guardian linux version work on 64 bit machines?

[fulat2k]

Yes, my last post :-) All modules mentioned that are shown there, should be available. You can either compile them directly in the kernel, or add them as modules (that still requires to recompile your kernel). Check your /boot/config-[kernel_version] to see what your current configuration is.

So did you install a custom kernel?

It is strange that you got no error message: pglcmd normally first looks, if the necessary modules are already loaded (or compiled in the kernel), if not it tries to load them, and if this fails, it exits. But in this case you should find an error message in /var/log/blockcontrol.log

Thanks for your help :) Installed the default kernel and everything worked as expected. Phew...

[jre]

Will the peer guardian linux version work on 64 bit machines?

Yes. I am running amd64 kernel, so this will definitely be the case.

Thanks for your help :) Installed the default kernel and everything worked as expected. Phew...

Glad to hear that. So now I am sure that your kernel missed some necessary stuff. But it sounds if blockcontrol did not catch this, so there is a bug in blockcontrol. The correct behaviour would have been to exit with a clean error message.
It would be a great help for me, if you checked your logfiles. Or you can send your /var/log/moblock.log and /var/log/blockcontrol.log of those days (they are rotated daily, so e.g. the moblock.log of three days ago is called moblock.log.3.gz). You can post them here or send them per mail to jre-phoenix@users.sourceforge.net

[fulat2k]

I only have moblock.log. There doesn't seem to be a blockcontrol.log in /var/log. Do you still want it? Somehow it's not rotated. It's one big 108MB file :) I'm trying to see if there's a timestamp.

BTW, is it possible to specify a network interface where moblock operates on? My new server has 4 IPs I can use; and I only need it to listen to just one.

Thanks.

[jre]

I only have moblock.log. There doesn't seem to be a blockcontrol.log in /var/log. Do you still want it? Somehow it's not rotated. It's one big 108MB file :) I'm trying to see if there's a timestamp.

Err, strange. What do you get on
blockcontrol show_config | grep CONTROL_LOG?
I think moblock.log will not be that helpful as blockcontrol.log, but you can still send it to my email address. But I don't know whether googlemail will block it. Don't pack it - googlemail is so clever to assume packed files might be viruses, and therefore bounces all mails with packed attachments!


BTW, is it possible to specify a network interface where moblock operates on? My new server has 4 IPs I can use; and I only need it to listen to just one.

I just added this to the FAQ: https://help.ubuntu.com/community/MoBlock#Is%20it%20possible%20to%20specify%20a%20ne twork%20interface%20where%20moblock%20operates%20o n

[fulat2k]

Oops, my bad. /var/log/blockcontrol.log is there. Just that the log is very recent; and I doubt it'll help you. I'll send it to you anyway.

Thanks for adding the scripts in the Wiki. Works like a charm :)

[jre]

Oops, my bad. /var/log/blockcontrol.log is there. Just that the log is very recent; and I doubt it'll help you. I'll send it to you anyway.
Haven't received anything. Probably it's just too big. Anyway...

Thanks for adding the scripts in the Wiki. Works like a charm :)

I gave a wrong command for iptables removal: you have to use iptables -D instead of iptables -X

[questioner1]

Hi

moblock/blockcontrol seems to work well here on karmic/amd64.

But it blocks too much. Especially frustrating is this entry:
OUT: ETH/UNIZH Camp Net,hits: 2,DST: 129.132.2.217



Why is this blocked? I can't login to my IMAP email at this university (ETH, Switzerland).

And more importantly:


How can I unblock it without having to stop the whole blockcontrol deamon?

And another important aspect:


How can I let blockcontrol only work on connections that are going out/in from a specific application, namely ktorrent?


Best regards and thank you for your appreciation

questioner1

[jre]

Please note the links in this post to the Moblock wiki here. Basically this should answer all your questions. Suggestions are always welcome.

OUT: ETH/UNIZH Camp Net,hits: 2,DST: 129.132.2.217
Why is this blocked?
Depends on your selection of lists. Try
blockcontrol search ETH/UNIZH (https://help.ubuntu.com/community/MoBlock#How%20do%20I%20choose%20what%20blocklists% 20to%20use?)
and then read /usr/share/doc/blockcontrol/README.blocklists.gz

How can I unblock it without having to stop the whole blockcontrol deamon?
Since it is only one IP I recommend you use WHITE_IP_OUT (https://help.ubuntu.com/community/MoBlock#How%20can%20I%20allow%20(whitelist)%20traf fic%20to%20certain%20IPs?).
Alternatively you might open the whole IMAP port (https://help.ubuntu.com/community/MoBlock#How%20can%20I%20allow%20(whitelist)%20traf fic%20on%20certain%20ports?).

When you have changed these settings, you have to restart blockcontrol once.
Alternatively you might directly issue the "sudo iptables ...." command, but I doubt that you want to do that (it would be only necessary if you want to never ever ever stop blockcontrol)

How can I let blockcontrol only work on connections that are going out/in from a specific application, namely ktorrent?
If your kernel supports it (and I doubt that) you can add a per-application whitelisting (https://help.ubuntu.com/community/MoBlock#How%20can%20I%20allow%20%28whitelist%29%20 traffic%20for%20a%20combination%20of%20IPs,%20port s,%20or%20applications?). Note that this is only possible for outgoing connections. See /usr/share/doc/blockcontrol/examples/iptables-custom-insert.sh. For incoming connections you might whitelist all other ports except the one, where ktorrent is listening on. But incoming connections hardly are relevant on a desktop machine.

If you really just want to check one application (and don't want your whole machine protected by a "stealth" mode, and don't care about the other features (e.g. blocklist management), then you should just use such an applications internal blocklist feature. I don't know whether ktorrent has this. At least other torrent apps do.

[johanholmquist]

Hello! I'm currently in the learning process of configuring a linux server, and quite recently I ran into my first "unsolvable" problem when I tried to get moblock working. So, from the beginning:

I'm having issues getting moblock to run on my Ubuntu 9.10 Server. IPTables is installed and working as it should. (And fail2ban is installed as well - I thought it seemed quite useful. I believe its modifications to the iptables shouldn't affect moblock, which may very well be a faulty assumption on my part.)

I haven't tried installing mobloquer since I don't have X installed on the server, and I would prefer to keep it that way.

I added the repo with the following command:
# sudo add-apt-repository ppa:jre-phoenix

That effectively added the following to /etc/apt/sources.list.d/jre-phoenix-ppa-karmic.list :
deb http://ppa.launchpad.net/jre-phoenix/ppa/ubuntu karmic main

When installing moblock and blockcontrol using
# sudo aptitude update
followed by
# sudo aptitude install moblock blockcontrol
I entered my desired whitelisted TCP and UDP ports.
A total of 15 TCP ports are to be whitelisted both in and out, including a range that I know counts as two entries. So, 13 specific ports and 1 range is to be TCP whitelisted.
Only 2 separate UDP ports are to be whitelisted.
No forwarded ports whitelisted.
I choose the option that whitelists DNS and loopback devices but not LAN. (I can't remember exactly what it says, even though I've reinstalled everything quite a few times. ;))

So far so good, moblock most likely started downloading its lists and everything seemed fine. No error messages were shown at this stage; the installation was "successful".

Then, if I type
# sudo blockcontrol status
I get a list of my IPTables rules, followed by this:
* moblock is not running
* blockcontrol.wd is running
PID: 27770 CMD: /bin/sh /usr/bin/blockcontrol.wd

Also,
# sudo blockcontrol test
yields the following result:
Trying to ping 4.18.0.255 from /var/lib/blockcontrol/guarding.p2p ...
moblock did not mark the IP to be blocked.
Was moblock already loaded completely? Wait some minutes and try again.

4.18.0.255 did not answer.

Maybe 4.18.0.255 is down/doesn't answer to pings
(this would still mean that moblock is not working)
or your firewall filtered the ping before moblock could check it
(then moblock may be working as desired, check your iptables rules).

Using the following commands several times had no effect on the above errors:
# sudo blockcontrol start
# sudo blockcontrol stop
# sudo blockcontrol restart
# sudo blockcontrol rebuild
# sudo blockcontrol update

It seemed to me that moblock consistently failed to start properly, and for some reason blockcontrol still thought that it did during starts/restarts. So, I went to have a look at /var/log/moblock.log which says:
* Ranges loaded: 580868
Sun Mar 28 17:31:32| * Merged ranges: 10229
Sun Mar 28 17:31:32| * Skipped useless ranges: 1887
Sun Mar 28 17:31:32| error during nfq_unbind_pf()
Sun Mar 28 17:31:32| Error during nfq_bind_pf()

I started googling the two errors without finding any real useful results. An old gentoo forum thread (http://bugs.gentoo.org/show_bug.cgi?id=143535) with an old entry read the following:
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

So, I had a look in aptitude and installed some packages that matched the above names: "libnetfilter-queue-dev", "libnfnetlink-dev", "nfqueue-bindings-perl" and maybe a few dependencies of lesser importance.

moblock still refused to start, so I reinstalled it again and again and again (even tried whitelisting fewer ports etc.) with no success. That's where I am now; I really feel like I'm fumbling in the dark on this one.

Could my iptables rules be the cause of moblock's failed start? They look fine to me, but I'm very much not an iptables guru. Here's my output of "iptables -L":

Chain INPUT (policy DROP)
target prot opt source destination
fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh
DROP tcp -- anywhere 127.0.0.0/8
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
DROP all -- BASE-ADDRESS.MCAST.NET/4 anywhere
PUB_IN all -- anywhere anywhere
PUB_IN all -- anywhere anywhere
PUB_IN all -- anywhere anywhere
PUB_IN all -- anywhere anywhere
DROP all -- anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
DROP all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
PUB_OUT all -- anywhere anywhere
PUB_OUT all -- anywhere anywhere
PUB_OUT all -- anywhere anywhere
PUB_OUT all -- anywhere anywhere

Chain INT_IN (0 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere
DROP all -- anywhere anywhere

Chain INT_OUT (0 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere

Chain PAROLE (14 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain PUB_IN (4 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere icmp echo-reply
ACCEPT icmp -- anywhere anywhere icmp time-exceeded
ACCEPT icmp -- anywhere anywhere icmp echo-request
PAROLE tcp -- anywhere anywhere tcp dpt:ftp-data
PAROLE tcp -- anywhere anywhere tcp dpt:ftp
PAROLE tcp -- anywhere anywhere tcp dpt:ssh
PAROLE tcp -- anywhere anywhere tcp dpt:smtp
PAROLE tcp -- anywhere anywhere tcp dpt:domain
PAROLE tcp -- anywhere anywhere tcp dpt:www
PAROLE tcp -- anywhere anywhere tcp dpt:pop3
PAROLE tcp -- anywhere anywhere tcp dpt:imap2
PAROLE tcp -- anywhere anywhere tcp dpt:https
PAROLE tcp -- anywhere anywhere tcp dpt:mysql
PAROLE tcp -- anywhere anywhere tcp dpt:http-alt
PAROLE tcp -- anywhere anywhere tcp dpt:webmin
PAROLE tcp -- anywhere anywhere tcp dpt:59638
PAROLE tcp -- anywhere anywhere tcp dpts:59681:59770
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:mysql
DROP icmp -- anywhere anywhere
DROP all -- anywhere anywhere

Chain PUB_OUT (4 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain fail2ban-ssh (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere

I would greatly appreciate any help I can get on this... Or any explanation as to why moblock won't start properly. Thanks in advance! :)

Edit: I forgot the list from "sudo blockcontrol status" (edited out my DNS IPs...):
Current IPv4 iptables rules (this may take a while):

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
9 2343 blockcontrol_in all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14
8 396 fail2ban-ssh tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22
0 0 DROP tcp -- !lo * 0.0.0.0/0 127.0.0.0/8
2201K 1924M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
31446 1887K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- * * 224.0.0.0/4 0.0.0.0/0
186K 50M PUB_IN all -- eth+ * 0.0.0.0/0 0.0.0.0/0
0 0 PUB_IN all -- ppp+ * 0.0.0.0/0 0.0.0.0/0
0 0 PUB_IN all -- slip+ * 0.0.0.0/0 0.0.0.0/0
0 0 PUB_IN all -- venet+ * 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 blockcontrol_fw all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 811K packets, 127M bytes)
pkts bytes target prot opt in out source destination
0 0 blockcontrol_out all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14
1250K 323M PUB_OUT all -- * eth+ 0.0.0.0/0 0.0.0.0/0
0 0 PUB_OUT all -- * ppp+ 0.0.0.0/0 0.0.0.0/0
0 0 PUB_OUT all -- * slip+ 0.0.0.0/0 0.0.0.0/0
0 0 PUB_OUT all -- * venet+ 0.0.0.0/0 0.0.0.0/0

Chain INT_IN (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain INT_OUT (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Chain PAROLE (14 references)
pkts bytes target prot opt in out source destination
9609 456K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Chain PUB_IN (4 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
65 4085 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
1 64 PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20
61 3172 PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
36 1792 PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
7047 322K PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
0 0 PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
2056 108K PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
0 0 PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
9 380 PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
1 40 PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
330 16672 PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
3 156 PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000
11 548 PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:59638
54 2808 PAROLE tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:59681:59770
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3306
0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0
177K 49M DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain PUB_OUT (4 references)
pkts bytes target prot opt in out source destination
1250K 323M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Chain blockcontrol_fw (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa
0 0 RETURN all -- * * 0.0.0.0/0 {DNS server 1}
0 0 RETURN all -- * * 0.0.0.0/0 {DNS server 2}
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Chain blockcontrol_in (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa
0 0 RETURN all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3306
0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:59681:59770
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:59638
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20
9 2343 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Chain blockcontrol_out (1 references)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa reject-with icmp-port -unreachable
0 0 RETURN all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all -- * * 0.0.0.0/0 {DNS server 1}
0 0 RETURN all -- * * 0.0.0.0/0 {DNS server 2}
0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5506
0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:59681:59770
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:59638
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Chain fail2ban-ssh (1 references)
pkts bytes target prot opt in out source destination
8 396 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0

Please check if the above printed iptables rules are correct!

* moblock is not running
* blockcontrol.wd is running
PID: 27770 CMD: /bin/sh /usr/bin/blockcontrol.wd


To me this looks like it should work... It depends what is meant by "before" in post #1 of this thread. :)

[jre]

moblock works fine with fail2ban. Also your other iptables rules should not be the culprit. Further there's no need to install additional packages (as "libnetfilter-queue-dev", "libnfnetlink-dev", "nfqueue-bindings-perl"). This is the part I'm sure about ;-)

I've seen that problem before. I think it was either something about a broken libnetfilter installation OR missing kernel modules. I'll check that and post again when I found that...

In the mean time please post the output of
lsmod|grep -E "^x|^nf|^ip"|grep -Ev "^ip6|^ipv6"|sed "s| .*||"|sort
This gives a list of all relevant kernel modules. Here I get
iptable_filter
ip_tables
ipt_REJECT
nf_conntrack
nf_conntrack_ipv4
nf_defrag_ipv4
nfnetlink
nfnetlink_queue
x_tables
xt_iprange
xt_mark
xt_multiport
xt_NFQUEUE
xt_state
xt_tcpudp

[johanholmquist]

lsmod returns absolutely nothing, no matter what I try... :-s
the lsmod --help isn't very useful either: "Usage: lsmod". ;)

I had a look around and found some old forum with someone that had the same problem. Just like that guy, my output from # modprobe ls is something like kernel/drivers/scsi/scsi_wait_scan.ko and nothing more.

Is it likely that recompiling the kernel will make lsmod work? Recompiling the kernel seems quite time-consuming, and judging by the manuals I'm sure it's not the easiest thing to do for a rookie... It's quite likely that I would end up with something else not working as it should. ^^ Is it my only way out? :-s

[jre]

"lsmod" is a command to list the loaded kernel modules. So it doesn't do anything special, but just gives you information. You definitely should get some output if you just type lsmod. So please post the output of this pure "lsmod". The rest of my last command just filters the complete output to the relevant parts. Since you got no results there, I guess we are on the right way, since this indicates that the modules are not loaded.

Please try to manually load the relevant kernel module NFQUEUE. Chances are high that this doesn't happen automatically for some strange reasons on your side. So do sudo modprobe xt_NFQUEUE
echo $?. The second command will only work if it is issued as next command after the first. It will give "0" if the modprobe command was successful and another number otherwise. In doubt you may modprobe also all other modules that I listed in my last post. After doing that you may try the "lsmod" again.

For more information you might also send me some contents of the configuration file of your current kernel. Figure out the name of that file with ls /boot/config-"$(uname -r)". E.g. here the actual file is called /boot/config-2.6.32-4-amd64. Then open that file in an editor and search for the passages
# Networking options
and
# Core Netfilter Configuration
and post its content here.

Finally please have a look at /var/log/blockcontrol.log to see whether there is something related to kernel modules.

[johanholmquist]

(johan@server)-(~) $ lsmod
Module Size Used by


That's all I get from lsmod. :/ Doesn't matter if I sudo lsmod either, still no real output.

(johan@server)-(~) $ sudo modprobe xt_NFQUEUE
FATAL: Module xt_NFQUEUE not found.
(johan@server)-(~) $ echo $?
1

(johan@server)-(~) $ ls /boot/config-"$(uname -r)"
ls: cannot access /boot/config-2.6.32.8: No such file or directory

This seemed quite strange.. I don't have a configuration file? Here are the contents of /boot:
(johan@server)-(~) $ cd /boot
(johan@server)-(/boot) $ ls -a
. .. System.map boot.0800 bzImage coffee.bmp debian.bmp debianlilo.bmp map sarge.bmp sid.bmp

Could it be RKhunter that hides it for some reason?

The path /lib/modules/2.6.32.8/kernel/ contains only one folder; /lib/modules/2.6.32.8/kernel/drivers. The only thing in that folder is another folder named "scsi", which contains the file "scsi_wait_scan.ko". It corresponds to writing the following:
(johan@server)-(/lib/modules/2.6.32.8/kernel/drivers/scsi) $ modprobe -ls
kernel/drivers/scsi/scsi_wait_scan.ko

It sure looks like I have only one (1) kernel module. A module that doesn't seem to be loaded.

Here's what I get in blockcontrol.log, repeating itself every 5 minutes:
2010-03-29 14:45:14 CEST Begin: blockcontrol restart
Stopping blockcontrol.wd ...done.
Deleting iptables ...
...done.
Stopping moblock ... ...done.
Inserting iptables ...
Allowing outbound traffic to DNS server XXX.XXX.XX.X ...done.
Allowing forwarded traffic to DNS server XXX.XXX.XX.X ...done.
Allowing outbound traffic to DNS server YYY.YYY.YY.Y ...done.
Allowing forwarded traffic to DNS server YYY.YYY.YY.Y ...done.
Allowing loopback traffic ...done.
...done.
Starting moblock ... ...done.
Starting blockcontrol.wd ... ...done.
2010-03-29 14:45:14 CEST End: blockcontrol restart


Like I said, exactly 5 minutes later, it does a new blockcontrol restart (2010-03-29 14:50:14 CEST Begin: blockcontrol restart).

Anyway, I guess the real problem is the (lack of) kernel modules and config. Does that mean my iptables are ignored by the kernel as well?

[jre]

I can't find kernel 2.6.32.8 - neither in Karmic (Ubuntu 9.10) nor in lucid (10.04). So where did you get your kernel from? Have you tried the official kernel from the repository?

BTW, the /boot/config-... file is only there for informational use. It tells with which options your kernel was compiled.

From the description of RKHunter I doubt that it hides any files, or is in any other way responsible for your problems. I think RKHunter just checks your system and reports problems, but doesn't actually do anything.

[johanholmquist]

I've come to the conclusion that my dedicated server provider installs a custom kernel on their dedicated servers. This means I might have to compile my own "vanilla" kernel, using the config they provide in /usr/src as a base. (Apparently some of their mainboards have some sort of issues with AHCI (S-ATA) drivers included in kernels <=2.6.22 ... I think. There has to be some reason they don't use the standard kernel.)

I guess I could try installing a package from aptitude first, since the latest kernel is something like 2.6.31? Would you recommend "linux-386" or "linux-server"? Should I also install additional packages to ensure all the necessary moblock modules are included, like "linux-backports-modules-karmic"?
Will the installation "linux-server" change which kernel is used automatically, or do I have to change that somewhere?

I'm a complete newbie when it comes to these kernel-related things, I just install linux and assume everything works "automagically". Haven't run into any kernel problems at all when I've installed ubuntu and ubuntu server on several PCs here at home, but my server provider obviously installs a custom kernel on "clean" installs.

Thank you so much for all the help so far! :)

[jre]

Do you have physical access to your server? In that case you can simply try a kernel from the Ubuntu repository. I'm running Debian and am not familiar with Ubuntu's kernel flavors. But I think I'd first try linux-server before linux-386.

EDIT: I doubt that you need to install additional packages!

Without physical access you can't choose which kernel will be booted on boot time in the grub boot. Instead you have to do this before booting in the grub config file (instructions how to do that are on the web).
So then you have the risk of preselecting an unbootable kernel, which would require physical access in order to select a bootable kernel again.

So in this case I would omit the step of installing a kernel from the repository, and choose to directly compile your provider's kernel. I've done that myself years ago in my linux beginners time and found it is not too hard. Just follow official instructions (preferably those of your provider, or ask your provider directly for help, otherwise Ubuntu's). Then keep all configuration settings as they are, and simply add the netfilter support as modules. In the end your configuration file should have something like this, especially the bold lines are important:
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
# CONFIG_DEFAULT_BIC is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_IPV6_OPTIMISTIC_DAD=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=y
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_SIT=m
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y
CONFIG_IPV6_MROUTE=y
CONFIG_IPV6_PIMSM_V2=y
# CONFIG_NETLABEL is not set
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_DCCP=m
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=m
CONFIG_NF_CT_PROTO_UDPLITE=m
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_PPTP=m
CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
CONFIG_NETFILTER_TPROXY=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_HL=m
CONFIG_NETFILTER_XT_TARGET_LED=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
CONFIG_NETFILTER_XT_MATCH_CLUSTER=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_HL=m
CONFIG_NETFILTER_XT_MATCH_IPRANGE=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_OWNER=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_RATEEST=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_RECENT=m
# CONFIG_NETFILTER_XT_MATCH_RECENT_PROC_COMPAT is not set
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_SOCKET=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_TIME=m
CONFIG_NETFILTER_XT_MATCH_U32=m
CONFIG_NETFILTER_XT_MATCH_OSF=m
CONFIG_IP_VS=m
# CONFIG_IP_VS_IPV6 is not set
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

[jre]

@johanholmquist:
blockcontrol should have correctly reported what is going wrong. Obviously it didn't do that. So please help me to improve blockcontrol and send me the output of the following commands (while running your old kernel):
[ -f /proc/net/ip_tables_targets ]
echo $?
grep -q NFQUEUE /proc/net/ip_tables_targets
echo $?
modprobe -q xt_NFQUEUE
echo $?
modprobe -q ipt_NFQUEUE
echo $?

[ -f /proc/net/ip_queue ]
echo $?
modprobe -q ip_queue
echo $?

[ -f /proc/net/ip_tables_matches ]
echo $?
grep -q mark /proc/net/ip_tables_matches
echo $?
modprobe -q xt_mark
echo $?
modprobe -q ipt_mark
echo $?

[ -f /proc/net/ip_tables_matches ]
echo $?
grep -q state /proc/net/ip_tables_matches
echo $?
modprobe -q xt_state
echo $?
modprobe -q ipt_state
echo $?

[ -f /proc/net/ip_tables_matches ]
echo $?
grep -q iprange /proc/net/ip_tables_matches
echo $?
modprobe -q xt_iprange
echo $?
modprobe -q ipt_iprange
echo $?

ls -l /bin/sh
blockcontrol show_config

[lovinglinux]

Hi jre, how are you doing?

I'm wondering when a ppa for Lucid will be available? I'm currently using the Karmic ppa and it is working fine, but I don't know if I could experience any issues by doing this.

Not making any pressure. I'm just addicted to moblock :)

[jre]

I'm just working on releasing pgl. Only drawbacks: no GUI yet and no debian transition for automatic updates from moblock. But the latter is only necessary if the first is available.
Debian packages of pgl will be available for Debian squeeze and sid and Ubuntu karmic and lucid. (I won't support any older releases, that's just too time consuming. But since lucid is a LTS that will be ok).
So when I've done that I might do lcuid packages of the rest, too. Perhaps even earlier.
I'll give you an update here.

Besides that, you might have noted that I greatly reduced my work on this stuff. I had a few months with nearly zero time commitment and I doubt that I will ever spend as much time as in the past on this. But on the other site I always enjoy it, when I work on this stuff. And your question came at the best time to motivate me to do what I just wrote above. And as always a big thank you for your active work here in the forum, lovinglinux. This helps me to find time for development.

[lovinglinux]

I'm just working on releasing pgl. Only drawbacks: no GUI yet and no debian transition for automatic updates from moblock. But the latter is only necessary if the first is available.
Debian packages of pgl will be available for Debian squeeze and sid and Ubuntu karmic and lucid. (I won't support any older releases, that's just too time consuming. But since lucid is a LTS that will be ok).
So when I've done that I might do lcuid packages of the rest, too. Perhaps even earlier.
I'll give you an update here.

Besides that, you might have noted that I greatly reduced my work on this stuff. I had a few months with nearly zero time commitment and I doubt that I will ever spend as much time as in the past on this. But on the other site I always enjoy it, when I work on this stuff. And your question came at the best time to motivate me to do what I just wrote above. And as always a big thank you for your active work here in the forum, lovinglinux. This helps me to find time for development.

That was fast :)

I don't know if I understood correctly, but are you saying PeerGuardian for Linux is being revived? Does it replaces moblock?

I understand the commitment issues. I have been thinking about stopping providing a Windows version of one of my Firefox extensions. It doesn't work 100% as the Linux version and is just too time consuming to make it. Besides, I hate having to boot into Windows. I feel completely lost. I need to focus on polishing the Linux version, so Mozilla can approve it for public download. Need to prioritize the development time available.

Thanks for the great work.

[jre]

Yes. PeerGuardian Linux (pgl) is based on nfblock (moblock
clone) and blockcontrol and has many improvements and fixes. If you want to try it you can get it from the git development repository:
https://sourceforge.net/projects/peerguardian/develop

You can install it e.g. with

# Install git, fakeroot and build-dependencies:
sudo aptitude install git-core fakeroot debhelper libqt4-dev
po-debconf zlib1g-dev libnetfilter-queue-dev libnfnetlink-dev
libdbus-1-dev
# Get the development repository
git clone git://peerguardian.git.sourceforge.net/gitroot/peerguardian/peerguardian
# Change to the source directory
cd peerguardian/pgl/
# Build the packages
dpkg-buildpackage -uc -us -tc -rfakeroot
# Install packages
sudo dpkg -i ../pgl*.deb

Oh, for releasing I only have to update the documetnation and fix the Debian packaging (nearly done).
That answer was even faster ;-) I like copy&paste.

[jre]

The real replacement will just occur when we have a GUI. Work on that was started, but is stalled currently. So I can't tell what will happen ....

[lovinglinux]

Yes. PeerGuardian Linux (pgl) is based on nfblock (moblock
clone) and blockcontrol and has many improvements and fixes. If you want to try it you can get it from the git development repository:
https://sourceforge.net/projects/peerguardian/develop

You can install it e.g. with

# Install git, fakeroot and build-dependencies:
sudo aptitude install git-core fakeroot debhelper libqt4-dev
po-debconf zlib1g-dev libnetfilter-queue-dev libnfnetlink-dev
libdbus-1-dev
# Get the development repository
git clone git://peerguardian.git.sourceforge.net/gitroot/peerguardian/peerguardian
# Change to the source directory
cd peerguardian/pgl/
# Build the packages
dpkg-buildpackage -uc -us -tc -rfakeroot
# Install packages
sudo dpkg -i ../pgl*.deb

Oh, for releasing I only have to update the documetnation and fix the Debian packaging (nearly done).
That answer was even faster ;-) I like copy&paste.

Thanks. I'm definitely going to try it. I hope it keeps the nice features provided by moblock. For instance, I use moblock as iptables manager, not only for blocking peers.

Do I need to remove moblock first? How do I revert the changes made by the above instructions?

[jre]

you need to uninstall moblock/....
then the new packages will be pgld, pgld-dbg and pglcmd
Most important for you the iptables chains have new names. the filenames changed of course, too. But I think both is already documented.
Besides that you can replace all "blockcontrol OPTION" commands with "pglcmd OPTION"

[dealcorn]

I am trying to obtain jaunty clarification of the Howto comment that most kernels do not permit whitelist traffic per application. My goal is to block transmission from a specific site but permit deluge. After blacklisting the site it appears that iptables-custom-insert.sh would permit me to either whitelist the application deluge or whitelist the site, but it would not permit a whitelist based on the requirement that both conditions be met. My initial read of the chain rule-specification of man iptables suggests that it is not helpful. Am I correct and is there an alternate approach?

[jre]

You can freely combine all iptables options. So the combination of whitelisting a site for a special application is possible.

If your system (kernel/netfilter/iptables) doesn't support the cmd-owner module, you may use other modules instead - I guess the uid-owner module (solution 3) is supported by every system.

Here are a few possible solutions (not tested!):

Use the pid-owner module (the first line first makes sure that deluge is running, and then inserts the whitelisting rule for deluge's pid which is inserted automatically by $(pidof deluge). So you need to restart blockcontrol after starting deluge.)
pidof deluge > /dev/null && \
iptables -I blockcontrol_out -m owner --pid-owner $(pidof deluge) -d [IP] -j RETURN
Use the cmd-owner module
iptables -I blockcontrol_out -m owner --cmd-owner deluge -d [IP] -j RETURN
Run deluge from a separate user and use the uid-owner module
iptables -I blockcontrol_out -m owner --uid-owner [deluge-user] -d [IP] -j RETURN

[dealcorn]

After I was unable to get application specific whitelist option 1 or 2 above to work, I simplified by blacklisting a local google site (64.233.189.104) and retried with the google site address, also to fail. Then I got rid of iptables-custom-insert.sh and edited /blockcontrol.conf to whitelist the site and verified that it appeared correct in Mobloquer only to again discover that the whitelist failed. I did stop, rebuild and start MoBlock appropriately. I use firestarter to blacklist my problem site. Do the MoBlock whitelist features require that the blacklist come from a list rather than iptables? If so, is there a technique to put a blacklst site into a list format that may be imported? My last blocklist control status follows:

:~$ sudo blockcontrol status
[sudo] password for dea:
Current IPv4 iptables rules (this may take a while):

Chain INPUT (policy DROP 4 packets, 5752 bytes)
pkts bytes target prot opt in out source destination
640 28112 blockcontrol_in all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14
0 0 ACCEPT tcp -- * * 192.168.0.1 0.0.0.0/0 tcp flags:!0x17/0x02
4 596 ACCEPT udp -- * * 192.168.0.1 0.0.0.0/0
19394 4442K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
121 15058 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/sec burst 5
0 0 DROP all -- * * 224.0.0.0/8 0.0.0.0/0
5 140 DROP all -- * * 0.0.0.0/0 224.0.0.0/8
0 0 DROP all -- * * 255.255.255.255 0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0
23 1020 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 LSI all -f * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/min burst 5
43584 24M INBOUND all -- wlan0 * 0.0.0.0/0 0.0.0.0/0
0 0 LOG_FILTER all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Unknown Input'

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 blockcontrol_fw all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 10/sec burst 5
0 0 LOG_FILTER all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Unknown Forward'

Chain OUTPUT (policy DROP 6 packets, 240 bytes)
pkts bytes target prot opt in out source destination
2396 210K blockcontrol_out all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14
0 0 ACCEPT tcp -- * * 192.168.0.102 192.168.0.1 tcp dpt:53
4 257 ACCEPT udp -- * * 192.168.0.102 192.168.0.1 udp dpt:53
19394 4442K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- * * 224.0.0.0/8 0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0 224.0.0.0/8
0 0 DROP all -- * * 255.255.255.255 0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
53936 45M OUTBOUND all -- * wlan0 0.0.0.0/0 0.0.0.0/0
0 0 LOG_FILTER all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Unknown Output'

Chain INBOUND (1 references)
pkts bytes target prot opt in out source destination
42201 23M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1382 234K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1 75 LSI all -- * * 0.0.0.0/0 0.0.0.0/0

Chain LOG_FILTER (5 references)
pkts bytes target prot opt in out source destination

Chain LSI (2 references)
pkts bytes target prot opt in out source destination
1 75 LOG_FILTER all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 1/sec burst 5 LOG flags 0 level 6 prefix `Inbound '
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02
0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x04 limit: avg 1/sec burst 5 LOG flags 0 level 6 prefix `Inbound '
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x04
0 0 LOG icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8 limit: avg 1/sec burst 5 LOG flags 0 level 6 prefix `Inbound '
0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
1 75 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/sec burst 5 LOG flags 0 level 6 prefix `Inbound '
1 75 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

Chain LSO (1 references)
pkts bytes target prot opt in out source destination
2 88 LOG_FILTER all -- * * 0.0.0.0/0 0.0.0.0/0
2 88 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/sec burst 5 LOG flags 0 level 6 prefix `Outbound '
2 88 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

Chain OUTBOUND (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
51112 45M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
215 26112 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 88 LSO all -- * * 0.0.0.0/0 64.233.189.104
2607 267K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Chain blockcontrol_fw (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa
0 0 RETURN all -- * * 0.0.0.0/0 192.168.0.1
0 0 RETURN all -- * * 192.168.0.0/24 192.168.0.0/24
0 0 RETURN all -- * * 0.0.0.0/0 64.233.189.104
0 0 RETURN all -- * * 64.233.189.104 0.0.0.0/0
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Chain blockcontrol_in (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa
637 28028 RETURN all -- lo * 0.0.0.0/0 0.0.0.0/0
3 84 RETURN all -- * * 192.168.0.0/24 0.0.0.0/0
0 0 RETURN all -- * * 64.233.189.104 0.0.0.0/0
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Chain blockcontrol_out (1 references)
pkts bytes target prot opt in out source destination
224 24878 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa reject-with icmp-port-unreachable
637 28028 RETURN all -- * lo 0.0.0.0/0 0.0.0.0/0
2 127 RETURN all -- * * 0.0.0.0/0 192.168.0.1
0 0 RETURN all -- * * 0.0.0.0/0 192.168.0.0/24
0 0 RETURN all -- * * 0.0.0.0/0 64.233.189.104
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
19 836 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
1514 156K NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Please check if the above printed iptables rules are correct!

* moblock is running
PID: 24547 CMD: /usr/bin/moblock -p /var/lib/blockcontrol/guarding.p2p -q 92 -t -r 10 -a 20 /var/log/moblock.log

* blockcontrol.wd is running
PID: 24552 CMD: /bin/sh /usr/bin/blockcontrol.wd

[jre]

First off, every configuration change requires a "blockcontrol restart"! But at least in your "blockcontrol status" everything seems fine. There you have whitelisted/allowed 64.233.189.104 in every direction for moblock. So moblock will never block this IP. Instead you reject this IP with firestarter for outgoing connections (chains OUTBOUND and LSO).

Just for clarification (I#m a bit at a loss to understand what you really want):
whitelisting:
moblock will not block this IP, even if it is in one of the blocklists. Note that e.g. firestarter still may block this IP, even if moblock does not block it. This can be achieved

with the WHITE_IP_IN, WHITE_IP_OUT and WHITE_IP_FORWARD entries in blockcontrol.conf
an iptables rule in iptables-custom-insert.sh with the target RETURN


blacklisting:
two ways to understand this:

Generally block traffic to/from an IP. This can be achieved by

Using e.g. firestarter
an iptables rule with the target REJECT or DROP

add an IP to moblock's blocklist. (I think this is the answer to your last questions):

Create a file /etc/blockcontrol/custom-blocklist.p2p and add a line like Google:64.233.189.104-64.233.189.104
then add this line to blockcontrol.conf:locallist /etc/blockcontrol/custom-blocklist.p2p



Feel free to ask again. I'm not sure whether this answer helped.

[chinaski]

Lately moblock (last version on 10.04-32) blocks lots of connection most of which outgoing, and this happens since few days despite no p2p software is running.

I rebooted the router and got new public IP several times, but since last time I shut aMule down few days ago moblock is still blocking connection.

Here's a small portion of moblock.log


Tue Jun 8 13:39:58| OUT: Valencia University,hits: 3,DST: 147.156.27.234
Tue Jun 8 13:39:58| OUT: Vodafone Ireland Limited,hits: 54,DST: 93.107.7.186
Tue Jun 8 13:40:05| OUT: Vodafone Ireland Limited,hits: 55,DST: 93.107.7.186
Tue Jun 8 13:40:07| OUT: Vodafone Ireland Limited,hits: 56,DST: 93.107.7.186
Tue Jun 8 13:40:11| OUT: Vodafone Ireland Limited,hits: 57,DST: 93.107.7.186
Tue Jun 8 13:40:32| OUT: Vodafone Ireland Limited,hits: 58,DST: 93.107.7.186
Tue Jun 8 13:40:34| OUT: Vodafone Ireland Limited,hits: 59,DST: 93.107.7.186
Tue Jun 8 13:40:38| OUT: Vodafone Ireland Limited,hits: 60,DST: 93.107.7.186
Tue Jun 8 13:41:49| OUT: Vodafone Omnitel N.V,hits: 6,DST: 93.147.74.54
Tue Jun 8 13:41:49| OUT: TeliaSonera AB,hits: 1,DST: 213.66.160.14
Tue Jun 8 13:41:49| OUT: University of Lancaster,hits: 1,DST: 148.88.181.173
Tue Jun 8 13:41:51| OUT: Vodafone Omnitel N.V,hits: 7,DST: 93.147.74.54
Tue Jun 8 13:41:51| OUT: TeliaSonera AB,hits: 2,DST: 213.66.160.14
Tue Jun 8 13:41:51| OUT: University of Lancaster,hits: 2,DST: 148.88.181.173
Tue Jun 8 13:41:55| OUT: Vodafone Omnitel N.V,hits: 8,DST: 93.147.74.54
Tue Jun 8 13:41:55| OUT: TeliaSonera AB,hits: 3,DST: 213.66.160.14
Tue Jun 8 13:41:55| OUT: University of Lancaster,hits: 3,DST: 148.88.181.173
Tue Jun 8 13:45:38| OUT: University of Lancaster,hits: 4,DST: 148.88.181.173
Tue Jun 8 13:45:40| OUT: University of Lancaster,hits: 5,DST: 148.88.181.173
Tue Jun 8 13:45:44| OUT: University of Lancaster,hits: 6,DST: 148.88.181.173
Tue Jun 8 13:50:19| OUT: I.Net S.p.A., Vodafone Omnitel N.V,hits: 28,DST: 213.92.110.188
Tue Jun 8 13:50:20| OUT: Early registrations SURFnet bv,hits: 61,DST: 145.116.233.143
Tue Jun 8 13:50:21| OUT: I.Net S.p.A., Vodafone Omnitel N.V,hits: 29,DST: 213.92.110.188
Tue Jun 8 13:50:22| OUT: Early registrations SURFnet bv,hits: 62,DST: 145.116.233.143
Tue Jun 8 13:50:26| OUT: I.Net S.p.A., Vodafone Omnitel N.V,hits: 30,DST: 213.92.110.188
Tue Jun 8 13:50:26| OUT: Early registrations SURFnet bv,hits: 63,DST: 145.116.233.143
Tue Jun 8 13:50:45| OUT: Vodafone Ireland Limited,hits: 61,DST: 93.107.7.186
Tue Jun 8 13:50:47| OUT: Vodafone Ireland Limited,hits: 62,DST: 93.107.7.186
Tue Jun 8 13:50:51| OUT: Vodafone Ireland Limited,hits: 63,DST: 93.107.7.186
Tue Jun 8 13:53:50| OUT: Bogon,hits: 1,DST: 42.242.39.203
Tue Jun 8 13:53:50| OUT: Bogon,hits: 2,DST: 42.242.39.203
Tue Jun 8 14:01:44| OUT: Early registrations SURFnet bv,hits: 64,DST: 145.116.233.143
Tue Jun 8 14:01:46| OUT: Early registrations SURFnet bv,hits: 65,DST: 145.116.233.143
Tue Jun 8 14:01:50| OUT: Early registrations SURFnet bv,hits: 66,DST: 145.116.233.143
Tue Jun 8 14:04:29| OUT: I.Net S.p.A., Vodafone Omnitel N.V,hits: 31,DST: 213.92.110.188
Tue Jun 8 14:04:30| OUT: Vodafone Ireland Limited,hits: 64,DST: 93.107.7.186
Tue Jun 8 14:04:31| OUT: I.Net S.p.A., Vodafone Omnitel N.V,hits: 32,DST: 213.92.110.188
Tue Jun 8 14:04:32| OUT: Vodafone Ireland Limited,hits: 65,DST: 93.107.7.186
Tue Jun 8 14:04:35| OUT: I.Net S.p.A., Vodafone Omnitel N.V,hits: 33,DST: 213.92.110.188
Tue Jun 8 14:04:35| OUT: Vodafone Ireland Limited,hits: 66,DST: 93.107.7.186
1) is this normal? in my experience with moblock I used to change public IP by rebooting the router every time I turned p2p software off, and no IN/OUT connection whatsoever

2) what is it on my machine that is trying to connect to those hosts? I run rkhunter and chkrootkit and nothing was found

On this machine I usually run Firefox, Skype, Rhythmbox with all plugin disabled, and OpenOffice, which are all open now and that's all.

???

[jre]

I wouldn't worry about that.
Since they are outgoing connections a new IP from your router can`t help here.
To investigate further you can check the ports of the blocked packets: For moblock check this link (https://help.ubuntu.com/community/MoBlock#How%20do%20I%20find%20out%20which%20IP%20o r%20port%20was%20blocked?) or just install pgl (no GUI yet) instead of moblock and have a look at /var/log/pgl/pgld.log

You can also use a packet sniffer (wireshark) to analyze the traffic.

[chinaski]

Hello jre,

Thank you for your answer.

I have realized I had set this machine as LAMP server just before this started.

I think this was the "problem".

Or better the fact I left Apache and MySQL on default auto start settings.

After stopping services and preventing them from autostart with sudo update-rc.d -f service_name remove no more connections are logged if p2p software is off.

Sorry to bother you for my stupidity :)

[chinaski]

I have found out those connections are blocked if Skype is on

today at 6:24pm I have shut Skype down, and I have reopened it right now:

Mon Jun 14 18:24:13| OUT: netdirekt e. K,hits: 2,DST: 89.149.253.183
Mon Jun 14 18:24:16| OUT: MCNC,hits: 3,DST: 152.2.71.239
Mon Jun 14 18:24:17| OUT: University of Michigan,hits: 3,DST: 141.211.98.176
Mon Jun 14 18:24:17| OUT: netdirekt e. K,hits: 3,DST: 89.149.253.183
Tue Jun 15 00:04:47| OUT: SUNET/NORDUnet,hits: 18,DST: 130.238.141.52
Tue Jun 15 00:04:48| OUT: Dzirciema iela 16, Riga, LV-1007,hits: 3,DST: 159.148.163.249
Tue Jun 15 00:04:48| OUT: University of Maribor,hits: 2,DST: 164.8.3.50
Tue Jun 15 00:04:49| OUT: Communications Networking Services,hits: 5,DST: 212.8.163.76
Tue Jun 15 00:04:50| OUT: Sony Network Taiwan Limited,hits: 4,DST: 61.64.138.162
Tue Jun 15 00:04:50| OUT: ELTEL,hits: 1,DST: 89.112.59.195
Tue Jun 15 00:04:50| OUT: Proxad Static DSL,hits: 10,DST: 82.246.178.227
Tue Jun 15 00:04:50| OUT: Chalmers University Network,hits: 1,DST: 129.16.137.104
why is Skype trying to connect to such hosts?

[ewan86]

Setting up Moblock and Mobloquer as a non technical person was hard going but I think it is done fairly correctly though I only partially understood what I did and which lists I should use.

Anyway question: Should I enable blocklists in transmission when I have moblock running??? will this enhance or degrade security??

Thanks for your hard work on this :)

[jre]

The correct list setting depends on your needs. My advice is to visit iblocklist.com and read the description. Generally I don't recommend to use too many lists. The default setting in my packages is already nearly paranoid.

If you don't have any whitelistings there is no point in using a blocklist in transmission, but it won't hurt either. If you have whitelistings (e.g. for http port 80) then you might gain a little additional security by using a blocklist in transmission.
If you use only blocklists in transmission, but not moblock at all, then your system will loose its "stealth" mode. Further I don't know if you can combine several blocklists in transmission, and how the updates are handled. So I strongly suggest to use at least moblock.

Perhaps the FAQ at https://help.ubuntu.com/community/MoBlock helps you further.

[ewan86]

Thanks so much for your speedy response. I have both running and I think I stuck with the standard blocklists so I should be fine!

I did open the ports for AMSN (and who knows what else Idid!!) so it would work but I don't think that is the same as whitelisting.

Anyway thats brilliant I will leave them both running if there is no conflict.

[jre]

"whitelisting" is opening the ports, or allowing traffic on those ports.
In most cases you will only whitelist outgoing TCP ports (WHITE_TCP_OUT), which allows you to use other services on the internet.
I don't know what is needed for AMSN - here it might be that you need to whitelist incoming (TCP) traffic, too.

You can verify your config with "blockcontrol show_config". Every variable is documented in /usr/lib/blockcontrol/blockcontrol.defaults. If you need to correct changes, but can't do it in mobloquer, then you have to edit /etc/blockcontrol/blockcontrol.conf.

[Origin_Unknown]

Hi Guys / Girls

I'm having a bit of a problem getting moblocker to start and I'm hoping someone can help! I've been through the guide @ http://help.ubuntu.com/community/MoBlock, done the install and gone through the configuration but when the app tries to start i get the following message in terminal'


mediacenter@MediaCenter:~$ sudo aptitude install moblock blockcontrol mobloquer
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initialising package states... Done
The following NEW packages will be installed:
blockcontrol libnetfilter-queue1{a} libnfnetlink0{a} moblock mobloquer
0 packages upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/409kB of archives. After unpacking 1,327kB will be used.
Do you want to continue? [Y/n/?] y
Writing extended state information... Done
Preconfiguring packages ...
Selecting previously deselected package libnfnetlink0.
(Reading database ... 144228 files and directories currently installed.)
Unpacking libnfnetlink0 (from .../libnfnetlink0_1.0.0-1_i386.deb) ...
Selecting previously deselected package libnetfilter-queue1.
Unpacking libnetfilter-queue1 (from .../libnetfilter-queue1_0.0.17-1_i386.deb) ...
Selecting previously deselected package moblock.
Unpacking moblock (from .../moblock_0.9~rc2-24~lucid_i386.deb) ...
Selecting previously deselected package blockcontrol.
Unpacking blockcontrol (from .../blockcontrol_1.6.12-1~lucid_all.deb) ...
Selecting previously deselected package mobloquer.
Unpacking mobloquer (from .../mobloquer_0.6+svn20090817+3-1~lucid_i386.deb) ...
Processing triggers for man-db ...
Processing triggers for ureadahead ...
Processing triggers for desktop-file-utils ...
Processing triggers for python-gmenu ...
Rebuilding /usr/share/applications/desktop.en_GB.utf8.cache...
Processing triggers for python-support ...
Setting up libnfnetlink0 (1.0.0-1) ...

Setting up libnetfilter-queue1 (0.0.17-1) ...

Setting up moblock (0.9~rc2-24~lucid) ...
Setting up blockcontrol (1.6.12-1~lucid) ...

moblock will soon be started ...
If any blocklists are missing, they will be downloaded. This may take several
minutes. Please be patient and don't abort. If you want to follow the update
process, then do in another terminal a
tail -f /var/log/blockcontrol.log
The lists are saved to /var/spool/blockcontrol/.
The installation of blockcontrol will fail, if starting moblock fails. So if
downloading the blocklists fails temporarily, the installation will fail.
To workaround this, you can turn the automatic starting of moblock off by setting
in /etc/blockcontrol/blockcontrol.conf:
INIT="0"
Please be patient ...
* Starting IP block daemon moblock [fail]
invoke-rc.d: initscript blockcontrol, action "start" failed.
dpkg: error processing blockcontrol (--configure):
subprocess installed post-installation script returned error exit status 9
dpkg: dependency problems prevent configuration of mobloquer:
mobloquer depends on blockcontrol; however:
Package blockcontrol is not configured yet.
dpkg: error processing mobloquer (--configure):
dependency problems - leaving unconfigured
Processing triggers for libc-bin ...
No apport report written because the error message indicates it's a follow-up error from a previous failure.
ldconfig deferred processing now taking place
Errors were encountered while processing:
blockcontrol
mobloquer
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
Setting up blockcontrol (1.6.12-1~lucid) ...

moblock will soon be started ...
If any blocklists are missing, they will be downloaded. This may take several
minutes. Please be patient and don't abort. If you want to follow the update
process, then do in another terminal a
tail -f /var/log/blockcontrol.log
The lists are saved to /var/spool/blockcontrol/.
The installation of blockcontrol will fail, if starting moblock fails. So if
downloading the blocklists fails temporarily, the installation will fail.
To workaround this, you can turn the automatic starting of moblock off by setting
in /etc/blockcontrol/blockcontrol.conf:
INIT="0"
Please be patient ...
* Starting IP block daemon moblock [fail]
invoke-rc.d: initscript blockcontrol, action "start" failed.
dpkg: error processing blockcontrol (--configure):
subprocess installed post-installation script returned error exit status 9
dpkg: dependency problems prevent configuration of mobloquer:
mobloquer depends on blockcontrol; however:
Package blockcontrol is not configured yet.
dpkg: error processing mobloquer (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
blockcontrol
mobloquer
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initialising package states... Done
Writing extended state information... Done


so obviously the program isn't started yet so I open the Mobloquer GUI, click manage and see some messages saying (log file isn't working so I'm having to type this)


Building blocklist... Updating Bluetack_level1...done.
Extracting Bluetack_Level1, detected gz...
gzip: /var/spool/blockcontrol/Bluetack_Level1/downloaded/Bluetack_Level1: Invalid compressed data--crc error
*Error 9:Failed to extract Bluetack_Level1.
*Removing /var/spool/blockcontrol/Bluetack_Level1/downloaded/Bluetack_Level1.
*Check your configuration in /etc/blockcontrol/blocklists.list and try a new blockcontrol update


the current selections on the list are;


#list.iblocklist.com/lists/atma/atma
#list.iblocklist.com/lists/bluetack/ads-trackers-and-bad-pr0n
list.iblocklist.com/lists/bluetack/bad-peers
#list.iblocklist.com/lists/bluetack/bogon
list.iblocklist.com/lists/bluetack/dshield
#list.iblocklist.com/lists/bluetack/edu
#list.iblocklist.com/lists/bluetack/for-non-lan-computers
#list.iblocklist.com/lists/bluetack/forum-spam
list.iblocklist.com/lists/bluetack/hijacked
#list.iblocklist.com/lists/bluetack/iana-multicast
#list.iblocklist.com/lists/bluetack/iana-private
#list.iblocklist.com/lists/bluetack/iana-reserved
list.iblocklist.com/lists/bluetack/level-1
#list.iblocklist.com/lists/bluetack/level-2
#list.iblocklist.com/lists/bluetack/level-3
list.iblocklist.com/lists/bluetack/microsoft
list.iblocklist.com/lists/bluetack/proxy
#list.iblocklist.com/lists/bluetack/range-test
list.iblocklist.com/lists/bluetack/spider
#list.iblocklist.com/lists/bluetack/spyware
#list.iblocklist.com/lists/bluetack/web-exploit
#list.iblocklist.com/lists/bluetack/webexploit-forumspam
#list.iblocklist.com/lists/cidr-report/bogon
#list.iblocklist.com/lists/dchubad/faker
#list.iblocklist.com/lists/dchubad/hacker
#list.iblocklist.com/lists/dchubad/pedophiles
#list.iblocklist.com/lists/dchubad/spammer
#list.iblocklist.com/lists/nexus23/ipfilterx
#list.iblocklist.com/lists/peerblock/rapidshare
#list.iblocklist.com/lists/spamhaus/drop
list.iblocklist.com/lists/tbg/bogon
list.iblocklist.com/lists/tbg/business-isps
list.iblocklist.com/lists/tbg/educational-institutions
list.iblocklist.com/lists/tbg/general-corporate-ranges
list.iblocklist.com/lists/tbg/hijacked
list.iblocklist.com/lists/tbg/primary-threats
list.iblocklist.com/lists/tbg/search-engines

#locallist /etc/blockcontrol/custom-blocklist.p2p


I've removed Bluetack_Level` and then moblocker updates everything down to 'TBH_Educational_Instuitions so I remove that, general-corperate-ranges and tbg/primary-threats then finally moblock starts...

is there any reason those 4 stop moblocker from starting at all? should it not just skip past and say they arnt updated? or is it because its a first time install and i've not downloaded those lists yet?

[jre]

Yes, this is intended behaviour: MoBlock refuses to start if any configured blocklist is not available. But if an update of a list fails, it just uses the last available version of that list. I decided that this way, so that users get aware of the fact that a list is missing (while it is acceptable that an old version is used).

BTW, I just tried your blocklists.list and all lists were available.

[Origin_Unknown]

Yes, this is intended behaviour: MoBlock refuses to start if any configured blocklist is not available. But if an update of a list fails, it just uses the last available version of that list. I decided that this way, so that users get aware of the fact that a list is missing (while it is acceptable that an old version is used).

BTW, I just tried your blocklists.list and all lists were available.


thanks for the reply - i guess mine was failing to start then because i didnt have a previous available version. it's interesting that mine wouldn't update - perhaps ill try again now and see

[Origin_Unknown]

I've just tried it again and i keep getting the same behavior even if i manually add the list from iblocklist.com - i also get the same issue on another machine i have with ubuntu 10.04.1 installed on

[jre]

Although I can't imagine what is going wrong, perhaps a "sudo blockcontrol force-update" helps. This will delete all currently downloaded blocklists and start from scratch again.
Another possibility might be that you had too many downloads from iblocklist.com, and were therefore banned temporarily (although this never happened to me, even when I made many downloads while working on the blocklist download code).

[Origin_Unknown]

it appears to be downloading the files as i've been to /var/spool/blockcontrol/Bluetack_level1/ had a look in the download folder and there is a file in there that just cannot be extracted - which would go with the CRC error that moblocker is giving me.

The owner of the folder above is OWNER and changing the folder permissions to my user name have no effect.

Ill give it another go on one of the machines at work tomorrow and see if i can get it to work there

[Origin_Unknown]

I've just tested it at work and for some reason it works just fine - I'm going to reload my pc at home tonight and see what's what.... still odd though.

[Origin_Unknown]

Re-installed Ubuntu and installed MoBlock then as if by magic it works - cheers jre

[jre]

Glad to hear. Although I think that was a bit overkill ;-)

I guess you were just unlucky and somehow got a coorupted list. The maintainer of iblocklist.com thinks it might be, that you just downlaoded the list from the server, while a new one was uploaded. So probably the "blockcontrol force-update" would have worked.

Have fun!

[urschrei]

My install of moblock 0.9rc2 (compiled OK from source, and installed OK; I can run 'moblock' from the terminal and get its usage options) and blockcontrol 1.6.12 is refusing to start on Ubuntu 10.04.1 (PPC).

Looking at blockcontrol.log, I just see:


2010-09-11 21:49:05 IST End: blockcontrol force-update
2010-09-11 21:50:01 IST Begin: blockcontrol start
Building blocklist... ...done.
* Warning: Could not load kernel module xt_iprange, continuing anyway.
* Whitelisting IP ranges with the allow list will not work.
* The allow list is in /etc/blockcontrol/allow.p2p.
Inserting iptables ...
iptables: Chain already exists.
...fail!
...fail!


And nothing else. Is there a way for me to see what's causing the "...fail!" messages? Syslog isn't showing anything.

[jre]

The log says that blockcontrol can't insert the necessary iptables rules/chains because they were already inserted previously. You can remove them by issuing a "blockcontrol stop". Verify that they are removed with a "blockcontrol status" - in that output you should see no reference to "blockcontrol" at all. Then try a "blockcontrol start" again.

After solving that problem I guess you will still experience another problem, which is the original reason for the error message you just got.

Do you use a custom built kernel? (I guess so because of the warning message about xt_iprange. Please note that this is eally just a warning, but does not prevent moblock from working. But it still indicates something special about your system). Make sure that you enable (as modules) the necessary netfilter support. See the README for details.

Why did you compile your own version? I recommend to just install from moblock-deb.sourceforge.net. See also the guide at https://help.ubuntu.com/community/MoBlock

Where did you get your sources from? The original moblock source from berlios.de needs patching in order to work. Even if you want to compile on your own, I recommend to use the source from moblock-deb.sf.net

[urschrei]

I built the package using the instructions from moblock-deb (I'm running on PPC, and there doesn't seem to be a package available in apt), ran blockcontrol stop, then start, then status, and now it's fine. I didn't even get the warning about the missing kernel module. Odd, but it's running, and I'm seeing hits in the log.

[jre]

Indeed I don't offer PPC packages, but you just made everything right. So great to hear that it works on PPC. Just strange that you had those problems in the beginning.

[skipper38]

Hi guys I've just registered to ask for your help, I'm a newbie of Ubuntu 10.4 and after a few weeks finally got Moblock installed, It says its running but in the log panel I expected to see running lists of ip's it is blocking (like PG2).........So I enabled blocklist microsoft and restarted MB and went to MS website expecting to get blocked:confused:

Not really sure whats going on and apologies if this has been posted already.....also when used to use PG2 my RSS for BBC news feed used to fail ! so I knew it was doing its job, this is just confusing me as it doesn't seem to be doing anything, I've had just one item on the log which was yahoo.....any advice VERY much appreciated:KS

[jre]

i guess on installation you accepted to whitelist outging TCP conections on port 80 and 443 (http and https services). Just edit /etc/blockcocntrol/blockcocntrol.conf and remove this whitelisting. See also https://help.ubuntu.com/community/MoBlock

[skipper38]

Hi jre thanks for your response, I'm not quite sure what you mean about editing the /etc/blockcontrol/blockcontrol conf ?? Heres my log dunno if this helps....sorry for being vague but I'm still getting my head around linux, but i am loving it

p, li { white-space: pre-wrap; } Current IPv4 iptables rules (this may take a while):
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 blockcontrol_in all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14
1866 1855K ufw-before-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
1866 1855K ufw-before-input all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-after-input all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-after-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-reject-input all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-track-input all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 blockcontrol_fw all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14
0 0 ufw-before-logging-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-before-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-after-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-after-logging-forward all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ufw-reject-forward all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 2 packets, 80 bytes)
pkts bytes target prot opt in out source destination
182 11348 blockcontrol_out all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14
1754 281K ufw-before-logging-output all -- * * 0.0.0.0/0 0.0.0.0/0
1754 281K ufw-before-output all -- * * 0.0.0.0/0 0.0.0.0/0
268 18758 ufw-after-output all -- * * 0.0.0.0/0 0.0.0.0/0
268 18758 ufw-after-logging-output all -- * * 0.0.0.0/0 0.0.0.0/0
268 18758 ufw-reject-output all -- * * 0.0.0.0/0 0.0.0.0/0
268 18758 ufw-track-output all -- * * 0.0.0.0/0 0.0.0.0/0
Chain blockcontrol_fw (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa
0 0 RETURN all -- * * 0.0.0.0/0 192.168.2.1
0 0 RETURN all -- * * 192.168.2.0/24 192.168.2.0/24
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92
Chain blockcontrol_in (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa
0 0 RETURN all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all -- * * 192.168.2.0/24 0.0.0.0/0
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92
Chain blockcontrol_out (1 references)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa reject-with icmp-port-unreachable
0 0 RETURN all -- * lo 0.0.0.0/0 0.0.0.0/0
123 7808 RETURN all -- * * 0.0.0.0/0 192.168.2.1
0 0 RETURN all -- * * 0.0.0.0/0 192.168.2.0/24
15 900 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
44 2640 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92
Chain ufw-after-forward (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-after-input (1 references)
pkts bytes target prot opt in out source destination
0 0 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:137
0 0 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:138
0 0 ufw-skip-to-policy-input tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
0 0 ufw-skip-to-policy-input tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
0 0 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:67
0 0 ufw-skip-to-policy-input udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:68
0 0 ufw-skip-to-policy-input all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
Chain ufw-after-logging-forward (1 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix `[UFW BLOCK] '
Chain ufw-after-logging-input (1 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix `[UFW BLOCK] '
Chain ufw-after-logging-output (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-after-output (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-before-forward (1 references)
pkts bytes target prot opt in out source destination
0 0 ufw-user-forward all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-before-input (1 references)
pkts bytes target prot opt in out source destination
6 300 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
1851 1852K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ufw-logging-deny all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 4
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 12
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
9 2637 ufw-not-local all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * * 224.0.0.0/4 0.0.0.0/0
9 2637 ACCEPT all -- * * 0.0.0.0/0 224.0.0.0/4
0 0 ufw-user-input all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-before-logging-forward (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-before-logging-input (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-before-logging-output (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-before-output (1 references)
pkts bytes target prot opt in out source destination
6 300 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
1480 262K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
268 18758 ufw-user-output all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-logging-allow (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix `[UFW ALLOW] '
Chain ufw-logging-deny (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID limit: avg 3/min burst 10
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10 LOG flags 0 level 4 prefix `[UFW BLOCK] '
Chain ufw-not-local (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
9 2637 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type MULTICAST
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
0 0 ufw-logging-deny all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 10
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-reject-forward (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-reject-input (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-reject-output (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-skip-to-policy-forward (0 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-skip-to-policy-input (7 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-skip-to-policy-output (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-track-input (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-track-output (1 references)
pkts bytes target prot opt in out source destination
72 4320 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
194 14358 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW
Chain ufw-user-forward (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-user-input (1 references)
pkts bytes target prot opt in out source destination
Chain ufw-user-limit (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 0 level 4 prefix `[UFW LIMIT BLOCK] '
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain ufw-user-limit-accept (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ufw-user-logging-forward (0 references)
pkts bytes target prot opt in out source destination
Chain ufw-user-logging-input (0 references)
pkts bytes target prot opt in out source destination
Chain ufw-user-logging-output (0 references)
pkts bytes target prot opt in out source destination
Chain ufw-user-output (1 references)
pkts bytes target prot opt in out source destination
Please check if the above printed iptables rules are correct!
* moblock is running
PID: 2045 CMD: /usr/bin/moblock -p /var/lib/blockcontrol/guarding.p2p -q 92 -t -r 10 -a 20 /var/log/moblock.log
* blockcontrol.wd is running
PID: 2050 CMD: /bin/sh /usr/bin/blockcontrol.wd

[jre]

Just have a look here: https://help.ubuntu.com/community/MoBlock#How%20can%20I%20allow%20%28whitelist%29%20 traffic%20on%20certain%20ports?
There it is described how to whitelist the ports I were talking about. Now I suggest you do just the opposite of that: change the entry to WHITE_TCP_OUT=""
Afterwards do a "sudo blockcontrol restart" in the console.

Please have a look at my signature about the CODE tags for quoting.

[jre]

In detail this means:
type in console
gksu gedit /etc/blockcontrol/blockcontrol.conf
An editor will open ... there you add this line to the file:
WHITE_TCP_OUT=""
Save the file and quit the editor.
Then type in console
sudo blockcontrol restart
And you're done.

[skipper38]

In detail this means:
type in console
gksu gedit /etc/blockcontrol/blockcontrol.conf
An editor will open ... there you add this line to the file:
WHITE_TCP_OUT=""
Save the file and quit the editor.
Then type in console
sudo blockcontrol restart
And you're done.
Ok jre I did what you said and now I can't access internet at all.....done a couple of searches and it looks like I have to whitelist my ip range ? is this correct as you seem to be able to explain all this very well for us noobs....cheers

[jre]

Been away and busy ...

What do you mean with "can't access internet at all". Can't you surf to any webpages with your webbrowser, or do all internet services (e.g. email client, chat client, weather applet), not work.

I guess it is the first problem. This is because the default blocklist setup is quite paranoid and blocks one third of the internet. You then have the following solutions:

choose less blocklists
or whitelist http again
or allow all IPs of webpages that you want to visit
or stop moblock, whenever you want to surf the internet


If it is the latter problem then please post the output of "blockcontrol show_config" and /var/log/moblock.log

[ewan86]

How do I install in Maverick?

[jre]

For Maverick I have only made "pgl" packages yet.
Moblock, .. packages will follow this or next week.

[jre]

I just made new moblock/blockcontrol/mobloquer packages, also for Ubuntu Maverick (10.10). They are built now and will be available soon.

At the same time I dropped support for Ubuntu Jaunty (9.04)

[radarman]

Hello,

Was having issues with the latest Moblock installation, wondering if anyone could help.

I'm trying to setup moblock the old way, no packet marking, just accept packet or drop/reject it. I'm trying to use moblock's nfqueue with iptables. I've had no success yet, but here is what I have so far.

My /etc/blockcontrol/blockcontrol.conf looks like this:

IPTABLES_SETTINGS="0"
NFQUEUE_NUMBER="0"
REJECT="0"
ACCEPT="0"

My iptables script looks like this:
# Flush all chains
iptables --flush

# Loopback Interface, Bridge
iptables --append INPUT --in-interface lo --jump ACCEPT
iptables --append INPUT --in-interface br0 --jump ACCEPT

# DNS
iptables --append INPUT --protocol tcp --sport 53 --match state --state ESTABLISHED --jump ACCEPT

iptables --append INPUT --protocol udp --sport 53 --match state --state ESTABLISHED --jump ACCEPT

# SSH
iptables --append INPUT --protocol tcp --dport 22

# ICMP Incoming
iptables --append INPUT --protocol icmp --match state --state ESTABLISHED --jump ACCEPT

# Default action is DROP
iptables --append INPUT --jump DROP


# Loopback Interface, Bridge
iptables --append OUTPUT --out-interface lo --jump ACCEPT
iptables --append OUTPUT --out-interface br0 --jump ACCEPT

# DNS
iptables --append OUTPUT --protocol tcp --dport 53 --match state --state NEW,ESTABLISHED --jump ACCEPT

iptables --append OUTPUT --protocol udp --dport 53 --match state --state NEW,ESTABLISHED --jump ACCEPT

# ICMP Outgoing
iptables --append OUTPUT --protocol icmp --jump ACCEPT

# Default action is moblock
iptables --append OUTPUT --jump NFQUEUE


So as you can see, any outgoing traffic that does not match a rule should be going to moblock's NFQUEUE. Unfortunately nothing seems to happen to that, and moblock's log shows no signs of activity. When I do 'blockcontrol status' it says moblock is running, and also shows an increasing number of packets going to NFQUEUE 0.

Any ideas?

[jre]

Your iptables setup looks correct to me. I'd suggest to remove
iptables --append OUTPUT --protocol icmp --jump ACCEPT
and then ping an IP from the blocklist.

IPTABLES_SETTINGS should be 2 if you use blockcontrol's custom iptables insert script. Or do you do this manually?


Besides that I'd suggest to use the MARKing feature for blocked packets, so that outgoing packets are REJECTed, instead of DROPped.

BTW, I see no target in this line:
# SSH
iptables --append INPUT --protocol tcp --dport 22

[radarman]

Thank you for catching that SSH line, jre :D

I tried your suggestion with ICMP, and found out that moblock would indeed work as intended for outgoing ICMP. This made me wonder why it would work for outgoing ICMP, but it wouldn't work when I launched lynx and tried to browse. Soon I realized that the problem was not handling TCP connections properly. I need to accept established TCP connections like this:

# Established TCP connections
iptables --append INPUT --protocol tcp --match state --state ESTABLISHED --jump ACCEPT


Problem solved! :D

Thank you Mr. jre for working on such useful and robust software :)

[jre]

This only makes sense to me if your CHAIN policy is DROP. But still I think, that you should have seen blocks before.

Of course you need to set your ACCEPT rule for established before the NFQUEUE rule.

[dougww]

I just made new moblock/blockcontrol/mobloquer packages, also for Ubuntu Maverick (10.10). They are built now and will be available soon.

At the same time I dropped support for Ubuntu Jaunty (9.04)

Is this why I can't install moblock on Jaunty? I'm using
apt-get install moblock

If so, do you have any advice on how I can get moblock or a similar program running on Jaunty? I'm a beginner so simple-ish instructions would be appreciated.

Thanks.

[jre]

Is this why I can't install moblock on Jaunty?
Yes. And first off, DO NOT USE JAUNTY, because it doesn't get any more security support (not only from me, but also none from Ubuntu/Canonical itself). Don't use it any more, update to a newer Ubuntu version.

Thus having said, you can either install the hardy packages (just replace in your /etc/apt/sources.list your old entry with
deb http://ppa.launchpad.net/jre-phoenix/ppa/ubuntu hardy main
deb-src http://ppa.launchpad.net/jre-phoenix/ppa/ubuntu hardy main), or add the same entry (or any other currently working) and follow the instructions "Build your own packages" on moblock-deb.sourceforge.net

Again, please update to lucid (Long Term Support) or maverick.

[dougww]

Yes. And first off, DO NOT USE JAUNTY, because it doesn't get any more security support (not only from me, but also none from Ubuntu/Canonical itself). Don't use it any more, update to a newer Ubuntu version.

Thus having said, you can either install the hardy packages (just replace in your /etc/apt/sources.list your old entry with
deb http://ppa.launchpad.net/jre-phoenix/ppa/ubuntu hardy main
deb-src http://ppa.launchpad.net/jre-phoenix/ppa/ubuntu hardy main), or add the same entry (or any other currently working) and follow the instructions "Build your own packages" on moblock-deb.sourceforge.net

Thanks so much for the quick reply. Upgrading is of course the best advice. Unfortunately, Ubuntu apparently doesn't support my architecture beyond 9.04. (I say apparently, because the only direct statements I could find are from second-hand sources: e.g., here (http://www.tonido.com/forum/viewtopic.php?p=7186#p7186) and here (https://lists.ubuntu.com/archives/ubuntu-mobile/2010-May/002729.html). Ubuntu's own docs are much less (https://help.ubuntu.com/10.10/installation-guide/powerpc/hardware-supported.html) clear (https://wiki.ubuntu.com/ARM/).) Installing the Hardy packages didn't work either.

BTW, it's not like I'm trying to scrape along with old hardware, either. I bought it brand new less than three months ago, and the company is still selling the same model (http://www.tonidoplug.com/tonido_plug.html) today. Of course, when I bought it, I didn't know (and didn't have any reasonable way of knowing) that support had been dropped.

None of this is your problem I know! Thanks for you help and if you have any more ideas, they would be appreciated.

Right now, it looks like I'll have to look into a different distro, like Arch Linux, but I'll miss the ease of use and great community support of Ubuntu.

[jre]

Well, I already posted my first idea: compile your own packages. The instructions are on moblock-deb.sourceforge.net

Generally the packages do work on all distributions. The only problem is that when they are compiled they depend on some certain software versions.

So next to "hardy" you may also try the packages from "karmic".

Otherwise, please post the errors that you get when you install.

EDIT: I just had a 10 second glance at your links and saw that you are using ARM hardware. So this is another problem. The ppa never contained packages for the ARM architecture (only i386, amd64, and for some distributions lpia packages can be built). So you have to build your own packages - either directly on your hardware or by crossbuilding it from your PC.

[JKarp84]

I have completely uninstalled: Firestarter, Moblock, BlockControl, and Mobloquer... and cleaned my iptables... all with the help and commands found in this thread, I noticed one other person in this thread has the same problem as I do, yet it is with older versions of ubuntu and programs from some time ago.

heres is what Im working with

Ubuntu 10.10 Maverick


||/ Name Version Description
+++-==============-==============-============================================
ii blockcontrol 1.6.13-1~maver Manage IP blockers
ii moblock 0.9~rc2-25~mav An IP blocker for Linux
un moblock-contro <none> (no description available)
ii mobloquer 0.6+svn2009081 GUI for MoBlock, an IP blocker for Linux
Reading symbols from /usr/bin/mobloquer...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/mobloquer
[Thread debugging using libthread_db enabled]
[New Thread 0xb669ab70 (LWP 5627)]
** Warning: void Mobloquer::g_SetRootPath(const QString&) Preferred file "/usr/bin/kdesudo" could not be found, using "/usr/bin/gksu" instead
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

Program received signal SIGABRT, Aborted.
0xb7fe1424 in __kernel_vsyscall ()
BlockControl and Moblock seem fine, but the GUI will not load up when executed.
This problem possibly originated when I checked Firestarter and a couple active connections disconnected and a wget connection was activated and out of not know what was happening I locked Firestarter. After some searching on the net for wget and moblock Ive come to the conclusion BlockControl was updating its lists and it was simply bad timing on my part to lock Firestarter. This is when Mobloquer started locking up and the uninstall and reinstall mayhem began.
Any help?

[jre]

verify that moblock/blockcontrol is running. Go to a terminal and do a "sudo blockcontrol status". You should get a bunch of lines from iptables and 2 lines saying whether moblock is running. If something is wrong, then check /var/log/blockcontrol.log. If everything is fine, then I can't think of any connection to moblock/blockcontrol/firestarter. (firestarter can mess up blockcontrol's iptables rules only temporarily. But mobloquer and firestarter do not touch in any area.)
if everything is fine, but you still have problems with mobloquer, then install "mobloquer-dev" and make a backtrace again. Perhaps we may fix mobloquer then.

[JKarp84]

* moblock is running
PID: 1487 CMD: /usr/bin/moblock -p /var/lib/blockcontrol/guarding.p2p -q 92 -t -r 10 -a 20 /var/log/moblock.log

* blockcontrol.wd is running
PID: 1494 CMD: /bin/sh /usr/bin/blockcontrol.wd

blockcontrol log
2011-01-02 15:25:07 EST Begin: blockcontrol stop
Stopping blockcontrol.wd [194G[ OK ]
Deleting iptables ...
[194G[ OK ]
Stopping moblock ... [194G[ OK ]
2011-01-02 15:25:08 EST End: blockcontrol stop
2011-01-02 15:26:03 EST Begin: blockcontrol start
Inserting iptables ...
Allowing outbound traffic to DNS server 192.168.1.1 [194G[ OK ]
Allowing forwarded traffic to DNS server 192.168.1.1 [194G[ OK ]
Allowing loopback traffic [194G[ OK ]
[194G[ OK ]
Starting moblock ... [194G[ OK ]
Starting blockcontrol.wd ... [194G[ OK ]
2011-01-02 15:26:05 EST End: blockcontrol start
Allowing outbound traffic to DNS server 192.168.1.1iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
...fail!
2011-01-02 15:31:02 EST Begin: blockcontrol restart
Stopping blockcontrol.wd ...done.
Deleting iptables ...
iptables v1.4.4: Couldn't load target `blockcontrol_in':/lib/xtables/libipt_blockcontrol_in.so: cannot open shared object file: No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
iptables v1.4.4: Couldn't load target `blockcontrol_out':/lib/xtables/libipt_blockcontrol_out.so: cannot open shared object file: No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
iptables v1.4.4: Couldn't load target `blockcontrol_fw':/lib/xtables/libipt_blockcontrol_fw.so: cannot open shared object file: No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
...fail!
* Don't worry! There occured some errors during the deletion of the iptables
* rules. The most common reason for this is that they did not exist, because
* moblock was not running.
* But if moblock was running there is some problem. Most probably you have
* installed another firewall application that did delete the iptables rules.
* A "blockcontrol restart" will then fix the situation.
Stopping moblock ... ...done.
Inserting iptables ...
Allowing outbound traffic to DNS server 192.168.1.1 ...done.
Allowing forwarded traffic to DNS server 192.168.1.1 ...done.
Allowing loopback traffic ...done.
...done.
Starting moblock ... ...done.
Starting blockcontrol.wd ... ...done.
2011-01-02 15:31:03 EST End: blockcontrol restartafter all this
i checked my blockcontrol status again

* moblock is running
PID: 2565 CMD: /usr/bin/moblock -p /var/lib/blockcontrol/guarding.p2p -q 92 -t -r 10 -a 20 /var/log/moblock.log

* blockcontrol.wd is running
PID: 2572 CMD: /bin/sh /usr/bin/blockcontrol.wd
mobloquer still wont run. I am new to linux so am unsure of what to do at this point.

[jre]

You issued the start commands 2 times, therefore the errors. But nothing to worry about. moblock and blockcontrol are running correctly!

Now, step 2!

[JKarp84]

after reinstalling mobloquer I ran the debug to "backtrace"
I couldnt find modbloquer-dev so assumed you meant to uninstall modbloquer-deb and reinstall it.
here is the result
(gdb) run
Starting program: /usr/bin/mobloquer
[Thread debugging using libthread_db enabled]
[New Thread 0xb6698b70 (LWP 3597)]
** Warning: void Mobloquer::g_SetRootPath(const QString&) Preferred file "/usr/bin/kdesudo" could not be found, using "/usr/bin/gksu" instead
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

Program received signal SIGABRT, Aborted.
0xb7fe1424 in __kernel_vsyscall ()
(gdb)

[jre]

Sorry, I can't find anything useful there.

You might get that Warning away, by changing the appropriate line in ~/.config/mobloquer/mobloquer.conf to
super_user=/usr/bin/gksu
But I doubt that is related to your problem.

My last idea is to remove the logfiles /var/log/moblock.log and blockcontrol.log and create empty ones instead. Maybe something very strange is in there.
sudo rm /var/log/moblock.log
sudo rm /var/log/blockcontrol.log
sudo touch /var/log/moblock.log
sudo touch /var/log/blockcontrol.log

[JKarp84]

This worked

sudo rm /var/log/moblock.log
sudo rm /var/log/blockcontrol.log
sudo touch /var/log/moblock.log
sudo touch /var/log/blockcontrol.log


First idea didnt sound logical but I am curious now, what could possibly be in a log file that effects the program itself? very strange...

thanks for your help. cheers!

[jre]

Wow, I'm surprised this worked!
mobloquer reads and parses these logfiles, so there is a way that this /can/ cause problems. But I have no idea what really caused the problem.

Next time I'll suggest to backup these files, so that we can inspect them. Do you know if they were really big (more then 10 MB)?

[JKarp84]

sorry for the late response, didnt expect your interest after fixing the problem.
I am unaware of the sizes of the log files during the problem.
however, It might be possibly to recreate the incident.
if you run firestarter and lock the connections using firestarter while mobloquer is sending a "wget" command in the "events" section of firestarter, it could very well shed some light on some things.

the "wget" connection might be under active connections but im fairly certain it was under events.

the wget function could also be something completely unrelated to mobloquer, I am unsure as I hardly know what a wget connection does and if mobloquer uses it to update the blocklists, which is what i was doing at the time of the initial problem after I locked firestarter out of being "scared"... so to speak...

anyway good luck in recreating this incident. Im afraid I cant be of much more use than to try recreating the incident myself, which im not too thrilled about doing unless its something you really need me to do.

ps
Im trying to find a way to whitelist an ip address net range I need for my messenger. msn messenger uses random IPs from 64.4.0.0 - 64.4.63.255 which are associated with MS Hotmail and Im getting perturbed that I have to unblock this range on a per IP bases as they popup in mobloquer. any help with this would make my day.

[jre]

Hmm, I probably won't dig deeper into this, better concentrate on developing pgl-gui. But generally I try to learn what went wrong in order to improve the code, while just knowing how to workaround a problem is only second best solution.

Anyway, blockcontrol and the corresponding daily cron job use wget to download the blocklists. So mobloquer uses wget indirectly, but might get something strange from an wget entry in blockcontrol.log.

Thx, I took your information to the BUGS file, for future reference.

[JKarp84]

glad i could help

[DOS286]

Is there a way to block all Internet activity except white-listed URLs?

[jre]

Yes, just use a list that covers the whole (IPv4) net.

Save the follwoing line as /etc/blockcontrol/custom-blocklist.p2p
The whole internet:0.0.0.0-255.255.255.255
Then disable all other lists in /etc/blockcontrol/blocklists.list and just enable (remove the #) the following line
locallist /etc/blockcontrol/custom-blocklist.p2p

Finally apply your changes
sudo blockcontrol restart

Note 1: per default port 80 and 443 are allowed - you might to change that.

Note 2: IPv6 is not checked per default, there are no lists available. You have the option to block all IPv6. Have a look at the example files in /usr/share/doc/blockcontrol/examples/

[chinaski]

hello,

I have this problem on my desktop machine (10.04 Lucid 32bit): since last night blockcontrol stopped working properly.

I start it with sudo blockcontrol start but after few seconds the status command show me this:

* moblock is not running
* blockcontrol.wd is running

system log viewer shows:

desktop kernel: [ 347.440368] moblock[2136]: segfault at bee32fe8 ip b769d821 sp bee32fec error 6 in libc-2.11.1.so[b7631000+153000]

so I see there is a problem with libc-2.11.1.so but unfortunately I do not know what to do.

shall I reinstall moblock?

I followed this tutorial to install it:

https://help.ubuntu.com/community/MoBlock

thanks :)

[jre]

Please also check /var/log/moblock.log and blockcontrol.log

Since the blocklists are the only thing that change, I'd just suggest to remove all downloaded blocklists and get new ones again (the first 2 commands just make a backup, so that we might investigate further, if my theory proves true):
mkdir ~/blocklists.backup
cp -rf /var/spool/blockcontrol/* ~/blocklists.backup
sudo blockcontrol force-update

[chinaski]

jre *thank you* for your fast reply

blockcontrol.log and moblock.log did not show anything unusual (I always keep them running with tail -f) but I tried the operations you suggested... and it works! :D

cris@desktop:~$ sudo blockcontrol status
Current IPv4 iptables rules (this may take a while):

Chain INPUT (policy ACCEPT 31474 packets, 40M bytes)
pkts bytes target prot opt in out source destination
4 468 blockcontrol_in all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 blockcontrol_fw all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14

Chain OUTPUT (policy ACCEPT 22851 packets, 2904K bytes)
pkts bytes target prot opt in out source destination
463 32368 blockcontrol_out all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14

Chain blockcontrol_fw (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa
0 0 RETURN all -- * * 0.0.0.0/0 208.67.220.220
0 0 RETURN all -- * * 0.0.0.0/0 208.67.222.222
0 0 RETURN all -- * * 192.168.1.0/24 192.168.1.0/24
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Chain blockcontrol_in (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa
0 0 RETURN all -- lo * 0.0.0.0/0 0.0.0.0/0
4 468 RETURN all -- * * 192.168.1.0/24 0.0.0.0/0
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Chain blockcontrol_out (1 references)
pkts bytes target prot opt in out source destination
69 4814 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0xa reject-with icmp-port-unreachable
0 0 RETURN all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 RETURN all -- * * 0.0.0.0/0 208.67.220.220
21 1327 RETURN all -- * * 0.0.0.0/0 208.67.222.222
2 180 RETURN all -- * * 0.0.0.0/0 192.168.1.0/24
0 0 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
7 420 RETURN tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
364 25627 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Please check if the above printed iptables rules are correct!

* moblock is running
PID: 9042 CMD: /usr/bin/moblock -p /var/lib/blockcontrol/guarding.p2p -q 92 -t -r 10 -a 20 /var/log/moblock.log

* blockcontrol.wd is running
PID: 9048 CMD: /bin/sh /usr/bin/blockcontrol.wdso it was something in the block lists that was no good?

[DOS286]

Jre,

Thank for the quick response! I have tried to put the settings just as you have said, but now it blocks nothing. I cannot figure it out. I double checked all the files but they all look correct. How can I track down where the error is to fix it?

Before, it blocked some sites, now it does not block any.

I am running Mobloquer as a front end. Could that cause problems?

I did not understand how to implement Notes 1 or 2. I could not find settings in either Mobloquer or settings files that discussed this. Could this be a problem?

Thanks again for your help so far.

[jre]

Thx, and sorry, I had no time this week.


@DOS286:
You are right, seems to be a bug. Use this entry instead:
The whole internet:1.1.1.1-255.255.255.255
Further, to apply the changes you have to do a "sudo blockcontrol reload" or "update" instead. You can verify that it has been applied by checking /var/lib/blockcontrol/guarding.p2p

mobloquer should not cause any problems here.

For Note 1: Edit /etc/blockcontrol/blockcontrol.conf and remove this entry:
WHITE_TCP_OUT="http https"

For Note 2:

sudo blockcontrol stop
Create /etc/blockcontrol/iptables-custom-insert.sh with:
# Block IPv6 completely:
ip6tables -I OUTPUT -j REJECT
ip6tables -I INPUT -j DROP
ip6tables -I FORWARD -j DROP

And /etc/blockcontrol/iptables-custom-remove.sh
# Remove the rules for complete blocking of IPv6:
ip6tables -D OUTPUT -j REJECT
ip6tables -D INPUT -j DROP
ip6tables -D FORWARD -j DROP


@chinaski:
You may send me the problmatic blocklists to jre-phoenix@users.sourceforge.net
Just compress them to a file named blocklists.tar.xz:
tar cvfJ blocklists.tar.xz ~/blocklists.backup/*/downloaded/*

[chinaski]

@chinaski:
You may send me the problmatic blocklistsdone ;)

thanks

edit: oops, it seems the attachment (12.3mb) is too big for your mailbox:

Delivery to the following recipient failed permanently:

jre-phoenix@users.sourceforge.net

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 552 552 Message size exceeds maximum permitted (state 18).

any suggestions? :D

[jre]

Send it directly to jre.phoenix@googlemail.com
I should have thought of that in the first place. Google allows up to 25MB.

[chinaski]

ok everything is on its way :)

btw no problem it's my bad I probably should have warned you before sending the email that I enable *all* lists...

[DOS286]

@jre,

Thanks again. I was on vacation last week. Before you responded, I was playing around with settings and decided that I really did not need a gui and that I should switch to pgl for future support, so I did. It introduced some new questions.

1. How do I add a custom block list? pgl does not have a custom block list to enable in blocklists.list. I tried adding the line and then creating the file without success; but perhaps pgl suffers from the same bug and I should try again with 1.1.1.1 instead of 0.0.0.0? After reading the header comments in blocklists.list I tried putting custom-blocklist.p2p in /var/lib/pgl without success.

2. How do I control pgl from a user login without supperuser privileges? I want the program to limit what my kids can see and do on the internet without me there watching. I set it up under my account and thought that I could do sudo -u me pglcmd stop when the kids are logged in to turn it off. When I do that it asks for the kids password, not mine. That's probably more of a general linux question. Sorry if it's too newbie.

Thanks for the excellent support on this.

[runeh76]

Hi guys

I have problems with Mobloquer and Thunderbird or Evolution email. (Email is Gmail.)
When i log in Ubuntu and open mail, mobloquer block connection "Google Inc".

Okey then i click "Stop blocking this IP"..everything is working, BUT when i reboot, same thing and just DIFFERENT "Google Inc" IP to block.

I tried to reinstall Mobloguer and Blockcontrol (sudo apt-get purge mobloquer) (sudo apt-get purge blockcontrol) but situation was same.
I did remove Mobloguer and everything worked, but i wanna use mobloguer sometimes and get this solved.

What i miss?

runeh

edit:

Got it solved with this: gksu gedit /etc/blockcontrol/blockcontrol.conf
IP_REMOVE="Google Inc"

[jre]

1. How do I add a custom block list? pgl does not have a custom block list to enable in blocklists.list. I tried adding the line and then creating the file without success; but perhaps pgl suffers from the same bug and I should try again with 1.1.1.1 instead of 0.0.0.0? After reading the header comments in blocklists.list I tried putting custom-blocklist.p2p in /var/lib/pgl without success.
There were some problems in the old version, which I fixed some time ago but never released. So I just did that. Please update to 2.0.4 and put your custom list to /var/lib/pgl. Everything should work then (even with 0.0.0.0)


2. How do I control pgl from a user login without supperuser privileges? I want the program to limit what my kids can see and do on the internet without me there watching. I set it up under my account and thought that I could do sudo -u me pglcmd stop when the kids are logged in to turn it off. When I do that it asks for the kids password, not mine. That's probably more of a general linux question. Sorry if it's too newbie.
pgl needs superuser rights - these you can gain with sudo.
So first the administrator has to configure sudo for the specified user to have enough rights. In your case "me" gets superuser rights with sudo, but your kids probably not. sudo always asks for the password of the user who executes it.

sudo -u me pglcmd stop will execute pglcmd with "me"'s rights, not the superuser's. Try
sudo -u me sudo pglcmd stop or
su me
sudo pglcmd stop instead.

This will allow to stop pgl from your kids login, so that your kids can do what they want.

[DOS286]

@jre: Thank you, thank you! all seems to be working as desired.

sudo -u me sudo pglcmd stopwould not work for me. It still asks for my child's password, not mine. But

su me
sudo pglcmd stopworks a champ.

I think that I have only one question left. Sorry to be a pest. How can I see the IP range that was blocked in case I want to white-list it? With moblock, I could issue the "status", or "stats" command (I don't remember which now). But in pglcmd, I get different looking output, which I cannot understand.

Thanks again for all your help.

[jre]

sudo -u me sudo pglcmd stopwould not work for me. It still asks for my child's password, not mine.Grin, seems to have been some stupid advice ... This would just work if your kids were granted your rights with sudo ... which wouldn't be clever ;-)

How can I see the IP range that was blocked in case I want to white-list it? With moblock, I could issue the "status", or "stats" command (I don't remember which now). But in pglcmd, I get different looking output, which I cannot understand.
Just have a look at /var/log/pgl/pgld.log, there you will find lines like these:
Jan 23 01:52:51 OUT: 192.168.178.21:55334 239.255.255.250:1900 UDP || Bogon
The columns are


date of block (Jan 23 01:52:51)
direction (OUT). Possible are outgoing OUT (websurfing, most important for whitelisting), incoming IN (you run a server that someone from the net tries to access), and forward (e.g. routed traffic)
originating IP 192.168.178.21 (this is my LAN IP)
corresponding port 55334
destination IP 239.255.255.250
corresponding port 1900
protocol UDP. Most important here is TCP
range description Bogon

So in this case you could add

239.255.255.250 to WHITE_IP_OUT
1900 to WHITE_UDP_OUT
or Bogon to IP_REMOVE
(Most probably you would choose the first one.)

You'll get stats in a similar format per Mail (daily and on every stop per default to root) or directly on "pglcmd stats".

Thanks your thumbs up! Have fun

[JKarp84]

Seeing as I need a GUI to make things understandable, im using blockcontrol, moblock , and mobloquer.
Problem is Everything is installed fine, and moblock says its running when I look at mobloquer. but if I block microsoft with the microsoft list that comes with my set up by default, I am still able to go to microsoft.com.
I know its not blocking anything, I would just like to know what I should do to fix it. Ive tryed running a search on these forums, but the results for "Moblock not blocking" and "Moblock not working" dont show the results as well as I would hope and Im getting tired of sifting through the posts one page at a time for an answer.
This forum could really use a search thread feature.

[jre]

You probably allowed traffic to port 80 (http) and 443 (https). Therefore websurfing is not checked at all.

You can change that in mobloquer.

To test moblock type "blockcontrol test" in a terminal.

[Gavin77]

It would be nice to have alternative sources for the blocklists as iblocklist.com is currently down so pgl, moblock etc cannot be installed as the lists fail to download.

[lovinglinux]

It would be nice to have alternative sources for the blocklists as iblocklist.com is currently down so pgl, moblock etc cannot be installed as the lists fail to download.

Any info if the downtime is temporary or permanent?

I don't use the automated blocklist download from moblock. So what I do is to untick all lists. You will be able to install moblock that way.

[Gavin77]

Any info if the downtime is temporary or permanent?

I don't use the automated blocklist download from moblock. So what I do is to untick all lists. You will be able to install moblock that way.


I did a google search and found mention of the site being under a ddos attack.

[jre]

iblocklist.com is under a ddos attack since feb 28 around 9pm. Work is done to restore the services. I'll keep you updated about that.

Meanwhile you can use alternate list entries, e.g. from bluetack.co.uk. Just add them to /etc/blockcontrol/blocklists.list

[lovinglinux]

iblocklist.com is under a ddos attack since feb 28 around 9pm. Work is done to restore the services. I'll keep you updated about that.

Meanwhile you can use alternate list entries, e.g. from bluetack.co.uk. Just add them to /etc/blockcontrol/blocklists.list

Thanks for the heads up.

[Gavin77]

The lists are available again now.
Official update from the site owner http://forums.peerblock.com/read.php?3,9886

[Jerriy]

Not sure what's going on but my moblock isn't working Jr.

Here's the result of "moblock status" detailsCurrent IPv4 iptables rules (this may take a while):
Chain INPUT (policy ACCEPT 174 packets, 30733 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 212 packets, 23865 bytes)
pkts bytes target prot opt in out source destination
Please check if the above printed iptables rules are correct!
moblock is not running. ... failed!
blockcontrol.wd is not running. ... failed!

[jre]

Please check /var/log/blockcontrol.log

[Jerriy]

I got the problem: I had sweep-cleaned my "Desktop" that was full of clutter but one of the files that were there was "custom-blocklist.p2p" ](*,)

New file created and problem solved!

[_T_]

First and foremost, thanks for this awesome piece of software. This is by far the best utility in it's category.

I have a quick question about how incoming packets are handled. Are they dropped or blocked? From my understanding, with blocked packets the sender is responded to and with dropped packets the sender receives nothing. In the file blockcontrol.defaults I see the section stating

# Set what happens to matched packets (IP is in the blocklist).
# 0 - DROP them directly (as in MoBlock 0.8).
# 1 - MARK them. Further iptables rules decide what happens to them. E.g. this
# allows to REJECT packets to avoid the long timeout, which occurs when
# packets are DROPped, see below. This setting is also necessary for
# iptables logging to syslog, see below.
REJECT="1"but I'm confused as to the exact meaning. Does this mean if I set REJECT="0" iptables could over-rule this setting? Just in case, here's the relevant section in my blockcontrol.defaults.

# Set how traffic is sent to the IP block daemon.
# 0 - Don't set any iptables rules.
# You or another script/firewall has to do this!
# 1 - Place the iptables rules in separate iptables chains (blockcontrol_in,
# blockcontrol_out and blockcontrol_fw). Afterwards the custom iptables
# scripts will be executed (if they exist).
# 2 - Only set custom iptables rules
# (/etc/blockcontrol/iptables-custom-insert.sh and
# /etc/blockcontrol/iptables-custom-remove.sh)
IPTABLES_SETTINGS="1"

# Activate the iptables chains?
# This section works only for IPTABLES_SETTINGS="1"
# 0 - Do nothing. You or another script/firewall has to do this!
# 1 - Send all NEW traffic to the iptables chains (blockcontrol_in,
# blockcontrol_out and blockcontrol_fw). These iptables rules are inserted
# at the head of the chains INPUT, OUTPUT and FORWARD. It is safe to only
# check NEW traffic.
# 2 - Send all traffic to the iptables chains (blockcontrol_in, blockcontrol_out
# and blockcontrol_fw). These iptables rules are inserted at the head of the
# chains INPUT, OUTPUT and FORWARD. Checking all (not only NEW) traffic
# might cause problems, because the IP block daemon has to check much more
# traffic then. Further, whitelisting gets more complicated, since you have
# to think of both directions, incoming and outgoing. Only do this, if you
# are sure that you want to.
IPTABLES_ACTIVATION="1"

# Set what happens to matched packets (IP is in the blocklist).
# 0 - DROP them directly (as in MoBlock 0.8).
# 1 - MARK them. Further iptables rules decide what happens to them. E.g. this
# allows to REJECT packets to avoid the long timeout, which occurs when
# packets are DROPped, see below. This setting is also necessary for
# iptables logging to syslog, see below.
REJECT="1"

# Set the corresponding MARK
REJECT_MARK="10"

# Set the iptables target for "marked block" packets.
# This section works only for IPTABLES_ACTIVATION="1"
# REJECT_IN is useless for the unpatched MoBlock source (0.8 and 0.9RC2), since
# there matched incoming packets are dropped directly. So the DROP rule in
# the iptables chain blockcontrol_in will never be met.
# Valid values are all iptables targets. Be careful: senseless values are also
# accepted.
# REJECT: The sender of the packet is notified that the packet was blocked.
# DROP: The sender of the packet is not notified that the packet was blocked.
REJECT_IN="DROP"
REJECT_OUT="REJECT"
REJECT_FW="DROP"

I'm asking this because this morning (via mobloquer) I noticed a non-stop flood of incoming attempts being blocked from a chinese IP address, and since I'd prefer to eliminate all chinese traffic (as it's mostly hackers and spammers) I added list.iblocklist.com/lists/cn to my blocklists. This got me to wondering if I'm actually replying (thus making myself visible) to these attempts.

[jre]

Short story: everything is as you want it :-)

With REJECT="1" incoming traffic gets handled by REJECT_IN="DROP". This means traffic is dropped, and this is exactly what you want (same result as for REJECT="0").
So the chinese sender tried to connect, but didn't get any answer so he tried again.

So with your setting REJECT_IN="DROP" (the default setting) you are in "stealth mode" from the outside world (e.g. incoming traffic from China). But at the same time you actively tell your applications that you don't want to connect (REJECT_OUT="REJECT") to China, and thus avoid long waiting periods until the apps give up with a timeout.

[_T_]

Excellent! Thank you very much jre.

[berky]

recently i just started getting these bogon blocks with moblock, but they aren't bogon addresses. the lists appear to block everything or almost everything. what is going on? i uninstalled and reinstalled and it does the same thing. if i stop using the bogon list, it finds it under some malware list.

[jre]

blockcontrol merges all single lists that are specified in /etc/blockcontrol/blocklists.list to one master blocklist. Overlapping and continuous IP ranges are merged to one IP range. IIRC only the description of the first range is kept for the whole new merged range. This explains why an IP is reported by its description to be part of an unrelated range.
I don't know though, why you get so many "bogon" hits. This may be normal (see above), but you may also have a look at the master blocklist /var/lib/blockcontrol/guarding.p2p to see if there are any other IP range descriptions.

You can find out the real IP range by executing
blockcontrol search $IP
Where $IP is the blocked IP. This will show you the original IP range and the blocklist where it was specified.
Since this is a very simple search function that just executes a "grep $IP" on the single blocklists it may be necessary to try a more common search term (Start it with ":" which separates the description and the IP. And just use the beginning of the IP). Repeat this until you find the matching range. E.g.
blockcontrol search :222.108.161.19
blockcontrol search :222.108.161
blockcontrol search :222.108.
I agree that this should be improved ;-)

[berky]

here is what i get:

example "bogon" IP: 66.96.99.10


# blockcontrol search "\:66\.96\."
Checking your currently used blocklists for "\:66\.96\." (case-insensitive):

atma_atma (list.iblocklist.com/lists/atma/atma)
2011-05 Malware .....................:66.96.145.103-66.96.145.103
2011-04 Malware .....................:66.96.145.103-66.96.145.105
2011-05 Malware .....................:66.96.145.105-66.96.145.105
2011-05 Malware .....................:66.96.207.161-66.96.207.161
2011-05 Malware .....................:66.96.207.207-66.96.207.207
2011-05 Malware .....................:66.96.212.230-66.96.212.230
2011-05 Malware .....................:66.96.212.86-66.96.212.86
2011-03 Malware .....................:66.96.214.134-66.96.214.134
2011-03 Malware .....................:66.96.214.215-66.96.214.215
2011-04 Malware .....................:66.96.215.214-66.96.215.214
2011-04 Malware .....................:66.96.215.76-66.96.215.76
2011-05 Malware .....................:66.96.218.85-66.96.218.85
2011-05 Malware .....................:66.96.220.5-66.96.220.5
2011-05 Malware .....................:66.96.221.5-66.96.221.5
2011-05 Malware .....................:66.96.222.152-66.96.222.152
2011-05 Malware .....................:66.96.223.40-66.96.223.40
2011-05 Malware .....................:66.96.240.245-66.96.240.245
2011-03 Malware .....................:66.96.241.38-66.96.241.38
2011-05 Malware .....................:66.96.245.68-66.96.245.68
2011-05 Spammer .....................:66.96.215.214-66.96.215.214
2011-05 Spammer .....................:66.96.215.76-66.96.215.76
2011-03 Spammer .....................:66.96.248.199-66.96.248.199
2011-05 SSH Attack ..................:66.96.201.178-66.96.201.178
2011-05 SSH Attack ..................:66.96.255.69-66.96.255.69

Bluetack_badpeers (list.iblocklist.com/lists/bluetack/bad-peers)
test p2p abusers:66.96.18.9-66.96.18.9

TBG_Business_ISPs (list.iblocklist.com/lists/tbg/business-isps)
E. I. Catalyst:66.96.16.0-66.96.31.255
Equant, Inc.:66.96.32.0-66.96.63.255
HIVELOCITY VENTURES CORP:66.96.80.0-66.96.95.255
Packet Clearing House:66.96.112.0-66.96.127.255
Endurance International Group:66.96.128.0-66.96.191.255
Network Operations Center Inc:66.96.192.0-66.96.255.255

TBG_General_Corporate_Ranges (list.iblocklist.com/lists/tbg/general-corporate-ranges)
SEGUROS LA PREVISORA:66.96.56.96-66.96.56.127
Ket Partners Net Solutions:66.96.207.0-66.96.207.255
Redlight.org:66.96.208.225-66.96.208.254
Alex Beschetnov:66.96.211.192-66.96.211.207
Incyber Advertising Incorporation:66.96.212.2-66.96.212.99
ems10.your-freedom.de:66.96.216.181-66.96.216.181
interservers:66.96.231.115-66.96.231.124
Seventennet Partners:66.96.237.0-66.96.237.255
interservers:66.96.244.5-66.96.244.34
vpn4.world-secure-channel.com:66.96.249.101-66.96.249.101

TBG_Primary_Threats (list.iblocklist.com/lists/tbg/primary-threats)
Schlumberger Network Solutions:66.96.46.0-66.96.47.255
Eternity:66.96.214.135-66.96.214.149
Aspiration Hosting/anti-p2p activity:66.96.224.37-66.96.224.37
Seventennet Partners/anti-p2p activity:66.96.237.251-66.96.237.251
DediCatedNEW/anti-p2p activity:66.96.248.53-66.96.248.53
Network Operations Center/anti-p2p activity:66.96.251.26-66.96.251.32

"\:66\.96\." was found in these lists:
atma_atma (list.iblocklist.com/lists/atma/atma)
Bluetack_badpeers (list.iblocklist.com/lists/bluetack/bad-peers)
TBG_Business_ISPs (list.iblocklist.com/lists/tbg/business-isps)
TBG_General_Corporate_Ranges (list.iblocklist.com/lists/tbg/general-corporate-ranges)
TBG_Primary_Threats (list.iblocklist.com/lists/tbg/primary-threats)

If you don't want to block the above shown ranges, then you may add
"\:66\.96\." to IP_REMOVE in /etc/blockcontrol/blockcontrol.conf.
Or you may remove some of these lists from /etc/blockcontrol/blocklists.list.


This seems to mean that it's not found, but somehow it's getting blocked anyway. my assumption based on what i'm witnessing is that there is a 0.0.0.0/0 block somewhere in the mix that is auto-blocking everything. this only started recently.

Thanks.

[berky]

Also, this just doesn't seem right, but I could be wrong:


<stop moblock>
# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


<start moblock>
# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
blockcontrol_in all -- 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14

Chain FORWARD (policy ACCEPT)
target prot opt source destination
blockcontrol_fw all -- 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
blockcontrol_out all -- 0.0.0.0/0 0.0.0.0/0 state NEW mark match !0x14

Chain blockcontrol_fw (1 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0 mark match 0xa
RETURN all -- 0.0.0.0/0 10.11.12.254
RETURN all -- 10.11.12.0/24 10.11.12.0/24
NFQUEUE all -- 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Chain blockcontrol_in (1 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0 mark match 0xa
RETURN all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 10.11.12.0/24 0.0.0.0/0
RETURN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
NFQUEUE all -- 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92

Chain blockcontrol_out (1 references)
target prot opt source destination
REJECT all -- 0.0.0.0/0 0.0.0.0/0 mark match 0xa reject-with icmp-port-unreachable
RETURN all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 0.0.0.0/0 10.11.12.254
RETURN all -- 0.0.0.0/0 10.11.12.0/24
RETURN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
RETURN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
RETURN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
NFQUEUE all -- 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92


why is the 'reject' line in there with a 0/0 destination? doesn't iptables get populated with every subnet from all of the block lists, or am I not comprehending what moblock does?



****
EDIT
****

I disabled the following lists and everything appears to be working ok now:

atma/atma
bluetack/bogon
tbg/bogon

i'm not sure what these lists are supposed to do, but they seem to be messing everything up.

[jre]

Indeed your "search" results don't explain the problem. But it may be a bigger range not matching your search pattern, in the worst case indeed even a 0.0.0.0-255.255.255.255. We'll try to add a real search function to pgld.

But it seems you found the solution on your own.

atma description:
Attackers who try to spy or remotely control others' computers by means such Microsoft remote terminal, SSH, Telnet or shared desktops.
Threats for email servers or users: spiders/bots, account hijacking, etc.
Sites spreading virus, trojans, spyware, etc. or just being used by them to let their authors know that a new computer has been infected.
Threats for servers: exploits, fake identities/agents, DDoS attackers, etc.
Port scans, which are the first step towards more dangerous actions.
Malicious P2P sharers or bad peers who spread malware, inject bad traffic or share fake archives.

TBGs bogon explanation (bluetack is very similar): This list contains ranges from which no traffic should be appearing on the internet. These ranges are either for internal use of some sort or are address space not currently in use.

For the REJECT line: this is correct, because it also contains the "mark match 0xa". This means that it is applied to all packets that where marked by moblock to be blocked. This is essential!

[Jerriy]

Hey Jre I got in trouble.

I was in Ubuntu and I did a bit of a cleanup using the standardly avalilable "Computer Janitor" ubuntu application and lo and be hold it turned out that moblock was in there. Not sure how it ended up there all of a sudden (I've been using both for the last few years without a hitch) but anyway now I'm without Moblock on my pc.

I went to your website (http://moblock-deb.sourceforge.net/) to reinstall it but it failed. I put this indeb http://archive.ubuntu.com lucid main universeIt gets rejected :-(

[Jerriy]

Failed to fetch http://archive.ubuntu.com/dists/lucid/main/binary-i386/Packages.gz 404 Not Found [IP: 91.189.88.45 80]
Failed to fetch http://archive.ubuntu.com/dists/lucid/universe/binary-i386/Packages.gz 404 Not Found [IP: 91.189.88.45 80]
Some index files failed to download, they have been ignored, or old ones used instead.

[jre]

In most cases you are already fine withsudo add-apt-repository ppa:jre-phoenix/ppa This will get you this sources.list entry: deb http://ppa.launchpad.net/jre-phoenix/ppa/ubuntu lucid main

The line that you entered is only needed if your package manager complains about missing dependencies (libnetfilter-queue and libnfnetlink). But here you are right, I forgot /ubuntu in the instructions, so you'd need
deb http://archive.ubuntu.com/ubuntu YOURDIST main universe
But I guess this is already part of your system.

[Jerriy]

Thanks jr!

Installed.

But I've one more question: when I reinstalled moblock a blue background colored setup-menu appeared within the terminal and I took the steps and installed the thing.

Now my question is: is it possible to reactivate that menu now (after install and while moblock is activated)?

[jre]

Yes, just run
sudo dpkg-reconfigure blockcontrol

[jre]

PeerGuardian Linux 2.1.0 - The GUI release!
Today we proudly present to you: pgl 2.1.0, including the long-anticipated pgl-gui. Try it, test it, report back. If you don't tell us otherwise the days of moblock, blockcontrol and mobloquer will soon be over.

Packages for lucid, maverick and natty are available as usual in my ppa (https://launchpad.net/~jre-phoenix/+archive/ppa). (oneiric currently fails to build, I'm on it.)

[Gavin77]

Thanks a lot for the gui, I can finally stop using tail now :)

[Gavin77]

Previous version of PGL automatically whitelisted ports 80 & 443 but upgrading didn't keep that setting. No big deal but someone might wonder why web pages don't work anymore :)