Fake SSH szervert használ valaki? Melyiket? Jól működik?

Fórumok

Sziasztok!

Általában nem a 22-es porton használom az SSH-t és eddig elég ritkán találták meg.

Azonban most az elmúlt hónapokban több szerveremnél is rátaláltak és persze megváltoztathatom megint, de
elgondolkodtam, hogy a 22-es portra felrakok valami fake SSH szervert és ott nyugodtan próbálkozhat.
Így nem fogja keresni a valós másik port-ot amit használok.

Elég sok fake ssh-t találtam, de nem tudom melyik a jó, melyik az amelyiket tényleg nem tudja egy bot sem megkülönböztetni egy igazitól?
Vagy ssh honeypot-ra keressek inkább?

- mielőtt még írná valaki, használok fail2ban-t és nem a biztonság növelése érdekében, hanem zavar ha valaki dörömböl az ajtón miközben én dolgozok
- a fail2ban teszi is a dolgát, de még így is sok kérés van, mert van hogy napi szinten 300-400 különböző IP-ről próbálkoznak
- jelenleg valamivel több mint 1 napig tiltom ki az IP-t, növelhetném, de úgy gondolom ez nem jó megoldás
- kulcsot használok a belépésre és erős jelszavaim vannak

Ezeket találtam és a star-ok alapján az első lenne a nyerő, használja valaki?
- https://github.com/cowrie/cowrie
- https://github.com/skeeto/endlessh (köszi ibenny)
https://github.com/jaksi/sshesame
https://pypi.org/project/fake-ssh/
- https://github.com/fffaraz/fakessh
https://github.com/cheeseandcereal/fake-ssh
https://github.com/droberson/ssh-honeypot

Köszi!

Hozzászólások

Én endlessh-t használok, pont nincs a listán, de jól teszi a dolgát.

Ha csak az a célod, hogy ne basztassák a rendes ssht, meg kicsit szarabb legyen nekik, nem akarsz logolni, meg megfigyelni, meg tököm tudja

1) ez a jó neked, lightweight, feltartja egy kicsit a szarabb scripteket. A többi általában ennél komplexebb, meg a leírásuk szerint is másra valók többnyire.

2) Brace yourself, Franko is coming, és elmondja, hogy be kell konfigurálni rendesen az ssh serveredet a többi csak false sense of security meg üzemeltetési kockázat

Szerintem, ezek a scriptek nem fognak megallni, ha megtalajak az elso ssh szolgaltatast.

Egyrészt ez. Attól, hogy van fake, nem biztos, hogy azt fogják először megtalálni, és nem az igazi SSH portot. Semmi garancia nincs rá. Ez a fake-elés szerintem teljesen felesleges öntúráztatás, ráadásul semmit nem is old meg, mert amíg a kamu SSH szolgáltatást birizgálják a gépen, akkor is lekötik vele a sávszélt, meg a gép prociidejét, az mindenképp elmegy fölösleges dologra. Azt úgyse fogod tudni elkerülni, hogy ne kopogtassanak, komplett botnetek pásztáznak minden IP-t globálisan, annak minden elérhető, támadható portját, ha az SSH-t el is zárod előlük, kopogtat a FTP, HTTP, stb. porton, bármin, amin úgy gondolja, hogy tudja támadni. Ha annyira zavar a sok kopogtatás, tiltsd ki az IP-ket nem 1, hanem 3 napra. Tudom, írtad, nem jó ötlet, de csak így lehet lecsökkenteni a forgalmi zajt, ami a portokra menne.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Lehet végül leteszek a fake ssh használatáról, első körben biztos :)
A 3 vagy több napos kitiltás során volt már hogy 2-3000 IP volt bannolva.
Nem tudom, hogy ez az iptables-nek sok vagy nem sok?
Azt viszont tapasztaltam, hogy ha a fail2ban-t restart-olom ilyenkor, az kb. 10 perc, mert egyesével unbanolja majd utána ismét bannolja mindet :)
 

Fullstack webfejlesztő vagyok közepes rendszergazdai tapasztalattal, ezt kérem vedd figyelembe ha hülyeséget írok vagy esetleg kérdezek ;)

Én sem látom ennek a fake ssh-nak az értelmét, produktív rendszert nem szemetelnék ilyen felesleges dolgokkal, hiszen ott is lehet valamilyen hiba, és ha pont az kihasználva jutnak be, az meglehetősen kellemetlen.

Ha "becsapósdit" akarsz, esetleg nat-tal átirányítanám az összes ilyen 22-es portot egyetlen rendszerbe, ami izoláltan fut és lényegében nem jelent kockázatot (tulajdonképpen egy honeypot, de különösebb egyéb elemzési stb szándék nélkül). Akár egy gyengébb dedikált hardvert saját VLAN-ban, akár egy VM-et, bár az egy fél fokkal kevésbé biztonságos (ha kiderülne valami hipervizor probléma).

Szerencsere nekem nem kell kinyitni a vilagnak egy gepemen sem az ssht. Ha lehet, erre kellene torekedni szerintem.

Viszont ha nincs fix ipd es nem akarsz sok idot tolteni vele, akkor csak siman DROP mindenre + rakd be google/microsoft sheetsbe/docsba ipket ahonnan engeded, aztan azt leszedegeti idonkent cronjob es engedi tuzfalon. ACL alapbol meg van oldva ezeknel, akar tobb ember is managelheti, van 2fa is, aztan jovan. A minden engedesnel azert jobb igy is.

Akkor engedheti a kapcsolatot és abban az 1-2 órában nincs IP szűrés. Szerintem nem rossz gondolat.

Én régen OpenWrt-n csináltam olyat, hogy cronba beraktam egy scriptet, ami kb 5 percenként megnézte, hogy a saját weblapomon megjelenik-e egy IP cím/port páros. Ha igen, akkor kapcsolódott rá reverse SSH-val (és PKI-vel). Azért volt erre szükség, mert az eszköz távol egy NAT-os mobilneten üzemelt, nekem pedig otthon mindig változó IP-m volt. Ma már (hogy otthon van dinamikus DNS-em, illetve fix IP-s VPS-em is van) inkább VPN-nel oldanám meg a dolgot.

Az ötletedet tovább gondolva, a local gépemre írhatnék egy scriptet, ami akár 5 percenként bekérdez a szerveren egy rejtett url-re, ami pedig szépen lekéri milyen IP-ről jött a kérés és lementi.
Hozzáadva a már létező listához. Így lesz egy olyan IP lista ahonnan beengedhetem.
Vannak telefonra is olyan app-ok, amivel időzítve tudsz url-ket lekérdezni.
Ez még jobb is, mert így ha melóban Wifi-n vagy a melós IP címed is bekerül.
Azaz bárhol ahol jártál a telefonoddal és Wifi-n voltál.
Aztán hogy meddig őrződ meg ezeket az IP-ket már másik kérdés.
 

Fullstack webfejlesztő vagyok közepes rendszergazdai tapasztalattal, ezt kérem vedd figyelembe ha hülyeséget írok vagy esetleg kérdezek ;)

- gondoltam már rá, de akkor ugye mindig "kopogni" kell ssh csatlakozás előtt, talán jobb ha a telefonom 5 percenként bekopog egy url-re és a háttérben lementem az IP-t, egy cron job meg nézi, hogy volt-e változás az IP címek esetében és csak akkor iptables-t állít
- meg van Gitlab-om, szintén ssh kommunikációval és automatikus deploy-okkal és körülményesnek érzem a CI folyamatba beleintegrálni

Fullstack webfejlesztő vagyok közepes rendszergazdai tapasztalattal, ezt kérem vedd figyelembe ha hülyeséget írok vagy esetleg kérdezek ;)

- nem biztos hogy én fogok csatlakozni, van egy otthoni NAS-om ami éjszaka backup-ol (rsync over SSH) időnként, persze beállíthatom hogy ébresszen fel előtte ;)
- de jó hogy írtad, mert eszembe is jutott, hogy a másik szerveren futó gitlab-runner-ek miatt kell egy whitelist IP lista
 

Fullstack webfejlesztő vagyok közepes rendszergazdai tapasztalattal, ezt kérem vedd figyelembe ha hülyeséget írok vagy esetleg kérdezek ;)

- knockd-ben fel lehet venni whitelist-et, akiknek nyitva van alapból a port? 
- mondjuk van olyan gitlab-runner ami nem fix IP-ről csatlakozik és szedi le ssh-n a repo-t
- szerintem nem tudom megoldani, hogy ha valaki a világ másik feléről commit-tól, akkor a gitlab-runner kopogjon be előtte a szerverre és utána próbálja meg a checkout-ot
- oké, beállíthatom, hogy https-en kérje le, de ezt a knockd-s utat most nehezebben járhatónak látom (aztán lehet ez lesz :)

Fullstack webfejlesztő vagyok közepes rendszergazdai tapasztalattal, ezt kérem vedd figyelembe ha hülyeséget írok vagy esetleg kérdezek ;)

- knockd-ben fel lehet venni whitelist-et, akiknek nyitva van alapból a port?
A portkonck egy általad megadott parancsot (célszerűen: iptables) futtat, ha a szekvencia jó. Ezen a ponton a white list kezelést nem a knockd-ben kell megoldani, hanem a tűzfal szabályokban.

- mondjuk van olyan gitlab-runner ami nem fix IP-ről csatlakozik és szedi le ssh-n a repo-t
Pont ezért kell(ene) a knockd: hogy az aktuális IP-nek kinyissa  a portot. Tehát a megfelelően paraméterezett knock parancsot be kell szúrni a gitlab-runner elé

- szerintem nem tudom megoldani, hogy ha valaki a világ másik feléről commit-tól, akkor a gitlab-runner kopogjon be előtte a szerverre és utána próbálja meg a checkout-ot
Gyári gitlab-runner valóban nem tartalmazza ezt a megoldást. Viszont ha van usere a világvégi valakinek (illő hogy legyen, különben hogy nyit ssh kapcsolatot), akkor lehet vele kommunikálni.

- oké, beállíthatom, hogy https-en kérje le, de ezt a knockd-s utat most nehezebben járhatónak látom (aztán lehet ez lesz :)
Elsőre nekem sem volt könnyű. Meg ugye ott van a másik kérdés is, hogy oké, hogy bekopogtattál, port megnyílt az adott IP-nek - na de mikor záródik? Mitől és hogyan?
Nálam úgy van megoldva, hogy a tűzfal a bejövő 22/tcp célport esetén a létező kapcsolathoz tartozó forgalmat beengedi, illetve ennek megfelelően a kimenő 22/tcp forrásport esetén a létező kapcsolathoz tartozó forgalom is mehet. A knockd sikeres szekvencia esetén beengedi a kopogtató IP felől a 22/tcp célportra az új kapcsolat kérő csomagokat is, viszont ez a szabály a 15 másodperc múlva törlésre kerül. Így nem kell szöszölni azzal, hogy a beengedő szabályt töröljük, amikor már nem kell.

"nem biztos hogy én fogok csatlakozni, van egy otthoni NAS-om ami éjszaka backup-ol (rsync over SSH) "

Épp pár hete valósítottam meg: Synology rsync over SSH backup + nmap alapú port kopogtatás. Távoli szerveren iptables alapú knockd logika.
Szépen teszi a dolgát.

Szerkesztve: 2021. 01. 22., p – 12:14

Már lehet, hogy lassan túl sokat emlegetem, de én fejlesztek egy SSH szervert amit erre a célra fel tudsz használni: containerssh.io. Az új 0.4-es verzióban készül hozzá egy audit log featuret ami részletesen feljegyzi, hogy mi történt.

A korai próbálkozásokból itt találsz egy mintát. Ezekből a következőket szűrtük le:

  1. A próbálkozások közel 100%-a automatizált. 22-es és 2222-es porton túl szinte senki nem próbálkozik.
  2. A támadások közel 50%-a csak jelszóellenőrzés, azonnal kijelentkeznek.
  3. Azon támadások amelyek bejutnak elég szofisztikáltan vannak megcsinálva, SFTP-n töltenek fel statikusan forgatott binárisokat.
  4. Ritka az, hogy a scriptbe bármiféle hibakezelés be van építve. Ha nem működik, süketen tolja tovább.
  5. Olyan próbálkozásokat láttunk, hogy pl. a gépre kötött telefonon keresztül akart SMS spamelni, stb.

TL;DR ritka az, hogy rád vadásznak. Automatizált támadások tömkelege, alapvető biztonsági praktikák betartásával kivédhető.

Azért ez meredek:

Olyan próbálkozásokat láttunk, hogy pl. a gépre kötött telefonon keresztül akart SMS spamelni, stb.

DVR-eket/NVR-eket és esetleg IP kamerákat nem próbálnak meg elérni a jump hoston keresztül?

Megnézi az architektúrát és hozzá tölti fel a megfelelő binárist? Hogy csinálja, hogy (akár statikusan fordított) libc kompatibilis legyen az adott kernel verzióval? Vagy valami különleges libc-t használnak?

Csak 24 óráig futott a teszt mielőtt rájöttünk, hogy bizony-bizony több sessiont használnak, szóval át kellett dolgoznunk a ContainerSSH architektúráját. Kamera hozzáféréseket nem láttunk.

Ami a binárist illeti, mélyebben nem néztünk még bele, gondolom valami Goban készült cucc. Ha készen van a következő release tervezünk egy mélyebb elemzést, eddig azzal voltunk elfoglalva, hogy megcsináljuk a multisession konténereket.

Esetleg UDP -n működő _valódi_ Ssh szerverről hallott valaki? Már régóta keresek olyat de még nem találtam. Egy olyan eléggé láthatatlan tudna maradni. 

Goban bármilyen transporton keresztül tudsz SSH szervert csinálni (pl. akár Unix socketen keresztül is). Ami problémaként felmerülhet, az az, hogy ugyan az SSH csinál valamilyen szintű adatfolyam-vezérlést, de nem vagyok biztos benne, hogy teljes mértékben kiváltja-e a TCP működését. Ha van kedved belemélyedni itt egy lista az SSH RFC-iről.

Szerk: elolvastam az RFC 4253 handshakere vonatkozó részét és első ránézésre nem fog működni alacsonyabb szintű transzport protokol nélkül. Vagyis nem fogsz találni működő UDPs SSH-t valamilyen közbenső protokol nélkül.

Az ssh szerveren is módosítani kellene. Ne kérjen be külön jelszót hanem egyben fogadja a usernévvel. Ha jó beengedi egyébként meg semmit nem válaszol. Így eléggé láthatatlan tud maradni. nmap vagy masscan, openvas úgy nem kap semmi visszajelzést és megy tovább a következő portra. 

Köszi az up-pot. Akkor marad a jól bevált OpenVPN és azon belül ssh. Az persze UDP-s. 

https://www.wireguard.com/protocol/

We require authentication in the first handshake message sent because it does not require allocating any state on the server for potentially unauthentic messages. In fact, the server does not even respond at all to an unauthorized client; it is silent and invisible. 

És ez (természetesen) UDP. Nem tudom mennyire igaz, ki kellene próbálni! A VPN másik végén pedig futhat egy SSH szerver és bármilyen kliens használhatsz.

Hát, ennél azért bonyolultabb. Sokkal :) Egyrészt elve úgy kezdődik, hogy kötelező egy id stringet küldeni mindkét félnek. Aztán még egy köbvödör dologban meg kell egyezniük a crypto vonalon, utána a kliens még fingerprintet ellenőriz meg ilyenek, aztán majd egyszercsak eljutnak odáig, hogy akár authentikálni is lehet. Addigra a szervernek már muszáj egy rakás mindent mondani.

(Arról nem beszélve, hogy még ha meg is lehetne csinálni, biztos cleartextben akarnád utaztatni a usert?)

A másik fele udp ügyben pedig, hogy: 

   SSH works over any 8-bit clean, binary-transparent transport.  The
   underlying transport SHOULD protect against transmission errors, as
   such errors cause the SSH connection to terminate.

Szóval ha elhagysz egy csomagot, vagy out of order jön meg, akkor lendületből IJ van.

Szóval ezt encapsulálni kell, másképp sose fog menni jól.

Ha úgy működik ahogy a linkelt oldalon van írva, akkor belépsz a csak openVPN-en elérhető sshd-ra. Mivel UDP-re tervezték és nem így nem TCP-re van bízva az elveszett csomagok kezelése fos netkapcsolat mellett is jól működik. Az ssh openvpn-en elég barátságtalan rossz netkapcsolat mellett.

Nekem a szerverem egy router(mikrotik) mögött csücsül, és persze nem a default 22 porton hallgatózik. A router úgy van beállitva, hogy az input chain tcp 22 portra jön connection az szépen megy egy blacklistre és eztán dobva vagyon minden onnan érkező csomag.

+1

Amúgy nem értem, hogy ezeknek mi értelme van. Ha valaki bejön, kitalálja a usernevet, kitalálja a 2048 bites kulcsot, és még kitalálja a 2FA auth által generált egyszerhasználatos jelszót, akkor azt nem az fogja megállítani, hogy nem a 22-esen van az sshd.

Ha ez sem elég, akkor IP-re is lehet szűrni, fentebb még dinamikus IP-re is van leírva megoldás. Ha meg csak az a cél, hogy a log tiszta legyen, akkor fail2bannal ki kell vagdosni őket 3 próbálkozás után.

Én biztos nem használnék olyan "védelmet", amivel nagyobb erséllyel lövöm lábon sajéát magam, mint a támadókat.

Ha találnak egy exploitot az adott SSH szerverben, akkor jól jön, hogy nem is tudják elérni.
Ma már nagyon nem tudod magad hosszabb időre kizárni, mert rakás IP címed van: otthon kábeles net, munkahely kábeles net, munkahelyi mobilnet, otthoni mobilnet, VPS-eiden keresztül, stb.. Simán kiszeded magadat a listáról egy másik forrás IP címmel. Szervernél/VPS-nél pedig van IP KVM szóval még több IP sem kell.

"Amúgy nem értem, hogy ezeknek mi értelme van. Ha valaki bejön, kitalálja a usernevet, kitalálja a 2048 bites kulcsot, és még kitalálja a 2FA auth által generált egyszerhasználatos jelszót, akkor azt nem az fogja megállítani, hogy nem a 22-esen van az sshd."

Valóban nem fogja megállítani ha nem 22 porton van az sshd. De "kitalálni" sem kell ezeket. Egyébként az openssh nem tartozik a gyenge láncszemek közé. De nem is nyilvános minden vulnerability, exploit hír. Ha iróniának szántad az más, csak nem jött át. 

Szerkesztve: 2021. 01. 22., p – 16:13

Hülye random ötlet: dockerből inditasz valami sshd -t, akármilyet akármilyen konfiggal, és kirakod kivülre 22-re. Ha be is jut, úgysem lát semmit.

Én használtam cowrie honeypotot ARM-os headless deszkákon (pld. NanoPI NEO). Nagyon élethű alap linux rendszert szimulál, rengeteg kamu-parancs (lscpu, ps, netstat, motd, uname, stb...) működik alatta, megtévesztően élethű kimenettel. A honeypot minden része állítható kézzel is, kis munkával szerintem pld Sun Solaris kamu-környezetet is létre lehet hozni. File touch-olás, szerkesztés is élethűen meg van csinálva. A cowrite-ba belépő illetéktelenek tevékenységét lenaplózza, a feltöltött dolgaikat is külön menti. Kaptam már el vele elképesztő feltöltéseket, pld olyan pakkot amiben statikusan lefordított futtatható binárisok jöttek. Minden CPU architektúrára le volt forgatva, Intel Itanium-tól kezdve, AMD, ARM, x86, MIPS binárisok, konfig fileokkal együtt amiben látszott hogy ha futna akkor melyik portot nyitná ki backdoornak.

Szerintem ez arra jó ha kutatási céllal gyűjtené az ember hogy manapság mikkel próbálkoznak be. 

Részemről 22-es portra próbálás azonnal 1 év fail2ban jár, az SSH máshol figyel, kulcs alapúra van állítva és root usernek tiltva. Egyetlen egy magyar IP van beállítva fail2bannál amit nem bannol, arra az esetre ha véletlenül rá-sshznék a 22-es portra.

Amúgy port knocking-ot szerenték, de még nem álltam neki megcsinálni.

Kb 15 évig eltolt SSH portot használtam, a kutya sem piszkálta, aztán nekem is pár hónapja erősen pörög az auth.log, meg az ssh auth processz és zavart.
Ahol tudtam, bezártam a szervereim SSH portját és csak fix IP címről engedélyeztem.
Ahol ezt nem tehettem meg, pl. dinamikus IP-ről backup távoli szerverre, ott port kopogtatást alkalmazok.