Debian 6 inbreker blokkeren

[Player1S]

Hoi,

Ik ga ongetwijfeld iets heel simpels vragen maar mijn collega beheerd normaal de Linux machines maar die is nu op vakantie.

Situatie: Debian 6 server is op ingebroken en iemand gebruikt het om litecoins te minen.

Ik kan wel het proces killen maar ik ga niet 24 uur per dag dit doen tot mijn collega het kan oplossen.
Ik heb al geprobeerd de poort en adres te blokkeren maar dit lijkt geen oplossing.
Ik heb een handleiding gevonden maar dit werkt niet.

Ik heb wachtwoord gewijzigd van de gebruiker die het steeds opstart. Geen oplossing

Iemand die mij de juiste kant op kan en wil sturen??

[Rikkiz0r]

De internetkabel eruit trekken will do the job

Als dat geen mogelijkheid is alles blokkeren met de firewall? (Ook SSH)

[Player1S]

Liefst zet ik de server gewoon uit tot mn collega er weer is maar dat is geen optie. Er draait een site op die nog niet echt actief is maar men wel graag wil dat deze blijft draaien. (en mogelijk de oorzaak dat men binnen komt X )

Ik heb ook geen idee hoe de desbetreffende persoon binnen komt en steeds weer zn miner opstart. Alles blokkeren is geen optie waarschijnlijk.

[Rikkiz0r]

Dikke kans dat er dan een lek in de website zit, ik weet niet of je kan programmeren maar dan zou ik daar toch eens naar exploits zoeken.

Je zou natuurlijk even de website op een andere bak kunnen gaan draaien.

[ Voor 21% gewijzigd door Rikkiz0r op 19-12-2013 13:44 ]

[Standeman]

Misschien dat crontab checked of de miner draait en deze steeds opstart?

[rvtk]

Er is zeker geen geld om iemand met de juiste achtergrond in te huren om dit probleem goed op te lossen?

Zonee, gewoon stekker eruit. De machine is gehackt, wie weet wat er nog meer op draait.

[Player1S]

Crontab is gechecked. Staat niks in over de miner.

Kans is idd groot dat het in de website zit maar helaas buiten mijn kennis en de webdesigner claimt dat er niks mis mee is.

[Hero of Time]

SSH stoppen (als je zelf nog fysiek toegang hebt, des te beter). Dan de site tijdelijk offline gooien (dagje), crontab nog een keer nakijken. Niet alleen voor de bekende gebruikers, maar alles in /var/spool/cron/ en in /etc/cron.*.

Als je het proces weet, weet je ook waar deze staat. Zoek erop, mieter de boel weg en check ook de logs in /var/log. Eentje die je wilt controleren is auth.log en dmesg/syslog/messages.

Als je na de dag offline weer alles terug ziet, is de site lek en gooi je die bak gewoon uit. Kan je collega hoog en laag springen, maar gehackte machine == uit. Simpel als dat. Je kan 'm niet meer vertrouwen dus eerste actie als die collega terug is, is een offline backup maken en herinstalleren. Daarnaast de webdevver een schop onder z'n kont geven als dat de werkelijke entrypoint is.

[CAPSLOCK2000]

Uitzetten of van het netwerk halen is de enige verstandige oplossing. Je kan wel een IP gaan blokkeren maar dan komen ze gewoon terug vanaf een ander IP uit het botnetwerk.

Aangezien je zelf aangeeft dat het nog geen productie draait zou dat een no-brainer moeten zijn.

Pas als je weet hoe ze binnen zijn gekomen kun je beginnen te denken over opruimen. Daarbij is het net als bij Windows dat er zoveel manieren zijn om troep te verbergen dat je beter kan herinstalleren.

Als je baas echt niet kan overtuigen zorg dan dat je firewall alles blokkeert, zowel inkomend als uitgaand en maak vervolgens een whitelist van vertrouwde adressen die wel nog verbinding mogen maken. Ik zou alle clients die verbinding hebben gehad met die machine ook maar eens goed onderzoeken.

Er zijn in praktijk drie manieren waarop Linux machines worden gehacked.
1. slechte wachtwoorden.
2. machines die niet tijdig gepatched worden. Je draait nog Debian 6. Installeer Debian 7 (of laat dit doen). Aangezien deze machine nog niet in productie is heb je daar nu nog de gelegenheid voor. Als het in productie gaat ligt het vast veel moeilijker.
3. brakke websites, dit is denk ik in meer dan 90% van de gevallen aan de hand. In ieder geval wel in alle gevallen die ik het afgelopen jaar gezien heb.

Opruimen is lastig, en als je zelf geen Linux-expert bent dan is het vrij kansloos.

Zet die machine uit. Voor ons is dit zo iets als de wegenwacht bellen met de vraag hoe je brand in de moter van je auto moet blussen zonder te stoppen met rijden. Sorry, ik kan het niet mooier maken.

Ask Slashdot: Application Security Non-existent, Boss Doesn't Care. What To Do?

[ Voor 7% gewijzigd door CAPSLOCK2000 op 19-12-2013 14:37 ]

[Player1S]

Het lijkt inmiddels opgelost te zijn of hij heeft het (voorlopig) opgegeven.

[Hero of Time]

Stilte voor de storm. Laat je niets wijsmaken. De 'inbreker' kan ook z'n tijd afwachten op een onverwacht moment en dan weer toeslaan. Ga op zoek naar de gaten, logs e.d. en zorg dat het gewoon niet weer kan gebeuren.

Zoals CAPSLOCK2000 al zei, websites zijn het overgrote deel van de gaten die misbruikt worden. Zonder de juiste afscherming (standaard settings zijn niet secure!!!) is het alleen maar een kwestie van tijd.

[Verwijderd]

Kun je niet een scriptje schrijven die onbekende processen op basis van bijvoorbeeld niet overeenkomende SHA-1 hashes automatisch killed? Kan zoiets eigenlijk en heeft dat nut?

[ Voor 23% gewijzigd door Verwijderd op 19-12-2013 15:53 ]

[DiedX]

Is het updaten van je software niet veel effectiever?

[Hero of Time]

Verwijderd schreef op donderdag 19 december 2013 @ 15:53:
Kun je niet een scriptje schrijven die onbekende processen op basis van bijvoorbeeld niet overeenkomende SHA-1 hashes automatisch killed? Kan zoiets eigenlijk en heeft dat nut?

Of het kan: vast wel. Of het nut heeft: nee. Bash moet je toestaan en je kan alles via bash laten lopen dmv argumenten e.d. Schiet je dus alsnog weinig mee op.

DiedX schreef op donderdag 19 december 2013 @ 15:58:
Is het updaten van je software niet veel effectiever?

Je beveiliging is zo lek als de grootste bug. Al is alle software dichtgetimmerd met patches, dan nog kan een gaar CMS systeem of website je hele server open zetten voor iedereen.

[himlims_]

imho; een gehackte linux/unix bak is niet/nooit meer te vertrouwen; verse installatie uitvoeren

[DiedX]

Hero of Time schreef op donderdag 19 december 2013 @ 17:01:
Je beveiliging is zo lek als de grootste bug. Al is alle software dichtgetimmerd met patches, dan nog kan een gaar CMS systeem of website je hele server open zetten voor iedereen.

Met je software bedoelde ik /ook/ je CMS Mijn ervaring is met WordPress/Joomla!/$vulin, je de grootste problemen in huis kan halen als je juist *DEZE* niet update

[Thralas]

L1nt schreef op donderdag 19 december 2013 @ 13:46:
Kans is idd groot dat het in de website zit maar helaas buiten mijn kennis

Dat is wel heel makkelijk.

Zoek de logs van je webserver eens op (hint: meestal onder /var/log/) en kijk eens of je iets geks ziet. Met name in de error logs vind je regelmatig sporen van attackers - output van bv. wget kom je wel eens tegen.

Even Googlen leert dat oa. ook CVE-2013-1823 exploited wordt icm. litecoin-miners. Een directe aanroep naar /cgi-bin/php5 is dan ook fishy (zie je access logs).

[Player1S]

Heb inmiddels het eea gevonden. Stond bijvoorbeeld svcrack.py op. Google leert mij dat het een hacktool is. Ik heb de map weg gegooid en wachtwoorden aangepast. Zal wel dweilen met de kraan open zijn maar toch.

[pven]

Ik weet niet wat voor gegevens via de server te benaderen zijn in de rest van het netwerk, maar ik zou niet verantwoordelijk willen zijn voor de impact van een gehackte server in een bedrijfsnetwerk. De server is gehackt, jij hebt geen idee waar je het moet zoeken; het is dus onbetrouwbaar: -> netwerkkabel eruit, en opnieuw installeren.

[Sallin]

Risico's zijn inderdaad te groot. Gewoon afsluiten en aan je collega overdragen als hij terug is.

[deadinspace]

himlims_ schreef op donderdag 19 december 2013 @ 18:36:
imho; een gehackte linux/unix bak is niet/nooit meer te vertrouwen; verse installatie uitvoeren

Dat. Dat de litecoin miner weg is wil niet zeggen dat de machine nu veilig is. Als iemand toegang had tot die machine (zeker als dat root-toegang is), dan zijn er de nodige manieren waarop hij backdoors heeft kunnen verstoppen.

En met elke reparatie-poging die je nu onderneemt loop je het risico dat het straks niet mogelijk meer is te achterhalen hoe de inbreker binnen is gekomen.

CAPSLOCK2000 schreef op donderdag 19 december 2013 @ 14:35:
2. machines die niet tijdig gepatched worden. Je draait nog Debian 6. Installeer Debian 7 (of laat dit doen).

Debian 6 ontvangt nog security updates, dus als security-updates goed zijn bijgehouden dan is dat het probleem niet.

Maar upgraden naar Debian 7 (of ja, herinstalleren in dit geval) is wel nodig ja, want de security support voor Debian 6 stopt waarschijnlijk in mei.

Verwijderd schreef op donderdag 19 december 2013 @ 15:53:
Kun je niet een scriptje schrijven die onbekende processen op basis van bijvoorbeeld niet overeenkomende SHA-1 hashes automatisch killed? Kan zoiets eigenlijk en heeft dat nut?

Dat zou ik nooit doen. Het risico op problemen is groot, en het is alleen symptoombestrijding. Op het moment dat je vreemde processen moet gaan killen is de inbraak al gebeurd.

Iets dergelijks om een inbraak te detecteren is een ander verhaal. Dat kan heel goed, en dan heb je een Intrusion Detection System (IDS). Daarvan zijn er verschillende, en process monitoring en binary checksumming zijn inderdaad dingen die veel IDSen kunnen doen.

[johnkeates]

Je had ook kunnen kijken onder welke user het uitgevoerd werd.. dan kan je kijken waar de persoon/botnet binnen komt.

Stel dat het www-data is, dan is het via je webserver. Als het root is weet je het niet zeker, want dan kan het ook een lokale privilege escalation exploit zijn. Als het een non-standaard user is, kan het ssh of rlogin backdoor zijn, of als dat er op zit een SoL verbinding.

Uiteindelijk zal je gewoon je server moeten uitzetten, de bestanden backuppen via een livecd of extern systeem, en daarna de schijf wissen en opnieuw installeren.