Iptables csomag állapota?

Linux-haladó

Sziasztok!

iptables-ben a recent modullal az alábbiakban "megjelölt" csomagok esetén:

-A INPUT ... -m conntrack --ctstate NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
-A INPUT ... -m conntrack --ctstate NEW -m recent --update --seconds x --hitcount y --name DEFAULT --mask 255.255.255.255 --rsource -j REJECT --reject-with icmp-port-unreachable

ha a küldő fél újra próbálkozik, amíg az IP címe "feketelistán" van, addig a "-m conntrack" modullal vizsgálva a "--ctstate INVALID" illeszkedni fog rá?

-A INPUT -m conntrack --ctstate INVALID -j DENY

Vagyis az újonnan érkező csomagok állapota INVALID lesz, amíg a forrás IP címe feketelistán van?

  • 1002 megtekintés

( veresh | 2018. 03. 06., k – 08:55 )

Vagyis:
-A INPUT -m conntrack --ctstate INVALID -j DROP

( gyu v | 2018. 03. 06., k – 12:06 )

Szerintem inkább azt írd le, mit szeretnél elérni.

Lehet, nem gondolok át valamit, de nem látom, miért lenne ráhatás a recent modulnak a conntrack modul álapotterére.

A "recent"ség, és a kapcsolat állapota (szerintem) egymásra nézve ortogonális.

Egy kicsit részletezem:
Egyik szerveren ufw-t használok a tűzfalszabályok kezelésére, amely segítségével felvettem a szükséges iptables szabályokat. A bejövő ssh kapcsolatokra ufw limit ... szabályt vettem fel, és nem világos, hogy a bejvő ssh kapcsolatokra miért az a szabály illeszkedik ami!?
Az INPUT láncon ezek a szabályok vannak:

-P INPUT DROP
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input

Az ufw-before-input láncon pedig ezek:

-N ufw-before-input
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input

Ezek eddig az ufw alapértelmezett beépített szabályai.
Az ufw-user-input láncon az alábbi szabályok vannak (a teljesség igénye nélkül):

-N ufw-user-input
-A ufw-user-input -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
-A ufw-user-input -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 30 --hitcount 6 --name DEFAULT --mask 255.255.255.255 --rsource -j ufw-user-limit
-A ufw-user-input -p tcp -m tcp --dport 22 -j ufw-user-limit-accept
...
...

Az ufw-user-limit láncon az alapértelmezett szabályok vannak:

-N ufw-user-limit
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable

És akkor a lényeg: kínai IP címekről (2-3 naponta változik az IP cím) napi szinten kb 3000 belépési kísérlet történik IP címenként. Ezek egy részét az ufw-user-limit láncon lévő szabály "fogja meg". Azonban egyes belépési kísérletekre az ufw-before-input láncon lévő alábbi két szabály illeszkedik:

-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP

Ebből gondolom azt, hogy ha a recent által (fekete)listára tett IP címekről érkezik belépési kísérlet ssh-n, akkor azoknak a csomagoknak az állapota INVALID, ezért illeszkedik rá az ufw-before-input láncon lévő két szabály.

#1. egyszerűbb lett volna a komplett iptables-save kimenetet feltenni pastebin-re. Esetleg a "titkos" adatokat anonymizálva benne értelmes módon.

#2. én mondjuk az olvashatóság és egyéb okok mentén a user-input-od lebontanám, és helyette ufw-ssh-recent nevűt csinálnék, valahogy így: ahol az ufw-user-input-ba elküldöd, ott ahelyett:
-A ufw-before-input -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ufw-ssh-recent
-A ufw-ssh-recent -m recent --set --name DEFAULT --mask 255.255.255.255 --rsource
-A ufw-ssh-recent -m recent --rcheck --seconds 30 --hitcount 6 --name DEFAULT --mask 255.255.255.255 --rsource -j ufw-logdrop
-A ufw-logdrop -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK]"
-A ufw-logdrop -j DROP
de, ha gondolod, az akár, maradhat is reject.

Legalábbis nem tartom annyira jó ötletnek egy szabályban ennyiféle összetett modul kérdezgetését match-ügyileg.
Hatékonyságban sem biztos, hogy olyan jó. Másrészt olvashatóságban is árt.
-> ezért javasoltam, hogy előbb conntrack és tcp modullal ejtsd meg a match-ed
-> második lépésben, másik láncon, ahová már a fenti kiértékelése után jutsz, pedig intézd a recent-es játékot

#3. ha INVALID, azt szerintem logolni is kár -> dropható

A kínaiak, ha a syn-re nem megy válasz, és mégis úgy tesz, mint ha kapott volna syn,ack -ot, vagy hasonló módon folytatnák, azok kerülnek INVALID-ba. Vagy nem nagyon értem, mi a várakozás.

De nem. Aki neked feketelistán van, az még nem lesz "INVALID".
Csak, ha úgy tesz, mint mondtam: syn, majd ack-os csomagokkal jön, mintha küldtél volna syn,ack-ot, közben meg rejectelted. Ő NEM lesz invalid. Az invalid a ctstate-re vonatkozik.

De ha jön egy újabb syn, az simán NEW lesz. Abban nincs semmi INVALID.

Legalábbis, hacsak nincs valami bug a netfilterben, akkor a következő, meg a következő, meg az azutáni is new lesz. De ez így jó, mert ha még folyamatosan próbálkozik, avval is updateli neked a countert.