Tag Archives: IPTables

Blocking social networks using iptables

Once on one of the NAT servers I needed to block some sites.

If the sites are located on several IP addresses, then you need to find out these ranges of IP addresses, for example, look for VKontakte on bgp.he.net, for example, a list of subnets for one of the AS belonging to VK “http://bgp.he.net/AS47541#_prefixes”.

When networks or hosts are known, add rules for them in iptables, for example:

/sbin/iptables -A FORWARD -s 87.240.128.0/18 -j DROP
/sbin/iptables -A FORWARD -s 95.142.192.0/20 -j DROP

Thus, we prohibit the passage of the traffic of these networks through the server.

See also my articles:
Blocking social networks on Cisco
Blocking social networks on Mikrotik routers

IPTables rules for DHCP

Assume the default server INPUT DROP, now I will give an example of a simple rule permitting DHCP requests to the server, this will be enough for clients to get IP from the server (where em1 is the network interface on which the DHCP server is running):

iptables -I INPUT -p udp -i em1 --dport 67 -j ACCEPT

To remove a rule, we’ll specify the same command, replacing -A with -D, for example:

iptables -D INPUT -p udp -i em1 --dport 67 -j ACCEPT

Restrict access by IP is strictly impossible, because clients that do not have an IP address usually send a broadcast request from the IP address 0.0.0.0 to 255.255.255.255, and extend already unicast from their received IP.

Here is an example of an IP restriction (where 192.168.5.1 is the IP on which the DHCP server is running, and 172.17.0.0/16 is the network of clients with which it is allowed to renew the IP lease):

iptables -t filter -A INPUT -i em1 -p udp -s 0.0.0.0 --sport 68 -d 255.255.255.255 --dport 67 -j ACCEPT
iptables -t filter -A INPUT -i em1 -p udp -s 0.0.0.0 --sport 68 -d 192.168.5.1 --dport 67 -j ACCEPT
iptables -t filter -A INPUT -i em1 -p udp -s 172.17.0.0/16 --sport 68 -d 192.168.5.1 --dport 67 -j ACCEPT

See also my articles:
Configuring IPTables
IPTables rules for TFTP

The solution to the error “Another app is currently holding the xtables lock”

Recently noticed on one server with the billing system ABillS, that when the script /etc/ppp/ip-up is executed in bulk, an error occurs:

Another app is currently holding the xtables lock. Perhaps you want to use the -w option?

Having looked at the script code, I found that there are two rules among the iptables rules that can slow down the work, namely, the search for ipoe interfaces by two commands:

IPTABLES="/sbin/iptables"
EXIST=`${IPTABLES} -t nat -L PREROUTING -v | grep "${IFNAME} ";  ${IPTABLES} -L -v | grep DROP | grep "${IFNAME} "`

To raise 3000 sessions, it took more than 30 minutes and some rules could not be added at all or deleted by the script.
By default, if the -L option is used, iptables resolves the IP addresses and tries to display DNS names instead of them, which takes a long time, and so that this does not happen, you need to add the -n option, and just in case I added the -w 20 switch, which will cause the new rules to be postponed until 20 seconds if iptables is already busy executing another command:

IPTABLES="/sbin/iptables"
IPTABLES_WAIT="-w 20"
EXIST=`${IPTABLES} $IPTABLES_WAIT -t nat -n -L PREROUTING -v | grep "${IFNAME} ";  ${IPTABLES} $IPTABLES_WAIT -n -L -v | grep DROP | grep "${IFNAME} "`

After that, the script with iptables rules began to work out instantly.
Since the old rules are not all fulfilled, I checked this by counting some by the team:

iptables -n -L -t nat -v | grep DNAT | wc -l

And I checked with the number of sessions, the rules were obviously smaller, so I had to clear all rules and restart the session so that the /etc/ppp/ip-up script worked correctly, this time at 3000 sessions it did its job in less than a minute.
Note that in the / etc / ppp / scripts, it’s better not to use iptables rules.