CentOS DDoS aanval bescherming

[Gideonnn]

Ik heb sinds een half jaar een VPS gehost bij Tilaa.nl om een Teamspeak server op te hosten en wat te experimenteren met PHP/Javascript/Linux, je kent het wel. Omdat ik een best flinke Linux noob ben is het vaak maar guides volgen om de commando's een klein beetje te leren kennen. Hierdoor zijn er denk ik nogal wat beveiligingsproblemen. Mijn VPS wordt namelijk gebruikt om DoS/DDoS aanvallen mee te uit te voeren. Dit is ondertussen de derde keer dat ik gemaild word door Tilaa dat er dus vanuit mijn VPS aanvallen worden gedaan.

Op dit moment draait er niet zoveel: namelijk een Teamspeak server, apache, php 5.3, vsftpd en msql-server. De laatste keer heb ik mijn website niet online gezet (dus alleen teamspeak geinstalleerd) en toen leek er niks aan de hand te zijn. Nu ik een wordpress website gehost heb is het weer raak.

Na de laatste keer laat ik vsftpd niet meer draaien, ik gebruik hem alleen 5 minuten wanneer ik een plugin wil installen in wordpress. Ook heb ik dit keer niet meer dan nodig is aan alles geprobeerd, denk aan rechten enzo. Ook is alles up to date.

Toch wil ik graag een VPS blijven hosten, het liefst ook veilig. Alleen heb ik geen idee waar ik moet beginnen of zoeken om alles wat ik heb op een goede manier te hosten zodat niemand er zomaar bij kan. Iemand een goude tip/uitleg hoe ik hiermee aan de slag kan?

[Sjoq]

Doen zij zelf nog wel iets aan actieve monitoring?

Wellicht zal je mysqld op een andere poort moeten gaan draaien dan de standaard poort? apache ook?

Draaien ze geen maldet (http://www.rfxn.com/projects/linux-malware-detect/) deze tool hebben wij (hosting provider) draaien om shared hosting actiever te kunnen monitoren en klanten te kunnen waarschuwen zodra er iets gevonden is dat niet klopt.

[sh4d0wman]

Ik denk dat het probleem in je experimenteren zit. Alle zaken die jij noemt zijn erg vatbaar voor exploitatie als er fouten in gemaakt worden en/of niet geupdate worden. Misschien is het slimmer om eerst gewoon eens binnen VMWare een Linux host op te tuigen en alles op uit te proberen op je interne netwerk. Wat is de reden dat je graag een VPS gebruikt?

[Gideonnn]

Nou, ze merken wel dat er dus iets mis is, want ze zetten mijn VPS uit zodra het merkbaar is dat er DoS attacks mee worden gedaan. Ze kunnen alleen niet veel zeggen omdat dat met privacy te maken heeft.

Wel kreeg ik dit:

Beste Gideon,

We zien een UDP flood uitgaan vanuit je server naar 96.49.---.--- op poort
53:

EBT UDP FLOOD IN=vnet10 OUT=vlan1 MAC source = --:--:--:--:--:-- MAC dest
= --:--:--:--:--:-- proto = 0x0800 IP SRC=46.19.--.--- IP
DST=96.49.---.---, IP tos=0x00, IP proto=17 SPT=48539 DPT=53

Kun je aangeven wat er gaande is? Dit lijkt op een uitgaande DDoS aanval.


Dat was het mailtje wat ik vannochtend kreeg. Heb ip's ed even aangepast.


Edit: Ik snap wel dat het heel gevoelig is en kon het me ook wel voorstellen, maar dit keer heb ik dus weinig geexperimenteerd en gewoon draaiend gemaakt, klaar. Blijkbaar is dit dus niet genoeg. Ook denk ik dat het in vmware wel te doen is, maar daar wordt ik niet veel wijzer van behalve dan de commando's snappen. Ik wil graag leren hoe het werkt omdat ik er waarschijnlijk mn brood mee moet gaan verdienen.

[ Voor 23% gewijzigd door Gideonnn op 30-07-2012 18:45 ]

[xares]

Sjoq schreef op maandag 30 juli 2012 @ 18:27:
Doen zij zelf nog wel iets aan actieve monitoring?

Wellicht zal je mysqld op een andere poort moeten gaan draaien dan de standaard poort? apache ook?

Draaien ze geen maldet (http://www.rfxn.com/projects/linux-malware-detect/) deze tool hebben wij (hosting provider) draaien om shared hosting actiever te kunnen monitoren en klanten te kunnen waarschuwen zodra er iets gevonden is dat niet klopt.

Hij heeft een eigen unmanaged VPS, dus ik ga er vanuit dat hij alles zelf moet installeren.


Kijk even of er geen gekke scripts draaien met top of ps -aux

De meeste hacks bij onze unmanaged VPS klanten komen voor door een simpel wachtwoord op het root account, welkom of Welkom01 bijvoorbeeld.

Teamspeak draait neem ik aan ook onder een eigen user en niet als root?

[Gideonnn]

Nee, het wachtwoord is gegenereerd door Tilaa zelf en zou dus secure moeten worden beschouwd, ik zal hem eens veranderen. Ja teamspeak heeft een eigen user, maar met wel een relatief simpel wachtwoord. Die user is wel default, dus ik neem aan dat het niet zo veel rechten heeft. Voor de rest gebruik ik voor ftp wel de root user omdat ik een snelle fix nodig had, maar die heeft in totaal maar 10 minuten aan gestaan.

Ik zal het commando eens proberen. Als ik in de log files ga kijken, waar moet ik op letten? Nog nooit gedaan trouwens en aangezien ik niet weet waar het probleem zit heb ik geen idee waar ik naar mij moet kijken.

Geen idee of er nou iemand access heeft tot mijn Tilaa account, of root user op de server zelf, of dat het via een exploit gebeurd.

[Bastien]

Wat staat er in /var/log/auth.log (of was dat in CentOS /var/log/secure?)? Daar worden dacht ik alle inlogpogingen (al dan niet gelukt) gelogd, mogelijk dat je daar wat uit kunt halen.

Ik schakel inloggen rechtstreeks inloggen met root altijd uit, altijd weer een kleine hindernis... maar ook niet meer dan dat.

WordPress moet je wel altijd uptodate houden, zeker ook plugins. Daar zitten nog wel eens lekjes in. Verder zou je met iptables (http://wiki.centos.org/HowTos/Network/IPTables) alles dicht kunnen zetten wat je niet gebruikt en vervolgens alles open zetten wat nodig is. Let wel op dat je jezelf niet buitensluit

[ik222]

Je weet zeker dat het account voor teamspeak (met een simpel wachtwoord) niet stiekem gewoon een shell heeft en root kan worden?

Ik lees namelijk een hoop aanames maar daar heb je niet zoveel aan.

[Gideonnn]

@Bastien, secure zo te zien. Zo te zien zijn er HEEL veel failed inlogs, met de raarste users door elkaar geprobeerd. Ik denk dus dat ze mijn root password geraden hebben.

@ik222, Geen idee, heb alleen 'useradd' en 'passwd' gebruikt voor dat account, hij draait ook alleen maar Teamspeak in screen.

[Bastien]

Nah, je moet je zorgen maken als er met een vreemd IP iets staat als 'Accepted password for root from %ip%'. Mogelijk kun je met |grep Accepted snel filteren, als dat in CentOS op dezelfde manier gelogd wordt (ik ken alleen Debian).

Ik heb ook tig pogingen per dag op sshd staan, dat zijn van die mislukte embryo's die niets beters te doen hebben. Ik kan poort 22 wel verkassen naar een andere poort, zie ik ze niet meer in de log. Maar ik ben lui

Je zou ook eens bijvoorbeeld rkhunter kunnen installeren en draaien. En verder... googlen en leren. Alles is al wel eens uitgevonden en te vinden, zo leer je een boel bij.

[Gideonnn]

Ja ik kan het meeste ook wel vinden en krijg het vaak wel voor elkaar, maar dan krijg je dus dit soort dingen! Ben hem nu maar weer opnieuw aan het installeren om Teamspeak running te krijgen en misschien later weer eens proberen. Is het slim om van te voren misschien iets te installeren, vóór ik weer probeer apache e.d. werkend te krijgen, zoals bijvoorbeeld dat Rootkit Hunter?

[ik222]

Ik zou onderstaande dingen in elk geval meenemen. Let op dat dit enkel een opsomming is van wat belangrijke dingen zijn om aan te denken, hoe je alles moet doen kun je vast op google vinden

- Wijzig eerst je password bij je VPS host, just to be sure. Gebruik uiteraard ook voor de administrative user op je nieuwe installatie andere wachtwoorden dan eerst.
- Iptables goed configureren, zet alles default dicht en zet enkel het noodzakelijke open. Indien je server IPv6 heeft zul je ook ip6tables goed moeten configureren.
- Configureer SSH op een fatsoenlijke manier, sta bijvoorbeeld rootlogin niet toe. Overweeg ook om certificaten te gebruiken i.p.v. username / password login.
- Indien je een min of meer vast ip hebt scherm dan SSH af op enkel je eigen IP.
- Installeer geen ftp server, gebruik gewoon sftp (ftp via SSH)
- Installeer geen dingen als phpmyadmin of als je echt niet zonder kunt scherm die af op enkel je eigen ip (dat kun je in je apache config doen).
- Installeer Fail2ban en configureer die om na bijvoorbeeld 5 foute inlogpogingen een ip te blokkeren.
- Installeer iets om de server in de gaten te houden (bv. logwatch en rkhunter)
- Indien je weer Wordpress gaat installeren zorg dat de webdirectory rechten goed staan en niet op 777 omdat dat makkelijk is.

Als je bovenstaande dingen goed regelt dan ben je al een heel eind, ik denk dat je daarmee wel even aan de slag kunt. In elk geval is een server veilig configureren meer dan enkel alles erop gooien zodat het werkt

[ Voor 15% gewijzigd door ik222 op 30-07-2012 21:04 ]

[Gideonnn]

Wow nice! Dat zijn aardig wat dingen om naar te kijken. Zeker dat Fail2ban klinkt wel heel interessant. Iptables is ook iets om naar te kijken, binnenkort maar eens de link van Bastien goed doorlezen. Ik gebruikte vsftpd, is dat sftp?

Bedankt voor de tips in ieder geval!

[webfreakz.nl]

http://www.cyberciti.biz/ daar staan handige tips.

[ik222]

Gideonnn schreef op maandag 30 juli 2012 @ 21:13:
Wow nice! Dat zijn aardig wat dingen om naar te kijken. Zeker dat Fail2ban klinkt wel heel interessant. Iptables is ook iets om naar te kijken, binnenkort maar eens de link van Bastien goed doorlezen. Ik gebruikte vsftpd, is dat sftp?

Bedankt voor de tips in ieder geval!

Sftp zit gewoon in de SSH server, daarvoor hoeft je niets anders te installeren.

[Kabouterplop01]

Bastien schreef op maandag 30 juli 2012 @ 20:28:
Nah, je moet je zorgen maken als er met een vreemd IP iets staat als 'Accepted password for root from %ip%'. Mogelijk kun je met |grep Accepted snel filteren, als dat in CentOS op dezelfde manier gelogd wordt (ik ken alleen Debian).

Ik heb ook tig pogingen per dag op sshd staan, dat zijn van die mislukte embryo's die niets beters te doen hebben. Ik kan poort 22 wel verkassen naar een andere poort, zie ik ze niet meer in de log. Maar ik ben lui

Je zou ook eens bijvoorbeeld rkhunter kunnen installeren en draaien. En verder... googlen en leren. Alles is al wel eens uitgevonden en te vinden, zo leer je een boel bij.

Met het commando "last" moet je ook kunnen zien wie er als laatste heeft ingelogd (en van welk ip adres)
Je logging is nu wel heel interessant (als die niet verwijderd is)
Eigenlijk wil je wel zien wat er is gebeurd op je systeem. Een uitgaande udp flood naar poortje 53 kan iets met een dns attack zijn. However jouw server kan nooit een DDoS doen. Het is tenslotte 1 server. Overigens wel goed dat je provider het ziet!

kijk eens wat er op je server openstaat:
netstat -rnv
daarmee zie je welke portjes aan de buitenkant open staan. (En met google kun je het e.e.a ontdekken, wat wat betekent)
Zo kun je wellicht ontdekken wat er vernaggeld is.
Of je moet gelijk actie willen/moeten ondernemen en je bak opnieuw installeren.
kijk dan hier eens naar:
http://wiki.centos.org/HowTos/SELinux/

kijk eens naar chrooted services.
kijk eens naar je hosts.allow en hosts.deny file en dat samen met eerder genoemde iptables. (al dan niet samen met fail2ban)
kijk ook eens hoe je sshd kunt dichtspijkeren enzovoortz
GL!

[webfreakz.nl]

Wat ik doe om mijn VPS te bereiken is het volgende:

- Alleen SSH access toestaan globally. Dit op een alternative port (niet de default 22), root access disabled.
- Alle overige services firewallen en je bekende IP addressen whitelisten.

Al mijn verkeer via SSH tunnelen. Bijvoorbeeld FireFox kan je door je tunnel heen laten connecten (proxy'en dus) en door naar het internet vanaf je VPS. Of als je het netjes wilt doen kan je OpenVPN installen.

[Gideonnn]

Hoe weet ik welke poorten ik wel en niet nodig heb? Ik kan namelijk wel alles dicht gaan gooien, maar dat lijkt me niet zo slim. Ook ga ik dat op andere poorten connecten denk ik maar eens nakijken, klinkt wel heel handig. Veel tips hier.

[Equator]

Een server maakt het topic niet meteen Professional Networking & Servers

Move naar Non-Windows Operating Systems

[igmar]

Gideonnn schreef op maandag 30 juli 2012 @ 18:38:
We zien een UDP flood uitgaan vanuit je server naar 96.49.---.--- op poort
53:

EBT UDP FLOOD IN=vnet10 OUT=vlan1 MAC source = --:--:--:--:--:-- MAC dest
= --:--:--:--:--:-- proto = 0x0800 IP SRC=46.19.--.--- IP
DST=96.49.---.---, IP tos=0x00, IP proto=17 SPT=48539 DPT=53

DIt is een DNS flood. Je draait waarschijnlijk named (of een andere DNS server), en je hebt recursion voor de buitenwereld aanstaan. Oplossing : Recursion uitzetten.

[igmar]

Gideonnn schreef op maandag 30 juli 2012 @ 19:32:
Nee, het wachtwoord is gegenereerd door Tilaa zelf en zou dus secure moeten worden beschouwd, ik zal hem eens veranderen.

Daarvoor hebben we al enige tijd SSH keys uitgevonden. Wachtwoorden zijn per definitie niet veilig.

Ja teamspeak heeft een eigen user, maar met wel een relatief simpel wachtwoord. Die user is wel default, dus ik neem aan dat het niet zo veel rechten heeft. Voor de rest gebruik ik voor ftp wel de root user omdat ik een snelle fix nodig had, maar die heeft in totaal maar 10 minuten aan gestaan.

Zet voor dat soort users de shell account uit : /sbin/nologin, en draai dat soort zaken via su / sudo. Als je dat te lastig vind : beperkt SSH access tot bepaalde gebruikers, en heeft die gebruikers su rechten tot dat account.


Ik zal het commando eens proberen. Als ik in de log files ga kijken, waar moet ik op letten? Nog nooit gedaan trouwens en aangezien ik niet weet waar het probleem zit heb ik geen idee waar ik naar mij moet kijken.

[Speedfightserv]

draai eens

code:

 crontab -e -u apache

en kijk of hier een cronjob draait die een script start. Meestal flikken ze het zo.

ben zelf een keer phpmyadmin vergeten. Dit draaide wel op acceptatie maar niet op productie. Toen een kopie van acceptatie naar productie ging is phpmyadmin vergeten (ja enorm dom ik weet het ) week later zat er een cronjob de wereld te spammen. Ze uploade via phpmyadmin een nep png bestand en die lieten ze uitvoeren

[ Voor 55% gewijzigd door Speedfightserv op 31-07-2012 10:15 ]

[labmuisfrl]

Gideon,

Is je wordpress installatie up2date?
En wat voor addons/themes etc heb je geinstalleerd in wordpress ?

Ik heb vaak genoeg gezien dat een niet up2date wordpress de oorzaak is of een bug/vulnerabilitie in een 3rd party addon

[Hero of Time]

Kijk ook hoe je je PHP installatie kan dichttimmeren. Opties die mogelijk misbruikt kunnen worden, zijn bijvoorbeeld allow_url_fopen e.d. Ook session.cookie.httpOnly (oid) is een leuke optie. Let wel op, want je kan door php veiliger te maken Wordpress slopen. Het werkt dan niet meer omdat het een van de iets onveiligere functies gebruikt.

Overigens met dat crontab commando, het is wellicht makkelijker om te kijken of er crontabs zijn voor alle gebruikers, want wie weet is je teamspeak gebruiker niet gewoon misbruikt. Zie /var/spoo/cron voor alle crontabs van gebruikers. En dan is ook nog een system-wide crons in /etc/cron.<daily|weekly|hourly|monthly|d>.

[Verwijderd]

ik222 schreef op maandag 30 juli 2012 @ 20:57:
Ik zou onderstaande dingen in elk geval meenemen. Let op dat dit enkel een opsomming is van wat belangrijke dingen zijn om aan te denken, hoe je alles moet doen kun je vast op google vinden
- Indien je weer Wordpress gaat installeren zorg dat de webdirectory rechten goed staan en niet op 777 omdat dat makkelijk is.

Als je bovenstaande dingen goed regelt dan ben je al een heel eind, ik denk dat je daarmee wel even aan de slag kunt. In elk geval is een server veilig configureren meer dan enkel alles erop gooien zodat het werkt

Dat betekend dat alle mappen 755 moeten zijn en bestanden 644. Zet ook de groep en ownership goed van die bestanden.

Bekijk dan ook gelijk even of Apache wel onder een eigen gebruiker draait die niet de mogelijkheid heeft om in te kunnen loggen.

En installeer mod_security als je weet hoe dat moet doen.

[Kabouterplop01]

Gideonnn schreef op dinsdag 31 juli 2012 @ 02:49:
Hoe weet ik welke poorten ik wel en niet nodig heb? Ik kan namelijk wel alles dicht gaan gooien, maar dat lijkt me niet zo slim. Ook ga ik dat op andere poorten connecten denk ik maar eens nakijken, klinkt wel heel handig. Veel tips hier.

Ik vind het juist superslim om alles wat je niet nodig hebt dicht te gooien! Daarom moet je juist google gebruiken om alles dicht te gooien wat je niet nodig hebt

[Hero of Time]

Verwijderd schreef op dinsdag 31 juli 2012 @ 18:49:
[...]

Dat betekend dat alle mappen 755 moeten zijn en bestanden 644. Zet ook de groep en ownership goed van die bestanden.

Bekijk dan ook gelijk even of Apache wel onder een eigen gebruiker draait die niet de mogelijkheid heeft om in te kunnen loggen.

En installeer mod_security als je weet hoe dat moet doen.

Ik zou 't persoonlijk op 750 en 640 zetten, met owner:group op root:www-data. Hierdoor kunnen andere gebruikers er niet bij, dus als je een lek hebt in Apache en je kan dan iets laten uitvoeren door gebruiker teamspeak, heb je met 755 en 644 dat hij 't kan lezen, en ook uitvoeren!

Hoezo uitvoeren? De execute bit staat toch niet aan met 644? Klopt, je shell zal 't bestand niet direct uitvoeren. Maar als je dit in een bestand zet en 't met de shell interpreter uitvoert, werkt 't wel.

code:

#!/bin/bash
# hoi.sh
echo "Hello World!"

Met dit werkt 't dus niet:

./hoi.sh

Je krijgt dan "Permission denied". Maar doe je dit, dan werkt het wel:

bash hoi.sh

Dan heb je mooi "Hello World!" als uitvoer. Het verwijderen van de execute bit is dus geen volledige security maatregel.

[jb044]

@Sjoq goede tip, die kende ik nog niet!

[init6]

De vraag is: Wil je veel van deze applicaties wel draaien op je omgeving? phpmyadmin heb je dat echt nodig? Als de werkzaamheden via een cli ook gedaan kunnen worden installeer ik het niet. Als je goed met een CLI kan werken heeft een GUI achtige tool met webinterface zoals php myadmin geen meerwaarde. Je kan zo veel meer bereiken door eigen configuratie.

MBT SSH: Ik werk 90% enkel met certificaten, sommige omgevingen hebben ook een ip restrictie.

Veel van de tips die ik hier lees kreeg ik al als 1st hit bij google met de zoektermen: Secure my Centos server.