[Megoldva] Mit tehetnék még ssh betörési probálkozások ellen?

 ( Fifi | 2017. szeptember 24., vasárnap - 10:17 )

Sziasztok!

Otthoni "szerverem" ssh szolgáltatását próbálják megtörni. Nem hiszem, hogy sikerül, mert csak egyetlen felhasználónak van engedélyezve a szolgáltatás és ő is csak a jelszóval védett rsa kulcsa segítségével authentikálhat, de vannak nem kíván mellékhatásai a betörési kísérleteknek:

1.) Rohamosan hizík az auth.log ezen mennyiségtől:
Sep 23 07:30:31 silent sshd[56367]: Did not receive identification string from 80.200.209.177
Sep 23 07:30:37 silent sshd[56364]: Did not receive identification string from 89.134.132.19
Sep 23 07:30:44 silent sshd[56366]: Did not receive identification string from 94.248.134.50
Sep 23 07:30:57 silent sshd[56368]: Did not receive identification string from 79.122.93.200
Sep 23 07:30:59 silent sshd[56369]: Did not receive identification string from 84.0.156.194
Sep 23 07:31:21 silent sshd[56372]: Bad protocol version identification '2\005\v9\0300\275\304+c\231\304\336/\263f\324\265R\334\243[\313\316:\365\223' from 80.98.102.29 port 50232
Sep 23 07:31:24 silent sshd[56373]: reverse mapping checking getaddrinfo for ecs-114-115-133-158.reverse.hwclouds.com [114.115.133.158] failed - POSSIBLE BREAK-IN ATTEMPT!
Sep 23 07:31:24 silent sshd[56373]: User root from 114.115.133.158 not allowed because not listed in AllowUsers
Sep 23 07:31:24 silent sshd[56373]: input_userauth_request: invalid user root [preauth]
Sep 23 07:31:25 silent sshd[56373]: Connection closed by 114.115.133.158 [preauth]
Sep 23 07:31:33 silent sshd[56376]: Invalid user hacluster from 213.162.48.163
Sep 23 07:31:33 silent sshd[56376]: input_userauth_request: invalid user hacluster [preauth]
Sep 23 07:31:33 silent sshd[56376]: Connection closed by 213.162.48.163 [preauth]
Sep 23 07:31:51 silent sshd[56375]: Did not receive identification string from 89.147.69.187
Sep 23 07:31:58 silent sshd[56378]: Did not receive identification string from 94.248.134.50
Sep 23 07:32:05 silent sshd[56382]: Bad protocol version identification '\375' from 94.21.183.60 port 49731
Sep 23 07:32:14 silent sshd[56380]: Did not receive identification string from 77.98.247.73
Sep 23 07:32:29 silent sshd[56384]: Did not receive identification string from 94.21.239.74
Sep 23 07:32:30 silent sshd[56388]: Did not receive identification string from 89.134.80.99
Sep 23 07:32:35 silent sshd[56383]: Did not receive identification string from 84.1.223.15
Sep 23 07:32:40 silent sshd[56386]: Did not receive identification string from 89.133.255.45
Sep 23 07:32:53 silent sshd[56387]: Did not receive identification string from 37.34.255.55
Sep 23 07:32:54 silent sshd[56389]: Bad protocol version identification '' from 178.164.182.74 port 32993
Sep 23 07:32:55 silent sshd[56390]: Bad protocol version identification '\277\031K\241\f\027\345q\023\335@\233r\355\017\032\371\035\343\2204=RS\260\356\3166V\354\352v:R\331\272s' from 178.164.209.206 port 56791
Sep 23 07:32:56 silent sshd[56391]: Did not receive identification string from 178.164.209.206
Sep 23 07:33:04 silent sshd[56393]: Did not receive identification string from 88.151.101.24
Sep 23 07:33:04 silent sshd[56394]: Bad protocol version identification '#' from 88.151.101.24 port 33904
Sep 23 07:33:08 silent sshd[56399]: Invalid user admin from 176.31.103.117
Sep 23 07:33:08 silent sshd[56399]: input_userauth_request: invalid user admin [preauth]
Sep 23 07:33:08 silent sshd[56399]: Connection closed by 176.31.103.117 [preauth]
Sep 23 07:33:15 silent sshd[56403]: Did not receive identification string from 80.200.209.177
Sep 23 07:33:24 silent sshd[56395]: Did not receive identification string from 81.0.115.55
Sep 23 07:33:25 silent sshd[56396]: Did not receive identification string from 94.21.183.60
Sep 23 07:33:26 silent sshd[56397]: Did not receive identification string from 94.248.134.50
Sep 23 07:33:27 silent sshd[56398]: Did not receive identification string from 195.184.176.2
Sep 23 07:33:28 silent sshd[56409]: Bad protocol version identification '\310\2123\321\274\263Q`\233\355\365\214D0%`\262\304\031\226X_\254\355U`\240r\304\205{"\206\365\232\236' from 185.148.3.118 port 56965
Sep 23 07:33:28 silent sshd[56410]: Did not receive identification string from 185.148.3.118
Sep 23 07:33:33 silent sshd[56401]: Did not receive identification string from 62.201.105.89
Sep 23 07:33:34 silent sshd[56402]: Did not receive identification string from 85.238.76.249
Sep 23 07:33:40 silent sshd[56404]: Did not receive identification string from 81.156.46.114
Sep 23 07:33:40 silent sshd[56413]: Bad protocol version identification '&V\036\005\307\262by\231\261x*C\322\343\033\255\327\376\021\3271\002\002\240\204\256\026\t~\364\231h\177R\220\254\2272' from 80.98.50.45 port 57795
Sep 23 07:33:43 silent sshd[56407]: Did not receive identification string from 91.147.204.212
Sep 23 07:33:44 silent sshd[56408]: Did not receive identification string from 84.0.156.194
Sep 23 07:33:52 silent sshd[56406]: Did not receive identification string from 89.132.92.173
Sep 23 07:33:53 silent sshd[56416]: Did not receive identification string from 95.211.101.149
Sep 23 07:33:56 silent sshd[56412]: Did not receive identification string from 94.21.104.35
Sep 23 07:33:58 silent sshd[56419]: Invalid user hadoop from 213.162.48.163

2.) A túlterhelt sshd daemon néha engem is elzavar "ssh_exchange_identification: Connection closed by remote host" üzenettel, ami jobban zavar.

A hálózat így néz ki:
internet --> lede-t futtató router --> LAN --> debian szerver, melyen fut az sshd

Mivel a szolgáltatómtól dinamikus IP-t kapok, ezért a duckdns szolgáltatását használom a távoli elérés megkönnyítésére és a routeren a port forwardolva van a szerver ssh portjára, ami persze nem az alap 22-es.
Mind a router, mind a szerver csomagszűrőjében droppolva van, ha egy külső IP-ről bizonyos időn belül több kérés érkezik, de mivel változó IP-kről jön a kérés, ez halottnak a csók.

Amit próbáltam:
1.) Új IP kérése a szolgáltatótól. -> Nem vált be: gondoltam a ddns szolgáltatás miatt
2.) ddns szolgáltatás leállítása és új IP kérése a szolgáltatótól -> Nem vált be az új IP-t ddns nélkül is megtalálták

Nem hiszem, hogy jó megoldás, hogy elkezdem növelgetni a MaxSessions és MaxStartups értékeket, ezért jelenleg ez a kompromisszumos megoldásom:
- A ddns szolgáltatás fut a változó IP miatt
- A routeren nem forwardolom a portot az ssh daemon felé
- OpenVPN fut a routeren, mely segítségével elérem a helyi hálót, ahonnan már beléphetek ssh-val a szerverre

Ez azért kényelmetlen, mert eddig elég volt egy pendrive-on vinnem az ssh-n át belépéshez szükséges programot, kulcsot, most meg vpn klienst is cipelhetek a certjével.

Szerencsére ez a támadás nem emészti fel az erőforrásokat (van szabad RAM és a load is 0.07), de zavar.
Mit tehetek még? Mi lenne ennél jobb, de kényelmesebb megoldás? Ti mit tennétek a helyemben?

UPDATE: Megoldva
Elnézését kérem a társaságnak, user error volt és mentem is a lammer számlálót pörgetni.

A logokat visszanézve a próbálkozások, percre pontosan akkor kezdődtek, amikor routert cseréltem és vele együtt openwrt-ről lede-re váltottam. A konfigurálás nem backupból történt, hanem nulláról és kézzel szerkesztettem a konfigurációs fileokat, így a firewall konfigból kimaradt az src_dport sor a portforwardnál.
A post előtt és közben is átnéztem mindent 100-szor, de elsiklottam felette. :-(

Tegnap este a régi config file-ok újakkal történő diffelése dobta ki lammerságom.

Lehet facepalmolni! Ciki, nem ciki: that's all folks! Köszönöm mindenkinek a rám fordított időt!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Erre például a fail2ban egy lehetséges megoldás.

Ezzel nem csak azt tudom beállítani, amit a tűzfalam úgyis tartalmaz, hogy azonos IP-ről érkező sok kérést droppolok?

Nem. Scanneli az auth.logot, és tiltja azokat az ipket, akik túl sokat próbálkoznak.

Na, nézd meg a témaindító hozzászólásban, hogy mennyire ismétlődnek az IP címek... :)

ez meg nem is akkora gaz, mint amikor valamelyik hupper a fail2ban-t ddos vedelemkent ajanlgatta. Na olyankor van kedvem igazan zokogni...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Hát, ez ciki, bár csak azt néztem, hogy az első 5-6 ismétlődik :). Komplett tartomány tiltása?

Komplett országok tiltása? Esetleg DENY ALL? ;-)

22-től eltérő port?

Azt írja, nem ott van. Reméljük, ez kívülről nézve igaz. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Biztos nem ott van, lehet tesztelni ;-)

Nem tudom, hogyan találtak rád. Hasonló felépítésben engem nem kóstolgatnak. Van egy LEDE router-em a legfrissebb, 4.4.88-as kernellel. Ez forwardolja az ssh kéréseket a lokális hálózaton lógó gépre. Természetesen kívülről nem a 22-es porton van az ssh. Van dinamikus dns-em, azon keresztül el tudom érni a gépem. Egyetlen felhasználónak engedem meg a belépést jelszóval. A root login ki van tiltva. Nézem a secure logot, abban látszik, amikor beléptem távolról, erre emlékszem is, tényleg én voltam, de nincsenek próbálkozások.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Akkor annyi az eltérés, hogy nálam a routeren még csak 4.4.87 kernel van és neked szerencséd van ;-)

Nyilván a kernel release-nek semmi köze hozzá, legalább is így gondolom. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Akkor még egyformán is gondolkodunk. :-D

fwknop vagy hasonló megoldást próbáltál?

Ettől még az adott port nyitva marad, amire jön a tömérdek kérés.

Alapjaban szerintem a vpn-el jarsz a legjobban.
Par ip-t nezve nagyreszt magyar cimek, igy geoip nem sokat fogna ezeken.
Esetleg valami masik alkalmazassal jelezni hogy milyen ip-t engedjen at a tuzfal x ideig, pl egy weboldal ahol authentikalsz akkor kliens ip-t engedi, vagy kuldesz egy email-t megadott cimre es targgyal es az abban szereplo ip-t engeded tuzfalbol.
Netan berelni egy olcso vps-t (1 euro-ert is vannak) aminek fix ip-je van es azt engeded be, majd azon keresztul lepsz be.

"Esetleg valami masik alkalmazassal jelezni hogy milyen ip-t engedjen at a tuzfal x ideig, pl egy weboldal ahol authentikalsz akkor kliens ip-t engedi, vagy kuldesz egy email-t megadott cimre es targgyal es az abban szereplo ip-t engeded tuzfalbol."

Ez jó ötlet! Köszi!
Ha a vpn tényleg annyival több macerát okoz majd, ahogy gondolom, akkor erre felé indulok el.

Esetleg valami masik alkalmazassal jelezni hogy milyen ip-t engedjen at a tuzfal x ideig, pl egy weboldal ahol authentikalsz akkor kliens ip-t engedi, vagy kuldesz egy email-t megadott cimre es targgyal es az abban szereplo ip-t engeded tuzfalbol.

gagyi. De ennel meg rosszabb, hogy egy takolt cuccal noveled a rendszer komplexitasat + egy ujabb attack vector-t vittel be.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

+1, ez nagyon rosszul hangzik

"Alapjaban szerintem a vpn-el jarsz a legjobban." -> +1

Számítástechnikai tippek, trükkök, leírások - Linux ● macOS ● Windows

Én a fail2ban-t használom ilyenre, első próba után ban.

“Az Internet nem arra való, hogy minden hülyeségre rákattintsunk, emelt díjas számokat meg akkor sem hívogatunk, ha azt ígérik, az örök életet kapjuk érte cserébe!.
Facebook idézet...

OK, de mire megyek a több száz bannal, ha mindig más IP-ről jön a kérés? Ugyanezt tudja a csomagszűröm is pár sor szabállyal külön program nélkül is.

Nem hiszem, hogy sikerül, mert ...

az sshd eleg jo, de arra azert ne vegy merget, hogy nem kerulnek bele / nem lehetnek benne hibak.

1.) Rohamosan hizík az auth.log ezen mennyiségtől

rotald :-) tomoritsd :-) 100 MB alatt ez nem kene problemat okozzon szamodra. Nalam ez a file 3,5 MB.

2.) A túlterhelt sshd daemon néha engem is elzavar "ssh_exchange_identification: Connection closed by remote host" üzenettel, ami jobban zavar.

nem hiszem, hogy ez tulterheltseg kerdese, hiszen nyilvan nincs csillio ssh session-od, es a geped load-ja is kb. zero.

Amit en tennek (a te helyedben):

- a routeren szurd az ssh portra meno forgalmat, es csak a sajat cimedrol engedd a kapcsolatot, igy nem lesz benne csillio "Did not receive identification string" sor. Ha nincs fix IP-d, akkor legalabb a szolgaltatod tartomanyara limitald, a tobbit meg dobalja el a routered.

- ne a standard 22-es portot kuldd be a szervered 22-es portjara, hanem mondjuk a 22222-es portot. Mondjuk ez is csak a csillio sorok szamat csokkenti, egy kicsit is komolyabb tamadason nem segit.

az új IP-t ddns nélkül is megtalálták

LOL. Mert nem hosztnev alapjan jutottak el hozzad, hanem egyszeruen beleestel abba a cimtartomanyba, amit scannelnek

Nalam pl. ez van az sshd konfigban: KexAlgorithms

,diffie-hellman-group-exchange-sha256
Aztan ilyenekkel vagyok tele: no matching key exchange method found. Their offer: diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth]

Az openvpn szerintem megsporolhato. Nem hiszem, hogy biztonsagosabb az ssh-nal.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Heti roatate van és még hely is egyelőre ...

root@silent:~# ls -l --block-size=M /var/log/auth.log*
-rw-r----- 1 root adm 44M Sep 24 11:45 /var/log/auth.log
-rw-r----- 1 root adm 1M Sep 17 06:25 /var/log/auth.log.1
-rw-r----- 1 root adm 1M Sep 10 06:25 /var/log/auth.log.2.gz
-rw-r----- 1 root adm 1M Sep 4 06:25 /var/log/auth.log.3.gz
-rw-r----- 1 root adm 1M Aug 27 06:25 /var/log/auth.log.4.gz

root@silent:~# df -h | grep var
/dev/md3 992M 495M 481M 51% /var
/dev/md4 45G 6.8G 38G 16% /var/mail

Szépen látszik, hogy 1 hete még mennyivel kevesebb auth volt.

"routeren szurd az ssh portra meno forgalmat, es csak a sajat cimedrol engedd a kapcsolatot"
Ez nem járható, mert több helyről lépek be (mobilok dinamikus IP-vel, más szolgáltatók hálózata stb.)

"ne a standard 22-es portot kuldd be a szervered 22-es portjara"
Nem a standard 22-es portról volt forwardolva a port és a szerveren sem a standard porton fut az ssh daemon.

"Az openvpn szerintem megsporolhato. Nem hiszem, hogy biztonsagosabb az ssh-nal."
Nem gondolom én sem. Eddig is volt vpn a helyi háló elérésére, de az ssh elérhető volt kívülről is eddig. Most majd csak a vpn-en keresztül a belső hálóból ... pár hét múlva újra kinyitom a külső portot, hátha addig elfelejtenek.

a szerveren sem a standard porton fut az ssh daemon

Az már mindegy.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tudom ...

Tudom, hogy tudod. :) Egy pillanatig sem gondoltam az ellenkezőjét. ;)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez nem járható, mert több helyről lépek be (mobilok dinamikus IP-vel, más szolgáltatók hálózata stb.)

hat, igen, a fix IP-nek megvan azert a maga varazsa. De nem hiszem, hogy ne tudnad 1 kezeden megszamolni, hogy akkor hany szolgaltatot hasznalsz. Ha nagyon edge case vagy, akkor 2 kezeden, de a cipodet tuti nem kell levenned...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Tehát szolgáltatóim tartományát engedélyezzem? Ez nem rossz ötlet!

https://www.digitalocean.com/community/tutorial_series/how-to-implement-port-knocking-to-obscure-your-ssh-daemon

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Ezt a kliens oldalon is kell támogatni. A notebookomon és androidos mobilomon lévő kliensnek ez megy, de a pendriveon lévő puttynak szerintem nem. Új kliensprogramot kellene oda is keresnem. Mint alternatíva könyvjelzőzve.

knockd támogat olyat, hogy ha sikerül azonosítanod magad, akkor az adott IP-re nyitja a portot. Ergo külön van választva az ssh kliens, meg a port knocker kliens: Első körben beautholod magad, onnan meg már ssh-val / putty-val, vagy bármivel be tudsz menni.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Köszönöm, akkor ennek majd utánanézek.

Lehet én gondolom rosszul, de ha csak egy portot engedsz az ssh-nak a routeren, akkor hogyan keletkezik, mindenféle porton az ssh logban bejegyzés? Ezeket a kísérleteket már a routernek el kellene dobnia. Hogyan jutnak el mégis a szerveredig?

Azokról a portokról indult a kérés a kérést indító IP-ről. Azok nem az én nyitott portjaim.

Kukkantsál már rá, hogy mi a mostani IP-d reverse.

catv-86-101-247-XXX.catv.broadband.hu

Ps: A UPC a szolgáltatóm. Ez volt a helyzet a 37.191.24 és 37.191.26 hálózatokból kapott IP-kel is.
Van viszont egy másik gépem a UPC-nél a 37.191.16.0 - 37.191.23.255 tartományból, de ott nem próbálkoznak. Még ...

Tehát a kíváncsiskodók most a 37.191.24.0 - 37.191.31.255 és 86.101.246.0 - 86.101.247.255 tartományokban próbálkoznak.

Mi lenne ha a SSHd csak óránként 5 percig futna. Ha jól emlékszem a kiépült kapcsolat nem szakad meg.

ezt egyedul talaltad ki, vagy segitettek benne? Mert ha ez sajat otlet, akkor szerintem be kene adnod a call for papers kereteben az idei hacktivity-re...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Szerintem az összes security by obscurity varázslás lófasz tejszínhabbal... ha tudod, hogy nem fognak megtörni, mert frissen tartod a rendszert és limitáltad az SSHD lehetőségeit, akkor maximum a naplózás kellene zavarjon, de valamelyik rétegben naplóznod kellene, hogy próbálkoznak... ha ennél jobban zavar a dolog, akkor ahhoz már DDoS védelem kellene, az meg nem a te feladatot egy otthoni router esetén sem.

Nem valami olyan portra tetted az SSH-t amit mas program hasznal?
Ugy nez ki a legtobb uzenetben, hogy nem is jutnak el az azonositasig.
En altalaban elteszem vmi 9000 feletti tartomanyba....
En ugy ogndolkodom, hogy a script kiddie-k csak ugyis talan <1024 es mas torheto nyitott portokat keresnek. ha mondjuk az SSH-t atteszed a 3389 portra arra ugyanugy fognak keresni, de ha 11111 a port azt mar talan annyira nem.
Ez sem fog megvedeni a celzott tamadasoktol, de kevesebb script fog arra keresni - velemenyem szerint....
Ez a tapasztalat egy otthon pfSense-el as par hobbi szerverrel.... - ha a port a 22 naponta - talan orankent - tobb ezres nagysagrenu kereses es fail2ban ban lesz a logban Ha eltesem 9000 fole, nincs semmi.

-+-+-+
Dropbox tarhely
Cave Canem
+-+-+-

Nem feltétlenül. Épp most néztem én is valahol egy friss log-ot, amelyben szinte kivétel nélkül a 20000-50000 közötti portokra próbálkozott sorozatosan rá valaki kínai ip-ről, root-ként... :)

Számítástechnikai tippek, trükkök, leírások - Linux ● macOS ● Windows

20000 feletti port lett forwardolva az sshd-nek és az is 20000 feletti porton figyel.

Á, ez már rég nem így van, megtalálják máshol is. Ha fejlesztesz a páncélon, hozzáfejlesztik az ágyút.

Azt elfelejtettem hozzaadni, hogy tuzfalon tilthatnad az elerest es csak azokon az IPkon engedni, amikrol biztos h te ered el.

-+-+-+
Dropbox tarhely
Cave Canem
+-+-+-

Anno volt olyan trükk, hogy csak egy fix forrás portról volt engedve a kliens és a többi drop. Sajna nem tudom, hogy a mostani klienseken lehet-e már állítani. Nekem elég volt a kliens oldali routeren egy iptables sor.

Született itt már sok értékes javaslat, de ezt még nem láttam:
DMZ nincs beállítva véletlenül? :)

Lede-t nem ismerem.
Több szerverem van ssh-val nem az eredeti, egyébkén jó magas számú portra kirakva a netre, nincs ilyen jellegű támadás a logban. Viszont, ha az ssh a 22-es porton figyel, akkor pár perc múlva már pörög a log...

Tehát, amit próbálnék:
1. Tedd át egy másik random portra az ssh-t. Ha folytatódnak a támadások, akkor az ip-d listázva van valahol. De szinte kizártnak tartom, hogy szkennelik a teljes port tartományt és rátalálnak.
2. Próbára tegyél be egy másik bármilyen routert, így ki tudod szűrni az esetleges félrekonfigurálást.

felteve, hogy erted a dmz koncepciojat (bar a kommented alapjan ketlem), megis min segitene a dmz a kerdezonek?

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Egyszerű SOHO routerekben szokták így nevezni azt, amikor az összes bejövő kapcsolatot egy belső ip-re lehet küldeni egy pipa behelyezésével.
Például: TL-WR741ND_V5_UG.pdf 58. oldal.
Erre gondoltam. Abban teljes mértékben igazad van, hogy ez a DMZ nem az a DMZ, amire Te gondolsz.
Köszi a pontosítást, valóban pongyola volt a megfogalmazás.

Két dolgot tudnék javasolni:

1. https://en.wikibooks.org/wiki/OpenSSH/Logging_and_Troubleshooting#Brute_force_and_Hail_Mary_attacks

"To deal with Hail Mary attacks, contact the attacker’s net block owner. A form letter with a cut-and-paste excerpt from the log is enough, if it gives the exact times and addresses. Alternately, teams of network or system administrators can work to pool data to identify and blacklist the compromised hosts participating in the attack."

Esélyes, hogy egy botnet áll a dolog hátterében. Dobj egy mailt az érintett IP-tartományok abuse címeire (ezt egy whois lekérdezéssel gyorsan ki tudod deríteni), hátha történik valami. Ha túl sok subnet van, akkor persze nem biztos, hogy érdemes bajlódni ezzel, egyébként egy próbát megér.

2. Sajnos nem tehetsz semmit az ellen, hogy egy hacker vagy egy botnet kipécézte az IP-címedet (vagy a UPC valamelyik IP-tartományát), de azt megteheted, hogy csökkented az sshd logolási szintjét, így kevesebb garbage lesz a logokban:

LogLevel
[...] The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. [...]

Én első körben megpróbálnám az "ERROR" szintet, ha így is sok a szemét, akkor mennék feljebb "FATAL"-ra, ha pedig minden kötél szakad, akkor "QUIET", bár ez már nem feltétlen jó megoldás, hiszen így a valóban hasznos logbejegyzések sem fognak bekerülni az auth.log-ba.

Kéne csinálni egy pseudo ssh alkalmazást, ami SSH-ként azonosítja magát, ezt elindítani a 22-es porton és csak annyit csinálna az azonosításon kívül, hogy nem engedi el a socketet, amin megnyitották.

> Sol omnibus lucet.

Mit csináljunk ezzel a kupac földdel? Ó, ássunk neki egy gödröt és tegyük bele.

annyiban nem hülyeség h lehet h egy ideig átvered vele a botokat.
viszont a port trappinggal csak a saját tcp/ip stack-edet telíted be, a túloldal ha akarja, figyelmen kívül hagyja hogy nem jött FIN/ACK vagy bármi tőled.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Ha elkezdesz a távoli géppel nagyon lassan kommunikálni, akkor nagyságrendekkel kevesebb próbálkozásra lesz ideje.

> Sol omnibus lucet.

Valószínűleg zombi gépekről tolják a próbálkozást, keresve az újabb áldozatokat... előbb elfogynak nálad az erőforrások, minthogy egy kicsit is lassítsd a másik oldal több százezer gépét.

+1, ez így értelmetlen.

Az iptables TARPIT volt valami hasonló,nagyon régen.

Tarpit módszer, 22-es port, szándékosan lassú válaszolgatás minden tcp negotiationra, de úgy hogy ne timeoutoljon egyik oldal sem. Természetesen ssh login nincs, csak kamu negotiation felőlünk. Elég sokáig lehet nyújtani a dolgot. 1 ilyen portra besshzni akarás pár perc pingpongozás. Nálam 22. porton próbálkozás 1 év fail2ban bármilyen ipről. 2201 az ssh portom, 3 rossz jelszó ott már örökban. Szkennelgető botok ellen 99%-van hatásos. Nagyon lement a bannelni való új ip címek mennyisége, már csak 1-5 új ip óránként. A gép dmz-ben van csupasz seggel a neten. Minden port zárva kivéve 22 és 2201.

Honeypot módszer, már kitalálták. Pszeudo OS fut álparancsokkal. Van ps, ls, uname, lspci minden anyám kínja, álkimenetet generál. Mkdir, cp mv stb... Mire rájön hogy honeypotba került és nem éles rendszeren van eltelik egy kis értékes idő. Ha rájön... 22-es portra való dolog.

Kössz a megerősítést.

> Sol omnibus lucet.

Két dolgot is tehetsz:

  1. GeoIP alapján letűzfalazod azokat a kéréseket, amelyek nem abból a régióból jönnek, ahonnan te belépnél. Ezek a kérések így el de jutnak az ssh démonig, így csökkentik a terhelést rajta. A kirakott példa alapján szúró próba szerűen ellenőrizve úgy látom, hogy a kérések cirka fele itthonról megy, azokat ezzel a módszerrel nem tudod elpattintani. Ha az ezzel elérhető terhelés csökkentés elég, akkor meg is vagy (érdemes előtte alaposabban átnézned a logokat és letesztelni a begyűjtött Ip-ket, hogy mennyi a nem nyilvánvalóan szűrhatő arány). Azzal azért érdemes számolni, hogy a GeoIP nem tökéletesen pontos, néha előfordul, hogy nem ott vagy, mint ahol ő gondolja.
  2. Port knocking - így tudod szabályozni, hogy csak neked nyíljon meg az ssh port, mindenki más elől elzárja a tűzfal. Hátránya, hogy kell plusz egy program.

    Hozzá kell tenni, hogy ez ránézésből nem igazi támadás. Csak a botnetek scannelgetik a gépedet. Csak hát mivel sok botnet van, ezért együtt már elég nagy terhelést adnak.

    Zavard össze a világot: mosolyogj hétfőn.

Na és ha az alábbi sorra regexp, fai2ban-al, majd első próbálkozásra ban, legalább egy napra?

Sep 23 07:33:43 silent sshd[56407]: Did not receive identification string from 91.147.204.212

Nálam a Drupal és Wordpress támadókat így üldöztem messzire, azóta se próbálkozik senki.

Orwell az 1984-et regénynek írta és nem használati utasításnak!

Off: Valahol még a fail2log-nál tartanak

Idézet:
This rule checks the RdpCoreTS/Operational Log for failed login attempts
This only tackles login attempts where the user does not exist (existing users do not trigger 140.. why? no one knows)

FTR:
* Regen csinaltunk olyat, hogy ddns volt beallitva minden rendszergazdanak a gepen (valami free) es csak azokat a cimeket engedte iptables. Ezen felul volt egy vritualis gep fix ipvel amit atjaronak hasznaltak ha mobilrol kellett belepni.

* Masik helyen ugy volt megoldva, hogy egy http request ment ki majd az egy apin keresztul bizgeralta a routert.

érdekes megoldás. :D

----------------------------------
szélsőségesen idealista, fősodratú hozzászólás