Re: General MoBlock thread
Quote:
Originally Posted by
lovinglinux
Thanks for the tip. Unfortunately, you can't install iplist and moblock at the same time.
Yes, thanks!
iplist and moblock conflict because they would mess up the MARKing of the packets when they run at the same time.
Of course just having them installed at the same time would not cause problems, but I want to keep with the "conflicts" to prevent the MARKing problems.
The peerguardnf command that I told you is safe to use.
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.
Code:
#!/bin/bash
#kill mobloquer and firestarter just in case
killall mobloquer
sudo killall firestarter
#stop moblock, removing it's ipchains from the iptable
sudo moblock-control stop
#reload firestarter to restore the default iptable configuration
sudo firestarter --stop
sudo firestarter --start
#replace moblock configuration files according to the profile used
sudo cp ~/Databases/Blocklists/Config/moblock-browsing /etc/default/moblock
sudo cp ~/Databases/Blocklists/Config/blocklists-browsing.list /etc/moblock/blocklists.list
sudo cp ~/Databases/Blocklists/Config/iptables-custom-insert-browsing.sh /etc/moblock/iptables-custom-insert.sh
sudo cp ~/Databases/Blocklists/Config/iptables-custom-remove-browsing.sh /etc/moblock/iptables-custom-remove.sh
#update the allow lists from the merged blocklists directory
sudo cp ~/Databases/Blocklists/Merged/allow-out.p2p /etc/moblock/allow-out.p2p
sudo cp ~/Databases/Blocklists/Merged/allow-in.p2p /etc/moblock/allow-in.p2p
sudo cp ~/Databases/Blocklists/Merged/allow-fw.p2p /etc/moblock/allow-fw.p2p
#reload moblock to update the profile blocklists in case they have been updated
sudo moblock-control reload
#start moblock to insert it's chains and custom iptable rules
sudo moblock-control start
sleep 10 && sudo moblock-control test
#load moblock log
tail -f /var/log/moblock.log &
#launch a panel alert to notify the process is finished
zenity --text "Moblock Browsing Profile Running" --notification
#replace the desktop background with profile specific wallpaper to show which profile is running
gconftool -t string -s /desktop/gnome/background/picture_filename ~/Pictures/Wallpaper/moblock/browsing.png
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.
Here are my default iptable rules, without moblock chains:
EDIT: removed iptables rules
This profile, which uses my Firestarter basic iptable configuration, allows outbound connections on ports 80, 443, 993 and 6667 only, plus local network related IP's and services. It does not allow incoming connections (except from the router IP).
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:
Code:
iptables -F INBOUND
iptables -A INBOUND -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INBOUND -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INBOUND -s 192.168.x.x -j ACCEPT
iptables -A INBOUND -p tcp -m tcp --dport 49152 -j ACCEPT
iptables -A INBOUND -p udp -m udp --dport 49152 -j ACCEPT
iptables -A INBOUND -j LSI
iptables -F OUTBOUND
iptables -A OUTBOUND -p icmp -j ACCEPT
iptables -A OUTBOUND -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTBOUND -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTBOUND -d 208.107.188.17 -j LSO
iptables -A OUTBOUND -j ACCEPT
And this is the resulting iptable rules (including moblock's chains)
EDIT: removed iptables rules
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:
Code:
iptables -F INBOUND
iptables -A INBOUND -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INBOUND -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INBOUND -s 192.168.x.x -j ACCEPT #router internal IP
iptables -A INBOUND -j LSI
iptables -F OUTBOUND
iptables -A OUTBOUND -p icmp -j ACCEPT
iptables -A OUTBOUND -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTBOUND -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTBOUND -d 192.168.x.x -j ACCEPT #router internal IP
iptables -A OUTBOUND -d 192.168.x.x -j ACCEPT #notebook internal IP
iptables -A OUTBOUND -d xxx.xxx.x.xx -j ACCEPT #DNS
iptables -A OUTBOUND -d xxx.xxx.x.xxx -j ACCEPT #DNS
iptables -A OUTBOUND -d 200.177.254.149 -j ACCEPT
iptables -A OUTBOUND -p tcp -m tcp --dport 80 -s 192.168.x.x -j ACCEPT
iptables -A OUTBOUND -p udp -m udp --dport 80 -s 192.168.x.x -j ACCEPT
iptables -A OUTBOUND -p tcp -m tcp --dport 443 -s 192.168.x.x -j ACCEPT
iptables -A OUTBOUND -p udp -m udp --dport 443 -s 192.168.x.x -j ACCEPT
iptables -A OUTBOUND -p tcp -m tcp --dport 993 -s 192.168.x.x -j ACCEPT
iptables -A OUTBOUND -p udp -m udp --dport 993 -s 192.168.x.x -j ACCEPT
iptables -A OUTBOUND -p tcp -m tcp --dport 6667 -s 192.168.x.x -j ACCEPT
iptables -A OUTBOUND -p udp -m udp --dport 6667 -s 192.168.x.x -j ACCEPT
iptables -A OUTBOUND -j LSO
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
profile 1 start:
Code:
firestarter stop
moblock-control stop
copy firestarter.configuration files profile1
copy moblock-control.configuration files profile1
firestarter start
moblock-control reload [no more needed for the next version moblock-control 1.1]
moblock-control start
profile 1 stop:
Code:
copy back firestarter.configuration files profile1 to your home
copy back moblock-control.configuration files profile1 to your home
I think this setup allows that you use both GUIs (after firestarter changes you have to restart moblock-control) as long as you do the "stop" to save its changes.
But I'm not common with firestarter and don't know what configuration files to use.
I hope this answers your questions, just write again if you miss something.
jre
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:
Code:
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
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:
Code:
iptables -N INBOUND
iptables -N OUTBOUND
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i eth0 -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i eth0 -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 192.168.x.x -j ACCEPT #router internal IP
iptables -A INPUT -s xxx.xxx.x.xx -j ACCEPT #DNS
iptables -A INPUT -s xxx.xxx.x.xxx -j ACCEPT #DNS
iptables -A INPUT -i eth0 -d 255.255.255.255 -j DROP
iptables -A INPUT -d 192.168.2.255 -j DROP
iptables -A INPUT -d 224.0.0.0/8 -j DROP
iptables -A INPUT -s 224.0.0.0/8 -j DROP
iptables -A INPUT -s 255.255.255.255 -j DROP
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p icmp -j INBOUND
iptables -A INPUT -j INBOUND
iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP
iptables -A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 53 -s 192.168.x.x -d xxx.xxx.x.xx -j ACCEPT #DNS
iptables -A OUTPUT -o eth0 -p udp -m udp --dport 53 -s 192.168.x.x -d xxx.xxx.x.xx -j ACCEPT #DNS
iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 53 -s 192.168.x.x -d xxx.xxx.x.xx -j ACCEPT #DNS
iptables -A OUTPUT -o eth0 -p udp -m udp --dport 53 -s 192.168.x.x -d xxx.xxx.x.xx -j ACCEPT #DNS
iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 80 -s 192.168.x.x -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -m udp --dport 80 -s 192.168.x.x -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 443 -s 192.168.x.x -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -m udp --dport 443 -s 192.168.x.x -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 993 -s 192.168.x.x -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -m udp --dport 993 -s 192.168.x.x -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 6667 -s 192.168.x.x -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp -m udp --dport 6667 -s 192.168.x.x -j ACCEPT
iptables -A OUTPUT -d 224.0.0.0/8 -j DROP
iptables -A OUTPUT -s 224.0.0.0/8 -j DROP
iptables -A OUTPUT -s 255.255.255.255 -j DROP
iptables -A OUTPUT -m state --state INVALID -j DROP
iptables -A OUTPUT -d 192.168.x.x -j ACCEPT #router internal IP
iptables -A OUTPUT -d 192.168.x.x -j ACCEPT #notebook internal IP
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT
iptables -A OUTPUT -j OUTBOUND
iptables -A OUTPUT -j DROP
iptables -A INBOUND -j LOG --log-prefix '*** INBOUND ***' --log-level 4
iptables -A INBOUND -j DROP
iptables -A OUTBOUND -j LOG --log-prefix '*** OUTBOUND ***' --log-level 4
iptables -A OUTBOUND -j REJECT
And here the iptables output :
Code:
Current iptables rules (this may take awhile):
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 moblock_in all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW MARK match !0x14
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 192.168.x.x 0.0.0.0/0
0 0 ACCEPT all -- * * xxx.xxx.x.xx 0.0.0.0/0
0 0 ACCEPT all -- * * xxx.xxx.x.xxx 0.0.0.0/0
0 0 DROP all -- eth0 * 0.0.0.0/0 255.255.255.255
0 0 DROP all -- * * 0.0.0.0/0 192.168.2.255
0 0 DROP all -- * * 0.0.0.0/0 224.0.0.0/8
0 0 DROP all -- * * 224.0.0.0/8 0.0.0.0/0
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 state INVALID
1 112 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 INBOUND icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 INBOUND all -- * * 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 moblock_fw all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW MARK match !0x14
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
2 168 moblock_out all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW MARK match !0x14
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT udp -- * eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * eth0 192.168.x.x xxx.xxx.x.xx tcp dpt:53
0 0 ACCEPT udp -- * eth0 192.168.x.x xxx.xxx.x.xx udp dpt:53
0 0 ACCEPT tcp -- * eth0 192.168.x.x xxx.xxx.x.xx tcp dpt:53
0 0 ACCEPT udp -- * eth0 192.168.x.x xxx.xxx.x.xx udp dpt:53
0 0 ACCEPT tcp -- * eth0 192.168.x.x 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT udp -- * eth0 192.168.x.x 0.0.0.0/0 udp dpt:80
0 0 ACCEPT tcp -- * eth0 192.168.x.x 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT udp -- * eth0 192.168.x.x 0.0.0.0/0 udp dpt:443
0 0 ACCEPT tcp -- * eth0 192.168.x.x 0.0.0.0/0 tcp dpt:993
0 0 ACCEPT udp -- * eth0 192.168.x.x 0.0.0.0/0 udp dpt:993
0 0 ACCEPT tcp -- * eth0 192.168.x.x 0.0.0.0/0 tcp dpt:6667
0 0 ACCEPT udp -- * eth0 192.168.x.x 0.0.0.0/0 udp dpt:6667
0 0 DROP all -- * * 0.0.0.0/0 224.0.0.0/8
0 0 DROP all -- * * 224.0.0.0/8 0.0.0.0/0
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 state INVALID
0 0 ACCEPT all -- * * 0.0.0.0/0 192.168.x.x
0 0 ACCEPT all -- * * 0.0.0.0/0 192.168.x.x
1 112 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 OUTBOUND all -- * * 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 INBOUND (2 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `*** INBOUND ***'
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTBOUND (2 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `*** OUTBOUND ***'
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain moblock_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 -- * * 192.168.x.0/24 192.168.x.0/24
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 239.255.255.250-239.255.255.250
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 239.255.255.250-239.255.255.250
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 224.0.0.22-224.0.0.22
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 224.0.0.22-224.0.0.22
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range xxx.xxx.x.xx-xxx.xxx.x.xx
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range xxx.xxx.x.xxx-xxx.xxx.x.xxx
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range xxx.xxx.x.xx-xxx.xxx.x.xxx
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range xxx.xxx.x.xxx-xxx.xxx.x.xxx
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 192.168.2.255-192.168.2.255
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 192.168.2.255-192.168.2.255
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 192.168.x.x-192.168.x.x
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 192.168.x.x-192.168.x.x
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 127.0.0.1-127.0.0.1
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 127.0.0.1-127.0.0.1
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92
Chain moblock_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.x.0/24 0.0.0.0/0
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 239.255.255.250-239.255.255.250
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 224.0.0.22-224.0.0.22
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range xxx.xxx.x.xxx-xxx.xxx.x.xxx
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range xxx.xxx.x.xxx-xxx.xxx.x.xxx
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 192.168.2.255-192.168.2.255
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 192.168.x.x-192.168.x.x
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 192.168.x.x-192.168.x.x
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 127.0.0.1-127.0.0.1
0 0 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 92
Chain moblock_out (1 references)
pkts bytes target prot opt in out source destination
1 84 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.x.0/24
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 239.255.255.250-239.255.255.250
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 224.0.0.22-224.0.0.22
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range xxx.xxx.x.xxx-xxx.xxx.x.xxx
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range xxx.xxx.x.xxx-xxx.xxx.x.xxx
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 192.168.2.255-192.168.2.255
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 192.168.x.x-192.168.x.x
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 192.168.x.x-192.168.x.x
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 140.211.166.66-140.211.166.66
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 destination IP range 127.0.0.1-127.0.0.1
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
1 84 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 is 8071.
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
Quote:
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).
Quote:
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
Quote:
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
Quote:
Originally Posted by
lovinglinux
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
Quote:
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"
That won't turn off the daily reloading though.
Re: General MoBlock thread
Quote:
Originally Posted by
skipo
That won't turn off the daily reloading though.
Yep. I have MOBLOCK_CRON="0" and it still reload.
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 ;-)