Rozdíl mezi REJECT a DROP ve firewallu

Rozdíl mezi REJECT a DROP ve firewallu
« kdy: 01. 01. 2025, 23:48:02 »
dává smysl pravidlo v OUTPUT -j REJECT (kontra DROP)? přijde icmp, dává to nějaký smysl?


Wasper

  • ***
  • 126
    • Zobrazit profil
    • E-mail
Re:má smysl iptables -je REJECT misto drop v OUTPUT
« Odpověď #1 kdy: Dnes v 01:00:31 »
dává smysl pravidlo v OUTPUT -j REJECT (kontra DROP)? přijde icmp, dává to nějaký smysl?
Nechapu otazku - co je konkretne cilem cviceni?

Pokud tim clovek blokuje neco sobe, tak to smysl dava (okamzity reject misto dlouheho timeoutu tak neprudi), asi porad na smysl do rejectu hazet tcp/113 (ident) pokud tam nebezi prislusna servica, dal bych do rejectu 80 pokud tam neni apache/nginx s redirem na 443, opet aby kdyz nekdo da omylem http:// misto https:// apod.

Re:má smysl iptables -je REJECT misto drop v OUTPUT
« Odpověď #2 kdy: Dnes v 07:21:38 »
Zamyslete se, na koho ten REJECT vs. DROP bude mířit, a s jakým efektem.

Reject je zdvořilé explicitní odmítnutí s okamžitým účinkem, tzn. "ano jsem tu, ale nemám zájem". Odesilateli se pošle nějaká ICMP odezva, proč mu jeho traffic neprošel.

DROP je "tvářím se, že tu nejsem, ale ať si tazatel počká = musí si sám pro sebe timeoutovat, aby k tomu závěru došel".

Jsou porty/situace/ směry příchozích pokusů, kde 100% trafficu budou tvořit šmejdi z internetu, kteří hledají otevřený port, aby třeba zkoušeli hádat hesla apod. Těm nemá cenu napovídat a šetřit tak jejich čas / zrychlovat obrátku pokusů o útok.

Naopak jsou situace, kde nějaké to "ICMP unreachable" je součástí správného a svižného fungování nějakého protokolu. Viz třeba tradičně zmíněný "ident" v souvislosti se SMTP (nevím jak moc je to dnes ještě aktuální) nebo třeba "couldn't fragment" při autodetekci path MTU (provádí TCP stack per connection, pokud se nepletu). Pak jsou třeba situace, kdy si ISP monitoruje dostupnost Vašeho CPE pomocí pingu - takže pokud si jako bezpečnostní opatření zakážete příchozí ping (nebo odchozí odpovědi) tak je dobré, udělat díru aspoň pro monitoring ze strany ISP. Podobně když budete DROPovat odchozí tuším "ICMP ttl exceeded", tak bude příchozí traceroute zvenčí končit v /dev/null - je jistě Vaše rozhodnutí, zda chcete být maximálně bezpečný, nebo to vezmete sportovně jako že "za svou existenci se nestydím a případných DoS blbečků se nebojím".  Obecně bych byl opatrný na paušální dropování ICMP.

Re:má smysl iptables -je REJECT misto drop v OUTPUT
« Odpověď #3 kdy: Dnes v 08:17:14 »
...moment...
Teprve teď jsem si všiml chainu OUTPUT :-)
To je traffic od lokálně běžícího procesu, směrem ven.

Tam mi popravdě nedává moc smysl něco filtrovat, snad kromě selektivního filtru na ICMP = kolik toho mašina je ochotna na sebe vykecat. Případně by se filtr na tomhle místě dal použít jako "pojistka s velmi krátkou životností" pro případ, že se někomu povede stroj "převzít" :-) V tomto kontextu mi přijde trochu bizardní řešit navíc REJECT :-)

Moje předchozí poznámka se týkala v zásadě směru "FORWARD" a "INPUT" - jenom to vracené ICMP je možné/potřebné filtrovat směrem ven.

Re:Rozdíl mezi REJECT a DROP ve firewallu
« Odpověď #4 kdy: Dnes v 08:49:04 »
Zvažte, prosím, v jakém kontextu se pohybujete. Sešna má nějaké parametry a timeouty, když dáte REJECT, tak aplikace / služba ví, že data neprojdou a může se přizpůsobit, reagovat. Když dáte jen DROP tak aplikace bude čekat až vyprší timeout ... zároveň se tím i omezuje počet (polo)otevřených spojení ...
U sebe si to můžete dělat tak, jak chcete, jinde se doporučuje nějaká přehlednost a třeba i logování ... pak se nastavují access-listy jen v nějakých směrech v souladu s bezpečnostní politikou.


Wasper

  • ***
  • 126
    • Zobrazit profil
    • E-mail
Re:má smysl iptables -je REJECT misto drop v OUTPUT
« Odpověď #5 kdy: Dnes v 09:13:45 »
...moment...
Teprve teď jsem si všiml chainu OUTPUT :-)

Tam mi popravdě nedává moc smysl něco filtrovat, snad kromě selektivního filtru na ICMP = kolik toho mašina je ochotna na sebe vykecat. Případně by se filtr na tomhle místě dal použít jako "pojistka s velmi krátkou životností" pro případ, že se někomu povede stroj "převzít" :-) V tomto kontextu mi přijde trochu bizardní řešit navíc REJECT :-)
Taky jsem se nachytal. :-)
A priznavam, ze tenhle use-case pouzivam hned z nekolika duvodu (primarne asi dedikovany uzivatel na AI experimenty - ma zakazane uplne vsechno krome lezt na lokalniho squida, aby pripadna kompromitovana librarka/modul neskodila vic nez malo). Pripadne kdyz mam na dedikovanem uctu steam, ktery chci z nejakeho duvodu udrzet offline (rekneme treba Skyrim SE s SKSE a automapou, ktera na novejsim EXE nefunguje...)

Kazdopadne trvam na tom, ze nechapu puvodni, takhle siroce formulovany dotaz. Ma to use-cases, pro jine veci je to naprosto k nicemu, ale prvne to chce vedet, ceho chce clovek dosahnout a pak vymyslet, jak to technicky resit.