Limiter le nombre de connexions par IP

26/11/2020 Categories: Réseau, Sécurité Tags: , Comments off

Source: petitchevalroux.net

Une journée de travail plus tard, j’ai enfin trouvé comment limiter le nombre de connexion par IP avec iptable sur le port 80. Pour se faire j’utilise l’extension match recent d’iptables qui permet de créer et de gérer des règles en fonction d’une liste d’adresses IP.

Limitation

Comme ces règles sont basées sur les adresses IP elles ne peuvent pas vous protéger contre des attaques DDOS(Distributed Denial Of Service).

Blocage simple

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --name BLACKLIST --set
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --name BLACKLIST --update --seconds 10 --hitcount 10 --rttl -j DROP

Avec les deux règles précédentes je refuse (DROP) les nouvelles (-m state –state NEW) connexions entrantes (-A INPUT) au port http (–dport 80) qui atteignent le taux de 10 connexions (–hitcount 10) sur une période de 10 secondes (–seconds 10) et qui utilisent le protocol tcp (-p tcp).

La première règle sert à mettre à jour l’adresse IP dans la liste BLACKLIST et la seconde règle permet de limiter les connexions.

Bloquer les attaquants sur une période plus grande que le taux

Le problème des règles précédentes est que l’adresse IP attaquante est bloquée sur une période glissante qui n’est que de 10 secondes.

Pour bloquer sur une période différentes que celle qui définit par le taux limite j’ai mis en place les règles suivantes :

Création d’une nouvelle chaine BLACKLIST :

iptables -N BLACKLIST

Lorsqu’un paquet arrive dans la chaine BLACKLIST on le drop et on ajoute son IP dans la liste BLACKLIST :

iptables -A BLACKLIST -m recent --name BLACKLIST --set -j DROP

On bloque les paquets pour une période de 60 secondes :

iptables -A INPUT -m recent --update --name BLACKLIST --seconds 60 --rttl -j DROP

Quand un paquet arrive en entrée sur le port 80 on met son IP dans la liste COUNTER :

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --name COUNTER --set

Si un paquet arrive en entrée et qu’il dépasse le taux on le redirige dans la chaine BLACKLIST :

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --name COUNTER --update --seconds 
10 --hitcount 10 --rttl -j BLACKLIST

Tuning de l’extension recent

Par défaut l’extension recent d’iptables garde 100 adresses IP différentes dans les listes et garde 20 paquets par IP. En faisant quelques tests je me suis rendu compte que ce n’était pas suffisant donc je vous donne les commandes qui vont bien.

Changer le nombre d’ip du mode recent

chmod u+w /sys/module/xt_recent/parameters/ip_list_tot
echo 200 > /sys/module/xt_recent/parameters/ip_list_tot
chmod u-w /sys/module/xt_recent/parameters/ip_list_tot

Changer le nombre de paquet par ip du mode recent

chmod u+w /sys/module/xt_recent/parameters/ip_pkt_list_tot
echo 200 > /sys/module/xt_recent/parameters/ip_pkt_list_tot
chmod u-w /sys/module/xt_recent/parameters/ip_pkt_list_tot

Surveiller les listes d’ip

Pour informations les listes d’IP de l’extension recent sont disponibles dans /proc/net/xt_recent/

root@home:~# ls /proc/net/xt_recent/* -alh
-rw-r--r-- 1 root root 0  4 juin  09:17 /proc/net/xt_recent/BLACKLIST
-rw-r--r-- 1 root root 0  4 juin  09:17 /proc/net/xt_recent/COUNTER

Un petit extrait du contenu de ma liste COUNTER :

src=81.245.XX.XXX ttl: 56 last_seen: 634716668 oldest_pkt: 7 634716652, 634716665, 634716666, 634716667, 634716667, 634716668, 634716668
src=67.xx.115.XXX ttl: 55 last_seen: 634719164 oldest_pkt: 1 634719164
src=2XX.46.X9X.XX ttl: 120 last_seen: 634831058 oldest_pkt: 1 634831058
src=6X.2XX.1XX.1X6 ttl: 60 last_seen: 634821958 oldest_pkt: 1 634821958
src=81.XX.143.3X ttl: 56 last_seen: 634806578 oldest_pkt: 1 634806578

Le format des listes est composé d’une ligne par adresse IP. Sur chaque ligne, en plus de l’adresse IP on trouve dans l’ordre :

  • Le time to live (ttl)
  • Le timestamp qui correspond au dernier paquet de cette adresse (last_seen)
  • Le nombre de paquets (oldest_pkt)
  • La liste des timestamps des derniers paquets
Categories: Réseau, Sécurité Tags: ,

Some iptables modules you probably don’t know about

26/11/2020 Categories: Réseau, Sécurité Tags: , , Comments off

Source: tummy.comsean reifschneider

I admit it, at the beginning of Rusty’s presentation on iptables years ago, I think it was at the Linux Expo or Raleigh back in the ’90s, I thought: “Just what we need, another network filtering system.” This was shortly after we made the change from ipfwadm to ipchains with little benefit (in fact, some lack of functionality, IIRC) and a re-learning. Rusty won me over pretty quickly though…

One of the big features that made it easy to swallow iptables was that it included backwards compatibility with both ipfwadm and ipchains. It also included, as the name suggests, tables, where you can branch off and handle packets by groups. For example, I have a table for detecting bogons (addresses like 192.168.0.0/24 and 10.0.0.0/8), and just have one rule in my main tables that jumps to the bogon check. In other systems, like FreeBSD’s ipfw, you can use gotos, which work about as well as they do in programming.

Another nice thing about iptables is that it has a plugin architecture for adding functionality. This has been used to great effect for things like firewalling weird application-specific protocols like FTP, marking packets or handing them off for shaping, etc… For example, one I mentioned yesterday was “hashlimit” to help protect from SSH attacks.

Let’s look at a few other interesting modules for iptables. Some of them are built-in to the stock kernel, others have to be patched in (requiring a rebuild of iptables in some cases as well as the kernel).

condition (patch?)

With condition, you can easily enable or disable a rule from a script by writing to a file under “/proc/net/ipt_condition”. For example: “iptables -I INPUT -m condition –condition killnet -j DROP”. Then if you “echo 1 >/proc/net/ipt_condition/killnet” the input chain will start dropping packets. Then “echo 0” will re-enable input packets.

connrate (patch?)

This includes a “–connrate min:max” and matches when a connection (managed by the conntrack module) is within the range. An optional “!” can appear before the rate to invert the sense of the match. You could, for example, start dropping packets if a particular connection is above a certain rate, for example.

iprange (built-in)

The iprange module allows you to specify source and/or destination addresses as ranges. While the built-in “-s” and “-d” will take a netmask, this can work with an arbitrary range of addresses, for example: “iptables -I INPUT -m iprange -s 192.168.1.5-192.168.1.100 -j ACCEPT”, that isn’t an address range that can be specified by “192.168.1.0/25” sort of syntax.

length (built-in)

Match a rule based on the packet length as a range.

limit (built-in)

Limit a match based on a rate and burst rate. For example, logging can be handy but also offers the opportunity for a denial of service by hitting your logs hard. “iptables -A INPUT -m limit –limit 10/min –limit-burst 30 -j LOG –log-prefix “Dropping:” would add a log target to the end of the input chain. This will log up to 10 messages a minute, with initial bursts of up to 30 messages. You’d normally use this at the end of an INPUT chain which has a default REJECT or DROP policy.

mac (built-in)

A rule which matches based on the MAC address the packet came from. For example, you could allow packets which have your name server’s IP on them, but come from another MAC address (one way of spoofing packets).

Lire la suite…

Firewall rules for transmission

25/11/2020 Categories: Réseau, Sécurité Tags: , 6 commentaires

Source: AskUbuntu

I have transmission installed, which listens on the default port 51413.

I have tried opening everything for this port.

iptables:

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT icmp -- 'Server IP' anywhere state NEW,RELATED,ESTABLISHED icmp echo-request
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp echo-reply
ACCEPT udp -- anywhere anywhere state RELATED,ESTABLISHED udp spt:domain dpts:1024:65535
ACCEPT tcp -- anywhere anywhere tcp spt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT udp -- anywhere anywhere udp spt:bootpc dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:9091
ACCEPT tcp -- anywhere anywhere tcp dpt:51413
ACCEPT udp -- anywhere anywhere udp dpt:51513
ACCEPT tcp -- anywhere anywhere tcp spt:51413
ACCEPT udp -- anywhere anywhere udp spt:51413
LOGGING all -- anywhere anywhere
DROP all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp spt:ssh
ACCEPT icmp -- anywhere anywhere state NEW,RELATED,ESTABLISHED icmp echo-request
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp echo-reply
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp spt:http 
ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc
ACCEPT tcp -- anywhere anywhere tcp spt:9091
ACCEPT tcp -- anywhere anywhere tcp spt:51413
ACCEPT udp -- anywhere anywhere udp spt:51413
ACCEPT tcp -- anywhere anywhere tcp dpt:51413
ACCEPT udp -- anywhere anywhere udp dpt:51413
LOGGING all -- anywhere anywhere
DROP all -- anywhere anywhere

Chain LOGGING (2 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 12/min burst 5 LOG level warning prefix "FirewallDrops: "
DROP all -- anywhere anywhere

If I flush the tables:

iptables -F

it then works, so I imagine there is something I’m missing in iptables.

Logging output:

/var/log/kern.log:May  5 18:43:32 StretchSvr kernel: [    9.258012] FirewallDrops: IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=72 TOS=0x00 PREC=0xC0 TTL=64 ID=2371 PROTO=ICMP TYPE=3 CODE=3 [SRC=127.0.0.1 DST=127.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=2370 DF PROTO=UDP SPT=51413 DPT=80 LEN=24 ] 
/var/log/kern.log:May  5 18:43:32 StretchSvr kernel: [    9.298081] FirewallDrops: IN=eth0 OUT= MAC='Svr MAC Address' SRC=62.210.137.203 DST='Svr IP Address' LEN=44 TOS=0x00 PREC=0x00 TTL=53 ID=55801 PROTO=UDP SPT=1337 DPT=51413 LEN=24
/var/log/kern.log:May  5 18:43:32 StretchSvr kernel: [    9.305079] FirewallDrops: IN=eth0 OUT= MAC='Svr MAC Address' SRC=31.172.63.226 DST='Svr IP Address' LEN=44 TOS=0x00 PREC=0x00 TTL=50 ID=0 DF PROTO=UDP SPT=80 DPT=51413 LEN=24 
/var/log/kern.log:May  5 18:44:53 StretchSvr kernel: [   90.444453] FirewallDrops: IN=eth0 OUT= MAC='Svr MAC Address' SRC=62.210.137.203 DST='Svr IP Address' LEN=44 TOS=0x00 PREC=0x00 TTL=54 ID=55802 PROTO=UDP SPT=1337 DPT=51413 LEN=24 
/var/log/kern.log:May  5 18:44:53 StretchSvr kernel: [   90.453131] FirewallDrops: IN=eth0 OUT= MAC='Svr MAC Address' SRC=31.172.63.225 DST='Svr IP Address' LEN=44 TOS=0x00 PREC=0x00 TTL=50 ID=0 DF PROTO=UDP SPT=6969 DPT=51413 LEN=24 
/var/log/kern.log:May  5 18:44:53 StretchSvr kernel: [   90.456361] FirewallDrops: IN=eth0 OUT= MAC='Svr MAC Address' SRC=31.172.63.226 DST='Svr IP Address' LEN=44 TOS=0x00 PREC=0x00 TTL=50 ID=0 DF PROTO=UDP SPT=80 DPT=51413 LEN=24 
/var/log/kern.log:May  5 18:44:53 StretchSvr kernel: [   90.458255] FirewallDrops: IN=eth0 OUT= MAC='Svr MAC Address' SRC=31.172.63.252 DST='Svr IP Address' LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=UDP SPT=80 DPT=51413 LEN=24 
/var/log/kern.log:May  5 18:45:01 StretchSvr kernel: [   98.435703] FirewallDrops: IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=72 TOS=0x00 PREC=0xC0 TTL=64 ID=2373 PROTO=ICMP TYPE=3 CODE=3 [SRC=127.0.0.1 DST=127.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=2372 DF PROTO=UDP SPT=51413 DPT=80 LEN=24 ] 
/var/log/syslog:May  5 18:43:32 StretchSvr kernel: [    9.258012] FirewallDrops: IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1 LEN=72 TOS=0x00 PREC=0xC0 TTL=64 ID=2371 PROTO=ICMP TYPE=3 CODE=3 [SRC=127.0.0.1 DST=127.0.0.1 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=2370 DF PROTO=UDP SPT=51413 DPT=80 LEN=24 ] 
/var/log/syslog:May  5 18:43:32 StretchSvr kernel: [    9.298081] FirewallDrops: IN=eth0 OUT= MAC='Svr MAC Address' SRC=62.210.137.203 DST='Svr IP Address' LEN=44 TOS=0x00 PREC=0x00 TTL=53 ID=55801 PROTO=UDP SPT=1337 DPT=51413 LEN=24 
/var/log/syslog:May  5 18:43:32 StretchSvr kernel: [    9.305079] FirewallDrops: IN=eth0 OUT= MAC='Svr MAC Address' SRC=31.172.63.226 DST='Svr IP Address' LEN=44 TOS=0x00 PREC=0x00 TTL=50 ID=0 DF PROTO=UDP SPT=80 DPT=51413 LEN=24 
/var/log/syslog:May  5 18:44:53 StretchSvr kernel: [   90.444453] FirewallDrops: IN=eth0 OUT= MAC='Svr MAC Address' SRC=62.210.137.203 DST='Svr IP Address' LEN=44 TOS=0x00 PREC=0x00 TTL=54 ID=55802 PROTO=UDP SPT=1337 DPT=51413 LEN=24 
/var/log/syslog:May  5 18:44:53 StretchSvr kernel: [   90.453131] FirewallDrops: IN=eth0 OUT= MAC='Svr MAC Address' SRC=31.172.63.225 DST='Svr IP Address' LEN=44 TOS=0x00 PREC=0x00 TTL=50 ID=0 DF PROTO=UDP SPT=6969 DPT=51413 LEN=24 
/var/log/syslog:May  5 18:44:53 StretchSvr kernel: [   90.456361] FirewallDrops: IN=eth0 OUT= MAC='Svr MAC Address' SRC=31.172.63.226 DST='Svr IP Address' LEN=44 TOS=0x00 PREC=0x00 TTL=50 ID=0 DF PROTO=UDP SPT=80 DPT=51413 LEN=24 
/var/log/syslog:May  5 18:44:53 StretchSvr kernel: [   90.458255] FirewallDrops: IN=eth0 OUT= MAC='Svr MAC Address' SRC=31.172.63.252 DST='Svr IP Address' LEN=44 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=UDP SPT=80 DPT=51413 LEN=24 

Any help appreciated.

Categories: Réseau, Sécurité Tags: ,

Linux Iptables: HowTo Block or Open HTTP/Web Service Port 80 & 443

25/11/2020 Categories: Réseau, Sécurité Tags: , Comments off

Source: nixCraft

By default Apache webserver listen on port 80 (http) and port 443 (https i.e. secure http). Apache webserver uses the TCP protocol to transfer information/data between server and browser. The default Iptables configuration does not allow inbound access to the HTTP (80) and HTTPS (443) ports used by the web server. This post explains how to allow inbound and outbound access to web services under Linux.

You can edit /etc/sysconfig/iptables file under RHEL / CentOS / Fedora Linux. Add the following lines, ensuring that they appear before the final LOG and DROP lines for the RH-Firewall-1-INPUT chain to open port 80 and 443:

-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT

Finally, restart the firewall:

# service iptables restart

If you’ve your own shell script, try:

/sbin/iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
/sbin/iptables -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT

Allow incoming http/web traffic at port 80

SERVER_IP="202.54.10.20"
iptables -A INPUT -p tcp -s 0/0 --sport 1024:65535 -d $SERVER_IP --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s $SERVER_IP --sport 80 -d 0/0 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

Allow incoming https/secure web traffic at port 443

SERVER_IP="202.54.10.20"
iptables -A INPUT -p tcp -s 0/0 --sport 1024:65535 -d $SERVER_IP --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -s $SERVER_IP --sport 443 -d 0/0 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

Allow outgoing http/web service traffic to port 80

SERVER_IP="202.54.10.20"
iptables -A OUTPUT -p tcp -s $SERVER_IP --sport 1024:65535 -d 0/0 --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 --sport 80 -d $SERVER_IP --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

Allow outgoing https/secure web service traffic to port 443

SERVER_IP="202.54.10.20"
iptables -A OUTPUT -p tcp -s $SERVER_IP --sport 1024:65535 -d 0/0 --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 --sport 443 -d $SERVER_IP --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
Categories: Réseau, Sécurité Tags: ,

Using Iptables to Block Brute Force Attacks

24/11/2020 Categories: Réseau, Sécurité Tags: , , , , , Comments off

Source: MDLog:/sysadmin

We can use the iptables recent module to write some iptables rules that can block brute force attacks. In order to use this method you need a kernel and iptables installation that includesipt_recent. If your linux distribution doesn’t include the ipt_recent module or you are using a custom compiled kernel you might need to first include the iptables recent patch that can be found on the author’s website or in the iptables patch-o-matic area. If you are using Debian/Ubuntu you don’t need to do anything special as this is already included in your system.

Let’s see how we can use the iptables recent module to block brute force attacks agains ssh. Let’s see a simple example:

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state **--state NEW** -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update **--seconds 300** **--hitcount 3** --name SSH -j DROP

This will basically allow only 3 NEW connections (as matched by the state NEW) in the timeframe of 300sec (5min). Any new connection will be automatically dropped.

The main disadvantage of using this method is that it will not make any distinction betweensuccessful and failed logins. If you are not careful and open too many connections yourself you might found yourself locked out. One walk-around for this issue is to whitelist our own administrative ips (still if we can do this for all the locations that need to connect to the system, then we can protect ourselves with simple firewall rules and we don’t need this added complexity). So at least for the hosts that we can (static ips) we should do this (replace with as many lines needed containing $WHITE_LIST_IP):

iptables -N SSHSCAN
** iptables -A INPUT -p tcp --dport 22 -s $WHITE_LIST_IP -j ACCEPT**
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP

Even if we lock ourselves out, our existing connections will remain up since we are matching only on NEW connections. If needed we can take appropriate actions.

In case we want to have the blocked hosts logged, then we will have to add another iptables rule:

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -s $WHITE_LIST_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP

You can peek at the internal database kept by the module, by looking inside:/proc/net/ipt_recent/* (DEFAULT will contain default matches; in our example the name of the file is SSHSCAN):

cat /proc/net/ipt_recent/SSHSCAN

This solution is very effective and easy to implement. You just add the needed iptables rules to your existing firewall setup and you are set. Still, it has many limitations when compared with the other methods shown: like limited time frames, it will not differentiate against failed/successful logins, etc.

References: http://snowman.net/projects/ipt_recent/ http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.16