Lite mer avancerade saker som går att göra med netfilter/iptables-brandväggsregler

Här följer beskrivningar av lite mer avancerade saker som går att göra med netfilter. Först dock en mer utförlig beskrivning av lite grundläggande begrepp.

Tabellerna

Netfilter består av tre tabeller, filter, nat och mangle.

TabellVad den gör
filterHär görs all filtrering som DROP, LOG, ACCEPT och REJECT. Filtertabellen består av kedjorna INPUT, OUTPUT och FORWARD.
natHär görs adressöversättningar för avsändaradress och mottagaradress, SNAT, DNAT och MASQUERADE. MASQUERADE gör av med lite mer CPU-kraft än SNAT. MASQUERADE används främst när datorn får en adress dynamiskt via DHCP. Tabellen består av kedjorna PREROUTING, POSTROUTING och OUTPUT. Kedjan OUTPUT används ej.
mangleI denna tabell manglas paketen och får till exempel en ny TTL (Time To Live), ny TOS (Type Of Service) etc. Det går även att märka paketen där andra brandväggsregler i andra tabeller kan använda markeringen för att bestämma vad de ska göra med trafiken.

Trafik in till den egna datorn går via mangle prerouting, nat prerouting och filter input innan den når den egna datorn.

Trafik ut från den egna datorn går via mangle output till nat output (som inte används), filter output och till nat postrouting innan den kommer ut på nätet.

Trafik från ett nätverksinterface till ett annat går via mangle prerouting, nat prerouting, filter forward och nat postrouting innan det kommer ut på andra nätverksinterfacet.

Bilden nedan visar tabellerna och deras kedjor.



Händelser och hopp

Händelser och hopp talar om för en regel vad den ska göra med den aktuella trafiken. Några av de händelser som finns som standard är DROP, ACCEPT, LOG, DNAT och SNAT. Andra händelser som också kan förekomma är bland annat REJECT och MARK.

DROP kastar all trafik som matchas av regeln. REJECT fungerar som DROP med den skillnaden att REJECT skickar tillbaka ICMP-paket som svar till avsändaren.



ACCEPT släpper vidare trafiken som matchas av regeln. Om ACCEPT görs i en standardkedja skickas trafiken vidare till nästa standardkedja i ordning. Om till exempel ACCEPT görs i OUTPUT-kedjan skickas trafiken vidare direkt till POSTROUTING-kedjan utan att passera några fler regler i OUTPUT-kedjan.



Om ACCEPT görs i en egendefinierad kedja hoppar netfilter till nästa fördefinierade kedja i ordning från den i vilken hoppet till den egendefinierade kedjan gjordes, på samma sätt som om ACCEPT gjorts i den fördefinierade kedjan.



Om hopp görs till en egendefinierad kedja och hela kedjan passeras kommer netfilter att gå tillbaka till den ursprungliga kedjan och regeln efter den som hoppade till den egna kedjan.



RETURN i en egendefinierad kedja gör att netfilter går tillbaka till den ursprungliga kedjan och regeln efter den som hoppade till den egna kedjan.



RETURN i en standardkedja gör att netfilter hoppar till defaultregeln för kedjan (den du har satt med iptables -P kedjan händelse).



LOG, DNAT och SNAT utför det de ska och skickar vidare trafiken till nästa regel i kedjan.



Om du definierar egna kedjor och vill hoppa till dem från andra kedjor måste dessa ligga i samma tabell.

TCP, UDP och ICMP och förbindelser

Netfilter håller reda på trafiken mellan två parter. När klientdatorn skickar första paketet till servern är det helt nytt för netfilter. Netfilter betraktar trafiken som NEW.

När servern svarar betraktar netfilter det som en etablerad förbindelse mellan de två parterna, ESTABLISHED.

Paket som inte hör till en förbindelse eller kan identifieras räknas som INVALID. Exempel på sådana paket är ICMP-felmeddelanden som inte hör till någon förbindelse som netfilter känner till, TCP-paket som inte är en uppkoppling och som inte hör till någon förbindelse.

Om det till en förbindelse kommer ICMP-felmeddelanden är dessa att betrakta som relaterade, RELATED. På samma sätt är datatrafiken till en FTP-förbindelse att betrakta som relaterad.



Mer avancerade saker

Nedan följer lite mer avancerade saker som går att göra med netfilter. En del av dem kan kräva att du har den senaste versionen av netfilter och en del av dem kan kräva moduler som är så nya att de inte finns med i standardkärnan. Gå till http://netfilter.samba.org/ för att hämta senaste versionen av iptables och för mer information om nyutvecklade moduler, patch-o-matic. Att applicera patch-o-matic tar en god stund.

Port forwarding med PREROUTING

Med en maskerande brandvägg och privata IP-adresser på det interna nätet bakom brandväggen (adresser som endast får användas för internt bruk, se RFC 1918) går det inte att komma åt tjänster på de interna maskiner från omvärlden. Omvärlden känner endast till brandväggens utsideadress.

För att göra tjänster på interna servrar tillgängliga för omvärlden behöver du använda PREROUTING och DNAT, det vill säga adressöversättning i kedjan PREROUTING i tabellen NAT. Tricket är att på inkommande trafik skriva om mottagaradressen till adressen till den interna servern. Trafiken kommer sedan att via routingen gå vidare till filtertabellen och kedjan FORWARD.

Om all tcp-trafik som kommer in till port 2022 på brandväggen ska skickas vidare till servern 192.168.22.17 och port 22 blir regeln följande:

iptables -t nat -A PREROUTING -p tcp --dport 2022 -j DNAT --to 192.168.22.17:22

Notera dock att denna regel skriver om all trafik som ska gå genom brandväggen och som ska till port 2022. Det gäller ovansett om det är trafik från Internet in till ett lokalt nätverk eller från ett lokalt nätverk ut till Internet. För att begränsa så att det bara är trafiken utifrån och in som skrivs om behöver du även matcha mot vilket nätverksinterface som paketen kommer in via. Om det yttre interfacet är eth1 blir regeln:

iptables -t nat -A PREROUTING -p tcp --in-interface eth1 --dport 2022 -j DNAT --to 192.168.22.17:22

Nu skickas trafiken vidare till FORWARD-kedjan i filtertabellen och för att trafiken ska komma fram behövs en regel i FORWARD-kedjan som släpper fram trafiken.

iptables -A FORWARD -p tcp --destination-port 22 -j ACCEPT

Om brandväggen har fler adresser på sitt yttre interface och du vill att allt (tcp) till adress 10.10.10.42 port 2022 ska skickas vidare till servern 192.168.22.17 och port 22 blir regeln:

iptables -t nat -A PREROUTING -p tcp -d 10.10.10.42 --dport 2022 -j DNAT --to 192.168.22.17:22

Om du vill forwarda flera portar som ligger i serie går det att åstadkomma genom att skriva lägsta portnummer kolon högsta portnummer. Exempel, skicka vidare portarna 900 till 910 från 10.10.10.42 till 192.168.22.17.

iptables -t nat -A PREROUTING -p tcp -d 10.10.10.42 --dport 900:910 -j DNAT --to 192.168.22.17



Om du vill forwarda passiv ftp-trafik behöver du dels göra forwarding på tcp-port 21 in till ftp-servern och ladda kärnmodulerna iptable_nat, ip_conntrack, ip_conntrack_ftp och ip_nat_ftp.

Exempel på forwarding av passiv ftp in till ftp-servern på adress 192.168.1.54. I nedanstående exempel är eth0 kopplat till Internet och eth1 till det interna nätverket.

# Om maskeringen är kompilerad som modul
# ladda modulerna iptable_nat och ip_conntrack
modprobe iptable_nat
modprobe ip_conntrack

# För att ESTABLISHED, RELATED ska fungera bra för FTP-trafik ladda
# nedanstående moduler.
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

# FORWARDA port 21 till 192.168.1.55 port 21
iptables -t nat -A PREROUTING --in-interface eth0 -p tcp --dport 21 -j DNAT --to 192.168.1.54:21

# Släpp in ftp-kommandokanal till 192.168.1.54
iptables -A FORWARD --in-interface eth0 -p tcp --d 192.168.1.54 -dport 21 -j ACCEPT

# Tillåt all trafik från interna nätet att komma ut mot Internet
iptables -A FORWARD --in-interface eth1 -j ACCEPT

# Släpp in svarstrafik från Internet
iptables -A FORWARD --in-interface eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT



Loggning

Genom att skapa en regel och i den göra "jump" till LOG skickas alla data om den aktuella trafiken till loggarna. Notera att trafiken inte kastas utan skickas vidare till nästa brandväggsregel i kedjan.

Exempel på en loggrad:
Apr 28 15:41:38 mindator kernel: IN=eth0 OUT= MAC=00:10:a4:6f:73:5e:00:80:3f:57:eb:f7:08:00 SRC=10.17.18.19 DST=10.10.10.42 LEN=40 TOS=0x00 PREC=0x00 TTL=253 ID=16146 DF PROTO=TCP SPT=46801 DPT=80 WINDOW=8760 RES=0x00 ACK FIN URGP=0

Del av loggradVad den innebär
Apr 28 15:41:38Datum och tid för det aktuella paketet.
mindator kernel:mindator är datorns namn, kernel talar om att loggraden kommer från linuxkärnan (brandväggsskyddet i linuxkärnan).
IN=eth0Talar om att trafiken kom in på nätverksinterfacet eth0 .
OUT=Om trafiken går ut via något interface kommer OUT att visa vilket interface det går ut via.
MAC=00:10:a4:6f:73:5e:00:80:3f:57:eb:f7:08:00Den första delen, 00:10:a4:6f:73:5e:, är mindator:s MAC-adress. Den andra delen är den avsändande dators MAC-adress om den finns på samma nät, annars är det defaultrouterns MAC-adress.
SRC=10.17.18.19Är avsändande dators IP-adress.
DST=10.10.10.42Är mottagande dators IP-adress
LEN=40Längden på paketet.
TOS=0x00TOS är Type Of Service-fältet i IP-paketet.
PREC=0x00-
TTL=253Paketets Time To Live
ID=16146TCP-paketets sekvensnummer
DFDon't Fragment-flaggan är satt, det vill säga paketet får inte fragmenteras (delas upp i flera delar).
PROTO=TCPVilket protokoll det rör sig om. I detta exempel är det TCP-trafik.
SPT=46801Avsändarport
DPT=80Mottagarport
WINDOW=8760Fönsterstorleken för TCP.
RES=0x00-
ACK FIN URGP=0Flaggorna ACK, FIN är satta och Urgentflaggan är 0.

Till loggningen går det att skicka med en text, ett prefix, som till exempel förklarar vad det är för typ av trafik som loggas. Texten får vara max 29 tecken lång. Exempel på en loggrad som loggar all tcp-trafik till port 99

iptables -A INPUT -p tcp --destination-port 99 -j LOG --log-prefix "LOGG AV TRAFIKEN TILL PORT 99 "

Detta resulterar i en loggrad enlig följande:

Apr 28 15:41:38 mindator kernel: LOGG AV TRAFIKEN TILL PORT 99 IN=eth0 OUT= MAC=00:10:a4:6f:73:5e:00:80:3f:57:eb:f7:08:00 SRC=10.17.18.19 DST=10.10.10.42 LEN=40 TOS=0x00 PREC=0x00 TTL=253 ID=16146 DF PROTO=TCP SPT=46801 DPT=99 WINDOW=8760 RES=0x00 ACK FIN URGP=0

Det går även att bestämma prioritet/loggnivå på loggningen. Loggnivå kan antingen skrivas som ett tal, där 0 är högsta loggnivå (emerg), eller som en prioritet så som de skrivs i syslog.conf (se manualsidan för syslog.conf). Exempel med loggning av prioritet warning:

iptables -A INPUT -p tcp --destination-port 99 -j LOG --log-level warning



REJECT

Istället för att kasta trafiken kan ett alternativ vara att skicka tillbaka ett svar att den aktuella trafiken inte var tillåten. Som standard skickas ett ICMP-paket port unreachable tillbaka. Exempel på en regel som gör reject:

iptables -A INPUT -p tcp --destination-port 99 -j REJECT

Till REJECT går det även att specificera vilken typ av ICMP-paket som ska skicas som svar. De typer av ICMP-svar som finns är: icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibitedor och icmp-host-prohibited. För brandväggsregler som gör REJECT på ping-paket går det att ange echo-reply till REJECT. För brandväggsregler som gör REJECT på TCP-trafik går det att skicka tillbaka en TCP tcp-reset. Några exempel:

iptables -A INPUT -p tcp --destination-port 99 -j REJECT --reject-with icmp-host-unreachable

iptables -A INPUT -p tcp --destination-port 99 -j REJECT --reject-with tcp-reset



MARK

Med MARK i mangle-tabellen går det att märka paket för vidare bearbetning t.ex. i senare regler i andra tabeller.

Märkningen görs som ett heltal.

Säg att du vill märka all trafik som kommer in på eth0 med märkningen 1. Det görs på följande sätt:

iptables -t mangle -A PREROUTING --in-interface eth0 -j MARK --set-mark 1

Den märkta trafiken kan sedan tas om hand av brandväggsregler i en kedja i en annan tabell. Om den ovan märkta trafiken ska loggas i FORWARD-kedjan med texten "Utgående trafik" kan du göra på följande sätt:

iptables -A FORWARD -m mark --mark 1 -j LOG --log-prefix "Utgående trafik "

Ett annat exempel på användning av MARK är för att minska på antal brandväggsregler. Säg att du vill portforwarda lite olika typer av trafik med hjälp av PREROUTING och DNAT in till en server på ett intern nätverk. Sätt upp en mangle-rad för varje tjänst där den märker den aktuella trafiken med en etta "1". Nedan görs detta för trafik som kommer in via eth1 där tjänsterna är;
tcp: ssh (port 22), www (port 80)
udp: DNS (port 53)
ICMP: alla ICMP-paket

iptables -t mangle -A PREROUTING --in-interface eth1 -d 10.10.10.42 -p tcp --destination-port 22 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING --in-interface eth1 -d 10.10.10.42 -p tcp --destination-port 80 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING --in-interface eth1 -d 10.10.10.42 -p udp --destination-port 53 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING --in-interface eth1 -d 10.10.10.42 -p icmp -j MARK --set-mark 1

Nu räcker det med en rad i NAT-tabellen

iptables -t nat -A PREROUTING -m mark --mark 1 -j DNAT --to 192.168.22.17

och det behövs endast en rad i FORWARD-kedjan.

iptables -A FORWARD -m mark --mark 1 -j ACCEPT



TOS, Type Of Service (typ av trafik)

"Type Of Service" används inte särskilt ofta men möjligheten finns att filtrera baserat på TOS och att sätta nytt TOS:värde.

De olika "Type Of Services" som finns är:
16 Minimera fördröjning
8 Maximera bandbredd
4 Maximera tillförlitlighet
2 Minimera kostnad
0 Normal trafik

Sätta nya TOS:värden går att göra i tabellen mangle i kedjorna PREROUTING och OUTPUT. Exempel där TOS för ssh-trafik (tcp port 22) som kommer in via eth1 och som ska till 10.10.10.42 ska sättas till att minimera fördröjning för bästa interaktivitet (värdet 16).

iptables -t mangle -A PREROUTING --in-interface eth1 -d 10.10.10.42 -p tcp --destination-port 22 -j TOS --set-tos 16

Filtrera och skilja ut trafik baserat på TOS går att göra i mangle och filter. I mangle är det möjligt att markera trafik med vissa värden i TOS. I filter är det möjligt att filtrera trafik baserat på värdet i TOS.

Exempel på markering av trafik i mangle:

iptables -t mangle -A PREROUTING --in-interface eth1 -d 10.10.10.42 -m --tos --tos 16 -j MARK --set-mark 1

Exempel på filtrering av trafik baserat på på värdet i TOS.

iptables -A INPUT -p tcp --destination-port 22 -m tos --tos 16 -j --REJECT



TTL, Time To Live

Time To Live begränsar nätverkstrafikens livslängd. Varje gång ett IP-paket passerar en router minskas TTL med ett. Max-värdet är 255. När TTL för ett IP-paket blir noll kastas paketet. Detta är bland annat till för att inte få oändliga loopar i något nätverk.

Värdet för TTL går att förändra i tabellen mangle. Notera dock att du måste ha en ganska ny kärna och patch-o-matic för att kunna ändra respektive matcha på TTL. Till kärnan slå på CONFIG_IP_NF_TARGET_TTL för att få stöd för att matcha på TTL för IP-paket.

Filtrera och skilja ut trafik baserat på TTL går att göra i mangle och filter. I mangle är det möjligt att markera trafik med vissa TTL-värden. I filter är det möjligt att filtrera trafik baserat på TTL-värde.

Sätt TTL till 255 för all trafik som kommer in via eth0.
iptables -t mangle -A PREROUTING --in-interface eth0 -j TTL --ttl-set 255

Minska TTL med ett för all trafik som kommer in via eth0.
iptables -t mangle -A PREROUTING --in-interface eth0 -j TTL --ttl-dec 1

Öka TTL med ett för all trafik som kommer in via eth0.
iptables -t mangle -A PREROUTING --in-interface eth0 -j TTL --ttl-inc 1

Kasta alla tcp-paket till port 42 i FORWARD-kedjan där TTL är exakt 17.
iptables -A FORWARD -p tcp --destination-port 42 -m ttl --ttl-eq 17 -j --DROP

Kasta alla tcp-paket till port 42 i FORWARD-kedjan där TTL är mindre än 7.
iptables -A FORWARD -p tcp --destination-port 42 -m ttl --ttl-lt 7 -j --DROP

Kasta alla tcp-paket till port 42 i FORWARD-kedjan där TTL är större än 42.
iptables -A FORWARD -p tcp --destination-port 42 -m ttl --ttl-gt 42 -j --DROP



TCP-flaggor

Med iptables kan man för TCP-trafik titta på TCP-flaggorna.

Vid en uppkoppling ska i första paketet endast flaggan SYN förekomma. Andra flaggor ska normalt inte förekomma samtidigt som SYN vid den första uppkopplingsbegäran. Vid första svaret ska SYN och ACK skickas för att etablera kontakt. Man ska dock vara medveten om att andra flaggor i kombination med SYN egentligen inte är förbjudet.

RESET används för att abrubt avbryta en förbindelse.

FIN används för att avsluta en förbindelse.

ACK används för att bekräfta att data har kommit fram.

Kombinationer av flaggor tillsammans med andra saker kan användas för att ta reda på vilket operativsystem en dator kör. Onormala kombinationer av flaggor kan användas för att försöka lura brandväggar.

Vi en uppkopplingsbegäran ska normalt endast SYN-flaggan förekomma.

Som synes ovan så går det att begära och få uppkoppling med de flesta operativsystem med kombinationer av flaggan SYN och andra flaggor. Att kombinera flaggor kan i värsta fall användas för att lura en brandvägg. Om t.ex. en brandvägg anser att allt som endast innehåller SYN är en ny uppkoppling och alla paket som innehåller andra kombinationer av flaggor tillhör en etablerad förbindelse och den är inställd på att spärra nya inkommande förbindelser men släppa fram svarstrafik till redan etablerad trafik kan det gå att lura den att släppa in uppkopplingsbegäran enligt någon av kombinationerna ovan.

För att förhindra detta går det att sätta upp regler som spärrar och loggar alla sådana försök.

Genom att titta på om följande flaggkombinationer är satta, där övriga flaggor kan vara satta eller ej, fångas de intressanta attackförsöken:

Med iptables matchar man mot flaggor med --tcp-flags mask flaggor.

Mask anger vilka flaggor som ska studeras och flaggor anger vilka flaggor som ska vara satta.

Exempel: -p tcp --tcp-flags ALL, FIN,URG,PSH
Här studeras alla flaggor och exakt FIN, URGENT och PUSH ska vara satta och övriga flaggor ska inte vara satta.

Exempel2: -p tcp --tcp-flags SYN,FIN SYN,FIN
Här studeras endast SYN och FIN där SYN och FIN ska vara satta. Övriga flaggor kan vara vad som helst, satta eller inte satta.

För att nu sätta upp skydd för SYN,FIN eller SYN, RESET eller SYN,PUSH och kombinationer av dessa med andra eventuella flaggor där trafiken ska loggas och kastas går det att göra enligt följande. Börja med att skapa en kedja för att logga trafiken med en egen text i loggarna: iptables -N bogus-new
iptables -A bogus-new -j LOG --log-prefix="Bogus new connection"
iptables -A bogus-new -j DROP
 Sätt upp reglerna som matchar på de olika kombinationerna av flaggor.

iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j bogus-new
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j bogus-new
iptables -A INPUT -p tcp --tcp-flags SYN,PSH SYN,PSH -j bogus-new

På samma sätt kan vi nu sätta upp skydd för Xmas-tree där tcp-flaggorna FIN, URG, PUSH och eventuellt fler flaggor är satta.

iptables -N tcp-xmas
iptables -A tcp-xmas -j LOG --log-level "ERR" --log-prefix=" --Xmas packet"
iptables -A tcp-xmas -j DROP

iptables -A INPUT -p tcp --tcp-flags FIN,URG,PSH FIN,URG,PSH -j tcp-xmas



Maskeringstimeout

Vid maskering håller netfilter reda på trafiken som maskeras, varifrån den kommer och vart den ska, för att kunna hantera svarstrafiken.

Om ingen trafik har passerat på ett tag över en förbindelse kommer netfilter att glömma bort allt den känner till om förbindelsen.

Timeout-tiderna för olika typer av trafik brukar som standard vara ungefär:

30 sekunder för ICMP-trafik.
10 sekunder för UDP-paket som det ej kommit några svar på.
3 minuter för UDP där minst ett av paketen besvarats.
5 dagar för TCP-koppel där ingen av parterna försökt koppla ned.
2 minuter för TCP-koppel där en av parterna försökt koppla ned men den andra av någon anledning inte svarat.

Dessa tider går att ändra på i filerna i /proc/sys/net/ipv4/netfilter/ eller med hjälp av sysctl. Exempel för att ändra timeouten för UDP där ett paket har kommit men inga svarspaket har synts till. Timeouten ska här sättas till 32 sekunder.

echo "32" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout

Alternativt editera filen /etc/sysctl.conf och ändra på raden eller om den inte finns lägg till raden:
net.ipv4.netfilter.ip_conntrack_udp_timeout = 32



Reglera utgående trafik för lokala processer

I iptables finns en modul owner som gör det möjligt att filtrera utgående trafik, trafik som passerar OUTPUT-kedjan, baserat på användarnamn, användarid, gruppnamn, grupp-id, process-id, processgrupp och processnamn. På så sätt kan man reglera vad och vilka lokala processer ska få skicka ut på nätet.

FlaggaVad den gör
--uid-ownerMatchar mot användarnamn eller användarens UID.
--gid-ownerMatchar mot gruppnamn eller grupp ID (GID).
--pid-ownerMatchar mot process-ID (processnummer).
--sid-ownerMatchar mot processer som ingår i en processgrupp.
--cmd-ownerMatchar mot programnamn.

För att t.ex. kasta all utgående trafik för alla processer som ägs av nisse kan man skriva:
iptables -D OUTPUT -m owner --uid-owner nisse -j DROP

För att tillåta programmet traceroute att få skicka ut data går det att skriva:
iptables -D OUTPUT -m owner --cmd-owner traceroute -j ACCEPT

För att spärra användaren root från att skicka icmp echo-request (ping-paket) går det att skriva:
iptables -D OUTPUT -m owner --uid-owner root -p icmp --icmp-type echo-request -j DROP

Observera att det bara är användbart för att reglera utgående trafik för program som körs på datorn med brandväggsskyddet.

Begränsa mängden inkommande trafik

Det går att begränsa den inkommande trafiken som kommer in via INPUT-kedjan eller FORWARD-kedjan så att det t.ex. bara sker ett begränsat antal uppkopplingar per tidsenhet. Ett exempel kan vara att begränsa antalet ssh-uppkopplingar in till datorn till max 4 st per minut.

Modulen recent

Begränsa mängden trafik går att göra med modulen recent. Först behövs en regel som lägger till avsändarens IP-adress för nya uppkopplingar i "recent"-listan. Följande regel lägger till ny trafik som kommer in via eth0 och som ska till port 22 (ssh) på denna dator:
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set

Därefter går det att sätta upp regler som matchar mot IP-adresser i "recent"-listan. Dessa regler kan även matchas mot antal paket, t.ex. 5, och tidsenheter, t.ex. 60 sekunder. För att begränsa antalet ssh-uppkopplingar från ett och samma ställe så att vi kastar alla uppkoppling efter den 5:e uppkopplingen inom ett intervall på 60 sekunder blir det:
iptables -D INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent \
--update --seconds 60 --hitcount 5 -j DROP

Det som --hitcount 5 gör är att matcha på paket efter 5 och uppåt. --seconds 60 matchar mot ett intervall på 60 sekunder. Det är --update som ser till att matchningen görs och att avsändarens IP-adress kontrolleras mot "recent"-listan.

Modulen recent kan användas i INPUT och FORWARD.

Modulen limit

Ett alternativ till modulen recent är att använda modulen limit.

Genom att ge ett värde med flaggan --limit matchar regeln mot en begränsad mäng trafik, t.ex. i medel 2 paket per sekund. Med flaggan --limit-burst anges maximala initiala antal paket att matcha mot. Regeln nedan matchar mot i snitt 10 pingpaket per minut med 8 st inledande paket i början. Regeln kommer att släppa fram en del trafik.
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 10/min --limit-burst 8 -j ACCEPT

För att spärra resten behövs även en spärraregel.
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

Dessa två regler tillsammans gör att en del trafik släpps fram och resten spärras. I det här fallet kommer det att resultera i ca 80% packet loss på inkommande ping-paket.

För att begränsa antalet nya tcp-uppkopplingar behöver man titta på SYN-paket. För att t.ex. matcha mot en begränsad mängd ssh-uppkopplingar kan man skriva:
iptables -A INPUT -p tcp --syn --dport 22 -m limit --limit 5/min --limit-burst 1 -j ACCEPT

Till detta behövs sedan en regel som spärrar resterande ssh-uppkopplingar.
iptables -I INPUT -p tcp --syn --dport 22 -j DROP

Resultatet av de två reglerna blir en begräsad mängd med ssh-uppkopplingar per minut.

Modulen limit kan användas i INPUT och FORWARD.

Copyright © 2010-2024 Kjell Enblom.
This document is covered by the GNU Free Documentation License, Version 1.3

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".