IPTABLES segítségkérés

Linux-haladó

Tudom hogy most záporozni fognak rám a jogos vagy jogosnak vélt kritikák, de akkor is megpróbálkozom, hátha van aki megpróbál a segítségemre lenni.

Nos a szerverem védelme hagy némi kívánnivalót maga után /és akkor finoman fogalmaztam/, az IPTABLES valószínű rosszul lett bekonfigurálva, vagy ezen kívül is lehet illetve valószínű van probléma.

Akiben van némi jóindulat /mivel van pár érzékenyebb adat is/ megköszönném ha segítene kitesztelni hogy min kellene erősíteni mind az IPTABLES mind a védelmen, esetleges frissítésekkel is.

A segítő szándékot előre is megköszönve.

  • 1219 megtekintés

( pgabor v | 2018. 02. 28., sze – 22:11 )

En ugy szoktam kezdeni, hogy tiltok mindent. Aztan egyesevel csak azt engedelyezem ami kell.

Igen értelek. A gond csak az hogy ez egy éles szerver és most távolról ha kitiltom magamat róla akkor be kell menjek a szerverparkba... Ez nem lenne túl szerencsés... És azt kéen kiteszteljem hogy be tudnak e jutni kívülről? azaz törhető e a szerver?

______________________________________________________________________________________________________

Az optimizmus nem azt jelenti, hogy valaki nem látja a problémákat, hanem hogy hisz abban, hogy mindig létezik egy megoldás.

IP-konzol nincs hozzá? Távolról tűzfalat konfigurálni veszélyes, de lehet a hibás konfigból eredő szívásfaktort csökkenteni. Faék egyszerű a dolog: szerkesztés, módosítás előtt lemented az aktuális szabályokat (iptables-save), csinálsz egy munkamásolatot róla, azt szerkeszted.
Mielőtt élesítenéd (iptables-restore), az "at" parancsot hasnzálva beütemezed mondjuk két perc múlvára az eredeti konfig visszatöltését.
Ez után a szerkesztett fájlt betöltöd (iptables-restore), megpróbálsz egy másik, új session-ben bejelentkezni, ha sikerül, akkor "atrm"-mel kidobod a fölösleges eredetire való visszaállítást (vagy az abban visszatöltésre kerülő fájlt az új session-ben felülcsapod az új beállításokkal), és készen vagy.
Ha nem sikerül bejelentkezni, akkor megvárod, amíg az időzített script megteszi, amit kell, és újra nekifutsz a dolognak :-)
Ha nagyon szépen akarod csinálni, akkor írsz egy scriptet, ami mindezt összerakja/megcsnálja neked (aktuális mentése, beállítások megnyitása szerkesztésre, ha kész a szerkesztés, időzített job elkészítése, várakozás az új sessionban történő bejelentkezésedre visszaállító job szükség szerinti törlése.)

Az, hogy IP-szinten szűrsz, az a biztosnág egy kicsi, de lényeges szegmense, aminél sok esetben fontosabb lehet az, hogy a nyitott portokon figyelő alkalmazások hogyan, mi módon vannak frissítve, védve, illetve konfigurálva, illetve az egész biztonság hogyan van kezelve.

( royal v | 2018. 02. 28., sze – 22:14 )

Az nmap segít neked megmondani, hogy milyen portok vannak jelenleg nyitva. Ha mindent letiltasz és tudatosan kizárólag azt engeded, amire tényleg szükséged van és lehetőség szerint ezeket sem mindenhonnan, akkor már elég jó irányba haladsz :)

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

( lx | 2018. 02. 28., sze – 22:17 )

Ne a saját hálózatodból, hanem pl. a szomszédéból, haveréból nézd meg nmappel, hogy milyen portokat lát nyitva a nagyvilág a gépeden.

Aminek nem kell nyitva lennie, az ne legyen nyitva, tiltsd le a szolgáltatást; ami meg kell, de nem kéne, hogy mindenki lássa, arra állíts be szabályt (erre már célirányosan tudsz gúgölözni).

A szoftver meg... annál többet úgyse tudsz tenni, hogy gyakran frissítesz yummal vagy apt-gettel vagy amid ott van. Ez sem jelent garanciát, sőt szélsőséges esetben árthatsz is vele (mentés!), de ha ilyen bizonytalan vagy, akkor az rizikósabb, ha nem fixelsz.

Köszönöm, de ez a saját szerver és nem nálam van hanem szerver parkban.

_____________________________________________________________________________________________________

Az optimizmus nem azt jelenti, hogy valaki nem látja a problémákat, hanem hogy hisz abban, hogy mindig létezik egy megoldás.

( joco01 v | 2018. 02. 28., sze – 23:06 )

Amit én csinálnék:
1. Minden tiltó/engedélyező szabályt törölni (NAT, port forward, ilyesmi maradjon), minden policy legyen accept.
2. Minden tábla végén menjen egy logolás. Itt logolod azokat a csomagokat, amikkel még foglalkoznod kell. Legyen ez a TODO log.
3. A TODO log alapján amit szerinted be kellene engedni, azt kezdd el felvenni egyesével. Minél szigorúbb szabályokat adsz meg, annál jobb. Szűrj IP tartományra, interfészre, protokollra, portra, helyi userre, conntrack state-re, amire csak lehet. Ezeket a csomagokat úgy fogadd el, hogy TODO log helyett a JO nevű logba kerüljenek.
4. A TODO log alapján amit szerinted tiltani kellene, azt tedd át egy másik láncba, ahol egyelőre átengeded, de logold őket a ROSSZ nevű logba.
5. Ismételd a 3-4 pontot, amíg a TODO log ki nem ürül.
6. Vess egy utolsó pillantást a JO és ROSSZ logokra.
7. Szüntess meg minden logolást, a JO csomagokat engedd be, a ROSSZ csomagokat tiltsd ki véglegesen.

Illetve használj iptables-persistent vagy hasonló csomagot, és a szabályok mellé írj kommentet (vagy -m comment), hogy később is tud, mi miért van úgy.

Köszönöm szépen a segítséget. Hát ez élő szerveren eléggé necces lenne,éppen ezért maximum azt csinálom hogy a mostani iptables beállításokon amit az évek folyamán megcsináltunk megpróbálom még biztonságosabbá tenni. Az SSH hozzáférés biztosan egy olyan pont amit szűkíteni kell majd.

Host is up (0.036s latency).
Not shown: 985 filtered ports
PORT STATE SERVICE
21/tcp closed ftp
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
110/tcp open pop3
143/tcp open imap
443/tcp open https
587/tcp open submission
993/tcp open imaps
995/tcp open pop3s
2121/tcp closed ccproxy-ftp
2525/tcp open ms-v-worlds
62078/tcp closed iphone-sync
63331/tcp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 6.34 seconds

Az optimizmus nem azt jelenti, hogy valaki nem látja a problémákat, hanem hogy hisz abban, hogy mindig létezik egy megoldás.

Logolni érdemes, de csak módjával - invalid és eldobott bejövő SYN mindenképp javasolt, de rate limittel, mert nagyon sz@r dolog, ha a logterület telemegy, és amiatt nincs érdemi infó arról, hogy miért állt meg a szerver, a végén meg minden egyebet eldobni (még akkor is, ha a default policy a DROP, biztos, ami ziher - enni nem kér az a rule, de tisztább, szárazabb érzés...): 


-A INPUT -m conntrack --ctstate INVALID -m limit --limit 6/min -j LOG --log-prefix "IPTABLES: DROP INVALID "
-A INPUT -m conntrack --ctstate INVALID -j DROP
...ide jöhetnek a "beengedem" szabályok... (elsőként célszerűen a --ctstate RELATED,ESTABLISHED...)
-A INPUT -m conntrack --ctstate NEW -m limit --limit 6/min -j LOG --log-prefix "IPTABLES: DROP NEW "
-A INPUT -m conntrack --ctstate NEW -j DROP
-A INPUT -j DROP

Vagy álljon neki helyesen: távmenedzselés kell, tehát ssh-t megerősíteni (root login tiltás, csak megadott csoportba tartozó userek léphessenek be, és ők is csak kulcsos authentikációval vagy valamilyen kétfaktoros megoldással, stb.) Ja, ha csak kulcsos auth van, akkor legalább egy sudo joggal bíró usernek _ne_ járjon le a jelszava... (ami az ssh-tól függetlenül mindenkinél hosszú és bonyolult legyen), opcionálisan portot cserélni, stb., minden egyéb befelé irányuló kapcsolatkezdeményezést rate limittel naplózni, és eldobni.

És ettől a "kályhától" elindulva lehet majd nyitogatni a szükséges portokat, mindenféle doloogra szűrve. A tapasztalat ugyanis az, hogy a "minden nyitva, és majd zárogatom befelé..." konvergenciája nem jó, ellenben nagyon rossz.

( uid_7086 | 2018. 03. 01., cs – 07:21 )

Subs helyett...

Valamit nem értek: ha jól sejtem, a kérdező nem rendelkezik stabil alapokkal a netfilter konfigurálás terén.
Nem lenne jobb, ha valami egyszerűbb keretrendszerrel kísérletezne? (ufw, esetleg shorewall stb.)
Kisebb lenne az esély, hogy valami baki folytán nagyobb lyukat nyisson a szerverén.

Köszönöm a válaszokat, igyekszem minden egyes választ megfontoltan alkalmazni. Egyenlőre egy virtuális szerveren kipróbálom és amiben biztos vagyok azt fogom az éles szerveren is használom. Inkább erősítenem kell a meglévő védelmet. Elsősorban ami a fő kérdés volt az ssh védelem, arra is választ kaptam.igazából eleve a szerver nem enged be root joggal, ez már évek óta így van. De tény hogy külön private kulcsos megoldást nem alkalmaztunk, arra gondoltam ezt is lehetne az IPTABLES-ben szűrni.

________________________________________________________________________________________________

Az optimizmus nem azt jelenti, hogy valaki nem látja a problémákat, hanem hogy hisz abban, hogy mindig létezik egy megoldás.

( lajos22 | 2018. 03. 01., cs – 13:14 )

Én nekiálltam egy teszt gépen nyomkodni. Alapban minden DROP és utána vannak engedélyezve dolgok. Aztán, amikor összeállt a teljes "konfig" azt letesztelve kiírtam egy fájlba, és úgy került fel a végső helyére.

Én az outputot is tiltom, és csak olyat engedek, ami kell. tehát pl bejövő kapcsolat visszafelé beszélhet, de pl a gép nem beszélhet ki csak egy dns szervernek, meg a frissítéshez szükséges szerver felé http-n. Így ha valami nem odaillő bekerül, kisebb esélye lehet, hogy felvegye a kapcsolatot a támadóval.

--
openSUSE 42.2 x86_64