Új hozzászólás Aktív témák

• #30140 Dißnäëß veterán inf3rno #30138

  Új Válasz 2020-05-04 13:25:40 #30140

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Dißnäëß

  veterán

  válasz inf3rno #30138 üzenetére

  A második felvetésedre: hááát ez jó kérdés, iptables-ben (vagy még az elődjében, ipchains-ben) volt anno olyan target, hogy REJECT, talán ma is megvan még akármilyen okok miatt, na az viselkedik úgy, hogy elutasításkor visszajelez, hogy "ide nem jöhetsz be" , aminek puszta megtörténte miatt elárulva, hogy ott van gép, port, szolgáltatás, amit lehetne törni. Az akkoriban erre válaszul hozott DROP target már olyan végződtetés, hogy onnan semmi infó nem megy vissza a küldő fele, szóval mintha fekete lyuknak beszélne, DROP esetén nemigen tudja megállapítani, van-e ott valami vagy sem. Még TCP SYN dolgokkal bohóckodhat, de mindenre fel lehet készíteni egy gépet úgy megcsinálva, hogy távolról isten se mondja meg, hogy ott van valami az adott ip címen, hacsak nincs fizikai hozzáférése a network-höz.

  Első felvetésed:
  Ha csak ideiglenesen van nyitva a port, miután bezáródik, nem fog működni az SSH, mert megszakad a kapcsolat. Vagy valamit nagyon nem értek a hálózati kommunikációból.
  
  Az, hogy egy port nyitva van-e, egy dolog. Arra is kihatásunk van, MIRE van nyitva. Egy nagyonegyszerű csecsemőbiztos példa most így fejből gyorsba, a teljesség igénye nélkül, csak az INPUT chain-re fókuszálva (pedig egy korrekt tűzfalban az OUTPUT is szűrve van, legalábbis akkor, ha magáról a tűzfal gép védelméről beszélünk.. ha a többiekéről, akkor meg a FORWARD mindkét iránya nat mangle és egyéb táblákban is, felhasználástól függően).

  Tehát egy marha primitív kézi fal arra a host-ra, amit védeni akarunk, és egy SSH-t beengedünk. Illetve a mi saját kimenő csomagjaink visszatérő lábát is különben semmit nem lehet erről nagyon csinálni azon kívül, hogy egy buta SSH kiszolgáló.
  iptables -X
  iptables -F
  iptables -P INPUT DROP
  iptables -A INPUT -i lo -j ACCEPT
  iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
  iptables -A INPUT -p tcp --dport 22 -j ACCEPT

  És akkor a vastaggal emeltet lehet (igazából erősen illik) cizellálni, hogy source-ot adunk neki, egy adott ip-t vagy ip régiót, satöbbi.

  Kérdésedre a válasz a state-ekben rejlik, azaz a 22-es port knocking alatt csukva marad NEW csomagok számára, de természetesen ha egy másik host már sikeresen bekopogott oda és kapcsolódva van, őt egy RELATED,ESTABLISHED szabály beengedi, ami generalizáltan, minden protokollra és minden source/destination portra értelmezve van. (Ezért nem szoktam használni ebben a formában, csak szűkítve, de akkor hasznos).

  Ha csak 22-es portra akarunk kétszintű definíciót, ami beengedi a már felépült SSH-k visszatérő lábait, de újakat nem enged be korlátlanul:
  iptables -A INPUT -p tcp --dport 22 -m limit --limit 10/s -m state --state NEW -j ACCEPT
  iptables -A INPUT -p tcp --dport 22 -m state --state RELATED,ESTABLISHED -j ACCEPT

  Ez minden 22-es portra érkező ÚJ kérést úgy enged be, hogy csak másodpercenként 10-et enged ebből, a többit dobja. Minden új kérésre érvényes, de csak újakra. Az alatta levő sor pedig korlát nélkül enged minden 22-es portra beeső SSH csomagot, aminek van egy korábbi kimenő párja a táblákban már, így ha egyszer kapcsolódott valaki, egy SSH fájlátvitel sem okoz limit miatt gondot, bármennyi csomaggal korlátlanul kommunikálhat az sshd-vel.. szóval RELATED,ESTABLISHED lábakat nem szokás (vagy csak nagyon paranoid esetben) limit-el ellátni, burst-re is ügyelve de arra most nem térek ki.

  A port knocking NEW-ra értendő, hiszen nem egy korábban kiment csomagra adott válaszcsomag az, ami érkezik és kopogna be, hanem új csomag, amolyan azonosítatlan, követés nélküli akarna bejönni. Őt csak számolni kell, mint kopogásszámot, de dobja is DROP-ra, míg a szekvencia nem teljesül, ergo nem lesz kimenő lába, mindig minden "kopogó" csomag NEW-nak minősül.

  Ha ezen dimenzió mentén nézed, máris nem lehet azt mondani, hogy nyitva egy port vagy zárva: van, amire nyitva, van, amire limitáltan nyitva és van, amire zárva.

  A limit egyébként hasznos, de érdemes a burst-öt is definiálni az elején, illetve tudni azt, hogy ha a szabályban definiált limitet pont egy hülye bot, vagy akármi lezabálja, Te sem jössz be már

  Csináltam egyszer olyat, amikor egy hobbigépem törni akarták (még kezdő szöcske koromban, amikor 22-esre tettem ki SSH-t a nagy világhálóra), hogy láttam a logokban a millió jelszópróbálkozást, auth-ot, úristen mondom mivanitt, bruteforce indult ellenem és úgy döntöttem, teszek 22-es portra NEW próbálkozásokra egy 3/m limitet, azaz 3 próbálkozás / perc, utána csőváz mindenkinek.

  1x tudtam belépni, utána kvázi örökre kizártam magam, mert a percenkénti 3-at elérte a próbálkozások száma a botok által, a fal zárt, én meg ugyanúgy kint maradtam egy putty zárás és újranyitás után

  Szóval mindenre a limit sem megoldás, de mondjuk túlterhelések ellen egy egészséges mérték beállítása jó lehet, ami azon képzeletbeli határ felett van, ahányan akarnak oda jönni amúgy, botokkal együtt. Meg általában ezek a zombi gépek, botok, akármik többnyire 22-es porton kopognak, tehát ha a 22-est vagy az sshd-ban, vagy iptables-en keresztül nem 22-re rakod ki a publik interfészen, hanem valami tökmáson (1024 felett lehetőleg), az sokat segít. (Persze ne híres port legyen lehetőleg). SSH esetében úgy tudom kell induláskor a root jog, de egyébként ha most IRC szervert vagy akármi egyéb alkalmazást akarnál kitenni a netre, mindenképp 1024 fölé érdemes tenni, mert 1024-es alatti portokhoz root jog szükséges, azt meg nem akarjuk odaadni minden processznek (hacsak fel nem vesz utána nobody-t stb, de az megint más tészta). Azt vettem észre mindenesetre, hogy 22-ről ha elviszed SSH-t bármilyen módszerrel is, drasztikusan lecsökkennek az auth próbálkozások számai. Ez még nem jelent semmit, csak plussz háttérinfó, könnyítünk az sshd lelkén kicsit

  Knocking esetén a NEW próbálkozások számát kell nézni, nem a RELATED,ESTABLISHED-eket, értelemszerűen. Utóbbiakból másodpercenként irdatlan sok jöhet és kell is bejönnie, lásd fájlátvitel, így a már felépült SSH kapcsolat nincs elkaszálva. NEW-val meg kopogjanak bátran, akinél teljesül, az eljut a szent grálhoz

  Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

• #30143 bambano titán inf3rno #30138

  Új Válasz 2020-05-04 14:05:39 #30143

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bambano

  titán

  válasz inf3rno #30138 üzenetére

  "Ha csak ideiglenesen van nyitva a port, miután bezáródik, nem fog működni az SSH, mert megszakad a kapcsolat.": ha előbb accepteled az establishedet meg a relatedet, és utána dobálod el a synt, akkor nem záródik be.

  "csak azokra a portokra tolunk port forwardot, amik a szekvencia részei, akkor baromi gyorsan fel lehet törni.": ez önmagában igaz, csak kopogtatást nem így csinálnak. a szekvencia részeit képző portokra nem kell forward, ugyanúgy dropolod, mint a többit, csak másik ipset-be jegyzed fel.

  [ Szerkesztve ]

  Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Új hozzászólás Aktív témák