Trójaim van?

Linux-security

Sziasztok!
A napokban azt vettük észre, hogy az egyik szerverünk külső hálókártyája random időközönként iszonyatos forgalommal árasztja el a hálózatot.
Először azt gondoltuk, hogy a hálókártya ment tönkre. Kicseréltem, de tegnap délután úőjra előjött a jelenség.
Szerencsére iptraffal sikerült kimonitorozni, és ott a következőt láttam: "Outgoing rates: 7500 kbit/sec", és az iptraf annyit írt, hogy az 50.115.40.202-es címre mennek tőlem udp csomagok! Ha jól fejtettem vissza, akkor ez valami kaliforniai ip...

Hangsúlyozom: teljes újratelepítés lesz belőle!

DE: tanulásképpen szeretnék egy kicsit nyomozni, hogy mi generál ekkora forgalmat Kaliforniába, hogyan lehet védekezni ellene, mit kell ilyenkor átnézni, hogyan lehet legközelebb ilyen ellen védekezni, stb. Tehát egy kis security tréning.
Ez utóbbiban kérnék tippeket, tanácsokat, hogy hol kezdjem a nyomozást.

Nem flamet akarok, hanem tanulni, és a végén újrainstallálok úgyis mindent, nehogy valami backdoor maradjon mégis!

  • 20900 megtekintés

Arrol van szo, hogy az itteni drupal elegge korlatozott funkcionalitasu. Viszont arra kepes, hogy ami topichoz hozzaszoltal, azt a http://hup.hu/tracker/_USERID_ cimen kovetni lehessen. A subscribe (fn. feliratkozas), arra szolgal, hogy ha az illetonek nincs konkret mondanivaloja, de szeretne kovetni az elobb emlitett oldalon a topicot, akkor csak ennyit ir be. Te peldaul a sajat tartalmaidat azt a http://hup.hu/tracker/15481 cimen tudod kovetni.

A masik ilyen a +1, ez altalaban az 'en is', 'csatlakozom', 'persze' jelentesarnyalattal bir.

Amiert nem nagyon szereti ezt senki beirogatni: korulbelul ketmillioszor kerult ez kulonbozo topicokban leirasra. Ha vetted volna a faradsagot, es rakerestel volna az oldalon a subscribe szora, elobb utobb raakadtal volna egy reszletes leirasra.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( cheoppy | 2012. 02. 17., p – 09:48 )

Az alapcuccok, mint az rkhunter meg a chkrootkit jeleznek valami lehetséges problémát?

Nem használtam még ezeket a programokat (máris tanultam valamit)!
Az rkhuntert lefuttattam, és egy helyen írt ki Warningot:
"Scanning for hidden files"
De a végén az összegzésnél nem jelzett mást.

Csak akkor fog jelezni, ha épp dolgozik a féreg, vagy most is várhatok eredményt?

( szollosiimre | 2012. 02. 17., p – 10:10 )

Elég részletes infókat nyom a whois

Amúgy megér egy tcpdump-ot a történet ha van szépen helyed. Utána vissza lehet olvasni ki mit akart csinálni. Milyen szolgáltatásaid vannak a szerveren?

( csonkasanyi | 2012. 02. 17., p – 10:44 )

Jah, és mióta a tűzfalon letiltottam a kimenő kapcsolatot a fenti IP-re, azóta nem látom a jelenséget.
Persze lehet, hogy csak idő kérdése, hogy más címre kapcsolódjon a féreg!

( djsilas | 2012. 02. 17., p – 12:19 )

Pontosan milyen rendszerről beszélünk?
Repóból vagy forrásból telepített csomagok?
Mit is csinál ez a szerver?
Web + phpmyadmin van rajta?
ps aux | grep IP
/etc/init.d/apache2 stop majd ps aux | grep www-data

Debian etch

Úgy, hogy az apache nem futott, ezt adta ki a
ps aux | grep www-data:

www-data 9575 0.0 0.2 4916 3048 ? S Feb15 0:00 /usr/local/apache/bin/httpd -DSSL
www-data 17713 0.0 0.2 4916 2172 ? S Feb16 0:00 /usr/local/apache/bin/httpd -DSSL
www-data 17717 0.0 0.0 1868 776 ? Ss Feb16 0:00 /usr/sbin/sshd
www-data 17719 0.0 0.2 4916 2172 ? S Feb16 0:00 /usr/local/apache/bin/httpd -DSSL
www-data 17723 0.0 0.0 1868 772 ? Ss Feb16 0:00 /usr/sbin/sshd
root 15214 0.0 0.0 3104 704 pts/0 S+ 12:18 0:00 grep www-data

Ebből az alsó sor értelem szerűen én vagyok, de a többi?

debian etch mar reges regen unsupported, miert nem volt dist-upgrade???

hopp ezt felzuztak...

ja amugy nincs trojaid, szimplan felzuzta valami joakarod, vagy valami bot a gepedet...aztan most gondolom ami rajta van azt kuldik ki akarhova, a legjobban akkor jarnal el ha nyomnal egy shutdown-t, ha csak nem akarod kozhirre tetetni, hogy mivan a vason...

--
FBK

Köszi!
Ahogy fent írtam: újra lesz installálva a gép, csak előtte tanulni akarok, hogy legközelebb ne járjak így.
Amikor nem vagyok gépközelben, akkor csak a belső hálózaton érhető el a gép, a külsőről lehúzom.
Amikor gép előtt vagyok, akkor pedig meg yaz iptraf, figyelem a forgalmat.

Nem tudom, hogy van-e fent fail2ban (vagy valami hasonló). Ha nincs, akkor tegyél, szerintem nem olyan vészes belőni (nekem is sikerült :) )A logot böngészve meg egész jól látszódik, hogy mikor mivel akarnak próbálkozni.
Meg még annyit, hogy szerintem jobb "eldugni" dolgokat - bár sokak szerint semmit sem ér - azaz a phpmyadmin ne a default könyvtárában legyen, ssh ne 22-s porton stb.(felhasználói hiba ellen nem véd) Aztán amikor a logból kiderül, hogy pld. valaki megtalálta az ssh portot (ez esetemben 4 év után következett be), akkor lehet növelni a ban time-ot. Most nálam pld. ssh bejelentkezés 2 hiba után 1 óra pihenő. (3 hete nem is láttam a támadót, gondolom elment a kedve)

Ne kattints ide!

Apropo fail2ban...
Megtetszett, feltettem, elinditottam, valahonnan probalkoztam jo sokszor sikertelenul belepni, de nem banelt...
A /var/log/fail2ban.log tartalma:

2012-02-17 20:10:08,822 fail2ban.server : INFO Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.4-SVN
2012-02-17 20:10:08,822 fail2ban.jail : INFO Creating new jail 'ssh'
2012-02-17 20:10:08,822 fail2ban.jail : INFO Jail 'ssh' uses poller
2012-02-17 20:10:08,836 fail2ban.filter : INFO Added logfile = /var/log/auth.log
2012-02-17 20:10:08,836 fail2ban.filter : INFO Set maxRetry = 6
2012-02-17 20:10:08,837 fail2ban.filter : INFO Set findtime = 600
2012-02-17 20:10:08,837 fail2ban.actions: INFO Set banTime = 600
2012-02-17 20:10:08,906 fail2ban.jail : INFO Jail 'ssh' started

Ha jol ertem belole, 10 percenkent megnezi az auth.log-ot, s ha tobb mint 6 sikertelen bejelentkezesi kiserlet egy ip-rol, akkor ban. Gyakorlatilag viszont semmi. Tipp?

Ugy lattam, hogy alapbol be van allitva. Ez van benne:

[ssh]

enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 6

Amin probalom: Debian 6.0.4

Probaltam a loglevel-t atallitani [DEBUG]-ra, latom, hogy latja az auth.log valtozasat, de nem csinal semmit...

Minden sikertelen login probalkozasomnal bekerul ez a 3 sor a /var/log/fail2ban-be:

2012-02-17 21:10:30,202 fail2ban.filter : DEBUG Got event: 1 for /var/log/auth.log
2012-02-17 21:10:30,202 fail2ban.filter : DEBUG File changed: /var/log/auth.log
2012-02-17 21:10:30,203 fail2ban.filter.datedetector: DEBUG Sorting the template list

Nálam a jail.local -ban vannak a "szabályok", most hirtelen nem tudom, hogy a jail.conf az lehet-e éles, vagy csak példa, és jail.local-t kell használni.
Bár nekem a fail2ban.log-ban nem ilyen üzeneteim vannak, nem a legújabb a rendszer, így nem tudom, mi változott.

Ne kattints ide!

En a jail.conf-ot hekkelgetem, es mukodik, a jail.local az azert lehet jo, hogy ha pl. a jail.conf-ot globalisan terited (cfengine, puppet, chef), akkor a jail.local-ban tudsz custom szabalyokat csinalni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nézd meg a /tmp és a /var/tmp könyvtárat! Esetleg találsz érdekes futtatható állományokat.
Amúgy saját tapasztalat, hogy alapból érdemes már az fstab-ban sok mindent korlátozni.
Nálam így néz ki a vas alapból:
/dev/md2 on / type ext4 (rw,errors=remount-ro)
/dev/md0 on /boot type ext2 (ro,noexec,nosuid,nodev)
/dev/md1 on /home type ext4 (rw,noexec,nosuid,nodev)
/dev/md3 on /tmp type ext4 (rw,noexec,nosuid,nodev)
/dev/md4 on /usr type ext4 (ro)
/dev/md6 on /var type ext4 (rw,noexec,nosuid,nodev)

Ilyenkor azért nem árt az apt.conf fájlt is szerkeszteni, mert szívás kézzel remountolgatni:

DPkg
{
Pre-Invoke { "mount /boot -o remount,rw" };
Pre-Invoke { "mount /var -o remount,rw" };
Pre-Invoke { "mount /tmp -o remount,rw,exec" };
Pre-Invoke { "mount /usr -o remount,rw" };
Post-Invoke { "mount /boot -o remount,ro,noexec,nosuid,nodev" };
Post-Invoke { "mount /tmp -o remount,noexec,nosuid,nodev" };
Post-Invoke { "mount /var -o remount,nosuid,nodev,noexec" };
Post-Invoke { "mount /usr -o remount,ro" };
};

üdv: pomm

A 852-es kídlap telepötúsa sikeresen befejezádétt

( vector | 2012. 02. 18., szo – 16:53 )

szerintem nyomj már egy teljes ps aux-ot, abban látszik hogy milyen userek mit futtatnak,vagy a root mit indított... ha nincs gcc a gépen, általában a rootkitek miatt kurva magas a load, érdemes erre is figyelni.

-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu

kellene, ha ismeri a rootkit:)) én eddig csak olyanokat láttam amit a rootkit nem :D) egyébként ezt a felnyomták a kernelt nem is értem, azért ez nem így megy, max ha találtak egy hibát a kernelben akkor az kihasználható, de nincs mit felnyomni rajt....

-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu

2.6.18-as kernel valamely kiadása. Olyan local exploit volt rajta, amivel root shellt lehetett kreálni. Az eset a következöképpen történt.

Többször kódolt php kód, amivel összetett utasításokat lehetett kiadni, így a www-data user kapott egy root shellt. Természetesen build-essential fent volt, így bejuttatott egy férget, nyitott egy portot, amin keresztül user és jelszó nélkül ott volt a rootshell. A logokat úgy manipulálta, hogy olyan IP-k szerepeltek benne, amiket a RIPE még nem osztott ki. Arra nem jöttünk rá, hogy bot volt-e vagy sem.

Hasonló volt a fentebb írt "mennek valahova az UDP csomagok" jelenséghez, annyi külömbséggel hogy mindíg más IP-re mentek a csomagok.

én így értettem a felnyomást.

Azt mondod, hogy egy olyan kerneled volt amiven backdoor volt? Ebben az esetben is rossz a megfogalmazasod, bar most mar ertem mire irtad...
-------------------------------------------------------------------------------------------
Mit használok? Na, na, na? Hát blackPanther OS v11.1-et * www.blackpanther.hu

( arpi70 (nem ellenőrzött) | 2012. 02. 21., k – 15:30 )

feliratkozás

----------
Az Örömtündér minden évben ellátogat a Földre és akit megérint a pálcájával az Boldog lesz! De esetleg az is megtörténhet, hogy kiveri belőled még a sz*rt is... (by radcsong)

( csonkasanyi | 2012. 02. 22., sze – 07:55 )

A szerveren fut egy apache, ami kiszolgál 1 statikus weboldalt és egy joomla oldalt.
A joomla miatt van fent a mysql és a phpmyadmin.
Többen írtátok, hogy valószínűleg a PMA-n keresztül jöttek be.

Kérdésem:
A joomlát ettől függetlenül a dokumentációban leírt módon (DocumentRoot lementése, majd mysql adatbázis lementése, ezután az újrainstallált gépen ezek visszaállítása) visszatehetem a gépre?
Ha PMA-n keresztül jöttek be, hagyhattak-e a docroot-ban, vagy a mysql db-ben valamit, ami később bajt okozhat, vagy csak kapunak/belépési pontnak használták a PMA-t, és nem a db-t/joomla_path-t volt érdekes?

Mire kell ilyenkor figyelni, ha van ilyen veszély?

Ha kikerülhetetlen, felteszed, megbuherálod, majd azzal a laza lendülettel le is szeded. Vagy úgy eldugod, hogy legközelebb még te is alig találod meg. Lényeg, hogy ne a default helyen legyen, mert ott keresik elsőként. Gondolom minden ellen ez sem véd, de ne a legelső scriptkiddie próbálkozás legyen már sikeres :) (Az apache error.log-ja elég beszédes tud lenni, hogy miket keresgélnek ügyeskedők )

Ne kattints ide!

Vagy egy egyszerű .htaccess -el is nagyságrendileg biztosabbá tehető a dolog...

A szál-indítónak pedig: ha megfelelően van beállítva a szerver, akkor szerintem egyik docrootból másikba nagyon át se kellene látni, nemhogy még ott valamit el is helyezni. Nem ismerjük a szerveredet, a beállításait, így nem hiszem, hogy bárki egyértelműen tudna a kérdésre válaszolni.

PMA-ról eddig csak jót hallottam: "Fúú, Dejó, kényelmes, biztonságos, hiper-szuper-faszaság"... Ennek ellenére sose használtam éles szerveren. Ezek szerint nem alaptalan paranoia volt.. :)
Én úgy használom, hogy a gépemen van a PMA, a szerveren pedig létrehoztam egy külön "root" felhasználót néhány feltétlenül szükséges joggal és egy szép hosszú jelszóval, a gépem külső IP-jéhez rendelve. Aztán onnan bizergetem PMA-val, ha szükséges. Egy biztonságban jobban jártas megmondhatná, hogy ez mennyire jó ötlet. :)

Joomla!-ról már hallottam nyilatkozni embert: "Ugyanmáá.. Pillanatok alatt úgy betörök, mint a p*csa!" (bocs szó szerinti idézet kellett..) persze látni nem láttam tőle ezt soha...

--
openSUSE 11.4

mysql alapból ethN-en zárva van ma már. Így szállítják a disztrók.
Nem értek a biztonsághoz, mert nem szakmám és nem tartozik az érdeklődési körömbe, de ettől függetlenül picit muszáj vele foglalkoznom. Nekem a józan paraszti eszem azt mondja, hogy inkább .htaccess-szel levédeni a PMA-t.

A Te esetedben 2 gépet kell karbantartani. Szerintem ez esély szinten kockázat növelő.

Nem disztróval szállított mysqlről van szó, hanem mysql.com-ról töltött binárist használok. nem tudom ez számít-e valamit.
Azért gondoltam ki anno ezt a megoldást, mert a gépemen a PMA-t nem érheti el senki (csak lo interfészen érhető el az apache).
Egy nyitott mysql, pedig szükséges, hogy a másik gép (ami a web szerver) hozzáférjen. Természetesen ezt csak adott adatbázishoz létrehozott külön user teheti meg.

--
openSUSE 11.4

- DocumentRoot-ot nagyon nezd at, csak a feltolteseket mentsed, minden mas kuka! Es a feltolteseken is tessek minden fajlt megnezni, hogy az-e ami a tipusa. ami kepnek latszik, de nem kep, fura nevu html, js, azokat kezzel atnezni!
- PMA-t elfelejteni, MySQL Workbench + valami korlatozott ssh user
- mpm_itk -val megismerkedni. Nem egy eletbiztositas, de a default apache telepitesnel barmi jobb.
- open_basedir-rel megismerkedni. Az se egy eletbiztositas, de a jelenlegi helyzetet nagysagrendekkel javitja.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Meg a disable_functions-el. :) Az mpm_itk mi ellen fogja megvédeni? Az különösen remek, hogy ha ua. juzer nevében fut a PHP szál, aki fullosan eléri a docrootot. A jelenlegi kedvencem egy .htaccess-et, amit egy world writeable docrootba tettek fel egy Joomla hibán keresztül... Tudom tudom, legyen a .htaccess kikapcsolva, de sajnos nem mindenhol lehet olyat. A korlátozott SSH usernél egy https-re és nem valami default helyre rakott phpmyadmin egy fokkal jobb szerintem. Az ilyen "azon keresztül jöttek be" c. dolgok általában robotok vak próbálkozásai, ugyanis ha nekiállnak módszeresen a gépnek akkor elsőre magát az alkalmazást (Apache, SSH, bármi) fogják támadni, ami elérhető.

Az open_basedir a shell hívás (különösen a shell_exec) tiltással együtt ér valamit és az sem árt ha a Joomla site-ok fölé a netet fellelhető rewrite szabályokat beilleszti az ember. Ezen egy kis mod_security-val lehet még javítani, de sajnos az alapvető szabályokon kívülieknél többször tapasztaltam, hogy teljesen normális dolgot fognak meg.

Ha kevés felhasználós a szerver, akkor a mail() függvény nyugodtan letiltható és csak SMTP azonosítással fogadjon levelet helyből is. Erre remek a PHPMailer a PHP oldalra.

A webszerveres cumót érdemes Linuxon legalább chrootba és szerencsés esetben grsec+pax-al erősített kerneles gépen futtatni. FreeBSD-n pedig a jail egyszerűen remek erre. Az is sok problémától megkímél, ha hirtelenjében egy elég kopasz helyen találják magukat a próbálkozók.

- Az mpm_itk egy jo jogosultsagrendszerrel szintekkel tudja emelni a prefork biztonsagi szintjet
- A docroot egy dolog, a lenyeg, hogy mashoz ne ferhessen hozza
- a .htaccess-re en jelenleg az AllowOverride bekorlatozasat latom mukodonek (nem csak None es All allapota van neki), bar itt mar figyelni kell a feltoltott .htaccess-re.

A chroot meg a tobbi akkor jo, ha keves (1-5) felhasznalos a szerver. Ha mar ennel tobb van, akkor kuka, mert horror menedzselni, es indokolatlanul zabalja az eroforrasokat.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nekem regebben ugy jottek be joomlan keresztul, hogy az egyik slideshow plugin egyik php-ja a GET-el neki adott fajlt direktben a lemezre irta (a joomla cache dirjebe). Na ennek kuldtek egy eleg fejlett backdoor php-t, amit futtatni is lehetett sajna (egy megfelelo url-el). Feltetelezem tobbet nem nagyon tudtak akkor kezdeni a geppel, ennek ellenere ujrahuztam. Viszont amit a php (www-data) tudott olvasni, azt valszeg lathattak. En is hibas voltam a dologban, ugyanis akkor meg lighttpd-t hasznaltam, amikhez nem hasznalhatoak az apacs .htaccess fajljai, en meg nem babraltam a lighttpd-re valo portolasukkal. Azota apacsot hasznalok.
Erdemes vegig-greppelned a php fajlokat es eval() fuggveny utan keresned, szerintem meg ott is erdekes dolgokat fogsz talalni. (Igy talaltam meg a kerdeses backdoort is.)

( Krampusz | 2012. 02. 24., p – 08:27 )

Olvasgatom ezt a szálat.

Közben ssh-zok szerveremre.
Szokásos szöveg...yes/no..
Mi van? Erről gépről még nem ssh-ztam be, soha?
(Na, jó, volt egy gépcsere 1 hónapja.)

acces denied
wtf?

3x
3x wtf

Felnyomták! Kizártak! De minden szolgáltatása megy, nincs gyanús jel. Ezen kívül.

Másik gépről ssh.
3x wtf.

Szerver kikapcs, lecserél, szétszed, másik hdd, telepítő cd.
Mi volt az IP?
xx.xx.xx.213.
Ja én meg ssh xx.xx.xx.212!

Lámer számláló léptet!

Nem nyomták fel. Pfff! Hhhh!

Olvasgatom tovább ezt a szálat. :)

:)
Egyszer, amikor sok év után internet szolgáltatót váltottam, a reggeli e-mailben kapott logban, az ssh belépés miatt (ott ugye a szolgáltató neve és az ip amiről beléptek) jó néhány másodpercig frászban voltam. :)
üdv: pomm

A 852-es kídlap telepötúsa sikeresen befejezádétt

( csonkasanyi | 2012. 02. 29., sze – 15:31 )

Üdv!
Közben újraraktam a teljes op. rendszert Debian 6.0.4-re.
- ssh eldugva
- joomla + mysql visszaállítva (phpmyadmin-t még átmenetileg sem tettem fel!)
- joomla DocRoot-ot átnéztem, semmi gyanúsat nem találtam benne.
- fail2ban-t is feltettem, az imént sikerült is magam - szándékosan - kizárni ssh-ból 10 percre. Szerencsére a hátam mögött levő teremben van a szerver, így gyorsan láttam is localhoston, mit műveltem... :-)

További tervem, próbálok még jó pár fail2ban filtert kreálni, olyanokat, ami mondjuk 2 napra elhajtja azokat az ip-ket, akik Apache log szerint http://szerver.nev/phpmyadmin-szerű oldalakat próbálnak elérni.

"További tervem, próbálok még jó pár fail2ban filtert kreálni, olyanokat, ami mondjuk 2 napra elhajtja azokat az ip-ket, akik Apache log szerint http://szerver.nev/phpmyadmin-szerű oldalakat próbálnak elérni."

Az apache-noscript filter elvileg erre jó, bár vigyázni kell vele, mert ha hibás pld. maga az oldal :), akkor is generálhat ban-t. Valamint pld. a favicon.ico hiány is bant okozhat bárkinek :) Én az etc/fail2ban/filter.d/apache-noscript.local (a .conf másolata)-ban az ingnoreregex =favicon.ico *$ részt beírtam ennek elkerülésére.
Így a noscript-el megfogok mindenféle próbálkozást (admin,phpmyadmin,pma,stb keresgélések)

Ne kattints ide!

Köszi az apache-noscript filter ötletét, pont ilyen kompakt megoldásra gondoltam, amivel minden keresgélést ki tudok hajítani.
Előfordul a logokban roundcube, phpmyadmin, webmail, stb. próbálkozás. De mivel ilyenek nincsenek a szerveren, ezért csak vaktában próbálkozások lehetnek, azok meg mehetnek a levesbe... :-)

Ui.: a faviconra köszi, hogy felhívtad a figyelmet, bár általában szoktam tenni a DocRoot-okba.

Egy kérdés. Ha amúgy nincs a szerveren olyan, akkor miért bántani azokat a botokat, amik ezeket nézik? Ígyis-úgyis minden nap más IP-ről kapod majd az áldást, felesleges erőforrást pazarolni a tiltásukra... (szerintem... ami nem jelenti azt, hogy valóban így van..)

Engem csak ez szokott zavarni: proxyjudge2.proxyfire.nethttp://proxyjudge2.proxyfire.net/fastenv Ez így jelenik meg a logban. refererként pedig saját maga. (mármint a kliens IP-je)
Egyébként csakis azért zavar, mert sehogy se jövök rá, hogy miért az én szerveremen próbálja keresni ezt a "fastenv"-t amikor a cím nem is a szerverre mutat, illetve mi az értelme ennek... HA már így eszembe jutott épp... Valaki nem tudja miez, és hogy káros-e nekem? Ha igen, akkor hogyan lehet ez ellen védekezni?

--
openSUSE 11.4

Lehet benne valami...

Kérdezzük mag a security-ban jártasabbakat!ú

1. Érdemes olyan szolgáltatást védeni a fail2ban-nal, ami nincs a szerveren?
2. Mekkora erőforrást igényel ez a szűrés, és "mennyit fogyaszt", ha a fail2ban folyamatosan birizgálja az iptables szabályokat (újakat vesz fel, lejártakat tesz ki)?

Tehát véleményeket kérünk!

Szerinted jóindulatú az a bot, amelyik pld. a "phpmyadmin" karaktersorozat szinte összes lehetséges változatát végigpróbálja a szervereden pár másodperc alatt, utána folytatja az "admin" verzióival meg az összes népszerű honlapmotor "elérhetőségeivel" ??! Az, hogy 100 próbálkozás nem jön be, nem jelent semmit, mert a 101. betalálhat. Aztán ha megvan az ismert modul, jöhet a brute-force, ismert hibák kihasználása stb.
Ha valaki tudja, hogy egy oldalon pld. hol a phpmyadmin vagy bármi más, akkor az egyből megtalálja, nem fog próbálkozni. Aki meg próbálkozik, vagy annyira balfék, hogy pld. harmadszorra is elgépeli :), annak semmi keresnivalója ott!

Erőforrások:
Egy plusz IPTABLES szabályról van szó, aminek élettartamát te állítod be. Én sem értek hozzá, de józan paraszti ésszel elviselhetőbbnek tűnik egy plusz IPTABLES szabály, ami él alapból 10 percig, mint az, hogy 10 percen keresztül másodpercenkénti több hibás címet kell "kiszolgálnia" az apache-nak :).

Ne kattints ide!

Javítom magam :) Az persze nem akkora igénybevétel a szerver számára, ha kicsukja az illetőt. Csak a beállításával tökölni, amikor amúgy naponta többször is új IP-t kapnak ezek a botok.
Nem tartottam sosem jóindulatúnak ezeket. Ha nincs a szerveren ilyen támadható felület, akkor feleslegesnek tartom a velük való idő és energia pazarlást. (ezt értettem erőforrás alatt.)

A kérdezőnek joomlája van (ha jól tudom) más nincs, akkor szerintem bőven elegendő a joomla sebezhetőségegeket felderítő kéréseket blokkolni. Ámde ha joomla megtalálható a szerveren, akkor hogyan figyelhető a felé érkező kérés a fentebb javasolt megoldással? Az csak 404-es kéréseket figyel, vagy mindent?

--
openSUSE 11.4

Ha van időd, és lehetőséged, akkor próbáld már ki a fail2ban-t! Alapból semmivel nem kell tökölni, a konfigban engedélyezed a telepített szolgáltatásnak megfelelő rész - esetünkben az apache-noscript szekciót. Nem kell foglalkoznod új IP-kkel, a fail2ban automatikusan bannolja, majd a letelt idő után visszaengedi az adott ip-t. Ha egy trükkös valaki egyszerre 10 címről támadja a gépet, akkor szépen mind a 10 ip megkapja a maga pihenőjét, neked annyi a dolgot, hogy néha ránézel a logra, és ha bizonyos szolgáltatást masszívan támadnak, akkor felemeled a ban idejét, meg csökkented az engedélyezett próbálkozások számát.

A második részhez:
Jobb válaszom nincs hirtelen, mint hogy nem így működik a dolog :) Nézd meg a fail2ban-t, mert rossz a megközelítésed. De ha pld. működne a dolog, hogy csak joomlát védesz (de hogyan??), attól még leterhelhetik a szervert másodpercenkéti több phpmyadmin kereséssel, de erről már írtam fentebb. (Egyébként a tárgyalt apache-noscript szűrő 2 rövid regexp sor - ha létezne előre definiált "joomla sebezhetőség pack", szerintem az nem jönne ki 2 sorból, meg mi van a nem ismert sebezhetőségekkel?)

Ahol esetleg tévedsz: a fail2ban szerver-szolgáltatásokat véd (ssh, ftp, web, dns, mail stb.), nem pedig "weboldalakat" - tudom ez nem a legkorrektebb kijelentés, de most hirtelen nem tudom jobban megfogalmazni.

Azt viszont igaz, hogyha a szerveren nincs dns és mail szerver, akkor felesleges bekapcsolni a hozzájuk kapcsolódó szűrőket. (Bár nem hiszem, hogy egy feleslegesen bekapcsolt szűrő brutális teljesítménycsökkenést okozna, mert a vizsgált log vagy minimális méretű vagy nem is létezik).

Ne kattints ide!

A fail2ban-t "ismerem". Azaz hallottam róla, hogy létezik. Sőőt, fent is van a gépen, félig-meddig bekapcsolva.. de még időm nem volt vele többet foglalkozni. Annyit tudok, hogy az nem az ellen van, hogy nemlétező phpmyadmin-t keresnek a szerveren.

A sokat tökölés alatt egyébkéntis az "apache-noscript" re gondoltam.. mivel azt nem ismerem, így arra gondoltam, hogy az egy fail2ban-hoz hasonló program, amit be kell állítgatni, hogy mit nézzen stb.. (bizony, lusta vagyok guglizni is néha... igyekszem leszokni róla...) :)

De majd jobban utána nézek. Mert megoldást keresek arra amit fentebb írtam, azaz arra a "proxy valami" kérésekre.. azok ellen valami megoldást. Úgy látom, hogy ez arra van, és ha nem kell vele tökölni, akkor megéri nekikezdeni. :)

Szerk:
Elolvastam még párszor a hsz-ed, és azt kell, hogy mondjam, Meggyőztél. Rágugliztam az "apache-noscript"-re. első ránézésre a egész cucc kap tőlem egy nagy csillagos 5-öst :)

--
openSUSE 11.4

( csonkasanyi | 2012. 03. 01., cs – 15:29 )

Biztonság kapcsán jutott még eszembe:
Néhány szerveren használok knock daemont is, amivel bárhol a világban tudok magamnak kaput nyitni, ha a megfelelő ritmusban kopogok!
Aki olvassa a szálat, talán euzt is tudja hasznosítani.

( Morin | 2012. 03. 03., szo – 16:32 )

Nem olvastam végig a thread-et, mert sokan írtak, lehet született megoldás, lehet nem.
A web szerver naplókba a következőre keress: eval=system(
config.inc.php -t fogják elvileg ily módon paraméterezve meghívni.
Aztán lesz wget, meg egyéb letöltések, amivel a shellbot-ot töltik le.
Régi PhpMyAdmin bug, hozzá tartozó CVE: CVE-2009-1151
A nagy mennyiségű UDP forgalom pedig DDoS.
A /tmp törlésével repül a shellbot-uk is (futó process-ek között httpd néven szerepel).
A szóban forgó shellbot tud DDoS-olni, remote access-t garantálni. Ha nézegeted még picit
a web szerver naplót lehet találsz más forrásról más állományletöltést is. Ott kicsit több
cuccot töltenek le, szintén backdoor-okat, syn és udp flood scripteket, elég sok perl és
python dolog. (A naplókban *.png, *.jpg-k szerepelnek a wget mögött, de ezek tar.gz-k.)
A gép egy botnet része lesz, IRC-n van a command channel.

Védekezni a következőképpen:

Tűzfal:
- Befelé csak az engedélyezett szolgáltatások legyenek elérhetőek (iptables, NEW, RELATED, ESTABLISHED states)
- Kifelé kizárólag ezek a szolgáltatások kommunikálhassanak, csak RELATED, ESTABLISHED
kapcsolatokra mehessen válasz. Persze itt gondolni kell még DNS kérésekre, egyebekre,
amik kifele kellenek.
(Így a támadónak nehezebb dolga van, mert a bind shell-t adó backdoor-ok rögtön nem
működhetnek, a reverse connect téma pedig lényegesen nehezebb, de adott esetben ez
utóbbi még működhet.)
Ha a tűzfalat úgy állítod be, hogy naplózzon, pl. az eldobott, kifelé tartó csomagokat
is, kiszűrheted (nem garantált, csak nagyobb az esélyed), hogy van-e még backdoor a
rendszeren.

Alkalmazás:
- PhpMyAdmin ugrade-et követően egész jó vagy. Egyébként ssh kivételével (mert feltételezem
az kell neked, de fentebb említett knockd-s ssh jó ötlet, csak akkor tűzfalra figyelni kell),
minden más alkalmazás, ami bármilyen adminisztratív tevékenységre ad lehetőséget, internet
felől történő elérését tiltani kell.
- Rendszeres update minden alkalmazásra, szolgáltatásra.

Vírusirtó, IPS:
- A fent említett shellbot-ot pl. a vírusirtók ismerik. :)
- A többi cuccot, amit letöltenek, már nem feltétlenül ismerik, de shellbot esetén már
kaptál volna riasztást, időben.

Mindenesetre a rendszer reinstall erősen javasolt. A szóban forgó sérülékenységet kihasználva csak
www-data -ként tevékenykedhettek első körben, de, ha nem lusták próbálkozhattak priviledge escalation-nal,
mondjuk egy local kernel exploit-tal.

Másik kérdésre válasz:
Nem létező szolgáltatásokra lehet filtereket, egyéb védelmet beállítani, a megoldás működésétől
függően plusz erőforrást vehet ez el.

Fene, regényt tudnék már írni lassan, úgyhogy befejezem. Ha esetleg kell még segítség, akkor privátban
elérhető vagyok (feltéve, ha a HUP küld e-mail értesítést - nem tudom hogy működik).

Küld, és levélben tudjátok folytatni a chatet.

Bakker, ezzel mintha én is találkoztam volna... Üfgép volt, leirtottam, meg befrissítettem a PMA-t, de nem gondoltam, hogy a PMA miatt volt. e107-hez nem volt hasonló exploit?
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal