Onderwerp: Compilers Linux, Gehacked en beveiligen

Hallo Mensen,

Hoe ik dit bericht moet beginnen weet ik nog niet precies, onze server is vorige week gehacked en dus schrijf ik maar wat ik allemaal wil vragen, ik heb het forum al doorgespit maar wordt er nog niet veel wijzer van.

De eerste vraag is, er is ons verteld dat waneer de compilers verwijdert worden uit linux(server) er dan geen executeble gestart kan worden, het enige nadeel is dat de machine niet geupdate kan worden, is het mogelijk om compilers te verwijderen (als beveliging) en waneer er een update dient plaats te vinden deze tijdelijk terug te plaatsen.
Kan iemand mij hier meer over vertellen en evetueel ook of een provider dit eigenlijk standaard zou moeten doen ?

Tevens de vraag of je een Redhat machine kunt updaten zonder compilers ?

Dan vraag 2 :

De machine die wij draaien heeft een raid systeem, nu is het zo dat ten tijde van de hack dus allebei de schijven platgelegd zijn, nu was mijn idee, om die 2e schijf niet meer als raid te installeren, maar 1 malig een complete ghost van schijf 1 te maken en dan handmatig 2x per week een deel van de schijf te kopieeren, en dan wel het deel waar alle users zich in bevinden, mail users, webcontent....etc.
Is dit mogelijk, heeft iemand hier ideeen over of ervaring mee ?

Op de server draait:
Linux Redhat 9.0
Appache 2.0
php 4.3.2
gd 2.01

Verders hoop ik hier op de volgende vragen ook iets meer antwoordt te krijgen:
Is het mogelijk om via php scripts (website) een Anonymous FTP Deamon op te starten of moet er daarvoor ergens anders een lek zitten ?

Volgens zeggen zou het een bekend probleem zijn dat de appache er af en toe uit knalt waneer er beveiligde mappen worden aangemaakt op de machine (de conf. Plesk/linux zou hiervan een beetje over haar touren raken)
Weet iemand hier iets over en waar dit eventueel aan kan liggen ?

Ik hoop dat jullie ons verder kunnen helpen om deze puzzel op te lossen en welke stappen we moeten/kunnen ondernemen om het de volgende keer te voorkomen, tevens hoop ik dat wij met dit onderwerp anderen er op attenderen goed op te letten dat dus gaten/lekken zijn waarmee men je server plat kan leggen

Groetjes en alvast bedankt voor de hulp
Jeroen

Ps. Hier een link volgen naar het bestand dat op de server werd gevonden en de vermoedelijk hack mee is uitgevoerd OF waarmee ze de server hebben laten klappen...
Rik-edit: Geen hack-files plaatsen hier !!
We willen je best helpen, maar niet op deze manier !
.... mischien verduidelijkt het iets en weet iemand waar de fout heeft gezeten.

Pps. mischien handig om te weten is dat wij verschillende sites op onze server draaien met een admin, men kan dus zelf aanpassingen doen aan de site, afbeelding toevoegen aan een agenda en dat soort zaken.

Hallo Jeroen,

Je kunt de compilers op 000 chmod'en, zodat geen enkele user de compilers meer kan gebruiken. De compilers staan in /usr/bin/

chmod 000 *c++ *g++ perlcc byacc yacc bcc kgcc cc gcc i386*cc
en
chmod 000 /usr/lib/bcc /usr/lib/bcc/bcc-cc1

Mocht je Redhat of Apache o.i.d. willen updaten, dan chmod je ze weer naar 700.
Maar een hacker kan ook de binary gebruiken i.p.v. de source.

Over vraag 2: zou een aparte backup server niet handiger zijn?

Beste jeroen_123,

Het is inderdaad zeer naar wat er gebeurt is.

Ik weet niet of ik ze helemaal goed beantwoord maar "I'll give it a shot" anders zal iemand mij vast wel hier corrigeren.

Antwoord vraag 1:

Compilers worden gebruikt om executables te bouwen, niet om ze te runnen.
Het verwijderen hiervan zorgt voor problemen met compilen van sources (tarballs).

Ik weet niet of RPM hier gebruik van maakt.

Antwoord vraag 2:

Als je de schijven MIRRORED hebt ingesteld zou bij het platgooien van 1 HD de andere alle DATA moeten bevatten nog.
Als door een hacker alle data word verwijderd van de 1e schijf, gebeurt dit naar mijn weten ook met de andere.

Een tip voor backup is om deze 2e HD erin te hangen en via een script laten mounten - Backup erop gooien - Unmounten.
Niet echt super veilig.

Verder zijn er prima backup systemen als Mondo Rescue voor Linux

http://www.mondorescue.com

Deze backuped je hele/gedeelte systeem naar een ISO die je dan kan laten fikken of rippen via FTP.

Antwoord vraag 3:

Via php een FTP server opzetten is denk ik vrij lastig en je kan eventueel zorgen dat bepaalde functies in php niet meegecompiled worden zodat zulke dingen in de praktijk niet mogelijk zijn.
Daarbij zal er bij "PHP Safe mode restriction" vrij weinig gebeuren met je server, maar meer met de files van de Virtual Hoster.

Antwoord vraag 4:

Over Plesk en beveiligde mappen weet ik niet al te veel hoe deze dat regelt, maar ik neem aan via de httpd.conf.
Hierdoor kan door een fout in de syntax de HTTPD server bij een Reload van de config plat gaan, omdat de config niet klopt.
Beste oplossing hiervoor zou zijn dat je deze optie in Plesk uitschakeld en de gebruikers zelf via .htaccess files dit laat oplossen.

Verder over het algemeen gewoon zorgen dat alle services (deamons) die draaien goed afgeschermd zijn van het systeem en dat ze uitgevoerd worden door gebruikers die geen of zeer weinig rechten hebben op het systeem.

Ik hoop dat dit je een beetje verder helpt.

Suc6

Origineel geplaatst door jeroen_123
Verders hoop ik hier op de volgende vragen ook iets meer antwoordt te krijgen:
Is het mogelijk om via php scripts (website) een Anonymous FTP Deamon op te starten of moet er daarvoor ergens anders een lek zitten ?

Een anonymous FTP daemon starten zal via PHP niet mogelijk zijn, of het script en je systeem moeten wel erg slecht geconfigureerd zijn. Wel is het mogelijk om een PHP script zo te misbruiken dat er binaries te uploaden en te runnen zijn vanuit bijvoorbeeld /tmp. Een connect-back shell bijvoorbeeld.
Zorg er voor dat je zaken zoals de save_mode van PHP aan hebt staan en dat processen als een aparte user (dus niet root) draaien.

Houdt ook je daemons, en als je shellaccess geeft je kernel, uptodate, er zijn in korte tijd erg veel vulnerabilities gevonden in verschillende daemons. 2003 was een erg slecht jaar wat dat betreft.

Vergeet niet je systeem volledig offline te halen, en herinstalleer het complete systeem. De data op je schijven is niet meer te vertrouwen, je moet 'from scratch' beginnen.

vraag 1:

als eventuele hackers een exploit willen compileren (bakken) op jouw machine, dan hebben ze access nodig tot de /usr/src directory, aangezien 99% van de scripts een aantal includes uit de kernel-sources nodig hebben. Als je de /usr/src chmod of een chown geeft naar de user die jij gebruikt om je software te updaten, dan heb je zelf altijd nog access tot die resources, maar eventuele andere users niet. Maar het hele gebeuren heeft geen zin als ze precompiled binarys op je systeem zetten.

Een hele andere aanpak voor dit probleem heb ik zelfgeschreven. Een kernel-module die ervoor zorgt dat bepaalde users rechten hebben tot compilatie van binarys. En nee dit is niet hetzelfde als een chmod mocht die vraag in je opkomen. De module filtert namelijk ook wat voor type bestanden gecompileerd worden. PM me maar voor meer info.

Mvg,

Daan Huijbregts
Foundry Engineer

Origineel geplaatst door dnh2
vraag 1:

als eventuele hackers een exploit willen compileren (bakken) op jouw machine, dan hebben ze access nodig tot de /usr/src directory, aangezien 99% van de scripts een aantal includes uit de kernel-sources nodig hebben.
[knip]

Helaas geldt dit niet voor RedHat omdat die z'n kernel includes gewoon in /usr/include gooit zonder een link naar /usr/src/linux/include....

Dit geldt denk ik zo'n beetje voor alle distro's.
Aangezien /usr/ voor elke gebruiker normaal toegangkelijk is.

Origineel geplaatst door jordy
Dit geldt denk ik zo'n beetje voor alle distro's.
Aangezien /usr/ voor elke gebruiker normaal toegangkelijk is.

dnh2 bedoelt dat het vaak zo geinstalleerd is dat /usr/include/linux symlinked naar /usr/src/linux/include etc.. Als je dan met chmod de rechten voor /usr/src aanpast kunnen de linux include files niet meer gevonden worden. Let wel: dit werkt alleen als het met een symlink gebeurt is. Een hard-link kan gewoon gevolgd worden omdat het alleen een extra verwijzing naar de i-node is en niet zoals met symlinks naar het bestand.