Szerver támadás megszüntetése

Linux-kezdő

Sziasztok,

lenne egy naiv kérdésem server védelemmel kapcsolatban. A fail2ban folyamatosan jelez szinte 10-20 percenként napok óta, hogy támadják a szerveren SSH portját. Ez jó, mert megfogja a támadókat, 2 próbálokozás után 30 napra blokkolom. Nem is értem, hogy lehet ennyi címről támadni......

Kérdésem, hogy a tűzfal szabályt vagy érzékenységet érdemes-e szigorítani más (valami új eszközt bevetni), vagy jó, hogy meg van fogva a támadó és kész?

Teljesen naiv kérdés, hogyan lehetne ezeket a támadásokat megszünetni?

 

Kalmi

( ibenny v | 2020. 04. 23., cs – 10:16 )

Megszuntetni nem tudod. Tedd jo magasra az ssh portjat, jatszadozz a fail2ban-nal, csinalhatsz blacklist-et, ha rendszeresen adott tartomanybol jon es nem faj, ha a teljeset kizarod, megnezheted a denyhosts-ot, mint megoldast is. Nagyjabol ezek vannak.

( gee v | 2020. 04. 23., cs – 10:31 )

Hagyd figyelmen kívül.

Próbálkoznak az ssh portoddal, igen. Ez normális, mindenkiét döngetik. Ha rendesen beállítottad* az ssh-t, akkor bejutni úgyse tudnak. A szerveren érezhető terhelést vagy más gondot nem okoz A próbálkozókat leállítani nem tudod. Csak fogadd el, hogy ez ilyen.

Az nem baj, ha fail2ban-nal kitiltod őket (én nem szoktam, mert nem zavarnak), de ezen felül energiát pazarolni erre vagy stresszelni felesleges.

Ha nincs elég helyed a logfájloknak, akkor vagy aggresszívabban rotálhatod a logokat, vagy állítsd be, hogy ezeket ne logolja!

* ssh-ban a jelszavas bejelentkezés legyen tiltva, csak kulccsal jöhessenek be a népek. Én emellett a root bejelentkezést le szoktam tiltani, de nem muszáj.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( peterson v | 2020. 04. 23., cs – 10:35 )

ssh portot lődd fel az űrbe, tipikusan 20000 fölé (nagyjából odáig nézegetnek az _egyszerűbb_ botok).

A többit meg hagyd figyelmen kívül. A fail2ban-nak ez a dolga.

Örülünk, hogy működik. :)

"A megoldásra kell koncentrálni nem a problémára."

( Proci85 v | 2020. 04. 23., cs – 10:40 )

Szerkesztve: 2020. 04. 23., cs – 10:45

- Port eltolás

- SSH erősítése: /etc/hosts.allow .HU reverse léphet be vagy adott IP-vel kezdődő host, root nem loginolhat be, csak kulccsal lehet belépni

- SSH és minden nem publikus szolgáltatás portjának lezárása, csak adott IP-kről whitelistezve engedni vagy csak VPN-ről engedni -  az egyik legjobb, ma már ezt alkalmazom. 10 évig kint volt egy magas porton az SSH, de egy ideje ráérnek a botok és itt is piszkálnak. Engem meg zavar, hogy szemeteli a logot, meg a proccess listában mindig van egy sshd auth próbálkozással kapcsolatos sor.

( _Franko_ v | 2020. 04. 23., cs – 10:55 )

Szokjál hozzá, hogy egy publikus IP-t támadni fognak, ez egy ilyen világ. Automatikusan keresik az egyszerűbb sebezhetőségeket, hogy ugródeszkaként használják vagy egy botnet része legyen a géped. Tarts mindent frissen és ne legyen túl egyszerű a jelszavad, ha van jelszavas belépésre lehetőség.

Én a fail2ban használatát se feltétlen értem, ugyanúgy naplózza, hogy mennyi bejövő kapcsolat van, ebben nem nyersz semmit, ha pedig az SSH támadható (gyenge jelszó és/vagy sebezhetőség), akkor egy elosztott szisztematikus támadást amúgy se fog meg. Cserébe meg üzemeltetési kockázat, hogy kizárod magad véletlenül, a nyeresége meg színtiszta placebo.

https://iotguru.cloud

mert szétspammelik a logodat és felesleges network aktivitás, minek hagyjad elszaporodni őket amikor egy apt-get-el megállitható?

Mellé is lehet szarni, aztán beletenni a wc-csészébe. A kérdés az volt, hogy mi az értelme? Felesleges log a fail2ban esetén is keletkezik. Hálózati forgalom is van.

Ha meg akarnak törni, akkor megtörnek fail2ban mellett is, ha meg csak próbálkoznak néhány gyenge támadással, akkor nem fognak tudni feltörni akkor se, ha nem használod. Ez színtiszta security by obscurity, egy placebo, semmi több.

Mi az értelme?

https://iotguru.cloud

Mégis mennyiről és mennyire csökkenti százalékban?

Ha nem törhető a jelszavad (vagy nincs is jelszavad), akkor mindegy, mennyit próbálkoznak, nincs mérhető kockázatod. Amúgy meg nem fognak sokat próbálkozni, mert nem éri meg, végigpróbálnak 20-50 egyszerű variációt és mennek a következő IP címre.

Ha meg nem frissítettél és/vagy a beállításaid hibásak, akkor elsőre is felnyomnak célzottan.

Ezek a dolgok placebók, security by obscurity megoldások, hamis biztonságérzetet adnak, illetve behoznak a rendszeredbe felesleges komplexitást és üzemeltetési kockázatot.

https://iotguru.cloud

Oszt? Ha 20-50 variációval sebezhető vagy és úgy gondolod, hogy 2-5 próbálkozás után már jelentősen megnövekszik a bejutás kockázata, akkor fail2ban esetén is bejutnak csak pár másodperccel később...

Hol kockázatelemzés? Szeretném látni a százalékokat, hogy szerinted a fail2ban mennyivel csökkenti a bejutás kockázatát.

https://iotguru.cloud

Nem értem. Ha fail2ban-nal kizárom az ártó szándékú próbálkozókat (még ha látom is, hogy ilyen módon soha nem fog bejutni), az nekem jobb lesz - kevesebb zaj és talán idővel leáll az IP "zaklatásáról" az adott rendszer, vagy legalább nem mozgósít még rá x ezer másik tagot a bontnetjéből.

Hasonlóképpen egyéb szolgáltatásoknál is - pl. Asteriskre is rátalálnak időnként, de azok is repülnek.

Lehet, hogy az indok nem jó (ha nagyon akar, próbálkozik más IP-ről), de a biztonságot nem rontja - akkor miért ne használjuk?
...akkora komplexitást nem ad a rendszerhez...

Lehet, hogy az indok nem jó (ha nagyon akar, próbálkozik más IP-ről), de a biztonságot nem rontja - akkor miért ne használjuk?

Szerintem használhatod, csak nincs értelme ssh esetén.

Ez kb. olyan, mint azt mondani, hogy döngetik az ssh-t és jelszavakkal próbálkoznak, ezért befestem a biciklitárolót a kertben narancssárgára. Segíteni nem segít semmin, de a biztonságot nem is rontja - akkor miért ne?

Más szolgáltatásoknál, ahol a jelszavas belépést nem lehet letiltani, ott nagyon is hasznos a fail2ban. De az ssh az egy olyan állat, ahol nem oszt, nem szoroz.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Nem, de amennyiben a biciklit festem át rózsaszínre, sokkal kevesebb érdeklődő lesz rá. :-D

Nem kizárólag az ssh miatt használok fail2ban-t, de inkább tetetem ki vele a próbálkozókat (DROP) mint hagyjam, hogy egyre több IP-ről próbálkozzanak.
Egy dolog, hogy nem jutnak be, egy másik, hogy egy találatra ráugrasztanak több ezer gépet - nem akkora baj, ha lezárom előttük a kaput és ezáltal kevésbé leszek vonzó számukra...
 

Minek? Miben jobb az, hogy a fail2ban is logol és ott kell hibát keresned a zajban, mintha csak az SSH logol és ott kell hibát keresned a zajban? Miért jó az, hogy hiba esetén minimum két helyen kell keresned a hiba okát?

A fail2ban és társai olyanok, mint egy kutyaközönséges utcai autóra mindenféle légterelőket, világítást meg díszeket aggatnánk és kutyaközönséges utcai célokra használnánk továbbra is. Jobban nem fog tőle menni az a szerencsétlen autó, de legalább több problémánk lesz vele és ugyanúgy nem lehet értelmes, megalapozott, szakmai választ adni a "Minek?" kérdésre, csak bárgyúan vigyorogni és azt válaszolni, hogy "Nekem tetszik így."

Optikai tuning, cargo-kultusz, placebo.

https://iotguru.cloud

A sikertelen loginra vonatkozó naplók kezelése, feldolgozása (megőrzési idő, archiválás) picit más szint, mint egy f2b log. Az f2b hibakeresése nem sokkal több annál első körben, hogy iptables-save | grep "f2b-". Ha valami hibásan került bele, akkor annak ott lesz a nyoma az sshd logjában, ha meg hibásan _nem_ került bele, akkor szintén.

Van egy kis vps-em, minimális a forgalma, de az sshd-re raktam fail2ban-t, mert azért elég rendesen elkezdték töcskölni, és próba-cseresznye. Rövid idő (<1 nap) alatt a f2b-sshd lánc bő 42000 csomagot fogott meg (drop, van benne már most 5 cím). Ezek mind-mind ott lennének az /var/log/secure naplóban - nagyjáól-egészéből négy-négy sort (Invalid user/input_userauth_request/Received disconnect/Disconnected) belerondítva - és egy-egy sshd-t indítva, annak minden erőforrásigényével együtt. A fail2ban-nal kihajított ip-címek darabonként 5+1 sort termelnek a fail2ban logjában. Azaz 5*4 sor a secure logban, meg hat a fail2ban logjában, az 26 logsor. Ha nincs fail2ban, akkor n*4 sor a secure naplóban - azaz összességében ha hatnál többször próbálkozik egy adott ip (a f2b- iptables sorok számlálóin látszik, hogy igen), akkor kevesebblesz a log úgy, hogy erőforrást is spóroltunk (élve azzal a feltételezéssel, hogy az sshd indítása és a sikertelen authentikáció "drágább" műveletsor, mint a log figyelése és a csomagszűrő szükség szerinti matatása).

Rádiós meg hifista világban megy a vérpisálás a jel/jaj viszony javításán, vedd úgy, hogy ez is az.

Van egy kis vps-em, minimális a forgalma, de az sshd-re raktam fail2ban-t, mert azért elég rendesen elkezdték töcskölni, és próba-cseresznye.

Aham, mondom én, hogy olyan ez, mint utcai autóra légterelő és légbeömlő szerelése, értelmes válasz nem jön arra a kérdésre, hogy "Minek?"

Ha nincs fail2ban, akkor n*4 sor a secure naplóban - azaz összességében ha hatnál többször próbálkozik egy adott ip (a f2b- iptables sorok számlálóin látszik, hogy igen), akkor kevesebblesz a log úgy, hogy erőforrást is spóroltunk (élve azzal a feltételezéssel, hogy az sshd indítása és a sikertelen authentikáció "drágább" műveletsor, mint a log figyelése és a csomagszűrő szükség szerinti matatása).

Aham, megfogtál akkor mennyi logot? 42000 próbálkozás átlag 1000 IP címről, az 42000 helyett 6000 bejegyzés az SSH logban és 6000 bejegyzés a fail2ban logban, plusz 36000 sor a tűzfal logban, hogy eldobtad, tényleg kevesebb bejegyzés. Mennyi erőforrás spórolódott meg egy nap alatt? 6-10 MB storage? Pár tucat másodperc CPU idő?

Rádiós meg hifista világban megy a vérpisálás a jel/jaj viszony javításán, vedd úgy, hogy ez is az.

Nem, ez egyáltalán nem az. Ez cargo kultusz.

https://iotguru.cloud

" Aham, mondom én, hogy olyan ez, mint utcai autóra légterelő és légbeömlő szerelése " - jelen esetben elsősorban a kíváncsiság, hogy milyen tényleges hatása van.

" 42000 próbálkozás átlag 1000 IP címről " - nem, ez a 42000 csomag arról a néhány IP-ről, amit már a fail2ban berakott a csomagszűrőbe (három, vélhetően irgalmatlanul buta forrás viszi el az eldobált forgalom döntő részét egyébként), azaz ~150-170E sor _nem_ került bele a secure naplóba, mert az sshd-ig el sem jutott ez a 42000 próbálkozás, ezekre van _összesen_ harminc sor a fail2ban logjában, és van húsz sor a secure naplóban.

 

 

jelen esetben elsősorban a kíváncsiság, hogy milyen tényleges hatása van

Hogy is mondtam? "de legalább több problémánk lesz vele és ugyanúgy nem lehet értelmes, megalapozott, szakmai választ adni a "Minek?" kérdésre"

azaz ~150-170E sor _nem_ került bele a secure naplóba, mert az sshd-ig el sem jutott ez a 42000 próbálkozás, ezekre van _összesen_ harminc sor a fail2ban logjában, és van húsz sor a secure naplóban.

Aham, az mennyi is? 500-700 byte egy sikertelen próbálkozás, legyen 600, szorozva 42000 darabbal az ~25 MBájt log naponta. Tényleg érdemes, enélkül bizony elfogyna a hely.

https://iotguru.cloud

Ja. Miért, még mi a lényeges? Jelenleg 25 MBájt naponta és pár tízezer SSH handshake, ennyiről beszélünk, ennek lófasz sincs az erőforrás igénye, a mérhetetlenség határán van valahol. Egy 'grep' nem ér a végére? Vagy mire gondolsz ilyenkor?

Persze, mindig hozzá lehet álmodni és félni extra forgalmat, hogy legyen mire fogni, de sajnos még mindig ott tartunk, hogy ez szimpla optikai tuning, cargo kultusz, placebo.

https://iotguru.cloud

sikertelen ssh utan, elkezdheti maszirozni az smtp-t, pop3-at, ott tobb az eselye hogy egy micike altal hasznalt hello123 jelszavat talaljon. esetleg az apacheba is beprobalkozik hatha lesz valahol egy phpmyadmin vagy valami cgi cucc.

szoval a fail2ban ilyen modon egy forditott portkopogtatas: aki rosszul "kopog", mehet a p'csaba. ez meg azert mar novelheti a biztonsagot.

nyilvan nalad nemkell ilyen, mert te pro linux hekker guru vagy! :)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

szoval a fail2ban ilyen modon egy forditott portkopogtatas: aki rosszul "kopog", mehet a p'csaba. ez meg azert mar novelheti a biztonsagot.

Reméljük nem jut eszébe, hogy először az smtp-vel, pop3-mal vagy http-vel próbálkozzék!

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Mennyi esélye van a sikeres támadásnak, ha mint minden rendes háztartásban a jelszavas bejelentkezés le van tiltva?

Szerintem vagy 0%, amiről nincs hova csökkenteni, vagy ha a támadó ismer egy kihasználható lukat, akkor 100%, amikor meg a fail2ban nem is jut szóhoz.

Ha te máshogy számolsz, írd le, mert kíváncsi vagyok.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Sosem voltam egy fail2ban rajongó, de a napokban meguntam az SSH tekerést, pedig nem volt normál porton. Inkább a fail2ban logoljon és kellően nagy kitiltási idővel nagyban csökkenti a szemetet. Az sem nyerő, hogy annyira ömlik a szemét, hogy egyéb hibákat is nehéz keresni vagy hogy jelentős helyet igényelnek. Az sok helyen nem opció, hogy 1-2-3 napnyi logot tartasz meg.

Úgy csináltam meg, hogy ipset -tel lőttem össze és abból is saját szabályra, azaz totálisan kitiltja magát az illető. Igazság szerint többször láttam érezhető CPU terhelést SSH vagy MTA brute force okán, bár egyszer a fail2ban is megőrült, szóval itt sincs überszolúció... :)

grep -v "sshd" syslog - ha hibát keresel.

Ha jelentős helyet igényel az, hogy beesik mondjuk percenként egy próbálkozás, akkor jobb lesz átgondolni az egész logolást, mert ha valami tényleg elromlik és elkezd ömleni a log, akkor elfogy a hely és megszívod hamar.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

De nem percenként egy jön, valszin az bőven nem ütötte volna meg az ingerküszöbömet. :) Nem szeretek gigás logokban greppelni, meg pakolgatni sem szeretem a nagy logokat. Hely hiába van bőven, azt sem szeretem elpuffantani ilyenre, illetve a diszk (hiába ssd) IO-ból 1 is sok arra, mert vmi brutefoce botnet megtalált...

mert szétspammelik a logodat

Ha nem akarod logolni, egyszerűbb a logolást átállítani, mint beállítani a fail2ban-t, ami aztán ugyanúgy szétspammeli a logot.

és felesleges network aktivitás,

Amit nem szüntetsz meg, hiszen a csomagok továbbra is eljönnek hozzád, csak éppen nem engeded őket a gépeden belül eljutni az ssh szerverig, hanem eldobod őket.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

SSH-nál nem sok, bár vélhetően minimális CPU terhelést okoz az SSH daemonnak a sok marha elzavarása.

Webnél viszont hasznos ez vagy hasonló blokkoló megoldások. Tegnap futottam bele ismét, hogy különböző oldalakat hívtak meg különféle gagyi paraméterekkel (.., ../../, ini.php stb). Ezzel nem talál fogást, de arra jó, hogy beterhelje a szervert, mert a wordpress és társai mindent berántanak még ha csak egy 404-t dob is ki.

Erre az apache féle mod evasive jó lehet. Az x perces blokkolás mellé meg esetleg betenni, hogy tűzfalból is bobja el az onnan érkező csomagokat x percre, így a logot sem szemeteli az amúgy igen agresszív lekérdezése. Másodpercenként 20-nál több volt, mert erre állítottam a küszöbszintet és ráugrott.

CPU 80%-on járatva mindjárt leesett 20% alá.

Az SSH-nál a legköltségesebb a titkosított kapcsolat kiépítése, azaz a key exchange. A jelszó már abban megy. Minek tekerni a CPUt, ha a fail2bannal ez elmerülhető?

Azzal mondjuk egyetértek, hogy hamis biztonságérzetet adhat. Lassításnak jó, védelemnek meg nem jó. Ha a beengedett kapcsolaton pont a jó jelszóval próbálkoznak, a fail2ban nem ér semmit.

( asch v | 2020. 04. 23., cs – 11:17 )

Port knockinggal lehet még tovább szigorítani talán. Nem tudom mi a nagyérdemű véleménye róla, szerintem zseniális cucc, és talán hatékony is.

Csak óvatosan, ki ne zárd magadat is véletlenül! :-)

Talán pont DDOS ellen annyiból hasznos lehet, hogy ha egy SSH belépést elkezdünk, az több erőforrással jár, mint a port knocking sorrendet fejben tartani. Ha a DDOS támadók elvéreznek a port knockingon, akkor olcsón megússzuk, nem terhelődik túl a rendszerünk. De ez csak spekuláció, nem tudom pontosan mi az erőforrásigénye ennek vagy annak.

Nem úgy van ez, hogy DDOS esetén a hálózati kapcsolatot tolják túl, és ezért hiába akarsz te mondjuk kopogtatni a portodon, az általad küldött csomagok nem jutnak el a saját gépedre rendesen. Timeoutokat kapsz.

De ha jól értettem, itt nem DDOS ellen akarunk védekezni, hanem a szokásos random próbálkozó botok zavarják a OP-ot.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Az is egy megoldás, persze. De az is DDOS-nek minősül, ha csak sikerül a sok lekérdezéssel megborítanod a kiszolgáló szoftvert/gépeket (pl. egy szarul skálázódó cuccnak elég lehet, hogy egyszerre mondjuk száz klienst ráeresztesz, sávszél/hálózati kapacitás még marad, de az alkalmazás már megborult)

BlackY

"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)

Ez a cikk overall faszsag szagu. Mar azzal van gond, ahogy elkezdte kiszamolni, hogy bruteforceolhato, mert ez megfelel egy X karakteres jelszonak. Tudnia kene, hogy mi az ASCII es mi a Unicode. Viszont nem ez a legnagyobb baj, hanem az, hogy ez a "kis" bruteforce beszaras mennyisegu packetot general(na). Masodszor pedig nyugodtan lehet tenni a packetba "dolgokat",  pl. valamilyen kriptografiai megoldas nyugodtan hasznalhato es akkor meg nehezebb lesz kijatszani. Szoval ha bruteforcoljak, azt el lehet kapni eleg konnyen.

Sot, ha a fentebbit elfelejtjuk es a tenyleges lenyeget nezzuk a dolognak, amire nem jott ra a szerzoje a cikknek, akkor pedig arrol van szo, hogy operational security szempontjabol elso korben valahogy ra kell jonnie a tamadonak, hogy egyaltalan van port knocking. Addig o csak azt lajta, hogy nincs SSH, meg akarmi mas se.

Mezei botoknak eszebe se fog jutni, hogy ilyenekkel probalkozzanak, ok csak azt fogjak latni, hogy nem fut sehol pl. az SSH. A fentebbi alapjan latszik is, hogy a port knockingot kijatszani a celzott tamadasok korebe tartozik. A beallitas nehezseget / a feature szuksegesseget pedig majd mindenki eldonti a szakertelme, elvarasok es az adott rendszer alapjan.

Ezzel kapcsolatban lenne egy olyan kérdésem, hogy elvileg elkészítettem ezt a scriptet, mert ez nagyon egyszerűnek tűnik és fut is. Viszont nem tudom, hogy ténylegesen melyik IP-ket blokkolja (tényelg fut-e a blokkolás).

iptables -L
 

Van ilyen bejegyzésem:

DROP       tcp  --  anywhere             anywhere             match-set china src

Kérdésem, hogy az itt blokkolt IP-t tesztelési célból, hogyan lehet kilistázni az iptables -ből?

Nagyon tetszik :). Én valami olyan kombinált lekérdezésre gondolnék, amiben látom az iptables -en keresztül látom az ipset által letiltott IP-ket, láncokat. Azaz valamilyen ellenőrzés legyen, hogy valóban minden a helyén van-e. (kezdők félelme, hogy tényleg fut-e :) ).

Akkor így 100%, hogy fut :)

iptables -L -n -v | grep china
   23  1300 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set china src
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set china src

 

Az iptables-t módosítottan és bővítettem a forward-ra is:

-A INPUT -m set --match-set china src -j DROP
-A FORWARD -m set --match-set china src -j DROP

(tcp portot kivettem). Gondolom, ezzel még nagy kárt nem okoztam :)

 

Amúgy, ha lefuttatom a scriptet újra, akkor ez az üzenet jön:

 

Ami ugye nem hiba, de, minden IP-nél kilistázza, akár 1000 szer is...

ipset v6.23: Element cannot be added to the set: it's already added

...

Ez jó is meg nem is, ha csak bővül a lista, akkor ez így jó, de ha kivehetnek belőle címet, akkor nem lesz jó....

Erre lenne ez a parancs:

ipset destroy china

Viszont, mivel fut, ezért nem lehet kivenni, ez a hiba jön vissza:

ipset destroy china
ipset v6.23: Set cannot be destroyed: it is in use by a kernel component

Erre van valami okosság?

 

Az ipset-nél lett még egy kérdésem.

A scriptet elkészítettem több országra is. Feltételezem, hogy ha logikusan átírom a scriptet és beteszem a tűzfalba, akkor jól csinálom.

Ukrán:

---

# Create the ipset list
ipset -N ukraine hash:net

# remove any old list that might exist from previous runs of this script
rm ua.zone

# Pull the latest IP set for russian
wget -P . https://www.ipdeny.com/ipblocks/data/countries/ua.zone

# Add each IP address from the downloaded list into the ipset 'ukraine'
for i in $(cat /etc/block-ip/ua.zone ); do ipset -A ukraine $i; done

# Restore iptables
/sbin/iptables-restore < /etc/network/iptables.up.rules

ipset list | grep ukraine -C 6

---

iptaples

---

 

# Block anything from Ukraine
-A INPUT -m set --match-set ukraine src -j DROP
-A FORWARD -m set --match-set ukraine src -j DROP
####
 

---

Bocs, hogy ennyire körülményes vagyok, de ha már változtatok a dolgon, akkor legalább jó legyen :)

Ez teljesen jo mukodes igy, nem kell tovabb gondolkozni rajta. Tudsz a listabol egyenkent is torolni, egyebkent, de ha megszuntetned az adott listat (destroy), azert nem tudod, mert ugye az iptables jelenleg is hasznalja. Elobb allitsd le es menni fog.

Amit meg javaslok, mivel az ipset nem perzisztens, hogy idonkent mentsd ki az aktualis allapotot (ipset save > /ahova/akarod).

Igen valóban, ebből a következőt raktam össze:

---

# Create the ipset list
ipset -N iran hash:net

for i in $(cat /etc/block-ip/ir.zone ); do ipset -D iran $i; done

 

ipset -F iran

# remove any old list that might exist from previous runs of this script
rm ir.zone

# Pull the latest IP set for China
wget -P . https://www.ipdeny.com/ipblocks/data/countries/ir.zone

# Add each IP address from the downloaded list into the ipset 'iran'
for i in $(cat /etc/block-ip/ir.zone ); do ipset -A iran $i; done

# Restore iptables
/sbin/iptables-restore < /etc/network/iptables.up.rules

ipset list | grep iran -C 6
---

 

Ezzel kitörlöm az összes meglévő IP-címet:

for i in $(cat /etc/block-ip/ir.zone ); do ipset -D iran $i; done -> mivel csak hozzá fűz parancsot találtam, így raktam össze....

Utána újra vissza töltődik... és megszűnt a hibaüzenet, illetve ha valamelyik IP kikerül, akkor az már az új letöltésbe nem kerül bele...

ipset -F iran a jó megoldás :)

" Ez jó is meg nem is, ha csak bővül a lista, akkor ez így jó, de ha kivehetnek belőle címet, akkor nem lesz jó.... " - Ha jól tippelem, az "ipset flush"-t keresed :-) Bár ebben meg ott a race condition, hiszen a flush és a betöltés élesedése között "nyitva" vagy. Ezt elkerülendő én egy másik néven (név+timestamp például) tölteném be az épp aktuális listát, majd a meglévő rule elé/mögé beraknék egy újat, ami már az új set-et használja, és amikor ez klsz, akkor a régit használó rule törölhető, és a törlése után a régi set is mehet a kukába.
De lehet akár két set is, mindkettőre ráküldöd a forgalmat - az egyiket üresen hagyod, amásikba meg betöltöd az aktuális listát. Amikor újlista jön, az üresbe töltöd, és a másikra nyomsz egy flush-t.

Ez jobb: https://github.com/trick77/ipset-blacklist

A configban és a scriptben (mely automatikusan frissíti a listát) van egy csomó jóság. tor kijáratok, spam bot IP-k és persze országkódok szerint elérhető IP listák.

Ebből össze kell válogatni egy kellemeset és betolni egy központi listába (a script elvégzi).

( vfero v | 2020. 04. 23., cs – 11:32 )

A fekete lista eleje nálam így kezdődik, hidd el, hogy a próbálkozások 90-95%-át megoldja azonnal.

14.16.0.0/12
14.112.0.0/12
14.144.0.0/12
14.208.0.0/12
27.16.0.0/12
27.192.0.0/11
36.16.0.0/12
36.96.0.0/11
36.192.0.0/11
39.64.0.0/11
42.128.0.0/12
42.160.0.0/12
42.208.0.0/12
42.224.0.0/12
49.64.0.0/11
58.208.0.0/12
60.176.0.0/12
#61.147.0.0/16
#61.160.0.0/16
#61.174.51.0/24
101.16.0.0/12
101.32.0.0/12
101.80.0.0/12
101.144.0.0/12
106.16.0.0/12
106.32.0.0/12
106.80.0.0/12
106.224.0.0/12
110.96.0.0/11
110.192.0.0/11
110.240.0.0/12
111.128.0.0/11
111.192.0.0/12
112.224.0.0/11
113.64.0.0/11
113.96.0.0/12
113.224.0.0/12
114.80.0.0/12
114.224.0.0/12
114.240.0.0/12
115.48.0.0/12
115.192.0.0/11
115.224.0.0/12
#116.16.0.0/12
#116.224.0.0/12
#117.80.0.0/12
119.128.0.0/12
119.176.0.0/12
120.0.0.0/12
121.101.208.0/21
121.224.0.0/12
122.64.0.0/11
122.224.0.0/12
#123.64.0.0/11
#123.112.0.0/12
125.112.0.0/12
171.208.0.0/12
175.0.0.0/12
175.48.0.0/12
175.64.0.0/11
175.160.0.0/12
180.96.0.0/11
180.160.0.0/12
182.32.0.0/12
182.96.0.0/12
182.112.0.0/12
182.128.0.0/12
183.128.0.0/11
219.128.0.0/12
220.160.0.0/11
222.32.0.0/11
222.184.0.0/13

vfero

( franklin | 2020. 04. 23., cs – 17:33 )

Esetleg segíthet hogy ilyesfajta hozzáférések, úgymint RDP/SSH portok nem a világ felé kellene nyitottnak lennie hanem mondjuk kizárólag egy SSL VPN-en keresztül lennének elérhetőek (nem PPTP!) és akkor nem kellene ez a sok fail2ban irány?

Ingyenes PFSense mint virtuális gép erősen javasolt lehet.

 

Remélem ez segít - üdv

Segíthet, a gond ott van, hogy

- az SSL VPN-t is védeni kell, ott is be fognak próbálkozni, ott is teleszemetelik a logot,

- ha az SSL VPN-t nem egy appliance vagy valami cloud szolgáltató szolgáltatása, akkor az alatta levő gépet menedzselni szívás lehet - ha pl. a pfsense virtuális gépben fut, akkor alatta hogy frissíted a hypervisort?

Igen bár ez kb. olyan mint a viccben amikor az anyuka kérdezi az apát hogy hallotta-e hogy van a lányuknak barátja és fél hogy nem-e lesz idejekorán gyerek.

 

Előbb azt mondja:

- Nade mi lesz ha egy szobában lesznek egyedül? Ááá, mondja az apa, majd vigyáz a lány.

- Aztán mi lesz, hogy ha közel ülnek egymáshoz? Ááá, jólnevelt a lányunk, nem úgy van az.

- Aztán mi lesz, ha az ágyon ülnek? Hát, vigyáz az azért.

- Nade mi lesz, hogy ha ott kell hogy aludjon és nincs hol aludnia aznapra? Hát, akkor majd a földön alszik.

- Nade mi lesz ha felmegy az ágyra? Hááát vakarja a fejét az öreg, hacsak úgy nem....

 

VPNen keresztül talán kevésbé macerás egy év munkavégzését alapul véve, de @gelei, ja stimmt értelek - lehet hogy csak én gondolom így. :)

"3 db szervernel tartunk azert,"

Nem _azért_ tartasz értelemszerűen 3 szervert. 

Néhány rendszergazda lehet, hogy nem ugorja meg, de aki ilyennel foglalkozik, több hálózat van a kezében. Pár cég + esetleg saját bohócságokra egy VPS, amin lehet egy ugródeszka vagy vpn szerver.

Ha bárhol van egy fix IP címed, whitelistbe mehet a célhelyen és megoldva.

Nem _azért_ tartasz értelemszerűen 3 szervert. 

Nem mondtam, hogy masra nem hasznalod a gepeket, csak hogy annyi kell hozza. :)

Pár cég + esetleg saját bohócságokra egy VPS, amin lehet egy ugródeszka vagy vpn szerver.

Haaaat, nalunk a cegnel egy ilyenert szetrugnak a seggem, szerintem. :)

( igor | 2020. 04. 23., cs – 20:21 )

Ha végponti védelemről van csak szó, akkor javaslom a ConfigServer Firewallt: https://www.configserver.com/cp/csf.html

Alapvetően hasonló a működése egy fail2ban-hez, de 10x többet tud.

Semmilyen portot ne tégy publikussá, hacsak nem az a konkrét célod vele.

Ha VPN-re nincs lehetőséged (bár egy wiregard-ot tényleg 10 perc beüzemelni), akkor a fenti megoldással dinamikus dns-t is tudsz kezelni.
DDNS-re meg duckdns.org-ot javaslom.

( zitev v | 2020. 04. 23., cs – 20:57 )

Sub

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( kalmarr | 2020. 04. 23., cs – 23:36 )

Olyan megoldás amúgy létezik, hogy ha valaki root-al próbál, vagy 22-es porton, vagy tanusítvány nélkül, akkor azonnal bekerüljön a hosts.deny-be? 

( khiraly | 2020. 04. 24., p – 00:12 )

Szerkesztve: 2020. 04. 24., p – 00:14

Nalam a bejelentkezés, de meg a sudo is ssh kulccsal tortenik.

Egyetlen szervernel van egy felhasznalonal engedelyezve a password login, azert hogyha valahonnan (lxd, docker kontener, fizikai gep) ki kell masolni egy fajlt, akkor egyszeruen ki lehessen scp-zni, es ne kelljen private kulcsot mozgatni. (amolyan gateway szerver:)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

amikor debugolsz egy docker kontenert, akkor belepsz majd nezel ki a fejedbol, hogy a kulcsot hogyan teszed bele.

Az ssh-agent is kulcsot masol. Raadasul en a private kulcsot nem szeretem a fejlesztoi geprol barhova masolni.

 

Mar banom, hogy hozzaszoltam.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( zeller | 2020. 04. 24., p – 01:10 )

A fail2ban,root ssh tiltva, csak kulcsos ssh alap nálam is, énmég megfejeltem az egészet google authenticator-os egyszer használatos jelszóval (a tartalék kódokat papíron kinyomtatva két helyen tárolva).

( KicsiBocs | 2020. 04. 24., p – 10:15 )

Szerkesztve: 2020. 04. 24., p – 10:15

Feketelistához:

https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level1.netset

https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level2.netset

https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level3.netset

https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level4.netset

( p2pking | 2020. 04. 25., szo – 15:18 )

En direkt tettem egy gepre sebezheto user/passt igy megszerezhettem a scriptet.

Egy nagyon buta ssh droid script, ami semmit nem csinal azon kivul, hogy epit. Legalabbis az amelyikkel en talalkoztam.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

( kalmarr | 2020. 04. 28., k – 11:30 )

Most így látva, valóban nagyon sok megoldás van szerencsére a problémára és, ha elkezdem blokkolni az ip-ket, akkor sok zavaró dolog megszűnik :).

Ami még kérdés lett, hogy IP6-ra valamilyen jó IPSET-es script van-e? pl: ehhez hasonló? - https://github.com/trick77/ipset-blacklist