SSH megfelelően biztonságos-e?

Security-all

Üdv,

Eddig a szervereink SSH portjai csak fix IP-kről engedélyeztem.
A dolgok változnak, így nem fix IP-t is be kellene engedélyezni.
Hozzáértők szerint, port kopogtatás+CSAK SSH kulccsal való belépés elfogadható szintű biztonságot ad-e? (GeoIP-vel még esetleg lehet szűkíteni az engedélyezett forrás IP tartományok listáját.)

1) Volt már erről szó itt is, csak nem találtam.
2) Tisztában vagyok vele, hogy a GeoIP-sem 100%-os.

( tomi66 | 2010. 05. 10., h – 12:42 )

SSH és iptables. Tökéletes. 2-3 rossz próbálkozás után az adott IP pihenni tér adott időre. :)

( zeller | 2010. 05. 10., h – 13:45 )

Javasolt az otp (opie) használata, plusz az ssh-forgalom sebességének drasztikus limitálása.

Jónak jó, de amikor win7/cygwin/ssh kombóval sikerül rátámadnom, akkor mindig elhajt "insane window size"-zal. Persze ezt csak a logban hajlandó elárulni, az user/valós szerver gazdája meg nézhetnek egymásra mint a csigák - a (mindkét fél szerint) sikeres auth után.

(Értem én hogy a cygwin által állított 65423x23422 inszánus, de ezt a kagylóvezérlő vagy egye meg, vagy legalábbis legyen hol felülbírálni benne.)

Jól működik, majd holnap összeszedem, mi kell hozzá, pontosabban én miket reszeltem, hogy jól működjön a dolog. Van windows-os, meg mobiltelefonos jelszógeneráló progi, teljesen jól lehet mindkettőt használni. 


# /etc/ssh/sshd_config:
ChallengeResponseAuthentication yes
PasswordAuthentication no
UsePAM yes

# /etc/pam.d/sshd:
auth       required     pam_env.so envfile=/etc/default/locale
auth 	required	pam_opie.so 
account    required     pam_nologin.so
@include common-account
@include common-session
session    required     pam_limits.so
@include common-password

Nagyjából ennyi, ssh-val csak egyszer használatos jelszóval enged be.

( egeresz | 2010. 05. 10., h – 13:56 )

az ssh-val ennyire teoretikusan az a problema, hogy ez egy bonyolult szerver. A bonyolultsaga miatt nem elhanyagolhato annak az eselye, hogy mint tcp szervert megtorik. ssh kucstol, jelszotol, mindentol fuggetlenul.

Én azért ennek ellenére egy nem standard UDP porton leső OpenVPN-ben jobban bízom.
TLS-es autentikáció, plusz CCD konfig a kliensekre, plusz iptables a VPN-en belül is.

Ezek felett pedig minden, ami a szimpla SSH daemon biztonságosabbá tételét célozza (kulcsos login csak fix IP-jű VPN kliensekről, tcpwrappers+iptables konfig).

Nálam így tekernek a szerverek.
Mondjuk az kicsit szopacs lenne, ha az OpenVPN szerver csukná be a szemét, mert akkor goto fizikai terminál. Ez velem eddig egyszer történt meg, még régebben. Sikerült feltolnom az OpenVPN logolási szintjét és a fájlrendszer nem tudott 2GB-nél nagyobb állományokat kezelni. Nem kellett volna elfelejtenem a logrotate alá az OpenVPN logjait is bekonfigurálni. :)
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Japersze ... :)

Én azért úgy gondolom, hogy bár mindenki hisz, amiben akar, de balf@sz konfigurálás miatti törés ellen azért az egymásra ráépített security szintek jobban védenek, mint a pár lehetséges védelem közül hit alapján kiválasztott egyik, amelyiket szarul állítasz be esetleg.

OpenVPN-nél nagyon sok mindent nem tudsz elbazilikázni, mivel ha rosszul van beállítva meg sem moccan.

Igen ... minden rendszer annyira biztonságos, amennyire a leggyengébb láncszeme. De ha ezek a rétegek egymás után "törendők", akkor ha hajszállal is, de több lakat töb esélyt jelent a biztonságra.

Ha valaki valami 0day remote exploittal rommá töri vasad, mert halom szolgáltatás figyel, amikben lehet hiba, akkor hiába izmosítod az SSH daemont.

Meg tudomásom szerint OpenVPN törést eddig még nem produkáltak, bár ez nem jelenti azt, hogy ez lehetetlen.

Ha meg már sikítás nélkül nem bírtad olvasgatni az OpenVPN kódját, esetleg valami konstruktív javaslatod is lenne ... vagy csak mindenki hülye, aki nem gyorsvonat?
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Érdekes szemlélet ...
Ezexerint minden shell script potenciálisan fostalicskahegy ezen értelemben ... :)

Egyéb alternatív megoldás a "mindenki tartsa tőle távol magát"-on kívül?
Láthatólag nagy szakértője vagy a kérdésnek ... tanítsd a tudatlanokat kérlek!
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Most hogy sikerült idekeverni a shell scriptet? Abból is lehet használni például a SIOCAIFADDR függvényt, vagy mi? Ha nem érted amit írtam akkor mondd meg miért, és megpróbálom jobban kifejteni.

De lehet szerinted jó és használható kód a libssd is, amiben így kapcsolják ki/be a screensavert:

StateCheck_Command="killall -WINCH -v xscreensaver 2>&1"
StateCheck_Success="with signal 28"
StateCheck_Failure="no process killed"

[ Like ]

Azért nemigen értettem, hogy miről beszélsz, mert egyrészt szerintem totál mindegy, hogy ifconfig-ot hívogat-e, vagy sem, hiszen az ifconfig alatta ugyanazt az ioctl-t hivogatja.

Másrészt belenéztem az OpenVPN kódjába. Rákerestem az ifconfig-ra, hogy hol használja.
Egy halom helyen hivatkozza a forrásban, meg üzeneteket ír, amiben ez szerepel, de nem találtam olyat, hogy magát az ifconfig binárist hívná.
Mindenütt ioctl hívásokkal hegeszt.

Szóval nem értem amire hivatkoztál ... :(
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Akkor most ne csak belenézz, hanem próbáld meg meg is érteni amit látsz. A tun.c és route.c fileok mindegyike végig ezt csinálja.

argv_printf (&argv,
"%s %s %s netmask %s mtu %d up",
IFCONFIG_PATH,
actual,
ifconfig_local,
ifconfig_remote_netmask,
tun_mtu
);
}
argv_msg (M_INFO, &argv);
openvpn_execve_check (&argv, es, S_FATAL, "Mac OS X ifconfig failed");
tt->did_ifconfig = true;

Elég kevés ioctl van itt ;)

Az, hogy szerinted mindegy hogy ifconfigot execve()-zik egy program, az a szakmai véleményed teljes devalválódásához vezet.

[ Like ]

Remek, hogy mindenki qrva okos ... ;)


------------
misc.c

/*
* Run execve() inside a fork(). Designed to replicate the semantics of system() but
* in a safer way that doesn't require the invocation of a shell or the risks
* assocated with formatting and parsing a command line.
*/
int
openvpn_execve (const struct argv *a, const struct env_set *es, const unsigned int flags)
{
...
------------
tun.c

...
if ((ctl_fd = socket (AF_INET, SOCK_DGRAM, 0)) >= 0)
{
CLEAR (netifr);
strncpynt (netifr.ifr_name, ifr.ifr_name, IFNAMSIZ);
netifr.ifr_qlen = tt->options.txqueuelen;
if (ioctl (ctl_fd, SIOCSIFTXQLEN, (void *) &netifr) >= 0)
msg (D_OSBUF, "TUN/TAP TX queue length set to %d", tt->options.txqueuelen);
else
msg (M_WARN | M_ERRNO, "Note: Cannot set tx queue length on %s", ifr.ifr_name);
close (ctl_fd);
}
else
{
msg (M_WARN | M_ERRNO, "Note: Cannot open control socket on %s", ifr.ifr_name);
}
...

Szóval kismillió helyen használja az ioctl-t egyébként.
Bizonyára annak is jó oka van, hogy execve-t használ a rendszerhíváshoz.

De azért mégsem olyan gagyi, mint amilyennek beállítod.

"Az, hogy szerinted mindegy hogy ifconfigot execve()-zik egy program, az a szakmai véleményed teljes devalválódásához vezet."
Mester, nyilatkoztasd ki a nagy igazságot, hogy szerinted hogy kellene e helyett?
Kérlek alacsonyodj le földi halandókhoz és lécci ne azon aggódj, devalválódik a szakmai véleményem.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Mint látható, csak ott használnak ioctl-t ahol ifconfiggal nem tudják összebaszni, lévén az nem tudja az éppen kellő funkcionalitást. Ez pár hely, nem pedig "kismillió". Durva grep-es összehasonlítással 62 (!) exec, és mindössze 14 ioctl fordul elő a forrásban. Szánalmas, és teljesen szakmaiatlan.

Kevésbé fogyatékos VPN implementációk 0 (nulla) exec-et tartalmaznak, természetszerűleg. Ez ugyanis egy annyira ocsmány hack, hogy az elképesztő.

Elég baj, ha valaki egy ennyire fossá gányolt programba bizalmat helyez, dehát legalább mindig lesz piaca a normálisabb applikációknak ;)

[ Like ]

Mint látható, csak ott használnak ioctl-t ahol ifconfiggal nem tudják összebaszni, lévén az nem tudja az éppen kellő funkcionalitást.
Ha te mondod biztosan így van.

Lehet, hogy más forrást nézünk. Ebben itt 64 execve van, ami csak 56, mert a többi kommentben van, vagy üzenet stringben. Az 56-ból meg van néhány hívás, ami ugyanazt csinálja Linux, Solaris, OpenBSD, NetBSD meg Mac OS X-en.
Ioctl meg 35 helyen van, amiből 8 kommentben. Kvázi 27 ok.

Tehát a 61 kontra 14 helyett 56 kontra 27. Ami kb 50%.

Kevésbé fogyatékos VPN implementációk 0 (nulla) exec-et tartalmaznak, természetszerűleg.
Például melyik és ott mit használnak exec helyett?
Az meg axióma, hogy természetszerűleg, vagy egyéb magyarázat is van?

---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Úgyérted arra külön magyarázat kell, hogy rendszerhívásokat használjon egy program, binárisok helyett? Reménytelen vagy. Mindenesetre jogodban áll kedvelni és használni a gagyit, ha ez megnyugtat. Persze ha remek alkotásnak hívod, akkor le leszel hülyézve.

Példákat nem mondok, mert nem publikus egyik se, az ioctl neveket meg kiguglizhatod magad is.

[ Like ]

Értem már ... lényeg, hogy te tudod a titkot. :)

Példákat nem mondok, mert nem publikus egyik se
:)

szarazópenvépéenmeregymásiksokkalfaszábbcsaknemmondommegmelyikmernempublikusdesokkalállatabba forráskóggya

:)
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

Mielőtt még nagyon megmondanád, hogy mit mondtam, olvashatnál egy kicsit figyelmesebben. Tán értelmeznéd is, amit az egód miatt nem látsz meg.

Sehol sem mondtam, hogy te miben vettél részt, vagy miben nem. Ezt most te mondod, hogy én kétségbevonom, hogy te VPN fejlesztésben vettél részt. (tudsz olvasni?)

Ha te mondod, biztosan hupszakértő vagyok. Látom más topikban is ömlik a fikatúra tőled, mindenki hupmém, hupszakértő stb., te meg megmondod a tutit.

Egyébként még mindig nem fedted fel ama titkos rejtélyt, hogy az ifconfig miért sz@r. Meghogy miért gányolás ha valaki system hívással rendszer utilityket hívogat.
Mondtál egy axiómát, hogy minden normális VPN-ben 0 exec van.

Ez olyan kb., mintha azt mondom, hogy minden festményben 0 piros szín van, mer a többi nem festmény.

Engedd meg, hogy gratuláljak.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

"Egyébként még mindig nem fedted fel ama titkos rejtélyt, hogy az ifconfig miért sz@r."

Úristen, ezt magyarázni kell?!?

Nem az ifconfiggal van a baj, hanem, hogy azt hívja. Mert kurvára nem az a dolga egy szoftvernek, hogy másik szoftvereket indítgasson jobbra-balra, ha van arra API.

Másrészt, mi van akkor, ha nincs ifconfig vagy egyedi a paraméterezése? Mi van akkor, ha éppenséggel valami fertőzött szemét? Soroljam még?

----------------
Lvl86 Troll

Ha meg már sikítás nélkül nem bírtad olvasgatni az OpenVPN kódját, esetleg valami konstruktív javaslatod is lenne ... vagy csak mindenki hülye, aki nem gyorsvonat?

Eloszedi a google-t es megirja normalis ioctl/socket fuggvenyekkel es nem csak odafos valami joval veszelyesebb es masszivan ocsmany dolgot. Nagyjabol negyed ora melo platformonkent megtalalni a szukseges modszereket. Ja kerem, hogy erre is lustak voltak inkabb oda nott egy 200kB-os katyvasz?

---
pontscho / fresh!mindworkz

( bambano | 2010. 05. 10., h – 14:13 )

esetleg el lehet pakolni az ssh szervert másik portra, meg megfontolhatod a fail2ban használatát.

Port kopogtatásnál alapban az SSH port(ja) zárva van a tűzfalon.
Tehát akkor pontosítva:
Port kopogtatásnak valamilyen gyenge pontjával találkozott e már valaki?
Default 22-t nem szívesen raknám odébb.
Blacklist (fail2ban) OK, bár ha valaki benéz(het)ett, akkor már gáz van.
GeoIP/egyéb lista alapján IP subnetek engedélyezése/kizárása forrásként. (kopogtatásra is!)

( samuf v | 2010. 05. 10., h – 14:32 )

Esetleg csak egy szerveren engedélyezni a login-t nem fix IP-ről és arról át ssh-zni a többire.

( log69 | 2010. 05. 10., h – 16:31 )

csak egy kérdés: általában nem az SSH-s kliens oldal a gyenge láncszem a biztonságban? mert gondolom te bebetonozhatod akár mennyire a házat, de egy ajtót fenn kell tartanod a kliensnek, hogy bemehessen. És ha a kliens gép kompromittálódik és pl. lelopják az SSH kulcsát? vagy keylogger stb. ugye..?

Tehát ha a biztonság szintjét nem emeled a kliens oldallal együtt, akkor az a kérdésem, hogy van-e értelme túlságosan ennyire fokozni a kliens nélkül? (csak találgatok)

Mondjuk a keylogger problematika esetén ez nem sokat ér sajnos.
Egyébként meg, ha a biztonságosnak hitt kliens kompromittálódik, akkor nem sokat tudsz tenni. Ha pl kimondottan azért telepítettek keyloggert a masinára, hogy a szerveredhez való hozzáférés elérhető legyen.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

( Fisher v | 2010. 05. 10., h – 17:25 )

Ezért most kövezést fogok kapni, de akkor is ez a véleményem:

Ha nem bízol meg az ssh-ban, akkor bármilyen, ssh alapú megoldást el kell vetned. Az összes hókuszpókusz (port knocking, random porton futtatni az sshd-t, otp) csak arra jó, hogy nehezebbé tedd a saját és mások életét. Attól nem lesz biztonságos, hogy a 22-es helyett a 34583-as porton fut (hacsak nem olyan bug van benne, ami a 22-es porthoz, vagy a 1024 alatti porthoz kötődik). Attól se lesz biztonságos, ha vpn-en keresztül éred el, csak elfeded a hibát, ami ugyanúgy megvan (zárva az ajtó, de olyan gyenge a beépítés, hogy a huzat épp nem veti ki).

Ha megbízol az ssh-ban, akkor meg nyugodtan lehet futtatni szabványos porton, nagyjából úgy, ahogy a apt|yum|bármi felteszi(*).

Ha a szervered nagyon-nagyon titkos adatokat tartalmaz, akkor igen, nincs remote root, admin hozzáférés, csak az alkalmazás érhető el, a saját portján, protokollján. Manapság már minden(?) hosting cég ad ip konzolt, szerintem egy rendes helyen oda lehet íratni, hogy ip konzolt csak akkor adjanak valakinek, ha előtte a következő két telefonszám legalább egyikével egyeztettek.

Persze az is kérdés, hogy mennyire lehet megbízni az ip konzolban :)

Mennyire lehet megbízni a saját desktopodban, laptopodban? Pl. ellopják, és kikanalazzák belőle a zokszigént, jelszavakat, miegymást.

Mennyire lehet megbízni benned? A derék ukrán szakemberek elkapják a barátnődet, szüleidet, a macskádat, kinek mit, és közlik, hogy nem puha párnákkal fogják szurkálni őket. Persze, vannak olyan rendszerek, amikhez csak két ember együtt férhet hozzá. Na bumm, annyival több macskát kell elkapni.

Tökéletes biztonság sosincs, hacsak nincs a gép betonba öntve és a Marianna-árok aljára temetve az urános hordók diszkrét fénye mellett. Viszont úgy nagy a pingje :D

(*) ez persze így erős, más okokból (lehet ddosolni az sshd-t?) nekem se a 22-es porton fut és/vagy csak bizonyos címekről engedem be. Meg egyáltalán, untam a logban a sok próbálkozást.

Igy van. Kb. az osszes, a topikban felsorolt nepi praktika csak arra jo, hogy szopasd magad, es/vagy noveld a tamadasi feluletet.
Ha jot akarsz, beallitasz egy key-only authot, letiltod azokat a feature-oket, amiket nem hasznalsz (tunneling, scp, ...), es gyakran nezel logot. Ennyi.

"Ha a szervered nagyon-nagyon titkos adatokat tartalmaz (...) Manapság már minden(?) hosting cég ad ip konzolt"

Ha a szervered nagyon-nagyon titkos adatokat tartalmaz, akkor mit keres a hostingban? :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( bitvadasz | 2010. 05. 10., h – 19:56 )

én ezt követtem el: http://hup.hu/node/71007
és a mh-i port(ás) gépen futtatom.
Nyilván, nem 22-es ssh porton keresztül lépek be.

a benne szereplő "ghost" átírva: http://hup.hu/node/78582
(egyszer majd kap 'egyéni' nevet is)

ns_1-et azóta átírtam 8.8.8.8-ra.

Tök jó, sshfs-t tudok otthonra becsatolni:
otthon - mh.tüzfal - portás - belső.router - szerver/symlink.aktuális

parancsok: server.mount, server.umount meindkettőhöz tartozik még egy script a mh-i portás gépen, (pubkey, jelszó nélkül) - 2 mp-en belül a csatolási idő.

(meg vagyok magammal elégedve :)

( hanzo v | 2010. 05. 10., h – 20:19 )

Szia!

Szerintem a tobbseg dont. Eleg sokan hasznaljak az openssh server. Alap telepitest nem erdemes hasznalni. Erdemes root logint tiltani, kulcsos hozzaferes, ha van belo halos laba a gepnek akkor csak arra engedni az ssh-t. Vagy csak az intezmeny vagy kiszemelet iprol engedni a loginolast. Ezen felul fail2ban is egy hasznos program, csak vigyazz el ne rontsd a logint :) Sot, ha telleg nagyon paras vagy akkor a kulcsot vedd jelszoval, tegyel fel fail2ban-t tedd el a portot de 1024 ala, tiltsd a root logint, es csinalj tuzfalat. :)

--
http://szolarenergia.hu

( gdes | 2010. 05. 10., h – 21:23 )

használat vs paranoia kérdése, amit meg lehet tenni kopogtatás nélkül:
- nem a 22-es port
- noroot, strict, protocol 2 stb.
- csak PK login
- PAM + user file access (vagy allowuser)
- hosts.allow: sshd adott tartományokból (pl .hu, .de)
scp helyett fuse + sshfs (szkriptelhető)

Az AllowUser és a csak kulcsolás engedélyezése, plusz a !22-es port bőven növeli annyira a biztonságot, hogy a sima robotos próbálkozásokat elkerüld. Ha valaki konkrétan rááll egy gépre, akkor előbb-utóbb talál hibát, amin be tud menni.

Az scp is scriptelhetőnek tűnt nekem, bár előfordult, hogy ssh-val kellett rm parancsot futtatni. :)

Én egy szerencsés ember lehetek. 2001 óta van bent egy gépem és a 22-es porton figyel az ssh....valóban próbálkoznak a robotok...alkalmanként háromszor...még nem találták meg azt a lukat, ahol be lehet menni. Nem kell túlspirázni mindent szerintem, amiket itt leírtak egyesek, az nem más, mint szivatás...elég perverz dolog, ha az ember saját magát szivatja...és ökörség, ha az ügyfeleit. Még annyit, hogy megnéztem 32 chroot környezetem is van és oda a tulajdonosa ssh-val megy be. Igen, a 22-es porton.

+akármennyi, ez olyan alapvetés, ami minden környezetben megállja a helyét. Ha valakiben felmerül, hogy ő az éles szerverén majd jól programozik, na azzal nem szabad még sírt sem ásatni. Annak nem elment a józan esze, hanem soha nem is volt.

A kulcsos móka lehet jó, meg okozhat problémát is. Ha garantálható, hogy mindig nálad van a kulcsodat tároló eszközöd, ÉS ahonnan be akarsz lépni, az megbízható hely, akkor egy sima passphrase-zel védett kulcsot alkalmazó csak kulcsos megoldás jó lehet. Ha bármelyik feltétel nemteljesülésére is van esélyed, akkor a kulcsos login mellé fallback jelleggel az opie használata jelenthet segítséget: van hozzá jelszógeneráló program mobiltelefonra is (vejotp). Ez utóbbi használatával nem megbízható környezetből is nyugodtan be tudsz jelentkezni, alapvető feladatok elvégzése céljából.

ha már annyira a biztonság a lényeg ebben a topic-ban, akkor had jegyezzem meg, hogy nem megbízható környezetből semmi esetre nem lépek be. erre még az 1x használatos jelszó sem ok szerintem. (a nem megbízhatón most ne lovagoljunk, de értsd kb.: nem használok idegen gépet belépésre).

( PunishR v | 2010. 05. 11., k – 14:25 )

hasznalj v6ot es tovabbra is szurj ipre, a sixxs AICCU-t felranthatod akarhol akarmire

( chx | 2010. 05. 11., k – 15:29 )

Denyhosts? Az azért nem teszi macerássá a használatot. Emellett természetesen csak megbízható gépekről belépni, az IP tartományt korlátozni, kritikus esetben csak fix IP-kről engedni a belépést. Ennek azért elégnek kell lennie.

_______________________
echo crash > /dev/kmem