Tűzfal port nyitás SMS-sel, e-mail-lel

Linux-security

Kedves Fórumozók! Néha hozzászólok, néha kérdezek. Most ez utóbbi...

Alapfelállás, hogy a CentOS7 szervereink tűzfalában a 22-es port egy fix IP-ről érhető el. Néha az itthoni munkához jó lenne belépni. Alternatív megoldás az irodai gépemre RDP, ott putty, tűzfal ki+be, közben belépés itthonról.

(Korábban próbáltam átrakni 2222-re vagy 32876-ra, de akkor sem kevesebb a próbálkozás. Jelszó elég erős, nem jutottak még be, de rossz volt látni login után a "7653 unsuccessful login attempt..." feliratot. Próbálkoztam a THome IP tartományával a tűzfalban, de elég gyakran változik az eleje is és egyébként jó lenne elérni egy freewifi-ről is)

Az alternatív megoldások helyett jó lenne valami szép. Találtam olyat, hogy OTPW (one time password: http://xmodulo.com/secure-ssh-login-one-time-passwords-linux.html) és two factor by google (http://xmodulo.com/two-factor-authentication-ssh-login-linux.html). Mindkettő jópofa, de akkor is látom/látnám a próbálkozásokat. A google two-way-re még hajlanék is, szép megoldás, de: "When change your phone-device there is no way to actually move all your saved Authenticator accounts to your new device. You have to re-link them one by one." Továbbá jó lenne ha az irodából (munka 99%-a ott van), nem kellene semmi különös.

Ezért a tűzfal nyitogatásra szavaznék, elég 30mp-re kinyitni, amíg elindítom az SSH sessiont.

Kérdésem: találkozott-e valaki kész megoldással SMS vagy e-mail kiküldés formájában, benne egy link, amire kattintva kinyílik? Úgy általában mi a véleményetek erről a megoldásról?

Köszönöm!

  • 6501 megtekintés

-1 fail2ban, egyszer csak úgy döntött hogy nem megbízható az IP ahonnan jövök. Ugyanaz reggel jó volt, délután már nem.

Nálam a preferencia a key based auth, pass+2FA csak ha muszáj. Ha zavar hogy szemetelődik a log (engem pl. pont nem, belépni nem tudnak), akkor a lentebb írt Asterix-es vagy web serveres megoldás, de saját e-mail vezérelt iptables-t se lehet nehéz összerakni (szerintem nem nagyon fogsz kész megoldásokat találni).
____________________
echo crash > /dev/kmem

"-1 fail2ban, egyszer csak úgy döntött hogy nem megbízható az IP ahonnan jövök. Ugyanaz reggel jó volt, délután már nem."
Ezt azért elég nehéz elhinni ;) A logokban azért benne van, hogy miért döntött úgy, biztos nem csak poénból

// Happy debugging, suckers
#define true (rand() > 10)

Akkor csináld meg szegény ember módjára: legyen egy URL, amit ha browserben megnyitsz, akkor ahonnan érkeztél annak a címét engedélyezi a tűzfalon. Ezt még kombináld össze egy .htaccess alapú jelszavas védelemmel a meglátogatandó oldalon, és már kész is vagy :) Persze nem a webserver usere matatja a tűzfalat, a cgi csak leteszi az IP-t egy file-ba, és valami másik script jár arra időnként felolvasni és a tűzfal szabályok közé tenni az IP címet :)

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Nem. A webszerver userénnek nem adunk semmilyen emelt szintű jogot. A cgi lerak egy fájlt a /var/ide/valahova alá, amit illendően egy root crontabjából futó script felolvas, és ha a fájl egy percnél nem régebbi(!), akkor csinál egy iptables save-t valahova, majd betolja a megfelelő címre a NEW-t ACCEPT-tel, törli a cgi által lerakott fájlt, vár 50s-et, és visszatolja az iptables mentést, majd törli a mentett iptables fájlt.
Első blikkre valami ilyen, de azért nézd át, hogy a root-ként futó script valamennyi leakadása/kilövése biztonságosan legyen kezelve.

Nincs mit - egyébként nem extra biztonság, "csak" annyi, hogy a webszervert futtató user könnyen támadható, úgyhogy nagyon nem jó ötlet a szükséges minimumnál bármennyivel több jogot adni neki. Persze, lehet azt mondani, hogy "csak egy nehezen kitalálható nevű script futtatására van joga, ami...", de jobb a békesség :)

( STP | 2016. 12. 22., cs – 10:49 )

Volt már fail2ban és port knocking.
Akkor legyen mondjuk.... GeoIP!

( joco01 v | 2016. 12. 22., cs – 10:56 )

Az authenticator a te biztonságod szolgálja. Én minden kétfaktoros accounthoz papírra nyomtatom a qr kódot biztonsági mentés gyanánt. De még sose volt rá szükség.

--

( wpeople v | 2016. 12. 22., cs – 10:58 )

Asterisk-el pillanatok alatt összehozható,hogy megadott címre VPN-t nyisson belülről.
Akár úgy is, hogy az IP-t DTMF-el adod meg :-)

( daroczig | 2016. 12. 22., cs – 12:54 )

Ha nem a Google-fele 2FA appot hasznalod, hanem valamelyik alternativajat, akkor a migracio uj mobilra eleg egyszeru tud lenni rootolas nelkul is.

Direkt így van kitalálva, az authentikátor lényege, hogy az eszközt birtokolni kell a kódokhoz, probléma esetére pedig a tartalék kód van.

Ettől függetlenül amikor beállítod az authentikátort, akkor simán lefotózhatod vagy képernyőmentheted a QR-kódot, és ezzel utána bármikor beállíthatsz egy új authentikátort. De ez a security model felrúgása, - kb mint a monitorra írt jelszó - szóval nem javaslom.

kisebb probléma lenne a kód biztonságos helyen tárolása, mint az authentikátor pótlása.
jó lenne tudni, mi a protokoll erre az esetre, hogyan lehet fájdalommentesen pótolni az elveszett app-ot....

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

Mi a nehéz az authentikátor pótlásában? A tartalék kódokat tárolod biztonságos helyen, ha gond van azokkal körülbelül 5 perc alatt készíthetsz új authentikátort.

Viszont ellentétben a qr-kód lementés / backupolás / egyéb trükközéssel, egy ilyen eseménynek jól visszakövethető nyoma marad, ami fontos, ha kézben akarod tartani ki léphet be a fiókba.

Amikor beállítod a 2-fa appot, akkor kapsz 10 db egyszer használatos tartalék kódot, és beállíthatsz egy tartalék telefonszámot is.

Ha meghal az app akkor simán beállíthatsz egy új appot:
a) egy olyan számítógépről amin be vagy jelentkezve
b) úgy hogy belépsz a 10 tartalék kódod egyikével
c) úgy hogy egyszer használatos kódot kérsz a tartalék telefonszámodra

A "sima" jelszavadat persze kérni fogja, úgyhogy azt ne felejtsd el, ha nagyon muszáj inkább azt írd fel valahova.

Mindhárom esetről e-mailt, és ha megadtál számot akkor SMS értesítést is fogsz kapni, valamint egy pár napig figyelmeztető csík lesz a Gmail fiókod tetején. Ez azért van, hogy észrevedd, ha esetleg egy támadó babrált volna az appoddal. Az új app beállításával a régi érvénytelen lesz, szóval ha elhagytad a telefonod, vagy tartasz tőle hogy valaki lemásolta, arra is ez a megoldás.

Ha sufnituning módszerekkel backupolsz mint rootolással app lementés, vagy a QR-kód lementése, akkor ettől a biztonsági visszajelzéstől elesel. Nem fogod tudni ha valaki "készített" még egy authentikátor appot a telefonodhoz, illetve ha valaki megtalálja a "régi" appodat azzal is beléphet. (Mivel ugyan az marad a titkos kulcs, ezért ugyan azt a kódot fogja kiírni az app, lényegében megkülönböztethetetlenek.)

Köszönöm a mindenre kiterjedő instrukciókat, a gmail-fiók kevésbé aggaszt, de a dropbox-om is ezzel megy, ott is ilyen "egyszerű" a metódus?
Illetve a 10db egyszer használatos jelszót ha a simple user nem menti el magának, akkor gondolom ezt később, utólag nem feltétlen tudja legeneráltatni?!...

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

Személyesen nem próbáltam, de a dropboxnál is hasonló kell legyen az eljárás:
https://www.dropbox.com/help/363

Az egyszer használatos jelszavakat természetesen bármikor újragenerálhatod, amíg hozzáférsz a fiókodhoz. Értelemszerűen ezt mielőbb érdemes megtenni, és nem akkor hiányolni amikor már kizártad magad.

( norbertkiss | 2016. 12. 22., cs – 13:10 )

Én OpenVPN-t használok erre. Az internet felé nincs nyitva ssh port, csak a VPN felé.
Nálam úgy néz ki, hogy van egy VPS-em, amin fut az OpenVPN szerver, erre csatlakozik minden kliens (tehát a szervereim is). Ha bárhonnan be akarok ssh-zni a szervereimbe, akkor openvpn kapcsolat, aztán ssh.

Pl:
Van egy szeród, rajta apache, n darab weboldal, stb. Van egy kis sérülékenysége, mert a site-okat nem te tartod karban, (elég gyakori) ééés persze megmásszák az indonézek, oroszok, perzsák, stb. (hesteg nórécizm).

Egy szimpla user (esetünkben legyen a www-data) gyönyörűen beszúr neked egy scriptet a szeródra, ami imitálni fogja az ssh daemon-t a 2222-n. Szerintem ötletes módja jelszót lopni, szakértelmet nem igényel, google megad mindent hozzá.

A másik nagy kontra, hogy alapvetően nem csak a támadók keresik a 22-es porton az SSH-t, hanem a tűzfalak és kb. minden más applikáció is. Persze, mindent be lehet állítani, persze a kollégáknak is el tudod mondani (menteni a puttyban :D), de akkor is zaklatni fognak előbb-utóbb, hogy "tesa nem megy az SSH, mi baja van a szervernek?!"

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

Egyrészt a www-data userrel futó cucc nem fogja kilőni a root-ként futó sshd-met, és ha valahogy megteszi akkor már olyan mindegy, root-ra vagyok törve.

Másrészt a tűzfalat és "applikációkat" _én_ állítom be (vagy hozzáértő kollegáim), nem érdekel hogy szerinte hol van a default ssh port.

Aki pedig nem képes egy nem default porton figyelő ssh-ra kapcsolódni annak nem lesz account-ja a gépen, jelenleg én így látom a dolgot. Ha meg zaklatni kezd akkor ütök de hirtelen :)

Igazad van, de ettől a művelet még kivitelezhető. Viszont kétlem, hogy pont itt kéne egy komplett tutorial-t készíteni hozzá. :D
Az applikáció szót még a suliban tanították, szerintem valid. (talán egy kicsit tényleg erőltetett)
Az utolsó mondatot meg szerintem te se gondoltad komolyan. Emberek vagyunk, néha én is a GEGE kulccsal akarom nyitni az Elzett zárat.

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

Kivitelezhető, persze. Kell hozzá egy httpd/php/cms/whatever és egy local root sebezhetőség. De akkor már úgyis mindegy, lényegtelen hogy hol figyel a port a root-ra tört vason.

Az applikáció szóval én leginkább mobilos környezetben szoktam találkozni, azok meg ne SSH-zzanak már nekem. :)

Az meg egy dolog hogy emberek vagyunk, de teljesen komolyan gondolom. Aki nem tudja megugrani azt a szintet, hogy egy paramétert beállítson magának azzal sok dolgom nincs. Cégesben r=1 (vagy inkább r=0) IT tudású emberekkel is sikerül ezt általában megértetni.

( SCOPE | 2016. 12. 24., szo – 12:38 )

Miért nem állítod teljesen kulcsos authentikációra az ssh-t ??

Akkor nem fog "látszódni" egyetlen próbálkozás sem, tökmindegy, hogy honnan próbálkoznak, belépni csak az tud, akinek kulcsa van generálva/beállítva, sőt utána nyugodtan maradhat a 22-es porton az ssh, és nem kell ilyen tűzfal-(rés)nyitó idiótaságokat sem alkalmazni!

( hnsz2002 v | 2016. 12. 24., szo – 20:50 )

Szerintem felesleges felhajtás.
a. tegyél kulcsot az ssh-ra
b. tedd el más portra
--
"Sose a gép a hülye."

( hzsolt94 v | 2016. 12. 27., k – 19:35 )

A google féle kétfaktort alkalmazd nyugotan. A 2. faktorhoz szükséges titkos kódot a home mappádban tárolja egy .google_authenticator fájlban. Ezt a fájlt nyugodtan átmásolhatod az összes szerverre, és akkor mindegyikre ugyan az lesz a 2. faktoros kódod. (Értelem szerűen ennek hátránya, hogy ha bármelyik szerverről ellopják ezt a file-t akkor bármelyik másikra is tudják a 2. faktorod kódját)

A logok kérdése is jobb mint gondolod, állítsd be úgy a PAM-ot, hogy akkor is kérje a 2. faktort, ha a felhasználónév/jelszó helytelen, és csak utána dobja vissza. Így egyrészt nem lehet a jelszavakat kipörgetni, mert egyszerre kell a kétfaktort és a jelszót eltalálni, másrészt pedig a botok 99.9%-a nem próbálkozik tovább mikor megkapja a "One time password:" promptot, így csak egy "Client disconnected (preauth)" lesz a logban. (Ez sajnos nem az alapértelmezett működés, általában csak a helyes jelszó elfogadása után kér 2. faktort a pam_google_auth)

( Z0l v | 2016. 12. 30., p – 21:13 )

http://www.cipherdyne.org/fwknop/

Biztonsagos, egyszeru, van kliens Androidra + nem csak ssh-t tudsz rajta engedelyezni, hanem barmilyen portot megnyithatsz vagy forwardolhatsz. En evek ota hasznalom, nincs is nyitva semmi a tuzfalon csak az az 1 db UDP port.