Bekijk Volledige Versie : Gehacked? Veel GB's traffic per maand!?
Beste allemaal,
Ik heb een dedicated server bij Leaseweb met Centos 5.2 en DirectAdmin. Tot een paar maanden geleden ging dat allemaal prima; todat ik voor maart opeens 600 euri's moest bijbetalen voor het dataverkeer.
Een poosje geleden was er wel een probleem met Roundcube; maar deze is inmiddels geupdated naar de laatste versie. Ook Centos is inmiddels 5.3. Ik dacht dat daarmee de problemen waren opgelost.
Als ik echter bij de stats kijk voor April dan zit ik alweer op 6.1 TB (!) terwijl ik maar 2 TB heb. Dat wordt dus weer een leuke rekening. Vorige week vrijdag is de laatste keer dat ik yum update heb uitgevoerd; en sinds die datum was het rustig; tot gistermiddag/avond:
20:00 - 21:00 7.24 MB 17.66 MB 24.90 MB
19:00 - 20:00 4.64 MB 26.42 GB 26.42 GB
18:00 - 19:00 4.43 MB 4.59 GB 4.60 GB
17:00 - 18:00 23.27 MB 34.12 MB 57.39 MB
De dus de nodige GB's over de balk. Er draaien een paar websites die weinig tot geen bezoekers hebben. De /home/ directory is 1.2 GB groot, en de groote vhost is 500 mb. omdat zij 450mb. aan mail hebben staan.
Wat kan hier aan de hand zijn?
Vraag om een herinstall anders?
en load je spullen opnieuw op (nadat je nagekeken hebt of daar het probleem niet inzit)
Nou een herinstall vind ik wel erg rigoreus :-/
En met spullen opnieuw uploaden bedoel je de bestaande websites/scripts ed. ? Zoveel zijn het er niet.
Met:
du -sk * | sort
Kom ik niet echt grote dirs tegen
En deze is ook wel interessant:
top - 11:48:01 up 7 days, 12:58, 1 user, load average: 1.00, 1.01, 1.00
Tasks: 195 total, 2 running, 192 sleeping, 0 stopped, 1 zombie
Cpu(s): 19.5%us, 5.6%sy, 0.0%ni, 74.7%id, 0.1%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 2074232k total, 1299304k used, 774928k free, 269700k buffers
Swap: 4008120k total, 88k used, 4008032k free, 705660k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3176 apache 25 0 5228 3064 1292 R 100.0 0.1 10852:41 perl
1 root 15 0 2064 592 512 S 0.0 0.0 0:03.47 init
2 root RT -5 0 0 0 S 0.0 0.0 0:00.30 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/0
4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.08 migration/1
6 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
7 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/1
8 root RT -5 0 0 0 S 0.0 0.0 0:00.19 migration/2
9 root 34 19 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/2
10 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/2
11 root RT -5 0 0 0 S 0.0 0.0 0:00.15 migration/3
Je bent overduidelijk onbekend met dit soort rakkers.
Een checklist
- Check dmv. ps -aux of er rare processen draaien
- Draai chkrootkit
- Check je /var/tmp /tmp en dergelijk op vage scripts (denk aan ... directories, bestanden watmet een . (hidden) beginnen)
//edit, kill dat perl process, zal me niks verbazen als het udp.pl is....
check eventueel ook je traffic met bijv. tethereal ofzo
Ik check m'n traffic met VNSTAT en het volgende commando watch -n 1 netstat -ta geeft:
tcp 0 0 GIY001.local:51750 83.170.110.178:ircd ESTABLISHED
tcp 0 0 GIY001.local:imaps c92-143.blackberry.ne:46506 ESTABLISHED
tcp 0 0 ns2.artdigital.nl:58446 83.170.110.178:ircd ESTABLISHED
tcp 0 0 GIY001.local:imaps bda001.bis.eu.blackbe:53730 ESTABLISHED
tcp 0 0 ns2.artdigital.nl:48311 83.170.110.178:ircd ESTABLISHED
tcp 0 0 GIY001.local:37604 83.170.110.178:ircd ESTABLISHED
tcp 0 0 GIY001.local:51850 69.57.160.2:afs3-fileserver ESTABLISHED
tcp 0 0 GIY001.local:imaps bda059.bis.eu.blackbe:37264 ESTABLISHED
tcp 0 0 ns2.artdigital.nl:37651 83.170.110.178:ircd ESTABLISHED
tcp 0 0 GIY001.local:48039 83.170.110.178:ircd ESTABLISHED
tcp 0 0 GIY001.local:45089 83.170.110.178:ircd ESTABLISHED
tcp 0 0 ns2.artdigital.nl:34075 83.170.110.178:ircd ESTABLISHED
tcp 0 0 GIY001.local:imaps bda186.bis.eu.blackbe:43654 ESTABLISHED
tcp 0 0 GIY001.local:imaps bda060.bis.eu.blackbe:43820 ESTABLISHED
Een poosje geleden was er wel een probleem met Roundcube; maar deze is inmiddels geupdated naar de laatste versie. Ook Centos is inmiddels 5.3. Ik dacht dat daarmee de problemen waren opgelost.
Als 'ze' door een hack ergens al eenmaal binnen zijn, is het probleem niet opgelost met wat updates hier en daar. Je hebt waarschijnlijk gratis wat extra programmatuur gekregen en wellicht is zelfs een cronjob aangemaakt om te zorgen dat je gratis programmatuur elke keer opnieuw opstart.
Je hebt echt een gronderige check nodig over wat er allemaal op staat wat er niet hoort. En een programmatje van 100 KB kan makkelijk een paar TB aan dataverkeer doen.
chkrootkit geeft overal: nothing found
echter dit stukje vind ik vreemd:
Searching for suspicious files and dirs, it may take a while...
/usr/lib/gtk-2.0/immodules/.relocation-tag /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/HTML/Parser/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Module/Build/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Mail/SpamAssassin/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/URI/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/IO/Socket/SSL/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Digest/SHA1/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Net/CIDR/Lite/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Net/SSLeay/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Net/DNS/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Net/IP/.packlist /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi/auto/Sys/Hostname/Long/.packlist /usr/lib/perl5/5.8.8/i386-linux-thread-multi/.packlist /usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/Storable/.packlist /usr/lib/perl5/5.8.8/i386-linux-thread-multi/auto/Digest/.packlist /lib/.libcrypto.so.0.9.8e.hmac /lib/.libcrypto.so.6.hmac
kill dat perl process nou maar, dan stop je tijdelijk met het versturen van UDP pakketjes.
Wat draait er allemaal op die sites van je (klanten?) ?
//edit;
Ben ff een kijkje gaan nemen op de 83.x ircd. And you never guess what i found.
Als 'ze' door een hack ergens al eenmaal binnen zijn, is het probleem niet opgelost met wat updates hier en daar. Je hebt waarschijnlijk gratis wat extra programmatuur gekregen en wellicht is zelfs een cronjob aangemaakt om te zorgen dat je gratis programmatuur elke keer opnieuw opstart.
Je hebt echt een gronderige check nodig over wat er allemaal op staat wat er niet hoort. En een programmatje van 100 KB kan makkelijk een paar TB aan dataverkeer doen.
ehmm ja, daar was ik inmiddels ook achter ja
Ik geef:
kill 3176
Geen output, top zegt dat hij nog steeds loopt:
killall 3176
3176: no process killed
Ook geen effect
pkill perl
Zal ff wat screenshotjes uploaden.
pkill perl
Geen resultaat, hij blijft lopen
kill -9 3176 did the job. Nu ben ik benieuwd wat er aan de hand is en hoe ik het weg krijg :-/
Je bent op zeker slachtoffer van een mass RFI scanner.
De ircd waar jij naar geconnect was zit er namelijk vol mee, ze gebruiken de volgende strings;
http://zmeu.eu/dork
Dus 1 of meerdere van je klanten en/of sites draait veroudere vulnerable software / applicatie(s)
Ik check m'n traffic met VNSTAT en het volgende commando watch -n 1 netstat -ta geeft:
Lijkt erop dat je wat IRC bot's hebt draaien.
Tijdje geleden hetzelfde gezien bij een dedicated server van een klant.
Ongeveer 500KB aan scripts, maar werkt gebruikt voor IRC DCC (filetransfer).
Zoek eens op .rar en .iso files. :)
Er zijn geen .rar, .iso of .mp3's te vinden (gelukkig)
Het lijkt me alsnog slim om contact op te nemen met LeaseWeb omtrent je "gehackte" server.
Misschien dat je een regeling kunt treffen omtrent het verbruikte dataverkeer.
Maar op het moment zouden je prioriteiten moeten liggen bij het controleren van je server op mogelijke backdoors en het beveiligen zodat het in de verdere toekomst niet meer gebeurd !
herinstall, freelancer zoeken om hem te beveiligen en te onderhouden... klaar
je server draait vast een backdoor, als ie al niet geroot is.. dus doe iedereen een plezier en laat iemand met clue er naar kijken :)
todat ik voor maart opeens 600 euri's moest bijbetalen voor het dataverkeer.
Toen ik dat lees dacht ik direct een externe expert inschakelen, die kan je voor minder dan dit bedrag vast van dit probleem afhelpen. Ik zou het risico zeker niet nemen om nog een maand zo'n rekening te krijgen.
Hulp is on the way; bedankt voor jullie reacties.
Even samenvattend: er draaiden een x-aantal scripts vanuit /tmp die IRC mogelijk maakten. De nodige poorten en IP's zijn geblocked en de scripts zijn verwijderd.
kratje pils er op dat ze binnen een week of 2 weer bezig zijn? je hebt waarschijnlijk brakke software zoals joomla, mambo, phpbb of andere zooi die lek is. Dit is een hobbeltje voor de gene die je nu geblokt hebt, maar een andere kan er net zo hard misbruik van gaan maken.
maar je moet het zelf weten, je ziet de rekening van leaseweb vanzelf, en die is duidelijk duurder dan of managed gaan zitten, of er iemand naar laten kijken die weet wat ie doet ;-)
Controleer ook even goed of er geen cronjobs achter blijven in de apache cron.
Sluit deze ook af voor gebruik. Scheelt ook alweer veel ellende met het automatisch herstarten van de processen.
Cronjob(s) reeds gechecked; deze week kijkt er een linux-nerd naar.
Kratje pils staat; echter die gaat redelijk snel leeg hier :-)
Poort 6667 , 54000 t/m 54010 en 113 dichtpleuren
@TS - aangezien het een dedicated server is, zou ik
1. het probleem 'terugleggen' bij Leaseweb. Zij zijn (lees eerst even je contract of het zo is) in principe verantwoordelijk voor het up-to-date houden van de server, beveiliging, e.d. en ze hadden m.i. je dan ook veel eerder moeten attenderen op het excessieve dataverkeer (dat kunnen ze toch monitoren!!)
2. als de donder gaan uitzoeken hoe men is binnengekomen. Er werd al gewezen naar (zoals altijd) Joomla, PHPBB e.d. maar mijn ervaring is dat door mensen zelf "gescripte" upload-dingetjes tot de grootste ellende kunnen leiden...
Het weggooien van de scrips helpt niet veel. Zolang je de oorzaak niet kent en wegneemt, blijft je server open staan. Even een "nachtje doorhalen" kan veel ellende besparen,.. mijns inziens heb je niet de tijd om een weekje te wachten op een derde maar moet je dit zelf zo snel mogelijk onder controle zien te krijgen.
Onder welke steen ben jij vandaan gekropen brinkie ?
Je weet toch dat er verschil is in dedicated servers?
Je hebt namelijk managed en unmanaged servers, dit bericht is immers gepost in het unmanaged gedeelte ;)
Leaseweb denkt in gigabytes en terabytes traffic, the more the better, makes it cheap..
@TS;
Suc6 gozer !
Je hebt namelijk managed en unmanaged servers, dit bericht is immers gepost in het unmanaged gedeelte ;)
Dit forumdeel heet "(unmanaged) Hosting". Met unmanaged tussen haakjes. Uit TS's post maak ik niet op dat hij een unmanaged server heeft. Als dat wel zo is, dan heeft hij een onjuiste keuze gemaakt want hij kan het klaarblijkelijk niet beheren.
Zo, maar weer terug onder m'n steen dan maar hè?
Begrijpend lezen is inderdaad vak apart.
Deze sectie heet niet voor niks;
Dedicated en VPS (unmanaged) Hosting
Het leek me toch vrij duidelijk dat de TS het over een unmanaged dedicated server heeft, welke in het leaseweb netwerk staat.
Maar genoeg hierover. Get to the roots to fix the problem \!/
Heb je niet een oude versie/ongepatchte roundcube draaien ?
Eventueel even iptables of APF draaien zou al moeten helpen.
Cronjob(s) reeds gechecked; deze week kijkt er een linux-nerd naar.
Hieruit concludeer ik dat je weinig zin hebt om naar ons te luisteren.. Iemand die jij kent en toevallig wat aan linux doet naar je server laten kijken valt niet onder iemand met ervaring met webservers en security.
De reden dat er hier zo fel op gereageerd wordt is omdat jou server waarschijnlijk iemand anders staat aan te vallen. En wie weet is dat de volgende keer wel een webhoster (of een klant van deze) die hier actief is.
Dus nogmaals, neem iemand in de armen die weet wat hij doet en die vaker met dit soort zaken te maken heeft gehad. OF neem een managed server en laat het doen. Das altijd nog goedkoper dan 600 euro naar leaseweb brengen.
das IMHO een stuk beter dan 'een linux-nerd' er naar laten kijken. :innocent:
Idd, als je er zelf niets van kent (je "kill werkt niet"-opmerking geeft aan dat je weinig kaas gegeten hebt van basis unix systeembeheer), laat je server door iemand beheren die er wel iets van kent.
Als ik zo'n lek had dan zou ik geen oog dicht doen en als de donder het lek dichtmaken.
Als iemand zegt ik laat er wel een keer iemand naar kijken deze week dat kan er bij mij ook niet in.
Waarom onderneem je niet gelijk aktie?
Er zijn genoeg mensen die je meteen willen helpen daarmee..
dreamhost_nl
26/04/09, 16:20
...en het zal je minder kosten dan alle extra traffic waarvoor je nu moet gaan betalen.
systemdeveloper
26/04/09, 19:03
En natuurlijk is het ook wel prettig voor die partij die al die tb-tjes voor de kiezen krijgt.
Je moet het zelf weten natuurlijk, maar met je post hier geef je aan dat je op de hoogte bent dat je server misbruikt wordt en dat je niet direct actie onderneemt. Nu maar hopen dat ze niks illegaals doen via jouw server. Anders moet je straks toch met een goede reden komen wáárom je niet direct de stekker eruit hebt getrokken...
Triloxigen
26/04/09, 19:07
Idd, als je er zelf niets van kent (je "kill werkt niet"-opmerking geeft aan dat je weinig kaas gegeten hebt van basis unix systeembeheer), laat je server door iemand beheren die er wel iets van kent.
En een yum update maakt je systeem niet veilig, het update enkel wat software.
Er zijn genoeg mensen die je meteen willen helpen daarmee..
Inderdaad, even gillen of een PM doet wonderen.
Ik zou hier inderdaad niet te lang mee wachten.
Wellicht kun je eens een firewall installeren zoals (CSF/LFD) die alle porten blocked en enkel porten opent die nodig zijn zoals 80,21,2222 etc?
Heb gister een PM conversatie gehad met de TS. Hij is ook rond de roundcube tijd gehackt, z'n server heeft toen der tijd hub gespeeld voor IndoIRC zonder dat hij het niet direct wist.
Na wat speurwerk ben ik erachter gekomen wat IndoIRC is.
IndoIRC is een irc netwerk waar voornamelijk RFI scanners draaien. Het zal me dus ook niet verbazen dat de TS z'n server gemeld is bij abuse@leaseweb.com
Maar wat wil je als vrijwel geen clue hebt van de basics van *nix.
anyway, keep your boxens up2date & secure !
Om maar even terug te komen op dit topic, de TS zijn doos is nog steeds zo lek als een mandje.
En dan spreek ik niet over 1 webapp / daemon wat lek is. En de suckit sshd wat nog steeds draait.
Laatste tijd valt het me steeds vaker op dat weinig mensen aan security denken, laat staan dat ze uberhaupt iets aan security doen.
Wakeup people !