vServer absichern?

[m0rphin]

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

[Hotwave]

root-login per ssh deaktiviert?

[m0rphin]

Ja ebenso anderen Port gewählt.

[mar.the.eng]

google t00ls (da gibts glaub ich 2 davon) drüberlaufen lassen.

Dauert aber glaub ich 6-8h

Dann siehst du genügend Schwachstellen.

[TerraTux]

-> 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 )

[DeDiHosting]

wenn ein apache webserver läuft würd ich dringlichst nginx als reverse-proxy davor hängen. hilft eventuell ankommende ddos attacken effizient zu filtern, sprech aus erfahrung

[k40073]

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.

[DeDiHosting]

hehe, dass man physikalische gesetze aushebeln kann ist ja wohl klar bzgl deiner 200mbit vs 100mbit. da reichen auch schon 110 Mbit, wenn die Leitung voll is, isse voll.

aber nginx entlastet den apache ungemein und wenn man sich mit den filter-möglichkeiten von nginx auskennt, kann man damit sehr wohl syn-floods oder http-floods sehr effektiv rausfiltern, und zwar so, dass am apache davon erst garnichts ankommt und php/mysql die maschine nicht zum kochen bringen können.

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.

mein webserver hatte vorher im schnitt 50 apache prozesse im tagesmittel, in den peaks über 120 gespawnte und nach dem zwischenschalten von nginx warens nurnoch 1-3.
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.

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 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?

[muenchner1989]

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.
http://www.fail2ban.org/

Hier eine Installationsanleitung: http://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: http://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=deine@adresse.tld

### 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 <--

[Darklord]

@muenchner19890: Wenn man schon etwas kopiert dann bitte mit Quellenangabe.

Quelle: http://www.netvision-technik.de/foru...ead.php?t=2457

[k40073]

Guten Morgen,

Zitat von DeDiHosting

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.

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
http://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.

Zitat von DeDiHosting

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.

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.

Zitat von DeDiHosting

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.

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.

Zitat von DeDiHosting

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?

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]

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...

ok wir reden hier gerade wirklich in anderen dimensionen. der host ist bei mir ein i7-920 mit 12GB DDR3 Ram, den jucken die 1mb relativ überhaupt nicht.
sagt ja auch keiner, dass du das geoip dort verwenden musst

du scheinst ja scho fit zu sein was dein server betrifft, aber wie du selbst schreibst hattest du noch kein (d)dos. ich bin selbst mit mehreren erfolgreichen gaming projekten aktiv und ein eigenes Hosting betreibe ich auch und es gibt da wohl leute die sich so über mich freuen, dass ich alle paar wochen einen mehr oder weniger heftigen ddos abbekomme. dagegen muss man sich und seine kunden einfach schützen und ein apache am netz ist leider die denkbar schlechteste lösung. les dich mal zB in "slowloris" ein bzgl apache. wenn man weiß wie kriegt man jeden apache mit einem uralten 28,8er modem downgelegt. dagegen ist nginx von haus aus imun und spätestens dann machst du dir gedanken was du dagegen tun kannst.
http-get/post-floods sind auch so eine liga, die bringt dann nicht nur den apache auf hochtouren sondern mysql dreht auch auf maximum. aber das kann man mit dem rewrite-modul auch rausfiltern.

und joa wie gesagt, die apache prozesse vor dem nginx einbau waren bei ~40 und peaks bei über 120 prozessen. die sind mit nginx auf max 10 runtergegangen, einfach aus dem grund weil der apache nicht mehr die verbindungen selbst verwalten muss. nginx spricht den apache erst an wenn der client die verbindung zum proxy aufgebaut hat.

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.

ich sag dir, nginx ist genial und du solltest dir die zeit mal nehmen und dir das teil anschauen. gehst ja auch vorbeugend zum zahnarzt und nicht erst wenns kind in den brunnen gefallen ist

genug deppen gibts leider auf der welt die einem hier und da ans bein pinkeln wollen und nginx ist wie ein kleiner schutzwall vorm webserver. schadet auf jeden fall nicht.

aber zurück zum thema, der threadersteller sollte sich vllt jemanden suchen, der sich damit auskennt

[k40073]

Zitat von DeDiHosting

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.

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

[tyygoor]

Zitat von k40073

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

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

[DeDiHosting]

Zitat von tyygoor

f... 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 :-)
...

über verhindern spricht garniemand, sondern von filtern. ich garantiere dir, dass der ddos nur ein wenig cpu am nginx verbraucht wenn die bots in den filter laufen und außer einem direkt closen der verbindung keinerlei info erhalten. solang bandbreite und cpu verfügbar ist, ist das garkein problem. habs oben schon gesagt, physik kann man nicht außer kraft setzen und bei ddos muss man zumindest zwischen leicht, mittel und stark unterscheiden, denn es macht einen immensen unterschied ob 50, 500 oder 5000 bots angeflogen kommen.

und ein apache direkt am netz steigt mit genau einem bot schon aus: slowloris. aber nginx ist imun gegen syn-flood und solang die bandbreite nicht vollgepumpt wird juckt das nicht.. und auch gegen http-flood hab ich eine lösung gefunden. man muss sich den traffic nur anschauen, dann kommt man vllt selbst drauf. -.- und solang die kiddies nicht raffen was sie falsch machen, könne die ruhig ihre bots verheitzen, freu mich über jede mail die vom anti-syn oder anti-http geschickt wird. "false-positives" kommen sonst nur von yandex.ru

sicher hat man mit einer hardware-firewall mehr möglichkeiten, vor allem weil man die last nicht direkt am host hat. und auch dort würde ich zwecks load-balancing und filtermöglichkeiten einen reverse-proxy (nginx) aufsetzen. oder willst du port 80 einfach stur forwarden? dann hilft dir die firewall auch nicht weiter. auch hilft dir deine firewall nicht, wenn der uplink vor der firewall nicht entsprechend dimensionert ist. denn dann erschlägt dich auch die physik, wenn 100mbit voll sind, sind sie voll. da hilft dann nur ein switch auf gbit oder den hoster drum bitten, die bösen ips direkt am uplink zu filtern.

denke du weißt schon worauf ich hinaus will