vServer absichern?

M

m0rphin

Well-known member
ID: 332664
L
24 Juni 2008
94
4
Hex leute,

Ich habe einen vServer, welcher bisher nur durch fail2ban abgesichert ist. Allerdings eigne ich mir gerade weitedtgehend iptables an, dabei faellt mir des oefteren auf, dass teilweise einige module fehlen wie z.B. Ip_conntrack_ftp usw..

Bedteht dennoch die moeglichkeit den Server dennoch vernuenftig abzusichern? Desweiteren, gibt es noch ne alternative zu iptables?

Bisher schien ein Scanner, namens dfind, den vserver nach luecken zu durchsuchen, das konnte ich ganz gut mit fail2ban einschraenken.

Evtl. Kennt sich damit ja jemqand aus. Gruss
 
google t00ls (da gibts glaub ich 2 davon) drüberlaufen lassen.

Dauert aber glaub ich 6-8h :D

Dann siehst du genügend Schwachstellen.:mrgreen:
 
-> Kernel rel. aktuell halten
-> PHP-SuHoSin / mod-security2
-> Snort
-> knockd
-> HINTERHER SEIN!!! (hab meinen aus Zeitgründen auch n Stück lang vernachlässigt, bis er einen Abuse-Lock wegen "auffälligen Verhaltens" bekommen hat :ugly:)
 
Hi,


such dir jemand der dir das macht, wenn man keine Ahnung davon hat, sollte man lieber die Finger weglassen. Ich bau ja auch kein Haus nur weil ich weiss, dass man Mörtel und Steine braucht.

Sich mit fail2ban und iptables auf einem vserver schützen zu wollen, geht zu 99,9999% am Thema vorbei.

Entweder du willst dich vor Bots schützen die nach Exploits suchen, dagegen hilft regelmäßiges patchen und ein entsprechender Umgang mit der Software.

Vor DoS Angriffen kann man sich generell nicht schützen.
Wenn das Host-System ein 100mbit Interface hat und mit 200mbit Bandbreite verstopft wird wird, dann bringt dir kein iptables und auch kein fail2ban was.
Da kann höchstens dein Provider den Verkehr droppen wenn er sein Netz erreicht. - Sofern er nicht von Hause aus ein Konzept hat, das solche DoS verhindert.

Bei einem vServer kommt noch dazu, wenn der Kollege rechts oder links von dir (bildlich gesprochen) das Opfer ist, reicht dein vServer ihm die Hand und geht mit unter.


Ich nutze auf meinem vServer iptables um Verbindungen aus sämtlichen Asia Netzen zu droppen, das blockt zwar 80-90% der spam und exploit bots, hat allerdings eher den Hintergrund, Ressourcen und Traffic zu schonen, als mich vor irgendwas zu schützen.
 
1. System updaten

Sehr wichtig: als erstes das System updaten. Auch wenn Ihr eine Vorinstallation vom Provider habt, die aktualisieren ihr Template nicht alle 2 Wochen, sondern etwa alle 2 Monate, wenn überhaupt. Deswegen, updaten! Sofort!

Wie das geht, ist von Distribution ("Marke" des Linux Systems) unterschiedlich, bei

Debian: apt-get update dann apt-get dist-upgrade
SuSE: YaST benutzen
Andere: RPM benutzen und damit neue Pakete installieren oder lest in Euren Handbüchern zur jeweiligen Distribution nach.

2. SSH gegen Angriffe absichern, Teil A: root Login verbieten

Damit kein Scriptkiddie über SSH Euer root Passwort knackt, solltet Ihr von vorneherein den Login mit root über SSH verbieten. Folgende Schritte ausführen:

Erstmal neuen Benutzer anlegen:

useradd Name

"Name" sollte natürlich nicht "admin", "login", "ssh" oder so was sein, das würde ja keinen Sinn machen. Am besten den eigenen Vornamen, oder "Firmen"namen oder was weiss ich, etwas, worauf man nicht so schnell kommt.
Testen, ob Ihr mit dem User per SSH reinkommt, sonst sperrt Ihr Euch aus! Und Kennwort festlegen:

passwd Name

und dann den Anweisungen auf dem Bildschirm folgen.
In der Datei sshd_config (meist unter /etc/ssh) die Zeile

PermitRootLogin yes

ändern in

PermitRootLogin no

Jetzt probieren, ob Ihr noch mit "root" reinkommt. Wenn Ihr noch weiter reinkommt, den Server mal neu starten, das ist am einfachsten ;-) Alternativ könnt Ihr den SSH service selbst neu starten bzw. die Konfiguration neu einlesen lassen.

Ab jetzt könnt Ihr Euch mit dem neuen Benutzer einloggen (der soweit ja keine Rechte hat und damit eher ein Dummy ist). Mit dem Befehl

su -

könnt Ihr zum root-Benutzer wechseln, dabei müsst Ihr dann natürlich das Root-Passwort eingeben!



3. SSH gegen Angriffe absichern, Teil B: Auf Protokoll 2 umsteigen

In der Datei sshd_config (meist unter /etc/ssh) folgende Zeile ändern (wenn Euer Provider das nicht gemacht hat):

Protocol 1

wird zu

Protocol 2



4. SSH gegen Angriffe absichern, Teil C: Nach X Versuchen bannen

Am besten aussortieren, wenn der jenige gerade angreift, deswegen sowas wie fail2ban installieren.
https://www.fail2ban.org/

Hier eine Installationsanleitung: https://www.fail2ban.org/wiki/index.php/MANUAL_0_8



5. Ports absichern

Die Firewall sollte so konfiguriert sein, dass nur die Ports offen sind, die Du brauchst, d.h. alles sperren außer SSH, FTP, Web, POP/SMTP Ports.

Am besten geht das bei vServern (wenn Euer Provider Virtuozzo verwendet) über die Virtuozzo Firewall. Dort haben sie Euch einige Konfigurationen vorgegeben, einfach erstmal die Standardumgebung nehmen und unter "Regel hinzufügen" / "Regel entfernen" die Ports freigeben, die gebraucht werden. Unter Virtuozzo sind die dann auch schön beschriftet mit "Web server" und "SSH login" usw.

Ansonsten: Klassisch per iptables.



6. "Sicherheitssoftware" installieren

Da gibt es einige Softwares, ich selbst mag chkrootkit, rkhunter und clamAV ganz gerne, deswegen rede ich jetzt mal über die ;-)

Mit chkrootkit und rkhunter könnt Ihr prüfen, ob jemand in Eurem System Software installiert hat, mit denen man den Server steuern kann. Das funktioniert ähnlich wie ein Trojaner. Mehr dazu in der Wikipedia: https://de.wikipedia.org/wiki/Rootkit

Unter Debian z.B. wird das so installiert:
apt-get install chkrootkit
apt-get install rkhunter

ClamAV ist ein kostenloser Virenscanner, den einzurichten ist etwas "kniffliger" für Unwissende und würde den Rahmen dieses Tutorials sprengen. ClamAV gibts bei www.clamav.org



7. Die Programme am besten per Cronjob ausführen

Das sichert einfach, dass Ihr so früh wie möglich von einer Infektion erfahrt und reagieren könnt. Ich habe selbst ein kleines Shell Script zusammengebastelt, welches Ihr gerne benutzen dürft. Es führt ClamAV aus (der dann die Verzeichnisse /root, /home und /tmp scannt), chkrootkit und rkhunter -- und mailt Euch dann die Logfiles.

--> E-Mail Adresse ersetzen, und ggf. die Logfile Pfade ändern. Der Ordner muss exisitieren, die Dateien selbst werden dann erstellt, wenn das Script ausgeführt wird (nach Datum sortiert).

Code:

#!/bin/sh

### LOG FILES PFADE ###
logfile1=/var/log/security/chkrootkit_scan_`date +%y%m%d`.log
logfile2=/var/log/security/rkhunter_scan_`date +%y%m%d`.log
logfile3=/var/log/security/clamav_scan_`date +%y%m%d`.log

### E-MAIL EMPFAENGER ###
[email protected]

### CHKROOTKIT ###

/usr/sbin/chkrootkit > $logfile1
cat $logfile1 | mail -s "chkrootkit !TREFFER!" $email


### RKHUNTER ###
/usr/bin/rkhunter --update >> /dev/null
/usr/bin/rkhunter -c --cronjob --quiet >> $logfile2
cat $logfile2 | mail -s "rkhunter !TREFFER!" $email


### CLAMAV ###
clamscan -r --quiet -l $logfile3 /home /root /tmp
cat $logfile3 | mail -s "ClamAV-Scan REPORT" $email

Abspeichern als "checkrootkit.sh" in einem beliebigen Ordner (und die Rechte natürlich so setzen, dass der Cron darauf zugreifen kann!! sonst wird das script nicht ausgeführt!), und danach in die Konsole eintippen:

crontab -e

Im folgenden Fenster dann eingeben:

0 3 * * * /pfad/zur/datei/checkrootkit.sh

(/pfad/zur/datei natürlich ersetzen!) Dann wird das Script morgens um 3 Uhr täglich ausgeführt. Wem das mit dem ClamAV Scan zu lange dauert, der kann das auch einfach rausnehmen. Ich mache es einfach, die Ressourcen opfere ich gerne.

--> nicht vergessen, dass ClamAV sich über freshclam auch regelmäßig updated, sonst ist das für die Wurst <--
 
Guten Morgen,

DeDiHosting schrieb:
nginx is mit ~2,5mb ram-verbrauch für 10k connections mehr wie sparsam und da der apache sich nicht mehr mit langsamen connections rum ärgern muss, werden auf einem gut besuchten webserver die apache-prozesse um einiges nach unten gehen.
Zum Vergrößern anklicken....

Hehe, damit benutzt du allein für dein nginx als Load Balancer soviel RAM wie ich für meinen Webserver. Bitte vergiss nicht, dass das Thema hier ein vServer war.
Deine Zahlen klingen übrigens sehr nach
https://blog.webfaction.com/a-little-holiday-present
Im Text findet sich dieser Satz:
"This benchmark is not representative of a real-world application because in my benchmark the web servers were only serving a small static file from localhost".
Das Beispiel mit den 10000 simultanen Verbindungen mit 1KByte Größe scheitert in meinem Fall bereits daran, das 10MByte/s an Bandbreite nötig wären + Header und mein vServer nicht über die 8MB/s drüber kommt. Unabhängig davon, dass Webseiten im Schnitt zw. 50 und 120kbyte groß sind und eine 1kbyte große statische Datei diesbezüglich keine Aussagekraft hat.

DeDiHosting schrieb:
wieviel ram man dadurch spart weil nicht mehr sinnlos viele apache-prozesse gespawnt werden, kann sich jeder selbst ausrechnen. grad auf einem vserver ist das sehr interessant. vorallem merkt man selbst nicht, dass nginx dazwischen hängt, ich würd sogar sagen, der komplette webserver-zugriff is dadurch gefühlt schneller geworden.
Zum Vergrößern anklicken....

Da kann ich nichts zu sagen, da sich diese Probleme mir nicht stellen. Ich habe auch nicht soviele simultane Verbindungen, dass ich nginx als LoadBalancer vor meinen Webservern brauche. Wie gesagt, knapp 3 MB RAM verbraucht er und konfiguriert ist er um maximal 250 Requests parallel abzuarbeiten. Das ganze in einem einzelnen Prozess. Dahinter hängt ein einzelnes PHP Backend mit 3 Childs, die sich alle 25000 Requests flushen um den Speicher zu schonen.

DeDiHosting schrieb:
und ich garantiere dir, dass mein nginx-setup aktuell gegen diverse botnet-angriffe effektiv schützt. würd sogar fast sagen, das mein wissen dazu gold wert ist, denn außer bissl last am proxy interessiert es den host überhaupt nicht wenn da was angeflogen kommt.
Zum Vergrößern anklicken....

Kann sein, bzw. ich kann mir ersteres vorstellen, habe noch keinen Botnet Angriff erlebt, nur das typische Rauschen.
Das dir jemand dafür Gold gibt kann ich mir jedoch garnicht vorstellen.

Ich kann da leider auch allgemein nicht mithalten, mein vServer ist eher klein, 256MB RAM hab ich + 768MB shared RAM und 10GB HDD (Dafür kostet er mich im Jahr nur 32€).
Ich nutz ihn auch nicht ausschliesslich als Webserver. Mysql, smtp, pop3, imap und dns server laufen da noch drauf.

DeDiHosting schrieb:
zum thema per "iptables" ganze länder aussperren. das mach ich direkt mit nginx und geoip, is sicher performanter wie alle pakete durch 100mio iptables-chains laufen zu lassen. frag mich grad: wie hast du bitte komplett den asia raum gebannt, das sind riesige bereich oder hast du einfach stumpf ganze /8 netze gedropped? :D
Zum Vergrößern anklicken....

Ich sehe nicht, wo dein Performance Vorteil ist, wenn du alle 7 OSI Schichten nutzt und zusätzlich eine ~1mbyte Datei (+ GeoIP-Modul?) im Speicher halten musst, bevor du mit ihnen was anstellst, wenn das auch schon in Schicht 3 mit einem 1kbyte kleinen Script beim Start des vServers passieren kann.

Natürlich habe ich auf /8 gedropt. Als Referenz habe ich die Datenbank von IANA genutzt. Sind im Moment 42 IPv4 Netze, die laut der IANA komplett von APNIC verwaltet werden. Ergo 42x /sbin/iptables -A INPUT -s XY/8 -j DROP.
(ich weiss das sind nur ~700Mio. IP's, IPv6 hat keine Priorität)

Aber es ging mir garnicht darum, dich zu kritisieren, sondern dem TE zu vermitteln, dass mehr nötig ist als nginx/fail2ban zu installieren und das man sich mit solch merkwürdigen Gebilden oftmals mehr ins Knie schiesst als alles andere.

@muenchner1989 Der Guide ist klasse, jeder der seinen vServer nicht nutzen, sondern nur angucken will, sollte diesen Guide benutzen.


*Kaffee schlürf*
 
DeDiHosting schrieb:
trau dich und setz ihn mal davor, wenn du fragen zur config hast kannst mich ja mal in einem der messenger adden ;)
wenn du auf debian lenny setzt, musst du das teil aber aus den sourcen compilen da in den repos nur die 0.6.x ausgeliefert wird.

grad wenn du so "geil" drauf bist das netzrauschen raus zu filtern. kannst mit nginx direkt $useragents, $referers, $uris etcpp filtern/blocken.
Zum Vergrößern anklicken....

Hey,

ich finds ja klasse das du von nginx so begeistert bist, aber ich bin nicht in der Situation, dass ich einen Proxy vor meinem Webserver brauche.
Die Tatsache das ein vServer stark begrenzte Ressourcen hat, macht ihn allgemein für derlei Angriffe verwundbar.

Übrigens ist der Lighty ebenbürtig gegenüber nginx(sogar ein wenig performanter bei dynamischen Inhalten) und eignet sich auch wunderbar als Load Balancer ohne extra Apache dahinter.

Bei mir hängt kein Konzept hinter, dass es nötig macht, dass der Webserver nicht DoS'd wird. Vielmehr benötige ich ein Konzept, dass wenn Dienst A angegriffen wird, Dienst B davon möglichst unbeeinflusst ist. Dein Konzept, wenn Dienst A angegriffen wird, muss Dienst A weiterhin erreichbar sein, benötige ich nicht, möchte ich aufgrund der mir zur verfügung stehenden Ressourcen auch nicht realisieren. Einen vServer gegen DoS Angriffe schützen zu wollen ist auf der Ebene des vServers nur schwer machbar. Da hilft es in erster Linie nur, Dienste so zu begrenzen wie sie benötigt werden. So gehe ich nicht davon aus, wirklich mal 250 Parallele Requests auf meinem Webserver zu haben, rechnerisch vertrage ich sie locker. Mein MySQL ist derzeit sogar auf nur 30 parallele Sessions eingestellt. Aber ich weiss, das wenn es mal dazu kommen sollte, ich mit meinen 256MB RAM und den 768MB flex locker über die Runden komme, wahrscheinlich reichen die 256MB sogar.

Ich würde sogar die Thesen aufstellen, das in den meisten Fällen einer DoS auf einen vServer der Hoster oder die anderen Guests die Täter sind. - Ob gewollt oder ungewollt.


Grüße
 
k40073 schrieb:
Hey,

------- schnipp----
Ich würde sogar die Thesen aufstellen, das in den meisten Fällen einer DoS auf einen vServer der Hoster oder die anderen Guests die Täter sind. - Ob gewollt oder ungewollt. Grüße
Zum Vergrößern anklicken....

falsch,

der hoster hat kein interesse seine ressis für ddos zu verbraten. punkt.
bei ddos auf server ist man normalerweise "opfer" und nen ddos täter möchte sich nicht selber schaden :) ergo .... xD.

denke hier werden wieder paar sachen durcheinander gemüllt. wenn du mit (betrifft vorposter) nginx ddos verhindern kannst, dann biste ein genie :) und ich werde dein kunde, spar ich mir doch so, mehrere hundert euro für hardware firewall :)

schau mal ins wikip. erreicht ddos den server ist es scheissegal was du filtern möchtest -- iss eh zu spät und alles lahmgelegt -- nur der provider (rz betreíber) kann die datenflut noch filtern -- aber in 90% der fälle schalten die einfach den server off und fettich :)

gruss tyy
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben