Re: General MoBlock thread

I'm slowly moving from mobloquer to a command-line/script setup and need some help to check if I'm doing something wrong.

Let me explain first how I'm using moblock.

1 - Instead of using the default lists from bluetack, I have a script that download several lists from different sources, extract the compressed files, clean up comment lines and typos, then append and merge specific lists into different compilation lists, with variable degrees of protection, which I call "profiles".

2 - So I have merged lists for web browsing, gaming, p2p and generic use, that can be easily enabled/disabled in moblock.

3 - I also have different /etc/default/moblock file for each profile, so I can configure them with different permissions or whatever. For example the browsing profile has WHITE_TCP_OUT="http https", while the others do not. Each profile also has the following specific files:

blocklists.list
iptables-custom-insert.sh
iptables-custom-remove.sh

I have a script for each profile, so whenever I launch them, they replace the configuration files in /etc/moblock/ directory with the ones above, so each profile end up with it's own sets of blocklists, configurations and iptable scripts.

Here is an example of a script that launch a single profile. I have included comments in the code.

Since iptables are a little bit overwhelming to me, I'm still using Firestarter to generate basic firewall rules, in which no ports are open and outgoing policy is restrictive (whitelist traffic). That's why the profile script stop and start Firestarter just after stopping moblock, so It can restore my default firewall rules.

When I start a profile like the one for p2p activity, it opens the necessary port in the iptables using the profile iptables-custom-insert.sh

In this case, the iptables-custom-insert.sh clears the INBOUND and OUTBOUND Firestarter chains, recreate the default rules which Firestarter would normally add, without the restrictive rules for outbound connections (change policy to permissive) and add the rules necessary to open the port for incoming connections (INBOUND chain). Here is the script:

Whenever I stop moblock manually, the iptables-custom-remove.sh replaces the INBOUND and OUTBOUND Firestarter chains with default values, thus restoring the restrictive outbound policy and closing any open port. If I launch another profile instead, the script will also stop moblock (iptables-custom-remove.sh will run), then stop and start Firestarter just in case something goes wrong with the iptables-custom-remove.sh and only then will copy the new moblock configuration files prior to restarting moblock with the new profile settings. Here is the iptables-custom-remove.sh scrip for the p2p profilet:

With this setup I can easily launch a profile script from a panel launcher, thus changing the configuration of Firestarter rules, based on ports I need to open and required outbound policy. At the same time, blocklists lists will be reloaded and moblock will be restarted, inserting rules according to the profile I'm using.

The only problem is that, if I decide to change my Firestarter basic configuration (which is sometimes a temptation) I have to manually update moblock scripts to perform the necessary rules replacements when starting/stopping. Additionally, If I manually enable/disable blocklists using mobloquer GUI, the scripts won't be updated accordingly. So, to be safe I have to avoid changing Firestarter or Moblock configurations using their GUI.

I guess I could uninstall Firestarter and create the entire iptable using moblock's custom scripts right? If possible to use moblock this way, is there any rule necessary to properly handle those packets marked by moblock (not in the blocklist)?

If I decide to replicate Firestarter rules to add them to moblock's custom scripts, do I need to create INBOUND and OUTBOUND chains or INPUT and OUTPUT are enough to do the job?

I don't know much about iptables, but it seems to me that any new allowed/blocked IP or service rule added using Firestarter GUI it's only included in the OUTBOUND and INBOUND chains, so why so many rules in the INPUT and OUTPUT chains? Are all necessary?

The final question: Is it possible to configure Firestarter and then export the rules to a script so I can use it to create moblock's custom scripts?

Sorry if I'm asking things not directly related to moblock, but I guess this is the best thread to post them. If someone could review my rules and procedures to verify if I'm doing something wrong would be much appreciated.

Re: General MoBlock thread

AFAIK firestarter is simply a wrapper which inserts iptables rules (and not a permanently running daemon).

But it's definitely coorect that you first stop moblock, then replace its configuration and then start it again.

So perhaps you have some overkill in your first script but it seems correct to me.

General iptables:
Please also refer to post #1 in this thread.

INPUT and OUTPUT are the chains that are always there.

INBOUND and OUTBOUND are those created by firestarter and
moblock_in and moblock_out those by moblock-control.

E.g. incoming traffic starts at the head of INPUT and passes through the rules towards the bottom. Every rule is configured to match certain packets based on their destination/source, port, state, mark, ...

When it hits a REJECT or DROP it will be blocked forever.
When it hits ACCEPT it will be definitely accepted.
When it hits INBOUND or moblock_in it changes to these chains.
There if it hits RETURN it will go back to INPUT.
When it hits NFQUEUE it will be checked by moblock and get a MARK which marks him either to be blocked or not to be blocked. Then it will start at the head of INPUT again, now being MARKed so that its travells will take a new route.
If traffic makes it till the bottom of the line without being blocked its fate will be decided by the chain policy.

So, yes, the rules in INPUT and in INBOUND are necessary.

Please note that I did not have a datailed look of your iptables commands but it sounds good.

To allow usage of mobloquer you may copy the /etc/default/moblock and the other conf files to your profile when you stop the profile.

To avoid the insertion of the firestarter iptables rules (I think you forget those from INPUT here) you might also create firestarter configuration files for every profile and then do

Re: General MoBlock thread

jre, thank you very much for this detailed explanation. I have already tried to copy Firestarter configuration. It works for replacing rules, but it doesn't work when you need to change default policy. I don't know why. Anyway, I decided to uninstall Firestarter and make all iptables rules with moblock scripts.

Now, whenever I stop moblock, the "remove" script flushes the iptables, remove additional chains and set the default policy (INPUT, OUTPUT and FORWARD) to DROP, thus working like Firestarter lock feature and preventing network activity while moblock is turned off. The code is below:

When I start moblock again, it will insert all rules in the INPUT/OUTPUT chains and create two new chains (INBOUND/OUTBOUND) which I use just for logging and dropping packets not accepted by the default chains. Here is the "insert" script:

As far as I understand, I don't have to be concerned anymore with moblock chains being correctly inserted before the other rules, but is there any rules in my script that could conflict with moblock's marking feature?

I have another question, not related to the post above. While using the tail command to monitor moblock's log, I have noticed that sometimes moblock stops and reload itself. I receive the following message in the log.

Code:

Got SIGHUP! Dumping and resetting stats, reloading blocklist

Is this normal? I guess while doing this, moblock is letting everything to pass through...

Re: General MoBlock thread

Originally Posted by lovinglinux

As far as I understand, I don't have to be concerned anymore with moblock chains being correctly inserted before the other rules, but is there any rules in my script that could conflict with moblock's marking feature?

The way you do it seems correct to me.
Just don't insert any rule that MARKs packages and always have the rules that send target to the moblock chains as first ones (so you chose correct to append them (-A) and not insert (-I) them).

Originally Posted by lovinglinux

I have another question, not related to the post above. While using the tail command to monitor moblock's log, I have noticed that sometimes moblock stops and reload itself. I receive the following message in the log.

Code:

Got SIGHUP! Dumping and resetting stats, reloading blocklist

Is this normal? I guess while doing this, moblock is letting everything to pass through...

No it doesn't. The problem you describe is only happening on "restart" when the iptables are removed and inserted again.
You can test it yourself: Ping a IP from the blocklist (e.g. your router with setting WHITE_LOCAL="2" so that it doesn't get whitelisted).
See the answers while moblock is not running.
Then start moblock: there will be a short break until moblock is loaded fully, then you will get rejects.
Then do a reload: Again a break and afterwards rejects, but no answers of the router.

This is because traffic is always sent by the iptables rules to userspace (NFQUEUE). If noone is listening there the packets will just get DROPed, but they may never leave userspace without someone (moblock) telling them so.

Re: General MoBlock thread

Originally Posted by jre

The way you do it seems correct to me.
Just don't insert any rule that MARKs packages and always have the rules that send target to the moblock chains as first ones (so you chose correct to append them (-A) and not insert (-I) them).

No it doesn't. The problem you describe is only happening on "restart" when the iptables are removed and inserted again.
You can test it yourself: Ping a IP from the blocklist (e.g. your router with setting WHITE_LOCAL="2" so that it doesn't get whitelisted).
See the answers while moblock is not running.
Then start moblock: there will be a short break until moblock is loaded fully, then you will get rejects.
Then do a reload: Again a break and afterwards rejects, but no answers of the router.

This is because traffic is always sent by the iptables rules to userspace (NFQUEUE). If noone is listening there the packets will just get DROPed, but they may never leave userspace without someone (moblock) telling them so.

Thank you again. I'm less worried now, but I still don't understand why moblock is reloading the blocklists if I didn't used the reload command. Does it reload by itself on regular basis?

Re: General MoBlock thread

Thank you again. I'm less worried now, but I still don't understand why moblock is reloading the blocklists if I didn't used the reload command. Does it reload by itself on regular basis?

Oh, didn't I mention that?
This is caused by the cron job (/etc/cron.daily/moblock). Once a day the blocklsits are updated. afterwards MoBlock gets reloaded.
You can turn this automatic update off by setting in /etc/default/moblock:
MOBLOCK_CRON="0"

Still, a manual "moblock-control update" does a reload at the end, too.

Re: General MoBlock thread

Originally Posted by jre

Oh, didn't I mention that?
This is caused by the cron job (/etc/cron.daily/moblock). Once a day the blocklsits are updated. afterwards MoBlock gets reloaded.
You can turn this automatic update off by setting in /etc/default/moblock:
MOBLOCK_CRON="0"

Re: General MoBlock thread

Strange ....
Please look in /var/log/moblock-control.log what is happening at the time when moblock reloads. From moblock-control this will only happen on "update" (either manually or by the cron job) or "reload".
I'm not the author of MoBlock (the daemon). Maybe there is something built in there that reloads it frequently.

Still, whatever the reason for the reload is: I see no reason to worry, since (as shown above) the reload does not break the protection. But of course I'd like to know what's happening there, too