szerverbiztonság

nemrég olvastam a fórumban hogy valakit sajnos sikeresen feltört valami szemétláda, viszont nem szeretnék hasonlóképpen járni a frissen beizzitott kis masinámmal, pláne hogy be vagyok szarva a torrentfluxtól. kicsit félek ettől, hogy lehet feltölteni fájlokat (jóesetben torrenteket), igy elmélkedtem a kérdésen, és végül a következő biztonsági lépéseken gondolkodom:

- ssh csak publickey + egy bash script ami adott időnként (gondolom crontábla lesz belőle) egy algoritmus alapján új portot generál sshnak és a tűzfalon is kinyitja, a régit meg ugye zárja. emiatt még a publickey birtokában sem lesz sima a belépés az algoritmus ismerete nélkül. azt hiszem, ez az ssh felőli részt kellően levédi.
- apache: ide nem nagyon volt ötletem, ezért max a torrentfluxnál beállítok egy .htaccess-t. olvasgattam ezt a htpasswd dolgot is, végülis lehet hogy ez lesz majd belőle, de semmiképpen nem szeretném ha a flux bejelentkezőjét esetleg egy brute-force script megdolgozná. (még az is felmerült, hogy az ssh megoldást és a .htaccess-t egybeolvasztva, ha torrentezni szeretne a felhasználó, először be kell lépnie ssh-n, és egy scriptet lefuttatva a .htaccessbe bekerülne az ipje, de ez már paranoid nem? :))
- illetve még az is felmerült, hogy ha valaki túl sokszor próbálkozik rossz loginnal, akkor valahogy bannolná a gép az IP-jét, de erre nincs koncepcióm hogyan is kellene ügyesen kivitelezni.

gondolom túlbiztosítottnak tűnhet, de el bírom képzelni ahogy a sok kis f*aszverő wannabe-hacker nézegeti torrentezésnél a peerek ip-it, hátha talál valahol egy rendszert ahol királykodhat kicsit...
nem akarok én különösebben senkinek sikerélményt adni :)

( peterson v | 2009. 10. 14., sze – 18:01 )

Én ezt először is úgy kezelem, hogy nem torrentezem. Van ~20 olyan barátom aki igen, és tőlük bármit megszerzek :)

Az ssh-nak nem feltétlenül kell alternatív portokon vándorolni. Elég ha iptablessel szigorítod, hogy percenként 1 ssh kapcsolat engedélyezett, a többi DROP. ezzel a brute-force kiiktatva.

"ha torrentezni szeretne a felhasználó, először be kell lépnie ssh-n, és egy scriptet lefuttatva a .htaccessbe bekerülne az ipje, de ez már paranoid nem?"
Nem! Ez öngyilkosság :D Nem mondom el miért, mert vagy te is belátod, vagy kár elmondanom...

"gondolom túlbiztosítottnak tűnhet"
Inkább sok hűhó semmiért...

Mi lenne, ha egy gépet külön tartanál (valami P2-es ócskavasat) ami csak torrentezik. Néha kimented belőle a letöltött cuccaidat. Csinálsz egy diskimage-et, és felnyomják, hát kit érdekel?! Vissza dd-zed a rendszert és minden megy tovább.
Ha torrenteznék, én ezt tenném.

---
"A megoldásra kell koncentrálni nem a problémára."

jah hajlamos vagyok túlagyalni a dolgokat, mert igazából jól szórakozom amikor ilyesmikkel vacakolok.
az ssh-portvándorlás is leginkább azért került bele, mert tetszett megirni egy ilyen scriptet :)

viszont elmondhatnád, miért öngyilkosság, mert nekem az is csak egy scriptnek tűnik :)
persze ez nem változtat azon, hogy semmi szükség rá, de agytornának jó.

nincs p2-es ócskavasam, és igazából ennek az egész biztosításnak is inkább elvi okai vannak, mint az adatféltés
az én káromra ne örüljön semmiféle kis hülyegyerek :)

----------------
mepis8-x86_64

és felnyomják, hát kit érdekel?! Vissza dd-zed a rendszert és minden megy tovább.

Nem jo hozzaallas. Eloszor is ez feltetelezi azt, hogy egyaltalan eszreveszed, hogy felnyomjak. Masreszt, ha felnyomjak, akkor egy ujabb gep csatlakozott a zombikhoz. Vegul ha image-bol visszatolod, nem csinalsz mast, mint helyreallitod az eredeti sebezheto konfigot. Amit ujra felnyomnak.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

( maniac | 2009. 10. 14., sze – 18:31 )

Nem ertem mi a halalert parazik mindenki az ssh-tol. Talan az egyik legbiztonsagosabb program szvsz. Normalis jelszoval ellatott userek (pl. nem sales/sales), esetleg pubkey ha nagyon parazol (bar ha lesz megint valami hasonlo elmes openssl bug akko baszhatod), ha nagyon parazol fail2ban aztan 3 probalkozas utan elkuldod pihenni az ip cimet. Ez, hogy random port, meg anyamkinja mi a feneert? Csak magaddal b.szol ki, hogyha valahonnan csak a standard portot engedik ki. Bar persze tok jo, mert nagyon szekurnak tunik, vegulis biztos nem talaljak meg random portokon egy portscannel (ha mar celzottan a te kis gepecskedet szemeltek ki, es nem valami bot probalkozik a 22-es porton).

apache: jol beallitott apache, nem kell mindenfele 3rd party modul ami esetleg meg tenne par lyukat kedvenc webszerverunkbe. Alapvetoen nem ismerem torrentflux nevezetu csodat, de ha ugy erzed, hogy nagyon bugos cucc, akkor vagy http authot allitasz be, aztan haveroknak adsz hozza jelszot, vagy ip tartomanyok szerint szursz a elerhetosegere. No meg nem tudom, hogy ez cgi-s vagy php-s vagy egyeb dolog, de ha php-s akkor minnel kevesebb fv-t hivhasson meg, nem tudom tenyleg mi kell neki, szoval probalkozz, mi az ami feltetlenul kell neki. No meg lehet hasznalni mindenfele suhosin es egyeb marhulast - ha elviseli.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

nem tudom honnan szűrted le, hogy itt bárki is az sshtól parázik.
főállásban nem szerverek feltörésével foglalkozom, igy nem nagyon van elképzelésem arról, milyen módszerekkel lehet megtörni egy szervert,
az ssh-port cserét olvastam egy fórumon, ezért gondoltam a megvalósítására, de elhiszem neked hogy bőven elég a pubkey :)

amúgy torrentflux php alapú

----------------
mepis8-x86_64

En szerintem egy sima eros jelszo is eleg :).

php-ra ajanlom akkor a hardening php-ra keresest, aztan tesztelgetest, hogy mit mennyire szeret (vagy esetleg doksijaban talan van valami leiras, hogy mik kellenek a mukodeshez).

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

( eax | 2009. 10. 14., sze – 18:45 )

"ssh csak publickey + egy bash script ami adott időnként (gondolom crontábla lesz belőle) egy algoritmus alapján új portot generál sshnak és a tűzfalon is kinyitja, a régit meg ugye zárja. emiatt még a publickey birtokában sem lesz sima a belépés az algoritmus ismerete nélkül. azt hiszem, ez az ssh felőli részt kellően levédi"

Onszopatas. Ha az ssh kulcsaidat (ami nem a public, hanem a private key, ugyebar) le tudjak lopni, akkor ugyanezzel a lendulettel le tudjak a minden bizonnyal hihetetlenul kifinomult, hatalmas kupac formalis matematikaval ellenorzott prng-d algoritmusat is, ha mar a portscan-ig nem jutnak el.

"olvasgattam ezt a htpasswd dolgot is, végülis lehet hogy ez lesz majd belőle, de semmiképpen nem szeretném ha a flux bejelentkezőjét esetleg egy brute-force script megdolgozná. (még az is felmerült, hogy az ssh megoldást és a .htaccess-t egybeolvasztva, ha torrentezni szeretne a felhasználó, először be kell lépnie ssh-n, és egy scriptet lefuttatva a .htaccessbe bekerülne az ipje"

Onszopatas. Ha korlatozni akarod, akkor htaccessben basic auth, vagy client-side ssl certificate, vagy ha mindenki ssh-zhat, akkor korlatozd 127.0.0.1-re, es tunnelezz sshn.

Egyebkent az ilyen "ubercseles-uberbiztonsagos" hazibarkacs bizbaszok szinte kivetel nelkul nemhogy novelik a biztonsagot, de hatalmas lyukat utnek a rendszeren. :)

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

( LGee | 2009. 10. 14., sze – 18:51 )

> - ssh csak publickey

...es untrusted helyeken azt ne is taroljuk, de mindenkeppen legyenek jelszoval vedve...!

Szep megoldas meg a dedikalt ssh user hasznalata (neadjisten kapasbol restricted shell-lel), ahonnan kulon su-val kell kijonni.

Kulon syslog szerver +mail kuldes segitsegevel a loginokat is konnyu nyomon kovetni, persze ez a gyakorisagtol es a dolog jelentosegetol fugg. Egy login folyamatot ugyanis nem lehet nyomtalanul lebonyolitani.

sshd_config-ban 'UseDNS no' hasznalata megkimeli a szervert egy csomo 'felesleges' reverse DNS ellenorzestol, foleg ha amugy nincs per-host ellenorzes konfiguralva.

Mivel az ember altalaban tudja, honnan jon be, lehetseges megoldas meg az osszes nagyobb magyar szolgaltato IP tartomanyanak felvetele hosts.allow-ba.

Publikus helyeken maszkolni kell az IP cimet (pl irc cloak), ezzel is csokkentve a tamadasoknak valo kiszolgaltatottsag esetet.

En default 22-es porton vagyok, es semmit sem teszek a kiddie-k ellen.

udv,
LGee

( tmms v | 2009. 10. 14., sze – 19:50 )

Engem kimondottan érdekelne, hogy lehet beállítani azt, hogy 1 perc alatt csak 1-szer lehet belépni ssh-ra.

VAGY!

Hogy lehet beállítani azt hogy csak bizonyos IP-ről lehessen elérni ssh-t? (Persze iptables beállításra gondolok)
--
Home: Ubuntu 8.04 LTS
Server: Debian Lenny

( zeller | 2009. 10. 14., sze – 21:56 )

Az ssh portvándoroltatásba belegondoltál, hogy mi van akkor, ha épp bemész,mert nagyon sürgősen be kell menni, aztán nincs időd lecsapni a vándoroltató scriptet, ami kihajít?

A kulcsos auth egy jó lépés, ha nem akarsz akárhonnan belépni. Ha igen, akkor az egyszer használatos jelszó lesz a te barátod: az opie pont erre való, a vejotp-vel akár mobiltelefonon is tudsz választ generálni. Az, hogy nem a 22-es porton hallgat az ssh, az egy apró, de hasznos lépés, bár ha valaki tényleg meg akarja találni, hogy hova tetted, akkor lassan, de meg lehet (gyakorlatilag észrevétlenül) találni.

"Az, hogy nem a 22-es porton hallgat az ssh, az egy apró, de hasznos lépés, bár ha valaki tényleg meg akarja találni, hogy hova tetted, akkor lassan, de meg lehet (gyakorlatilag észrevétlenül) találni."

Vagy egyszeruen csak lesz.rja, hogy eszrevetlen-e, ugyis egyfolytaban portscannelnek mindent, ami a neten log - el fog veszni a zajban.

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