VPS Ddos aanval en misschien gehacked

[Anoniem: 647586]

Dag tweakers,

Vandaag heb ik wat problemen gehad met mijn VPS. Zoals je op de screenshot kan zien is er ongewoon veel verkeer op mijn server toegekomen:


Tijdens de aanval haperde de terminal, maar via "top" zag ik het volgende:
- ksoftirqd (30% cpu)
- teamspeak server (30% cpu)

• Voordat jullie hier de stempel "ddos aanval" op plakken, zou ik graag je aandacht op enkele puntjes vestigen: Je ziet dat het inkomende verkeer domineert. Wilt dit zeggen dat mijn server zelf aan het DDossen was? Of was mijn server "gewoon" aan het incasseren? Ik hoop het laatste want anders is mijn server gehacked en dan is het een groot probleem.
• ksoftirqd is een interrupt proces? is dit normaal?
• de teamspeak server zelf gaat nooit boven de 6% cpu. tijdens de aanval boven 60%

.

Toen de aanval gedaan was, heeft nog heel de namiddag mijn php5-fpm van een van de sites constant op 30% CPU gedraaid, zonder merkwaardig dataverkeer. Na php5-fpm restart was dit opgelost.

Ja waarom post ik dit hier? Ik ben deels in paniek, deels teleurgesteld in mezelf (ik dacht dat ik dit soort situaties beter kon afhandelen), en beetje radeloos.

Na al die ongewone acties begin ik te geloven dat mijn server gehacked is. nochtans heb ik ssh logs nagekeken (daar zat niets speciaals in).

Iemand tips of ervaring?


Overige details:
- VPS provider: Digital Ocean
- VPS gelegen in amsterdam
- Ubuntu 14.04
- firewall: UFW
- draaiende services:
-- ssh
-- ftp
-- mailserver (pop, smtp, imap)
-- nginx
-- php5-fpm
-- teamspeak3
-- ispconfig

[TVH7]

Als je server tfc. ontvangt, dan ontvangt hij eventueel een DDOS aanval, als hij zelf aan het DOSSEN was had je dat gezien door een hoog TX verkeer. Al is het dan niet echt een hele indrukwekkende DDOS op 600mbits..

Het hoge CPU gebruik van ksoftirqd komt puur vanwege het hoge netwerk verkeer. Je server kan niet snel genoeg alle handeling uitvoeren, dus zet hij ksoftirqd hiervoor in, dit verklaart het hoge cpu usage.

Het hoge cpu usage van PHP-FPM is denk ik puur een gevolg van het hoge cpu gebruik.

[ Voor 43% gewijzigd door TVH7 op 22-02-2015 03:21 ]

[Anoniem: 647586]

Bedankt voor je reactie.

Heb je toevallig een idee hoe je kan zien welk script er wordt uitgevoerd door php5-fpm?
Er is een www-data user (de default nginx website) die constant iets uitvoert (30% cpu). Ik vind dit heel vreemd omdat er geen website op staat...

[Thralas]

TVH7 schreef op zaterdag 21 februari 2015 @ 22:16:
Het hoge CPU gebruik van ksoftirqd komt puur vanwege het hoge netwerk verkeer. Je server kan niet snel genoeg alle handeling uitvoeren, dus zet hij ksoftirqd hiervoor in, dit verklaart het hoge cpu usage.

Dat is slechts deels waar en een (niet geheel onredelijke) aanname. Om werkelijk vast te stellen waar die softirqs vandaan komen kun je /proc/softirqs checken, de entry die het snelste oploopt zal de schuldige zijn.

Anoniem: 647586 schreef op zondag 22 februari 2015 @ 12:12:
Heb je toevallig een idee hoe je kan zien welk script er wordt uitgevoerd door php5-fpm?
Er is een www-data user (de default nginx website) die constant iets uitvoert (30% cpu). Ik vind dit heel vreemd omdat er geen website op staat...

Heb je de access logs al bekeken? Anders kun je iets doen als

for pid in $(pgrep php5-fpm); do ls -l /proc/${pid}/fd; done

[Anoniem: 647586]

Heb je de access logs al bekeken? Anders kun je iets doen als

for pid in $(pgrep php5-fpm); do ls -l /proc/${pid}/fd; done

Dit is de output:

lrwx------ 1 root root 64 Feb 22 16:39 18 -> anon_inode:[eventpoll]
lrwx------ 1 root root 64 Feb 22 16:39 2 -> /dev/pts/5
lrwx------ 1 root root 64 Feb 22 16:39 3 -> /tmp/.ZendSem.abXBEE (deleted)
l-wx------ 1 root root 64 Feb 22 16:39 4 -> /var/log/php5-fpm.log
lrwx------ 1 root root 64 Feb 22 16:39 5 -> socket:[11841]

Geen idee wat het betekend. Maar die /tmp/... ziet er niet goed uit denk ik?

[Anoniem: 647586]

Maar als deze situatie zich nog eens voordoet, hoe zou jij dit dan aanpakken?

Je krijgt een email binnen dat je servers down zijn (uptimerobot gebruik ik hiervoor). Wat ik dan zou doen is hetvolgende bekijken:
==> var/www/.../logs/access.log
==> var/www/.../logs/error.log
==> var/log/syslog

Maar dat leverde me niets op... Enkel een deel ip addressen in access.log.
Welke commands gebruiken jullie in "the heat of the moment"?

[Anoniem: 647586]

Heb nog wat zitten zoeken in de logs:


Wilt dit dus zeggen dat er een kerel een botnetje (of een booter) heeft gehuurd en letterlijk alle poorten zat af te rammen?

[adis]

Je zit op DigitalOcean met je server, krijg je ook vanuit DO ondersteuning hierin? Of heb je dat niet gevraagd?

[Thralas]

Anoniem: 647586 schreef op zondag 22 februari 2015 @ 21:11:
Heb nog wat zitten zoeken in de logs:
[afbeelding]

Wilt dit dus zeggen dat er een kerel een botnetje (of een booter) heeft gehuurd en letterlijk alle poorten zat af te rammen?

Gezien je een nameserver op :53 draait, gok ik dat het wel eens een poging tot DNS amplification kan zijn. Maar dstportinformatie ontbreekt in die log rules, dat maakt ze vrij nutteloos.

Voor wat betreft de fd-output van php5-fpm, jammer, ik dacht dat je daar het executed script wel uit kon vissen; niet dus.

Had je de access logs nu bekeken? De php-fpm log? Als daar niets staat, verhoog het log_level? Ook interessant in de php-fpm configuration manual, alle directives met betrekking tot slowlog - daar kun je de boosdoener vast wel mee achterhalen.

adis schreef op maandag 23 februari 2015 @ 09:27:
Je zit op DigitalOcean met je server, krijg je ook vanuit DO ondersteuning hierin? Of heb je dat niet gevraagd?

Die bieden alleen unmanaged services aan geloof ik.

[TVH7]

Gebruik eens dit tooltje om te kijken of je server kwetsbaar is voor een DNS amp. attack.

https://isc.sans.edu/dnstest.html

[johnkeates]

Je draait ISPConfig, maar je draait geen website? Dat is niet heel logisch.

Draai anders even rkhunter en clamav om bekende payloads te vinden, en zet je firewall aan?

[Anoniem: 647586]

johnkeates schreef op maandag 23 februari 2015 @ 15:03:
Je draait ISPConfig, maar je draait geen website? Dat is niet heel logisch.

Draai anders even rkhunter en clamav om bekende payloads te vinden, en zet je firewall aan?

Hey,
Daar was ik niet zo duidelijk mee.

Ik bedoel dus dat ik ispconfig draai. Elke website heeft een eigen directory en socket.
Maar als je NGinx installeert dan is ook een default socket en directory (dus als je naar het ip van de server surft, dat is de default website). En die is leeg (enkel een html paginatje)

[Anoniem: 647586]

adis schreef op maandag 23 februari 2015 @ 09:27:
Je zit op DigitalOcean met je server, krijg je ook vanuit DO ondersteuning hierin? Of heb je dat niet gevraagd?

Zij stelden voor om mijn server te sinkholen of me te verdiepen in hun forums.
Met andere woorden dus een "spijtig, maar het is jouw probleem" antwoord.
Langs ene kant wel begrijpelijk want het is zoals iemand hier aanhaalde unmanaged hosting.

[ Voor 12% gewijzigd door Anoniem: 647586 op 24-02-2015 16:53 ]

[Anoniem: 647586]

TVH7 schreef op maandag 23 februari 2015 @ 14:50:
Gebruik eens dit tooltje om te kijken of je server kwetsbaar is voor een DNS amp. attack.

https://isc.sans.edu/dnstest.html

Handige tool!

Gelukkig niet vatbaar.

"Good. your name server refused the query"

[Anoniem: 647586]

Thralas schreef op maandag 23 februari 2015 @ 13:50:
[...]


Gezien je een nameserver op :53 draait, gok ik dat het wel eens een poging tot DNS amplification kan zijn. Maar dstportinformatie ontbreekt in die log rules, dat maakt ze vrij nutteloos.

Voor wat betreft de fd-output van php5-fpm, jammer, ik dacht dat je daar het executed script wel uit kon vissen; niet dus.

Had je de access logs nu bekeken? De php-fpm log? Als daar niets staat, verhoog het log_level? Ook interessant in de php-fpm configuration manual, alle directives met betrekking tot slowlog - daar kun je de boosdoener vast wel mee achterhalen.


[...]


Die bieden alleen unmanaged services aan geloof ik.

Hey, bedankt voor de info.

Ik ga me eens verdiepen in de php-fpm configuratie. Ik ben maar een ICT student die dit als hobby doet, dus ik ben blij dat ik van jullie deze feedback krijg om me te verbeteren.

Ik zal eens de log-levels verhogen, moest de aanval nog eens gebeuren, dat ik betere logs heb.

Is het nadeel hiervan dat je server trager wordt? (meer logs, meer schrijfwerk, hoog cpu gebruik voor logs?)

[Equator]

Wist je dat je je eigen post (als je de laatste poster bent en je informatie toe wilt voegen) kunt wijzigen? NU lijkt het steeds alsof je je eigen topic omhoog aan het schoppen bent, iets wat we liever niet zien.

[DonnieDoezoe]

Misschien een wasstraat ervoor gooien a la cloudflare ofzo