Fórum Root.cz
Ostatní => /dev/null => Téma založeno: mikesznovu 17. 02. 2023, 15:35:58
-
Narazil jsem při hledání použití parametru --mask v iptables
na zajimavou ukázku (https://serverfault.com/questions/273324/how-to-make-iptables-rules-expire):
Na něm mě (kromě mírně nezvyklého zápisu -I1- I2,I3)zarazila přítomnost+nepřítomnost action u set+update a taky jejich samotné pořadíiptables -A black -m recent --set --name blacklist -j DROP
iptables -X ssh
iptables -N ssh
iptables -I ssh 1 -m recent --update --name blacklist --reap --seconds 86400 -j DROP
iptables -I ssh 2 -m recent --update --name timer --reap --seconds 600 --hitcount 4 -j black
iptables -I ssh 3 -m recent --set --name timer -j ACCEPT
Setkali jste se s tím? (ano, je to tam vysvětlená a man jsem četl, -vím, že --set matchne vždy, taky se musí dávat pozor že právě pravidlo za always match efektivně ukončí chain) Většina použití má prohozené pořadí Dokonce obou věcí
- první pravidlo je --set, druhé pravidlo je --update
- u --set není action, u --update je -DROP
Tady je to opačně.
Funguji oba zápisy stejně nebo sice fungují ,ale jinak?
A zpět, k tomu, co jsem hledal: musí se --mask uvádět u --set i u update??? Nikde jsem to nenašel vysvětlené. Experimentálně jsem to nezkoušel zatím.
-
Zapomněl jsem dodat tu druhou stranu diffu:
-A guard_block -m recent --set --name listname
-A guard_block -m recent --update --seconds 180 --h
itcount 3 --name listname -j DROPI když myslím, že jde o učebnicový příklad. Pozor, ze jde iptables -A
-
Je funkcionalita r e c e n t orientovaná pakety nebo na spojení? (dejmetomu že mám hitcount 3 za nějakou dobu a připojím se poprvé, proběhne nějaká obou směrna komunikace 20 paketů. Vymlátí to v daném časovém okně zbylé 2 volné pokusy hitcount ) Jakým modifikátorem (u --update nebo u --set) alternovat toto chování?
-
Zjistil jsem dost nepříjemný problém, když mám ty pravidla -m recent na příchozí službu na serveru, všímám si, že můj server odesílá "útočícímu počítači" zpět . Neděje se to pravidelně pokaždé a nevyzkoumal jsem vzorec, možná je to jen nějaký přechodný stav když zrovna vložím pravidlo DROP do iptables když jsou aktivní script kiddies.
Na to jsem se chtěl zeptat, jestli by tahle hypotéza seděla, nebo má jiné vysvětlení a zda to má smysl řešit
IP SRV.6666 > 121.3.4.5.11537: Flags [F.], seq 0, ack 1, win 510, length 0
(obykle 3x za sebou )
Jako rozumím tomu, to pravidlo -A guard_block -m recent --update --seconds 900 --reap --hitcount 2 --name porty -j DROP zablokuje i příchozí FIN+ACK a pak tedy se tcp stack nedozví že sshd démon naštvaně po GraceTime prásknul sdveřmi
Ale nevím proč a jak tomu zabránit, aby odcházely zbytečně pakety na spojení které zrovna je na blackxtlistu momentálně.
a ss -4t hlásí
FIN-WAIT-1 pro tento soketový pár
-
Sice jsem si četl man iptables Sekce "recent" --update a --rcheck... (Rcheck "jenom " testuje, navic vsune do seznamu /proc"/net/xt_recent/jmeno)
snažim se přijít na praktický rozdíl:
Je to jenom to že mohu zapsat --hitcount 42 --update a je to stejné jako --hitcount 43 --rcheck ? Nebo je v tom nějaký háček a u předchozího příměru jsem něco zanedbal?
-
Je --reap jen kosmetické (že v xt_recent stavovém výpisuřádky zbytečně nejsou dlouhé)nebo nějak mění fukncionalitu?
Nevidím v příkladech v v)láknu že by to mělo mít efekt? Nebo to má efekt? Nebo to má efekt v slož.užitích module r e c e n t ?
Pro uvedení podvobraz, (je to jeden řádek celý ačtualy)
src=185.129.10.0 ttl: 122 last_seen: 8267592506 oldest_
pkt: 4 8267372497, 8267430811, 8267430811, 8267592506, 8265694432, 8265694432, 8265694432, 8265788809, 826578880
9, 8266076541, 8266103917, 8266103917,8266112651, 82661
12651, 8266528383, 8266627875, 8266627875, 8266658008, 8
266658008, 8266658008, 8266658008, 8266695579, 826669557
9, 8266790658, 8266790658, 8266790658, 8266790658, 82668
28052, 8266828052, 8266828052, 8266828052, 8267028106