ugrás a tartalomhoz

Bruteforce és próbálgatások ellen

vbence · 2006. Jún. 26. (H), 14.38
Üdv!

Használ valaki valami okos programot a rosszindulatú ip-k tiltására? Én igazán meglepődtem, az első az openssh logokon, amikor hagyta, hogy ugyanaz az ip végigpróbáljon kb 200 felhasználónevet. Gondolom, az openssh készítői is úgy gondolják, hogy ezt a problémát nem az ő programjukban kellene megoldani, hanem valami központ cuccal a szerveren, ami több szolgáltatást (pl. ftp login, smtp) figyel.

A bruteroceblockert próbáltam - valami hiba lehet vele, mert csak a központi szerverről letöltött ip-ket figyeli, újakat nem ad hozzá a listához - meg még egy másikat, asszem sshit volt a neve. Egyik sem működött igazán.

Nemrég ehhez hasonló probálkozások jelentek meg a httpd-error.log-ban (tudom, "get a life, man"), szóval ez gyakorlatilag ugyanaz a probléma, a "próbálgatás".
/home/mysites/default/www/phpmyadmin/main.php
/home/mysites/default/www/PMA/main.php
/home/mysites/default/www/mysql/main.php

Tudom, hogy túl szép lenne, hog igaz legyen, de ha mégis tudtok ajánlani valami próbálkozás elleni progit?

B
‹ Index.html fájl átírásának kizárárása a rewrite-ból Erőforrásrabló userek ›
 ■
1

iptables

Anonymous · 2006. Jún. 26. (H), 15.02
SSH-ra nálam első lépcsőben frankón bevált, hogy az iptables-ben eldobtam az összes bejövő ssh-portra érkező adatcsomagot, kivéve a saját dedikált ip-imet.
Természetesen ha dinamikus az ip-d, akkor ip-tartományt kell megadnod és a veled egy tartományban levő gépekről még jöhet kísérlet a támadásra, szóval ebben az esetben nem tökéletes, de egy durva szűrőnek mindenképpen jó:
-A INPUT -s sajat_ip(_tartomany)/netmask -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j DROP

A sorrend fontos, mert az iptables az első illeszkedésnél alkalmazza a szabályt és nem megy tovább a szabály-láncon! Vagyis előbb engedélyezd a saját ip-det, és utána tiltsd az összes többit.

.bonga
2

sajnos nem ilyen egyszerű

vbence · 2006. Jún. 26. (H), 16.56
Köszi, de sajnos nem tehetem meg, hogy ennyire szigrítom a "házirendet". Máshonnan is csatlakoznak, meg ssh tunnelt használnak pl. mysqlhez.

Valami szkript kéne, ami figyeli a logfájlokat. Phpben viszont többet veszít mint nyer rajta az ember, ha minden egyes security logbejegyzésre elkezd regex-eket próbálni a bejegyzésen. Bár a bruteforceblocker is egy PERL szkript, én nem bízom ennyire a php-ben..
3

Megoldás

tiny · 2006. Jún. 26. (H), 20.54
Én azt szoktam csinálni, hogy egy felhasználónévnél ha 3 rossz jelszót írsz be, akkor nem lehet arról az ip-ről belépni fél óráig. Ez már 5 karakteres jelszónál is megfelelő védelmet nyújt, kivéve ha valaki nagyon mákos :)
4

de hogyan?

vbence · 2006. Jún. 26. (H), 23.37
Köszi a tippet.. az elv nekem is megvan :) Gondolom ez akkor az SSHban valahol..
5

PHP fejlesztés felsőfokon

paragliders · 2006. Jún. 27. (K), 08.17
A PHP fejlesztés felsőfokon foglalkozik a témával. Itt is írja, hogy a kitiltott ip -et letárolod adatbázisba bizonyos mennyiségű próbálkozás után, majd időközönként egy scripttel felszabadítod. Igazából ott érdemes elolvasni mert kódokkal is szemlélteti az egészet.
6

Az elvel nincs probléma...

vbence · 2006. Jún. 27. (K), 14.19
.. de nincs kedvem írni egy saját progit. Biztos valaki más is rájött a problémára, és meg is oldaotta (gondoltam).
A PHP nem megfelelő erre a célra. Perlhez meg nem értek. Tehát teljesen fölösleges lenne most nekiálljak és összeberheljek egyet magamnak.

De köszi a tippeket.. nem adtam fel, hogy találjak egy értelmes programot a feladatra.. :)
7

Nem megfelelő?

tiny · 2006. Jún. 27. (K), 14.30
Nem értem, hogy miért nem megfelelő a php. Íme egy csöpp script, ami még adatbázis használatát sem feltételezi:

<?php
/* itt a $jelszo változót valahonnan ki kell még olvasni */
$open=fopen($_POST['user'].".php",'r');
$i=fgets($open);
fclose($open);

If((md5($_POST['jelszo']) !== $jelszo)||($i>=3))
{
 $open=fopen($_POST['user'].".php",'w');
 fwrite($i+1,$open);
 fclose($open);
 echo "<form> ... </form>";
}
else
{
 $open=fopen($_POST['user'].".php",'w');
 fwrite('0',$open);
 fclose($open);
 //belépés
}
?>
Ezt persze még át kell alakítani a környezetnek megfelelően, de úgy gondolom, hogy így simán meg lehet oldani még adatbázis nélkül is.
És ilyen kis programocskánál igenis van értelme annak, ha te csinálod, max. lusta vagy.
8

Minden eseményre külön

-zsolti- · 2006. Jún. 27. (K), 15.03
Nálam is valami hasonló van. Azzal a különbséggel, hogy mindent eseménynek van egy külön konstans kódja (pl. belépés: 1, regisztráció 2), amit megkap az Auth osztályom setFalseAttempt metódusa, ha hibás próbálkozás történt. A konstans kódot, a timestamp-et és a látogató egyedi hash-ét (ip+useragent+sessid) belelöki az adatbázisba.

Ezután minden eseménynél az első ellenőrzés arra irányul, hogy megnézem, az adatbázisban hány ilyen próbálkozás tartozik a látogatóhoz+eseményhez. Ha X-nél több, akkor 10 perc pihi. Egy szemétgyűjtés pedig értelem szerűen törli a már nem aktuális sorokat.
9

Ez csak egy szelete a dolognak

vbence · 2006. Jún. 27. (K), 15.22
Mégegyzser köszi a javaslatokat. Az én problémám elsősorban nem a saját webalkalmaztásom megvédése. Amire én gondolok az egy általános védelem a próbálkoás ellen. FTP, SSH, POP3 és persze a HTTP alapú explotiok próbálgatása. Arra soha senki nem vette a fáradtságot, hogy szkriptet írjon speciel az én oldalam ellen, úgyhogy őszintén még nem is gondoltam arra, hogy ezt védjem.

Az SSH és FTP-re elég jó megoldás lenne a már említett bruefrorceblocker. Ez egy perl script, ami megkapja syslog-on keresztül az összes auth.* üzenetet, és ebből regex-el kiszedi az ipket stb stb stb. (Meg persze van központi feketelista).

Én egy ugyanilyen, csak (esetleg) mégtöbb dolgot figyelő progira gondolok.

Amúgy mellesleg ugyanígy lehetne központi védelmet csinálni a lefársztások ellen, amikor valaki egy lassú php-t kér le újra és újra.
10

evasive

reho · 2006. Jún. 27. (K), 15.32
Nézd meg ezt, hátha ez kell neked:
http://www.nuclearelephant.com/projects/mod_evasive/
Nekünk bevált.
11

Ez tetszik

vbence · 2006. Jún. 27. (K), 15.53
Köszi.. Még ilyet :)

Amúgy új ötlet. Egy 404 figyelő: aki például asp fájlt keres egy linuxos szerveren az kapásból blaklist, beletenni egy netről frissülő listát, meg ilyesmit. Ezek annyira egyértlmű ötletek, csodálkozom, hogy nincs már 500 ilyen program. Ezt az utolsót akár php-ben is le lehetne programozni...
13

mod_security

Bártházi András · 2006. Jún. 27. (K), 20.12
Ezzel is lehet próbálkozni a témakörben. De ez is "csak" webszerver.
12

szerver védelem

Bártházi András · 2006. Jún. 27. (K), 20.10
A szerver védelem témája inkább a http://hup.hu-ra tartozik. Itt offtopic, illetve ne csodálkozz, ha webfejlesztés témakörben kapsz válaszokat. :) Ott tuti kapsz jó tippeket!
14

van benne valami

vbence · 2006. Jún. 27. (K), 22.41
igaz.. csak gondoltam, a két dolog eléggé rokon.. lamp meg minden...
Azért ha metalálom a tökéletes megoldást az közzéteszem.. :)