Rendszer feltörések védekezés mit csináljak ha valaki betört a rendszerembe

Rendszer feltörések védekezés mit csináljak ha valaki betört a rendszerembe
2005-04-06T07:15:46+02:00
2005-04-28T18:31:20+02:00
2022-11-01T00:25:38+01:00
  • MOst találtam egy oldalat:

    Internet Storm Center - Internet Security

    Ha jól értettem amire való akkor:

    be kell küldeni nekik a firewallunk logját a tobbit elintézik ( roviden ennyi ). HOgy mukodik -e a valosagban ki tudja? mindenesetre megér egy probát!

    adriankoooo
    Mutasd a teljes hozzászólást!
  • "Ha harc hát legyen harc"

    Szemet szemért, fogat fogért!
    Mutasd a teljes hozzászólást!
  • Én a következőt tenném hasonló esetben, ha felnyomják a céges szerveremet:

    1. várnék és figyelnék, elrejteném a valóban fontos céges adatokat ideiglenesen.
    2. leszedném a szervert a netről, majd full backup.
    3. Restore az utoldó biztosan jó rendszerbackupról.
    4. restore a feltört gépről egy másik fájlrendszerbe, majd összehasonlítás, ezután dokumentálása a cracknek.
    5. Kielemezve a logokat, összehasonlítás eredményét megállapítanám, hogy szerintem hol jött be.
    6. kiskapu betömési kisérlet, peccselések.
    7. net visszakapcsolása.

    Amit biztosan nem tennék:
    1. Nem görcsölnék a bosszúvággyal, csutira vettek, legközelebb odafigyelek.
    2. Nem értesíteném a hatóságokat, mert utána több vele a baj, mint a haszon sajnos.
    3. Valószínűleg elérném a cégnél, hogy ne hajnalpírral fessünk a jövőben tojásokat

    És pár jótanács saját tapasztalatból:
    1. SSH-t engedj csak a gépre és azt is kizárólag SSH2 key auth-al, legalább 2048 bites DSA kulccsal.
    2. Közhely, de csak az a szolgáltatás fusson, amire szükséged van és olyan jogosultsággal, amire annak szüksége van.
    3. Ne az alacsony szitű (IP,TCP) támadásoktól félj, hanem a magas, protokoll szintűektől.
    4. Ellenjavallat a bonyolult protokollok alkalmazása, igyekezz megkerülni azokat. Pl ne használj IMAP-ot, kipublikálva meg pláne ne.

    üdv: Hara

    ps: Esetleg leírhatod, hogy milyen szolgáltatásoknak kell futnia rajta, hátha lesz itt valakinek pár ötlete!
    Mutasd a teljes hozzászólást!
  • Szóval itt van egy halom live cd-ről link vagy írás, Windows-, BSD- vagy Linux-alapúak egyaránt: http://www.livecdforums.com
    Esetleg még itt is érdemes körbenézni:
    Live CD list
    Mutasd a teljes hozzászólást!
  • Én ha észreveszem, hogy valaki stealth-scannel (úgysem ér vele semmit, mert még az ICMP is le van tiltva), akkor csuklóbol megy egy FIN-scan. :)


    Jujj de gonosz
    "Ha harc hát legyen harc"
    Mutasd a teljes hozzászólást!
  • Szia

    Vagy készítesz egy saját boot cd-t (ha kell, küldök egy leírást) vagy letöltesz egy LIVE cd-t. Ezekkel be tudsz lépni az adott gépre és ellenőrizni tudod a tartalmát.
    Ha éppen nincs egy (mások által korábban említett) tripwire vagy hasonló progi a cd-n akkor ne aggódj, nem erre készülnek, tehát ezt már saját magadnak kell összeraknod.

    Akár megcsinálhatjátok azt is, hogy a tűzfal egy boot cd-ről indul és onnan is fut, de ha tutira akartok menni, akkor nem letöltitek az IPCop vagy SmoothWall lemezeket, hanem elkészítitek magatok. A beállításokat is a cd-ről olvashatja a rendszer, s a forrásban bármit lehet módosítani, aztán kb. 10 perc alatt újraírható az egész lemez.
    Ez kicsit macerásabb a mostani, vinyóról futó rendszernél, de adott esetben jól jöhet.

    Továbbá én nem látom értelmét a gép kikapcsolgatásának, mert bár nehéz feltörni egy gépet úgy, hogy nincs bekapcsolva, de ettől függetlenül még mindig van legalább 16 órányi online üzeme, amely alatt ugyanúgy törhető. Ez tehát nem megoldás, csak a probléma megoldásának elódázása (de ez az én véleményem, természetesen szívesen veszem, ha valaki ebben meg tud cáfolni).

    A UPC tette érthető és valszeg ebben ki is fog merülni, mivel hiába olyan a szerződés amilyen, nem fogja kihúzni a fizetős ügyfele alól a netet. Praktikus módon ilyenkor érdemes megpendíteni a húrt, miszertint a következő hasonló esetnél szeretnéd elkérni a rád/rátok vonatkozó logfájlokat, mellyel jogi útra terelheted a dolgot a renitens júzerükkel szemben.
    Idevágó hiányos ismereteim szerint ezt ki KELL adniuk, nem tagadhatják meg. Ha pedig mégsem tennék, akkor tudniuk kell arról a fekete dobozról, amely ott van minden szolgáltatónál, tehát ugyanúgy logol mindent, abból is megszerezhető a kért infó (csak jóval nehezebben) és persze akár a UPC/Chello is perelhető, mert nem tud/nem akar infót kiadni, melyet meg kellene tennie.
    Mutasd a teljes hozzászólást!
  • Szóval nem gondolom hogy lámák lennénk...

    Nem is mondtam/feltételeztem ezt.

    Vannak olyan LiveCD-k, amik direkt tűzfalnak/gatewaynak vannak kihegyezve.
    CD-ről bootolsz, a konfigurációs fájlok mondjuk egy pen-drive-on, és megy is a tűzfal.
    Ott tuti nem tud felülírni semmit (max. a pendrive-ot, de azt könnyen vissza lehet állítani).

    Amúgy azt már tudod, hogy milyen programon keresztül, hogyan jött be a támadó?
    Mert ha olyanok a tűzfal-szabályok, hogy még csak nem is válaszol semmire (ICMP-re se!), hanem a policy DROP, és csak egy ssh van nyitva mondjuk 10000-es port felett, de még az sem válaszol ICMP-re, akkor szeritnem nem tud egy programban sem buffer-overflow-t okozni, sem egyéb hibát kihasználni, hogy átvegye az irányítást.
    Erről írj egy kicsit légyszi, hogy jobban tudjuk, miről is van szó!
    Pl. engem egyszer régen úgy nyomtak fel, hogy láma módon az Internet felé is látszott egy wu-ftpd, ráadásul a default porton.
    Ennek volt egy hibája, hogy nem volt saját ls prancsa, hanem a rendszer ls parancsát használta.
    A wu-ftpd ugye setuid-es volt.
    Így az ls rootként ment, amit hívott.
    Volt a daemonban valami hiba, tán buffer-overflow, és ezen keresztül el lehetett érni a rendszer ls parancsát, amit ha jól tudom, felül kellett írni egy exploitossal, és akkor már akár root shell-t is tudodd kapni a támadó.
    Engem így nyomtak fel, még a 2.2-es kernelek idejében. :)
    ipchains rulz.

    Én ha észreveszem, hogy valaki stealth-scannel (úgysem ér vele semmit, mert még az ICMP is le van tiltva), akkor csuklóbol megy egy FIN-scan. :)
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Köszönöm a sok érdekes hozzászólást...nem tudok mindenki hozzászólására reagálni elnézést...veszek egy nagy levegőt és belekezdek...

    Előre bocsátom hogy a linuxot csak felhasználó szinten tudom kezelni...a szervereket a rendszergazda konfigolja..
    Én csak mint téma dobtam fel hogy az itt fórumozóknak mik a tapasztalatai és javaslata a témával kapcsolatban.

    _psc_ válasz:

    És ez nálunk pontosan így volt és van...még annyi korlátozással hogy Internetről két IP helyről engedélyezte a bejutást a tűzfal ott is csak és kizárólag azok a portok amiket használunk...otthon UPC-s előfizetésem van ezért a dinamikus a kiosztott IP címem ennek ellenére 4 hónapig fix!!!...nem csoda hogy érdemes UPC-s előfizető gépére betörni...széles sávszélesség.... tárkapacitás....erőforrás...sokáig el lehet érni....

    A biztonság növelése érdekében OpenVPN-t használunk ha be szeretnék jutni az adatbázis szerverre.
    (külön számítógépen van a tűzfal az adatbázis szerverek (teszt és éles) plusz egy fálj szerver...automatikus napi mentés éjjel , tűzvédelem miatt egy helyileg is máshol lévő gép Pen drive-ja ami reggel egy páncélba kerül..)

    Szóval nem gondolom hogy lámák lennénk...a betörés valószínűleg a nem a legfrissebb kernel miatt történhetett...de nagyon rizikós és macerás azonnal átállni mindig a legfrissebbre...picit sokat vártunk...talán ez miatt történhetett..



    a_x válasz:

    425 próbálkozás az én otthoni gépemen történt és én engedélyeztem az első próbálkozása után , hogy lehet több is...


    A tűzfalam logjában ezt találtam:(Pontos dátumot és IP én módosítottam):

    annyit tudok hogy egy Stealth scan futatott +

    2005.04.06 ,Supervisor,"Rule ""Unused Windows Services Block"" blocked (80.98.X.X,1025).","Rule ""Unused Windows Services Block"" blocked (80.98.X.X,1025). Inbound TCP connection. Local address,service is (name(IP),1025). Remote address,service is (80.98.X.X,1307). Process name is ""N/A""."
    2005.04.06 ,Supervisor,Unused Windows Services Block was detected and blocked.,"Unused Windows Services Block was detected and blocked. All comunication with 80.98.X.X will be blocked for 30 minutes."


    ennél untam meg..


    Az ügyben nem kerestük meg a rendörséget megelégedtünk azzal hogy az internetes szolgáltatójánál jeleztük a problámát...
    UPC nagyon korrekt levelet küldött..."a szerződésszegő tevékenységet folytató ügyfelekkel felvettük a kapcsolatot.Amennyiben a probléma 72 óra után továbbra is fennáll kérjük jelezze ezt ismét"

    A tűzfal gép gyalu és kernel újra fordit...azon eszelünk hogyan lehetne még biztonságosabb a rendszerünk...
    egyik változat amit ti irtatok(tropwore,aide)...a másik írni egy boot CD-t, amin rajta van minden és onnan bootolni. Read-only file system semmit nem lehet rajta módosítani. A legjobbnak ez tűnik....persze ezzel annyit lehet elérni hogy a tűzfalgépen nem tud sokmindent módosítani(persze rengeteg egyéb macera módosításnál plusz a páncélban egy biztosági másolat stb.)...de a többi gépet eléri...

    most jutott eszembe nem tudom mennyire elmebeteg ötlet...de 20:00 és hajnali 4 között leáll a tűzfal szerver...az nagyon amatőr?...talán ezt nem is gondoltam át...na mind1


    Várom értékes építő hozzászólásokat...

    A.

    Mutasd a teljes hozzászólást!
  • Amúgy szvsz nem szerencsés, hogy ha pl. az adatbázis szerver az Internetre van kötve...
    Érdemesebb beruházni egy hardveres tűzfalra, vagy akár egy kiszuperált konfigot (akár 486-os is elég) betenni tűzfalnak/gatewaynek (slackware-val, gentoo-val, esetleg debiannal, ízlés szerint), amin nincs nyitva semmilyen port (max. egy ssh, de az sem a default porton), és nem is fut semmilyen szolgáltatás.
    Én erre a célra egy AMD 5x86 "P75"-ös gépet használok, 16Mb RAM-mal, egy 1,2 gigás HDD-vel, Slackware-t futtatva.
    Az egész kb. 500Mb-t foglal el (de úgy, hogy van pár nagyobb pdf-em a -/homeban).
    Alap-rendszerre slapt-get fel, meg iptables, meg mc, esetleg netris. :)
    A belső szervereket semmiképp sem tenném ki netre, semmilyen formában.
    Ha szoknak az ssh-elérése is szükséges, akkor a gateway-on keresztül lehet elérni őket (akár a gatewayon futtatott ssh-klienssel, akár ssh port-forwardinggal).
    Mutasd a teljes hozzászólást!
  • Ja, van valami program, ami ezt tudja, de én sem emlékszem a nevére. :)


    tripwire,aide
    Mutasd a teljes hozzászólást!
  • Szia

    chkrootkit-et futtassal. az persze pont a rendszer binarisait hasznalja, ezert egy erintetlen debianon, forgass a szukseges programokbol (grep, ps, stb. - chkrootkit oldalan ki van irva) statikusakat, azt ird ki egy cdre a chkrootkit-tel egyutt, es onnan futassad -p /cdrom/statikusbinarisam parameterezessel.
    Mutasd a teljes hozzászólást!
  • Nem a CVS-re gondolok, azt ismerem, mert hasznalom fejleszteshez.
    Este utananezek.
    Azert irtam, hogy emlekszem, hatha valaki ismeri, es vannak tapasztalatai, es akkor nem kell keresgetnem.
    Tenyleg meg lehet irni par sorban, de a ket soros script pl. nem fog elinditani egy automatikus vedelmet, legfeljebb riaszt egy emailbe, amit mondjuk megkapsz hajnal kettokor, azaz reggel mar bajban vagy megint, mert lehet, hogy nem azokba a konyvtarakba tette fel a sajat programjait, amire Te megirtad a scriptet...
    Mutasd a teljes hozzászólást!
  • Ja, van valami program, ami ezt tudja, de én sem emlékszem a nevére. :)
    De nem olyan ördöngösség ám egy szkript, ami rekurzívan bejárja a könyvtárakat, és kiszámítja az MD5-sumot.
    (van ugye chdir, ls, md5sum program, ezeket kell csak "kombinálni". A tárolt és a generált md5-sum meg ugye egy sima IF -fel összehasonlítható... levélküldésre van mail parancs.)
    Mutasd a teljes hozzászólást!
  • Lehet, hogy a CVS-re gondolsz, azzal is lehet ellenőrizni a rendszer(fájlok) módosítását, módosulását. Ráadásul a CVS-ben látod, hogy ki, mikor, mit módosított.

    Egyébként ritka egyszerű a scriptek megírása, hiszen egyik paranccsal kiadod, hogy futtassa le a kívánt könyvtárakon az ellenőrzést, a másikkal pedig ellenőrzöd és 'diff' segítségével nézed a változást, s ha van, akkor elküldöd egy címre.
    Ha kell megírom és bemásolom ide. Alig pár sor az egész.
    Mutasd a teljes hozzászólást!
  • Esetleg friss telepítés/konfolás után minden rendszerfájlnak (/bin/* /sbin/* /lib/* /usr/* stb.stb.) legenerálhatod az MD5-sumját egy fileba, és felírod CD-re...

    Szerintem erre mar van komplet megoldas. Kb 3-4 eve olvastam rola, de sajnos nem emlekszem a nevere.
    A rendszerfrissitesek, ... miatt sajat profi scriptet irni szerintem nem ket perc, es nem is biztos, hogy jobb lesz, mint egy tobb eve letezo project.
    Mutasd a teljes hozzászólást!
  • Mivel ahogy irtad a logok megvannak es akar bizonyito jeleggu szerintem innen kezdve mar valamilyen hatosagi ugy(nek kell lennie).

    Háát, sajnos a logok nem bizonyító erejűek (mivel nem bizonyítható az eredetiségük).

    Amúgy én is a komplett gyalu-ra/reinstallra szavazok!
    (Egyszer régen sajna velem is történt ilyesmi, Slackware 7.0-n, wu-ftp-t nyomták fel. :( Azóta "megtanultam" Linuxozni. :) )
    Esetleg friss telepítés/konfolás után minden rendszerfájlnak (/bin/* /sbin/* /lib/* /usr/* stb.stb.) legenerálhatod az MD5-sumját egy fileba, és felírod CD-re.
    Írsz mellé egy kis scriptet, ami a cdről futva végigcheckeli az egész systemet (és összehasonlítja a telepítés utánni MD5-sumokkal). Ha kaki van, azonnal kiabál.
    (A scriptet mondjuk naponta-kétnaponta lefuttathatod, esténként.)
    Így könnyen kideríthető egy esetleges behatolás, és az is hogy maradt-e utánna rootkit.
    (Érdemes nem csak az MD5-sumokat eltárolni, hanem a könyvtárak tartalmát is - hogy tudd, van-e új program telepítve.)
    Mutasd a teljes hozzászólást!
  • Velem lehet beszélni, valszínűleg tényleg egyszerűbb, de főleg biztonságosabb a gyalu.

    425* probálkozott legalábbis ennyit loggolt a tűzfalam


    Ebből 2 dologra következtetek:
    1.: nem vérprofi, hanem egy script kiddie, aki brute-force jelszótörőt használ,
    2.: marha gyenge volt a rootpass, ha kitalálta (meg az egész védelmi rendszer, ha megenged 1 ip-ről ennyi próbálkozást gyors egymásutánban)

    Mutasd a teljes hozzászólást!
  • Talán ő írta őket.

    Vagy nem profi hacker.
    Vagy nem is hacker, csak egy szerencsétlen aki írt egy hibás scriptet tudomisén milyen céllal és az össze vissza bénázik.
    Mutasd a teljes hozzászólást!
  • Bennem felmerul a kerdes hogy ha profi hacker torte fel akkor miert nem torolte a logokat?
    Mutasd a teljes hozzászólást!
  • Van egy U.S.Army szolgáltatás amivel IP-címre lehet föld-föld rakétát küldetni.
    Mutasd a teljes hozzászólást!
  • Azért ez nem vindóz, hogy szíre-szóra újra kelljen rakni.

    Es azt hogy ellenorzod, hogy minden binaris erintetlen maradt-e? Hogy nincs-e valami jo kis kernel rootkit telepitve (amivel pl kapasbol kikerulheted a tuzfalad akarmilyen beallitasat)?
    Gyorsabb es biztonsagosabb a gyalu.

    Meg kell nézni a processzeket, mi fut,


    Azokat a processzeket amiket a tamado otthagyott, te nem fogod latni.

    A távoli hozzáférést (ssh, stb..) csak azokra az ip tartományokra kell engedni, ahonnan ténylegesen és jogosan használják.


    Ez azert sok esetben nem tul trivialis dolog, masreszt ha egyszer root joga volt azon a gepen a fikconak, onnantol kezdve mindegy mit allitasz be.

    Kulso tuzfal persze valamicsket segithetne, felteve, hogy senki nem lepett be ra a felnyomott geprol...

    Gyalu.

    netchan
    Mutasd a teljes hozzászólást!
  • Az egyetlen lehetseges vedekezes az a user adatok lementese es a szerverek ujratelepitese.

    Azért ez nem vindóz, hogy szíre-szóra újra kelljen rakni. Meg kell nézni a processzeket, mi fut, és amiről nem tudjuk mi célt szolgál, azokat le kell lőni. Megnézni a cron munkákat, ilesmit. A távoli hozzáférést (ssh, stb..) csak azokra az ip tartományokra kell engedni, ahonnan ténylegesen és jogosan használják. Egyébként is az egész input lánc policyje legyen drop, és csak a kivételeket kell engedni. Nem hiszem, hogy egy szigoruan konfolt iptablessel felvértezett debiant olyan könnyen meg lehetne dönteni.
    Mutasd a teljes hozzászólást!
  • Az, hogy megvan az ip cim nem jelent semmit. Mivel egy magyar es egy nem magyar ip cimrol is probalkozott, elkepzelheto sot valoszinu, hogy nem sajat cimek voltak, hanem valaki masnak a gepet hasznalta, amin volt egy backdoor-ja. Ebben az esetben nem sokat ersz az ip cimekkel, illetve ha ersz, akkor is nehezebb lesz kovetni a dolgokat.
    Mutasd a teljes hozzászólást!
  • letöröltük az általa létrehozott két usert....átírtuk a jelszavakat stb...ennyit tehettünk


    Nem, ez nagyon nagyon keves. Ilyenkor minden valamire valo hacker hagy hatr nehany backdoor-t, amit vagy megtalaltok vagy nem. Az egyetlen lehetseges vedekezes az a user adatok lementese es a szerverek ujratelepitese.
    Masreszt kezeljetek ugy a dolgot, mintha keylogger futott volna vegig a szerveren.


    Mutasd a teljes hozzászólást!
  • Ez a másik IP cím viszont már magyarországon kiosztott IP cím...
    felhivtam az ügyfélszolgálatukat elmondtam mi a gondom...kapcsolták az illetékest...küldjem el a tűzfal logját és ha még néhányszor probálkozik akkor figyelmeztetik -mondá...

    hagytam az egészet mert nagyon flegma volt a nő...



    Küld el a loggokat!
    Mutasd a teljes hozzászólást!
  • Hello!

    Szerintem (bar meg nem volt ilyen szitum szerencser): keresd meg az illetekes szervezetet (bar ha magyarorszagon van ilyen (bar egy olyan orszagban ahol a bunosnek jogai vannak az aldozatok meg ...)) es hatha ok tudjak hogy mit kell tenni, mi a megfelelo eljaras! (ahogy az I love you-t is le tudtak nyomozni... (bar az nem itthon volt) hat ha van szep orszagunkkban is erre valami szabalyzat vagy szerv (rendorsegnek egy osztalya vagy valami) aki tudja hogy mit kell tenni es el is tudja kezdeni (esetleg nemzetkozi(EU) szervekkel egyuttmukodve). mivel irtad hogy nem magyar tartomanyi IP cimet - is - fogtatok.

    Mivel ahogy irtad a logok megvannak es akar bizonyito jeleggu szerintem innen kezdve mar valamilyen hatosagi ugy(nek kell lennie).

    De nem vagyok jogasz nem tudom biztosan.
    De en valahogy ezen az uton indulnak el, ha komolyan veszitek az ilyesfajta betoreseket.

    u.i.: ha rovidebb eljarast akarsz akkor localizalod az IP cimet -> kikuldesz ket szekrenyajto nagysagu baratot es elbeszelget az illetekes behatoloval az rendszerfeltoresekrol meg hogy milyen szep kint az eg...
    (ez csak vicc volt)

    Udv, dreamer!
    Mutasd a teljes hozzászólást!
  • Sziasztok!


    Feltörték a céges debian-os szerverünket - tűzfal meg minden specko cucc volt rajta...létre hozott két usert és azzal 2 napig - amig észre nem vettük - olyan időpontokba amikor szerinte már nem dolgoztunk - 18:00 -óra és hajnali 4 között - más rendszerekbe probált betörni...last parancsal kilistáztam mikor login-elt tehát elvileg tudjuk mikor használta a szerverünket...rendszerellenörzést tartottunk hacker meg port scan letöröltük az általa létrehozott két usert....átírtuk a jelszavakat stb...
    ennyit tehettünk

    viszont megvan a delikvens IP címe rákerestem a visual route 2005 -el és kiderült melyik országban osztják ki ezt a címet- ki a szolgáltató - és az is hova probált betörni - nem Magyarországi egyik Ip cím sem.

    Mit lehet kell még tenni? - a logok megvannak...

    Én otthonról ssh-zok a céges gépekre...és openvpn-el még egyéb dolgokat...elviekben dinamikus az IP címem de már három napja úgyan az...

    tegap mikor kiderült ez az egész akkor rajta logtam a céges gépeken - elvileg igy ha bent volt akár láthatta is az én IP címemet is...mikor mindent átálitottunk...a tűzfalam folyamatos támadásokat logolt letíltottam egy napra azt IP címet amiről érkeztek a támadások- úgyan az volt amit a szerver loggolt...5 óra múlva egy másik IP cím-ről érkeztek a probálkozások...ezt már hagytam mert érdekelt be tud-e törni hozzám...425* probálkozott legalábbis ennyit loggolt a tűzfalam , nyilván valami programot használt...


    Ez a másik IP cím viszont már magyarországon kiosztott IP cím...
    felhivtam az ügyfélszolgálatukat elmondtam mi a gondom...kapcsolták az illetékest...küldjem el a tűzfal logját és ha még néhányszor probálkozik akkor figyelmeztetik -mondá...

    hagytam az egészet mert nagyon flegma volt a nő...


    Szóval mit lehet és mit kell tenni ilyen és ehhez hasonló esetekben...

    Várom hozzászólásokat és a storikat..


    A.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd