Onderwerp: Beter beveiligen OpenVZ Node/containers

Een bedrijf waar ik de servers (mede) voor beheer biedt VPS servers aan m.b.v. OpenVZ en SolusVM.

Dit gaat allemaal prima. Het is echter zo dat er regelmatig containers zijn die worden misbruikt door "hackers" die vaak dankzij zwakke root-wachtwoorden of andere "simpele" lekken van de clienten toegang weten te verkrijgen tot een container. De meest voorkomende problemen hierbij zijn spam, portscanners en zo nu en dan een DOS aanval (welke uiteraard allemaal niet zijn toegestaan op het netwerk waar deze servers worden gehost).

Door actief te monitoren, kunnen deze problemen vrij snel worden gedetecteerd en kan de container in kwestie handmatig worden afgesloten om verdere problemen te voorkomen.

Het blijft echter zo dat problemen pas kunnen worden opgelost wanneer de attacker al een tijdje bezig is met zijn ongewenste praktijken. Ik ben nu aan het onderzoeken of er een oplossing is om een container die vreemd gedrag vertoond automatisch tijdelijk uit te schakelen voor verder onderzoek en om te voorkomen dat er problemen ontstaan op andere containers en/of de hardwarenode. Onder vreemd gedrag versta ik dus bijvoorbeeld:

* Het openen van een absurd aantal connecties (port/rangescanners)
* Buitensporig veel traffic gebruiken op bijv. poort 25
* Binnenkomende traffic binnen krijgt die duid op een aanval (zo lang deze paketten geforward worden door de node kan deze ervoor zorgen dat alle containers onbereikbaar worden)

Ik weet dat hiermee niet alle problemen op te vangen zijn, en dat de bron van de problemen uiteindelijk ligt in zwak beveiligde containers. Het is echter zo dat deze unmanaged zijn, en het dus onbegonnen werk is om alle containers te controleren op eventuele beveiligingsrisico`s.

Leuk en aardig, maar is dit niet een beetje mosterd na de maaltijd?

Lever de server op met passwordauthenticatie uit en geef klanten een SSH key. Op deze key zet je ook weer een password, zodat toegang alleen mogelijk is met iets dat je hebt en iets wat je weet. Als dit te moeilijk is, draai eventueel SSHd op een andere poort en installeer bij een openstaande poort 22 zeker iets als een lokale firewall (CSF) of op zijn minst denyhosts.

Dit gaat je niet helpen tegen exploits in Joomla of andere software, maar hier weet je NIDS je wel weer tegen te beschermen. Iets simpels als een Snort doos en je uplink mirroren op je switch en wat updates/lijsten met bekende exploits is voldoende om hier makkelijk mee verder te kunnen.

Als klanten geen fatsoenlijk password kunnen verzinnen moet je gewoon de uplink doorknippen. Dat zal ze leren.

Maar ok... snort of ossec doosje erbij is ook 'leuk'... (In feite is dat hetzelfde als 'actief monitoren' en dat doe je al (zeg je) dus het zal weinig extra's toevoegen. Hooguit dat je zelf minder actief gaat monitoren
Ik zou kiezen voor een betere beveiliging.

Oorspronkelijk geplaatst door systemdeveloper

. Hooguit dat je zelf minder actief gaat monitoren
Ik zou kiezen voor een betere beveiliging.

Ik licht dit er even uit, dit spreekt elkaar een beetje tegen, ik krijg bij sommige klanten namelijk het gevoel dat ze denken dat als je beveiligingsmaatregelen doet, dat je dan veilig bent.

Er zijn een hele boel maatregelen die overal geadviseerd worden die schijnveiligheid creeren, een firewall is leuk, tot dat de klant denkt dat updates dan niet meer nodig zijn, hoor nu heel veel dat ze hun (uitgaande) spams door lekke scripts tegen willen gaan door spf records.

Het eerste wat ik dacht bij "zwakke rootpasswords" was initieel ook "ssh als root uitzetten", dus ik betrap mezelf er ook op.

Servers die gehacked of misbruikt kan je nooit helemaal voorkomen, ik denk wel dat de meeste winst te halen valt bij het opvoeden van klanten.

Oorspronkelijk geplaatst door vDong

Servers die gehacked of misbruikt kan je nooit helemaal voorkomen, ik denk wel dat de meeste winst te halen valt bij het opvoeden van klanten.

+1
Het probleem ligt niet bij jou, maar bij de klant. Mocht het voorkomen dat je last krijgt van een geinfecteerde klant doordat die bijvoorbeeld aan het portscannen is, dan offline halen en/of de software verwijderen. Maar, dit hangt uiteraard er van af wat je hebt afgesproken met de klant.

Oorspronkelijk geplaatst door Yourwebhoster

+1
Het probleem ligt niet bij jou, maar bij de klant. Mocht het voorkomen dat je last krijgt van een geinfecteerde klant doordat die bijvoorbeeld aan het portscannen is, dan offline halen en/of de software verwijderen. Maar, dit hangt uiteraard er van af wat je hebt afgesproken met de klant.

Wat +1?

Oorspronkelijk geplaatst door systemdeveloper

Als klanten geen fatsoenlijk password kunnen verzinnen moet je gewoon de uplink doorknippen. Dat zal ze leren.

Maar ok... snort of ossec doosje erbij is ook 'leuk'... (In feite is dat hetzelfde als 'actief monitoren' en dat doe je al (zeg je) dus het zal weinig extra's toevoegen. Hooguit dat je zelf minder actief gaat monitoren
Ik zou kiezen voor een betere beveiliging.

Hierop +1

Ik zou het eerder voor een andere benadering kiezen; schakel over op Virtuozzo (de betaalde versie van openVZ). Je hebt dan veel meer en betere resource management en monitoring.

Uiteraard is enkel deze overstap niet voldoende, je zal alles ook goed moeten beheren, waar vooral ook veel ervaring bij komt kijken.

Verder lost dit de perikelen van de zwakke beveiliging natuurlijk niet op, dat zou op ieder willekeurig platform problemen geven. In een unmanaged omgeving zou je dit het beste kunnen oplossen door de VPS's voor oplevering te beveiligen (waarbij iedere VPS ongeveer hetzelfde is en je dus een image zou kunnen maken) - waarbij je kunt denken aan het installeren/configureren van een firewall, mod_security, uitschakelen van gevaarlijke PHP functies, beveiligen van /tmp, enzovoorts.

Misschien kun je met Xen ook iets doen? Of is dit een no-go voor jullie?

Installeer Ntop op de server dan kan je al het e.a. monitoren.

Is het een optie om zelf een systeem er bij voor te hangen als firewall die bijvoorbeeld uitgaand poort 25 gesloten heeft en vervolgens een mailrelay (smarthost) gratis aan te bieden aan de klanten? Op deze mailrelay kun je kijken wat het gemiddeld aantal emails per dag is dat een VPS verstuurd en dat keer 2 doen en dat als limiet instellen. Bovenstaande is te automatiseren (zelfs met uitzonderingen voor bepaalde klanten die bijvoorbeeld meer mogen versturen of geen last van de poort blokkade hebben).

Verder kun je icm snort (of iets vergelijkbaars) de firewall die ervoor staat automatisch updaten bij bepaalde (potentiële) problemen en meer sluiten. SSH geforceerd op een andere poort dan 22 draaien kan dan natuurlijk ook (poort 22 sluiten).

Oorspronkelijk geplaatst door T. Verhaeg

Misschien kun je met Xen ook iets doen? Of is dit een no-go voor jullie?

Het nadeel is dat dit een nogal omvangrijke migratie zou vereisen, terwijl een migratie van openVZ naar Virtuozzo zeer eenvoudig te realiseren is. Het is hetzelfde soort systeem, waarbij Virtuozzo dan een stuk uitgebreider is (maar dit heeft geen invloed op de migratie).

Veranderen van het type virtualisatie helpt ook verder niet aan de lekke security die op de vm's zelf staan. Het enige voordeel dat je kan halen is het beperken van resources per vm maar het probleem wordt hierdoor niet opgelost. Beetje het princiepe geef een man een vis en hij kan 1 dag eten, leer hem vissen en hij heeft voor de rest van zijn leven eten. Conclusie biedt managed diensten aan of beperk de unmanaged diensten zoals hier al bescheven met een algmene firewall, smarthost smtp en andere shared diensten onder eigen beheer. Nu niet om direct conclusie te trekken, maar is het ook niet dat de doelgroep waarop je mikt gevoelig is voor dit probleem of het juist aantrekt.

Oorspronkelijk geplaatst door Apoc

Het nadeel is dat dit een nogal omvangrijke migratie zou vereisen, terwijl een migratie van openVZ naar Virtuozzo zeer eenvoudig te realiseren is. Het is hetzelfde soort systeem, waarbij Virtuozzo dan een stuk uitgebreider is (maar dit heeft geen invloed op de migratie).

Ken Virtuozzo zelf niet, dus daar moet ik je dan maar gelijk in geven.

Bedankt voor de reacties.
Ik ben nu aan het bekijken of ik een oplossing kan maken met Iptables, PSAD en Snort.

Het gaat aardig, maar als iemand hier toevallig goede documentatie over heeft liggen is dit uiteraard zeer welkom

Die hebben toch allemaal uitgebreide documentation pages op hun betreffende project?