ssh állandóan nyitott port nélkül

Ez a cikk ihletett, hátha valakit érdekel.

Eredetileg hsz-be szántam, de annak hosszú a lepcses pofám miatt. :-D

Kicsit filóztam, mert "security by obscurity", de legyen. :-DD

Az alábbi gányolt módszer nagyjából a tűzfal iptables egyfajta távirányítása, hogy az ssh portja
állandóan mégse legyen nyitva csak a szükséges időben, szükséges mértékben ip címre/tartományra.

Gépelési helyesírási hibákért felelősséget nem vállalok. :-D

Én egy ideje / néhány éve / a következő kiegészítő módszert (is) használom házi barkácshasználatra extraként ssh védelmére, nyilván nem felel meg mindenkinek, akinek mégis annak egészségére :

hozzávalók ssh serveroldalon: iptables, bash, exim, coreutils, procmail, fetchmail, ssh :-), gpg, bsd-mailx /asszem ennyi, más nem kell ha minden igaz,de lehet, hogy kifelejtettem valamit, alábbi szövegből úgyis kiderül; hja sudo is kell :-D (mondom hogy elfelejtek mindent :-D) /

1. egy megfelelő formátumú szövegfájlba írok egy ip címet / akár wifi public címét/, amit szeretném ha az iptables beengedne, meg mellé egyfajta "időbélyeg"-et, meg egy kis egyebet.
2. ezt gpg-vel lekódolom.
3. email-ben megy egy bizonyos emailcímre speciális tárggyal a kódolt email / mobilnettel minden körülmények között, akkor is ha egy natolt wifi hálózat látható címét adtam meg !! /.
...
4. ssh serveres gép fetchmail-el leszedi ó'tomatán az emailt /=tehát itt sincs úm. nyitott port/, speciális tárgy + méret alapján szűri /exim, procmail/, ha stimmel, akkor futtatja a dekódolást, ha sikerül, kinyeri belőle az ip címet és az "időbélyeg"-et, amennyiben a szövegfájl a "kis egyeb"-et is tartalmazza.

Ha az "időbélyeg" több mint kb. 9 perces akkor ennyi volt; a történet véget ért. Ha az emailszolg. szarakodik, vagy lassú, akkor így jártam, kint maradtam. Volt rá példa sajna. Ez van. Azt nem mondtam, hogy a módszer teljesen tökéletes és buktatómentes. :-D

Ha az időbélyeg is jó, akkor elindít egy sudo iptables szkriptet ami megkapja az ip címet "paraméter"-ként, így "beengedi" az adott ip címet az ssh portjára. / nem, 0.0.0.0-t és hasonlót nem fogad el, akkor sem ha ez volt a kódolt emailben. :-D /

Majd a rendszer visszadob egy "visszaigazoló" emailt az egyik emailcímemre, hogy leengedte a falat, és elindul egy számláló. / ezt az emailt csak mobilnettel nézem, ha megjött az email akkor nyertem./ Általában 4-5-6 perc alatt megjön azért a visszaigazoló email.

Ennek a forrásában megnézem, hogy melyik ip címről jött. (hátha a szolg. éppen most cserélte a dinamikus ip címet sosem lehet tudni.). És már fel is lehet csatlakozni, vagy mobilnetről, vagy mobil bont+egy ingyenwifiről és máris kiderült, hogy még statikus ip cím sem kell az ssh servernek.

Az "időbélyeg" 9 percéből a legrosszabb esetben is van még 2,5-3 percem, hogy belépjek.

Ha sikerült bejelentkezni a 9 perces számláló leáll, és elindul egy másik, ami azt vizsgálja időnként, hogy az adott felhasználó még be van-e jelentkezve, vagy már disconnectált/megszakadt, ha igen, vár kb. 2 percet, és ha nem lép vissza, akkor törli az iptables engedélyező szabályokat is. / Sajnos kezdő alzheimeres lehetek, igen gyakran vissza kell lépni mikor valamit elfelejtek, ezért van a 2 perc./

Majd küld a mobnetes emailcímre egy visszaigazolást, hogy leállt a cuccal.

Kicsit bonyolultnak tűnik, valójában sima néhány soros barkácsolt-gányolt bash szkriptekkel oldom meg az egész sztorit. Nem kell túlbonyolítani.

Viszont így nem kell napi 24 órában nyitva tartani egy porton az ssh-t az egész világnak még egy tetszőleges porton sem.

Hanem csak célzottan, vagy nagyjából célzottan, ha egy public-wifi címét adom meg.

----------

- A sudo szkript miatt van némi biztonsági kockázat, de talán több a nyereség biztonság terén, mint a rizikó, mert még sincs állandóan nyitva az a fránya port.
- Meg az emailküldéses módszer miatt, ha a rendszer törik, akkor könnyen spam-gyár is lehet belőle.
- Nyilván ha public wifi címet adom meg, akkor az adott teljes wifi hálóra nyilván nyitva van port. De az mégsem a teljes internet.

----------

Az ssh servert én is más portra tettem, bár ez szerintem csak ideig-óráig jó, ha elég sokáig van nyitva a port, azért meg lehet találni. Nagyon sok eszköz van.
Az nmap- és hasonló script kiddies szkennerek számára pluszban van egy extra meglepetésem, mivel emiatt nem ismerik fel az OS-t szabványos minta alapján:

IP ID Sequence Generation: Randomized

Ez a szkennelő szkript kiddieket, akik véletlenül szerencsésen rábukkanak a nyitott ssh portra, ez a "kedvcsináló" üzenet fogadja a sor végén, hogy talán nem itt kellene próbálkozni. A linuxok ugye ún. "all zero"-val jönnek ki.

Biztonsági jelentősége nem sok van ma már, de jól néz ki, és egy normál linuxtól azért nem ez az elvárható, kis "pszichológiai" :-) extra.
Kis elrettentés a kiddieknek. :-D A profik meg nem fognak magamfajta lézengő dinamikus ip-s tartományban egyszerű halandók között keresgélni. Max. zombit, de annak meg nem vagyok jó nekik sem a szkenner eredmények alapján.

A szkennerek os-type mintájába a randomizációs hálózati kernel patchek miatt a rendszer nem illeszkedik.

U.I.:
Hja igen az ip cím kizárólag ipv4. ipv6-t abszolút nem használok. (kerneleket is anélkül fordítom.)

-------

Ennyi.:
Most jöhetnek a trollok , és szétszedhetik ízekre a módszert !

--------

Előállított "Vállalati
Internetszennyező"

Hozzászólások

nem lenne egyszerubb es kevesbe ganyolos, ha mondjuk 2 faktoros auth-ot vezetnel be ssh-hoz?

Lehet. Bár ki tudja, pl. google authenticatorhoz okostelefont nem használok magáncélra, úgyhogy akkor meg kell külön böngésző kiterjesztés, ha jól tudom.

Az meg megint egy plusz potenciális hibaforrás szerintem.

Ráadásul attól még a port nyitva lenne, vagy talán nem ?
Én meg nem szeretem a nyitott portokat. Maradi vagyok. :-)

Ha a kulcsot lenyúlják az ellen véd a 2faktoros cucc, de ha az ssh-ban igen durva hibát találnak, akkor nem biztos.

- Egyébként csak így leírva/olvasva tűnhet bonyolultnak, valójában tényleg néhány darab pár soros bash szkript az egész cucc.

fetchmail, exim, procmail ettől függetlenül is van használatban, szóval akkor már majdhogynem tökmindegy.

+ ha a szolg. ip címet cserél ( /elvileg ;-) / dinamikus ip-em van), valahogy mindenképpen ki kell vernem a gépből, hogy milyen új címet kapott. A szolg. routert adott, úgyhogy sima ifconfig nem elég. Sz'al mindenképpen kell
gyányolni, akkor meg legyen meg az egész egy kosszal.

port-knocking szintén hasonló miatt ugrott, a dynamic ipcímre mindenképpen kellett volna gányolni / akkor legyen meg egy kosszal/, és a szolg. routert is pluszban állítani kellett volna a sequence-ben megadott portokat is forwardolja.

--------

Előállított "Vállalati
Internetszennyező"

pontatlanul fogalmaztam már látom, félreérthető.

Szóval magántelefonom nem okostelefon, hanem normális, másik szálban van részlet, hogy miért ilyen... :-)

A céges telefon az ugyan okostelefon, / amit magáncélra is szabad használni, ktg.keret is van, ez is szabályozott, app-ot is szabad rá telepíteni, sd kártyát is szabad bele /, de azt mégsem fogom erre használni.

Nem térek ki az okára. Egyéb fenntartásaim vannak a "céges okostelefon"-al kapcsolatban, amire részben a 2012/I tv. vonatkozó pontjai miatt nyilvános fórumban nem térek ki. Másik részben meg az, amiért magáncélra sem vettem.

--------

Előállított "Vállalati
Internetszennyező"

Értem. Létezik egyébként hardveres (H/T)OTP képes token, ami kb. csak ezt tudja, van benne egy LCD kijelző, meg bele lehet táplálni a titkot, ami alapján a kód generálódik. Mivel semmilyen hálózati kapcsolata nincs, ezért egyik hárombetűs se tudja se lehallgatni, se távolról leolvasni. Amennyire biztonságos lehet egy ilyen eszköz, az.
--
Blog | @hron84
Üzemeltető macik

"ha a szolg. ip címet cserél ( /elvileg ;-) / dinamikus ip-em van), valahogy mindenképpen ki kell vernem a gépből"

Erre való a mindenféle dyndns és hasonló szolgálatás, nem? Mégis csak kézenfekvőbb ismerned egy fix domaint, ami mindig az aktuális ip-dre mutat, mint folyton kikeresgélni valamilyen logból/emailből, hogy most mi is az új ip

Esetleg egy port knocking megoldás ?

------------------------------------------
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

A néphagyomány úgy tartja elégséges nem standard portra tenni.

--
arch,debian,retropie,osmc,android,windows

tökéletesen biztonságos rendszer nincs
de minden rendszer biztonsága növelhető a teljes használhatatlanságig

--
Live free, or I f'ing kill you.

+1

Nekem az a legnagyobb bajom az egésszel, hogy ha valamelyik használt szolgáltatás beszarik (pl. fetchmail, exim, procmail), akkor nem tudsz belépni, hogy kijavítsd.

Másik bajom, ha jól értem, akkor nem lehet, legalábbis egyszerűen nem, belépni vele mobilról, hogy sürgős esetben gyorsan kijavíts valami egyszerű dolgot.

ha valamelyik használt szolgáltatás beszarik (pl. fetchmail, exim, procmail), akkor nem tudsz belépni, hogy kijavítsd..

Mióta ezt a módszert használom az elmúlt pár évben olyan volt csak, hogy az email szolgáltató szarakodott átmenetileg, és későn jött meg az email, mikor már lejárt az időbélyeg. Igen, ilyenkor kicsuktam magam. :-)

De ilyen erővel a netszolgáltató is beszarhat, és ugyanúgy nem tudom elérni a gépet. Vagy kliensen mobilneten nincs térerő, mert úton vagyok. Vagy országos mobilnet leállás van akármiért.

legalábbis egyszerűen nem, belépni vele mobilról, hogy sürgős esetben gyorsan kijavíts valami egyszerű dolgot.

Egyrészt a mobilnetes kapcsolódás - ha már szóba hoztad - relative a leggyorsabb, mert nem kell a natolt wifi-hálózat külső címét "nyomozni":-).

Most megnéztem egy konkrét példát /legutóbbit/ a naplóban fetchmail xx:52:53-kor szedte le az emailt amit a kliens xx:47:??-kor küldött el (a 2 óra nem jár teljesen pontosan fél perc lehet közöttük kb.).

Az auth.log a sudo szkriptet xx:53:00-ra írja, tehát ekkor állt be az iptables engedélyezési szabály, exim xx:53:07-kor küldte el a visszaigazoló emailt a smarthostra, ami a kliensre xx:53:38-kor jött meg. Én xx:54:18-kor léptem be az ssh-val. Ez nem mobilnet volt, hanem egy ingyenwifis cucc. Tehát mobilnet bont+wifi csatlakozik. Az időveszteség a max. érték körül mozgott. Legrosszabb esetben éri el a 6-7 percet a folyamat.

A gyenge láncszem a fetchmail, mert 300sec defaultból az ütemezése, és úgy is hagytam, mert nekem jó így. De ez konfiguráció kérdése. Le lehet venni 1, vagy akár 2 percre is. És akkor ennyivel gyorsabb a sztori.

/Ha valamiért nagyon kerget a tatár, és 100%, hogy nem kapott az ssh server új dinamikus ip címet, nem kell megvárni a visszaigazoló emailt, lehet próbálkozni, mikor nyílik ki a port. A példában ez xx:53:01-kor állt be./

sürgős esetben gyorsan kijavíts valami egyszerű dolgot.

Nekem ez a pár perc csúszás megér annyit, hogy ne legyen nyitva állandóan a port.

Én ennyit tudok engedni a kényelemből a biztonság javára, de ugye én nem utazom IT iparban, mint ti, ahol minden ezredmásodperc számít. Én nem vagyok ilyen pörgős.

Ha a kényelem, vagy a szupergyorsaság fontosabb, akkor nektek ez a módszer nem jó. Ahogy a bevezetőben is írtam, hogy tudom hogy nem univerzális, nem mindenkinek felel meg. Akinek mégis, annak egészségére. :-)

szerk:

egyszerűen nem, belépni vele mobilról,

Hja hogy ilyen okostelefonos érintőképernyős akármire gondolsz, (most esik le :-D). Oscon-nál ez a mobiltelefon.

A telefon legyen telefon gombokkal, minden másra ott a netbook, és hasonlók rendes billentyűzettel nem holmi taperolásos szarral... :-DD

Hja hát ha tudsz gpg/pgp-vel emailt küldeni róla akkor minden további nélkül megy a fenti időkeretben. Mondjuk az "időbélyeg" elkészítése az picit macerásabb lehet okostelefonról.

A mobilnetes cucc nálam az, hogy (netbook+usb_mobilnet kütyü).

--------

Előállított "Vállalati
Internetszennyező"

Annó, ping payload alapú hasonló megoldást csináltam. A küldő program generált egy user+timestamp+service+salt kombinációból hashelt stringet és amíg ment a ping addig engedélyezte a szerver futását.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Security through obscurity eseten az implementacios reszletek nem ismerete az, ami ved (vagy legtobbszor nem). Szoval ha nem tudja a tamado, hogy a kulcs a labtorlo alatt van.
A GPG kulcsos alairas eseten szerintem nem ez a helyzet, szoval ez annal azert erosebb. Itt a kulcsot is meg kellene szereznie.

--
A strange game. The only winning move is not to play. How about a nice game of chess? - Wargames