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.
Köszi, fel is írtam a többi közé.
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
up
> Sol omnibus lucet.
Szerintem, ezek a scriptek nem fognak megallni, ha megtalajak az elso ssh szolgaltatast.
Lehetséges ez is, majd kiderül :) vagy remélem megírja valaki akinek már van ebben tapasztalata.
Viszont akkor azt a bátor versenyzőt lehet is tiltani egyből és nem zavar utána egy jó ideig, nem?
Ehhez nem kell fake SSH szerver, eleg egy Fail2ban is.
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.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
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 :)
É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).
Nem lesz sok az iptablesnek, majd ha 10x ennyi lesz gondolkozz. Ha kicsit ugyes vagy akkor csinalsz egy scriptet ami fastrukturat epit az IP-kbol es chainekbol, akkor nem lesz olyan hosszu a lookup. :)
Nagy szerencse, hogy feltalaltak mar az ipsetet :)
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.
És ha lehal pl az MS (ahogy volt már párszor), akkor vársz fél napot, hogy be tudj jutni a rendszeredbe. Mert közben változott az IP-d. Jó megoldásnak tűnik ;)
Viszont fillérekből megvan. Sőt, használhatsz több szolgáltatót is egyszerre. :)
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.
Lehet egyszerre google, ms, barmi. Egy random domainben egy subdomain alatt felsorolva.
+ fallback tenyleg knockd.
Szerintem jobb mint kinyitni a vilagnak.
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.
knockd ?
- 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
Miért kell 5 percenként? Nem elég akkor, amikor éppen csatlakozni készülsz?
- 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
Most vagy én értek félre valamit, vagy nem tudom, de a NAS backupjához minek a telefon? Nincs a NAS-on cron? :)
Gondolom azért, hogy a nas is be tudjon menni, ne legyen kizárva, mert manuálisan nem kellett bemenni a cím változás óta, és a kolléga éjjel úgy érzi, mindig otthon tartózkodik :)
A NAS script nem bővíthető ki azzal, hogy előtt kopogtat?
Vagy külön script, egy perccel a backup előtt fut és csak kopogtat?
- 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 :)
- 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.
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:
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:
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.
Ezen a ponton ez egy custom protokoll ami egy remote shellt indit. :)
https://www.wireguard.com/protocol/
É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.
Teljesen, tényleg így van.
Akkor megvan a megoldás :)
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:
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.
Nem tűnik megoldhatatlannak, de ne feledd a másik oldalt sem! Egy ilyen ssh szerverhez a standard ssh kliensek nem fognak tudni kapcsolódni pont azért, mert nem udp-n közelítenék meg a szervert. Tehát ha ez az irány, akkor nem csak szerver kell.
Igen ez így van.
Esetleg ez:
https://mosh.org/#about
Úgy tudom kell hozzá SSH szerver. Tehát nem lesz "láthatatlan". Legalábbis amikor én használtam úgy volt.
Nem tudom, lehet, eddig még nem próbáltam, csak olvastam róla.
Ugyanakkor több helyen írja magáról, hogy UDP alatt megy:
https://www.usenix.org/system/files/login/articles/winstein.pdf
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.
Ez egy nagyon jó és érdekes projekt. Csak annyi kérdésem van, hogy miért September 29, 2017 az utolsó hír a linkelt oldalon?
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 És portscanra is ugyanezt teszem. Persze ez sajnos egy jól megtervezett botnet támadás ellen nem véd. Azonban általában nem túl okosak szoktak próbálkozni, így egy címről több próbálkozás is jön.
És egyszer elfelejted megadni a portot kapcsolódáskor 🤣
True story.
+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.
És erre miért nem megoldás az, hogy eleve whitelist alapján engedsz be IP-ket? Miért kell egy olyan elem a láncba, aminél egyetlen user error miatt megszívhatod?
Dehogynem megoldás. Lehet whitelist is, én is mondtam. Csak ahhoz fix IP kell vagy valamilyen kerülőút (lásd korábbi hozzászólásokat)!
Csináltál már vulnerability test-et?
Eléggé automatizált toolok vannak
sudo nmap -Pn -n -sS ... --script=ssh* 275.257.258.259
És ez úgy megy át a fent leírt védekezésen (pl. IP whitelisting), hogy...?
(Vagy nem értem, mit akarsz mondani.)
"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.
Nem irónia. A második bekezdés pont az IP whitelistinggel folytatódik, ami ez ellen véd.
Igazából az egész komment arról szólt, hogy lehet az ssh-t úgy is védeni, hogy nem teszel köré taposóaknákat, amikbe te is beleléphetsz.
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.
Ovatosan az ilyen otlettel, mert ha szeretnel portot kimappelni akkor nem tudod network nelkul futtatni a kontenert, azaz ami bejut az tud kifele is kommunikalni.
É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.