Bekijk Volledige Versie : Server beveiliging
Beste WHT'ers,
Ik ben op dit moment bezig om te kijken hoe we onze hosting omgevingen beter kunnen monitoren met betrekking tot de beveiliging. Ik ben de applicatie OSSEC tegen gekomen. Hebben jullie hier positieve ervaringen mee? Hebben jullie nog andere applicaties die ik kan gebruiken?
Alvast bedankt!
- Welk OS/Dsitro?
- Welk control panel?
- Firewall?
Heel basic een aantal punten:
- Je kan bijvoorbeeld heel simpel root logins monitoren, ik krijg bij iedere root login een automatisch e-mail.
- Een aparte /tmp partitie -> beveiligen!
OS: Redhat ES5.4
Control panel: DA
Ik gebruik nu al rkhunter en chkrootkit
Ik zal de vraag omdraaien: weet jij wat er gebeurt op je platforms?
Nee? => RKH en CHk zijn daar al een goed begin van, maar heb je ook controle over je mailque, hoe draait PHP, wat gaat er over SSH. Zomaar om wat op te noemen....
Ik denk dat ik dat wel weet. Onze queue en andere services monitoren we, ssh is alleen toegankelijk vanaf bepaalde ip adressen. Maar om het nog beter te monitoren/beveiligen ben ik altijd op zoek naar extra tools daarom de vraag in deze thread.
Heb ik nog geen ervaring mee. Ik ga er naar kijken.
Ik mis in het hele verhaal WAT je precies wilt monitoren. En welk monitoring platform gebruik je?
Dingen die je bijvoorbeeld met Nagios zou kunnen monitoren:
- is de /tmp partitie noexec?
- Draaien er perl processen (betekend vaak niks goeds op DirectAdmin servers, behalve awstats)
- bevat de /tmp partitie perl scriptjes
- ....
Ik gebruik Nagios om dit te monitoren. Omdat een paar websites van ons gehackt zijn ben ik op zoek naar een systeem wat ook de log bestanden kan monitoren. Ik kwam het IDS systeem OSSEC tegen maar omdat ik hier geen ervaring mee heb wilde ik hier vragen of de mensen van WHT hier wel ervaring mee hebben.
Ik gebruik Nagios om dit te monitoren. Omdat een paar websites van ons gehackt zijn ben ik op zoek naar een systeem wat ook de log bestanden kan monitoren. Ik kwam het IDS systeem OSSEC tegen maar omdat ik hier geen ervaring mee heb wilde ik hier vragen of de mensen van WHT hier wel ervaring mee hebben.
Logfiles kun je ook prima monitoren met Nagios... je kunt kijken of een bepaalde check al bestaat, en anders zul je zelf aan de slag moeten in bash. Maar dat is de kracht van Nagios..
Ik gebruik Nagios om dit te monitoren. Omdat een paar websites van ons gehackt zijn
Monitoren is leuk (en noodzakelijk), maar weet je ook al hoe wat er gehacked is?
Wat -> PHP, FTP, MySQL?
Hoe -> Brakke scripts, slechte (PHP) configuratie?
het lijkt mij nuttig dit eerst te achterhalen (logfiles lezen) dan te monitoren)
Helemaal mee eens.
In dit geval was het een slecht php script. Ik zag verschillende scripts codes in de httpd access log(bijv. ../../../../../../script). Daarom ben ik op zoek naar een applicatie die de bekende soort codes/scripts monitoort in de logs.
Helemaal mee eens.
In dit geval was het een slecht php script. Ik zag verschillende scripts codes in de httpd access log(bijv. ../../../../../../script). Daarom ben ik op zoek naar een applicatie die de bekende soort codes/scripts monitoort in de logs.
Dan heb je de log, maar heb je dan de bron / oorzaak aangepakt?
Of wil je met de monitoring wachten op de mail / sms en dan ingrijpen? (dweilen met de kraan open).
Ik snap je beredenering namelijk niet helemaal...
Wouter-Ospito
20/12/09, 20:51
- Draaien er perl processen (betekend vaak niks goeds op DirectAdmin servers, behalve awstats)
Euhh...SpamAssassin? Lijkt me (als je dat niet op een dedicated bak draait, wat ik niet vermoed bij TS) toch ook geen onbelangrijk perl proces. Daarnaast kunnen klanten natuurlijk ook gewoon Perl scripts uploaden en draaien. E.e.a. kan je natuurlijk wel afvangen wat ze daar wel of niet mee mogen/kunnen doen. Simpelweg zeggen dat Perl processen die draaien vaak niks goeds betekend, is m.i. wat kort door de bocht.
Voor TS lijkt deze website mij een goed begin: http://help.directadmin.com/item.php?id=247
Voor de rest zal het toch vooral aankomen op zelf logisch nadenken wat eventuele kwaadwillende mogelijk zouden kunnen bereiken op welke manieren en wat je daar dan weer tegen kan doen. Serverbeheer is niet iets wat je er even bij doet als je hier geen ervaring in hebt, zeker niet als je het goed en veilig wilt doen. Dan kan je m.i. beter iemand elke maand een paar tientjes betalen, die het beheer (voornamelijk onderhoud/updates) voor je doet, en bij eventuele incidenten op uurtarief voor je kan werken.
fail2ban http://www.fail2ban.org/wiki/index.php/Main_Page is meschien ook wel iets voor je dan
Euhh...SpamAssassin? Lijkt me (als je dat niet op een dedicated bak draait, wat ik niet vermoed bij TS) toch ook geen onbelangrijk perl proces. Daarnaast kunnen klanten natuurlijk ook gewoon Perl scripts uploaden en draaien. E.e.a. kan je natuurlijk wel afvangen wat ze daar wel of niet mee mogen/kunnen doen. Simpelweg zeggen dat Perl processen die draaien vaak niks goeds betekend, is m.i. wat kort door de bocht..
Mijn opmerking over DirectAdmin/perl processen was ook geen "alleen en uitsluitend awstats" opmerking ;) Er draaien er vast wel wat meer, echter kun je natuurlijk met een whitelist werken bij je check.. spamd / awstats.pl en misschien nog wat andere kunnen daarin.. mocht een klant een keer een legitiem perl script willen draaien dan krijg je daar een melding van, perl proces even controleren en zonodig opnemen in de whitelist.
(wij hebben geen klanten die perl processen draaien en bij alle bedrijven waar wij server management voor doen draaien er ook geen buiten de gebruikelijke)
Misschien dat Configserver CSF nog een idee is, een onderdeel hiervan heet LFD, wat je een email zal sturen als een script en/of programma te veel vooraf ingestelde recources gebruikt.
systemdeveloper
08/04/10, 19:32
Ik zou sowieso nooit op 1 ding rekenen. Wij hebben ossec gewoon naast dingen zoals nagios, antispam, firewalls, virusscanning e.d. draaien.
Voor 1 server is dat goed te doen, maar dat zal je standaard op een dag wel een paar false-positives opleveren. Als je 100 servers hebt kom je dan alsnog om in de mail.
OSSEC is (bij dat aantal) dan prettig om 'erbij' te hebben omdat zijn notifications lekker makkelijk te parsen zijn. Zo kun je op basis van ossec's rules en levels eenvoudig automatisch acties ondernemen zoals een ip sitewide in de firewalls gooien van alle servers die aan de ossec main server gekoppeld zijn.
Leuk voor erbij dus :)