# ein vServer nach außen schützen?

## anime-otaku

Hallo gentoo Gemeinde,

da ich neu in der Server Welt bin wollte ich mich mal erkundigen, was es prinzipiell für Möglichkeiten gibt(also Denkanstösse), seinen (virtuellen!) Server gegen äußere Angriffe zu schützen. Nicht das mein Server irgendwann von jemand anderem in Besitz genommen wird.

Auf dem Server laufen bzw. sollen laufen:

- Apache(2) Webserver mit aktuellem phpBB 3 Forum

- ssh daemon natürlich

- Ajaxterm (shell, welches übern Browser erreichbar ist), welches mittels SSL und mod_proxy übern apache geht

- postgreSQL Server 8.2.7

- (real)VNC Server (falls man doch mal grafische Programme braucht)

- Tomcat

- Teamspeak Server

- FTP-Server

Da es sich um einen virtuellen Server handelt....bin ich natürlich etwas eingeschränkt (gerade wegen Kernel).

Ich würde mich auch bereit erklären, die Tips dann ins Gentoo Wiki zu packen (deutche und englische).

P.S.: Wie kann man bei nem vServer den noch verfügbaren Platzenplatz anzeigen lassen?^^....weil ein df findet nichts....abziehen über du?

----------

## DarKRaveR

Standardantwort: Alle deamons ordentlich konfigurieren und sichern, zweitens die eine oder andere netfilter-Regel.

Und natürlich ordentliche Passwörter wo welche verwendet werden.

Auf die schnelle vornweg zu ssh:

1.) nicht auf standardport binden (hält scripkiddies fern)

2.) keine root logins zulassen, user mit wheel anlegen, und von diesem su-en - macht bruteforce auf root zwecklos

3.) noch besser keine passwort logins sondern nur auth mit key

4.) netfilter rule mit recent um den port des ssh zu schützen, wenn du von einer bestimmten IP kommst, noch besser, dann beschränken auf diese (egal ob via netfilter oder allow list)

Natürlich regelmässig updaten.

VNC hat ja eine nette Vergangenheit bezüglich exploits etc., am besten auf eine nicht öffentliche ip binden, die in einem vpn liegt, da kannst du eventuell auch den ssh rein legen (man ist ja paranoid).

Und wie gesagt, brav die Dokus lesen und richtig konfigurieren, das hält ne MEnge schlimmer finger fern, kritisch sind natürlich sachen wie phpBB bzw. Applikationen auf dem Tomcat, dir nutzt die beste planung nichts, wenn eine (Web)applikation ein Scheunentor aufreißt.

----------

## schachti

Außerdem: hardened-gcc verwenden (am besten gleich das hardened-Profil), hardened-sources nutzen und grsecurity entsprechendkonfigurieren. Die ganzen technischen Maßnahmen helfen aber nicht gegen die Sicherheitslücke Mensch.

----------

## DarKRaveR

Ich muß gestehen, ich habe mich immer vor grsecurity gescheut, andererseits habe ich auch keine fremden shell user auf meinen Servern.

Was ich allerdings für unverzichtbar halte: ACL statt UID/GID Dateirechte ...

Achja, die besten PolicySysteme sind natürlich nutzlos, wenn die Policies nicht in Ordnung sind, wo wir wieder beim Thema Mensch wären.

----------

## anime-otaku

 *schachti wrote:*   

> Außerdem: hardened-gcc verwenden (am besten gleich das hardened-Profil), hardened-sources nutzen und grsecurity entsprechendkonfigurieren. Die ganzen technischen Maßnahmen helfen aber nicht gegen die Sicherheitslücke Mensch.

 

Das hört sich schonmal interessant an...auch wenn ich nicht weiß, ob ich das hardened Profil verwenden kann....ist halt ein vServer. grsecurity werde ich mir mal anschauen.....aber das sind doch patches für den Kernel wie ich gelesen hab...bringt mir leider nichts, da man bei einem vServer keinen Einfluss auf den Kernel hat. (zumindest gehe ich bisher davon aus).

aber was macht hardened-gcc gegenüber dem normalen gcc? Ist er einfach pingeliger was mögliche Sicherheitsfehler angeht und/oder macht er die binarys auch sicherer?

Bezüglich ssh:

Ich hab das Problem, dass Ajaxterm über ssh(lokal) eine Shell aufbaut und ich weiß nicht so recht, ob man das so einfach umbauen kann....bzw...lasst sich scheinbar der ssh Port zu dem sich ajaxterm verbindet nicht ändern (nach nem Forumbeitrag).

Ich werde eh überlegen, ob ich nicht ajaxterm weglasse.....ist zwar net, dass man von überall auf den Server zugreifen kann....aber der sshd ist halt dadurch ungeschützter.

Bestanden Sicherheitsprobleme mit VNC nur für realvnc oder auch für die anderen?...tightvnc usw.?

Als "Firewall" welche die Eingehenden Ports abcheckt...ist doch IpTables das richtige?...hoffentlich kann ich das hier benutzen

----------

## Knieper

 *DarKRaveR wrote:*   

> Was ich allerdings für unverzichtbar halte: ACL statt UID/GID Dateirechte ...

 

Sehe ich nicht so. Er hat eigentlich ein recht einfaches Anwendungsschema, solch komplexe Rechte bringen ihm nichts. KISS gilt auch hier.

 *Quote:*   

> Achja, die besten PolicySysteme sind natürlich nutzlos, wenn die Policies nicht in Ordnung sind, wo wir wieder beim Thema Mensch wären.

 

Eben, am besten gleich weglassen.

Und vor allem - such Dir die richtige Software aus! Quark wie Ajaxterm, vnc, Tomcat gleich weglassen. Sftp nur wenn wirklich notwendig und Teamspeak... nunja. Mal sehen wie phpbb3 abschneidet, momentan scheint es ja bugtechnisch ganz gut zu laufen - bleibt aber immer noch php. Wenn Du postgres nur dafuer brauchst, muss es natuerlich nicht nach aussen zur Verfuegung stehen.

----------

## anime-otaku

Das mit den ACL finde ich auch eher übertrieben.

 *Quote:*   

> Und vor allem - such Dir die richtige Software aus! Quark wie Ajaxterm, vnc, Tomcat gleich weglassen. Sftp nur wenn wirklich notwendig und Teamspeak... nunja.

 

Was ist gegen Tomcat einzuwenden?...oder solls gleich ein Applicationserver a la JBoss sein? Ich meine irgendwas in der Richtung werde ich später brauchen, um meine JSP Seiten darstellen zu können

 *Quote:*   

>  Mal sehen wie phpbb3 abschneidet, momentan scheint es ja bugtechnisch ganz gut zu laufen - bleibt aber immer noch php. Wenn Du postgres nur dafuer brauchst, muss es natuerlich nicht nach aussen zur Verfuegung stehen.

 

phpBB benutze ich einfach, weil jforum vom Funktionsstand bei weitem noch nicht so weit ist. Naja ist momentan alles noch im Aufbau...und ja momentan ist der Postgres Server nur für das Forum da....mal schauen, vielleicht wechsel ich doch zu jforum^^.

Achja was ich noch fragen wollte....braucht man einen eigenen Mailserver, um Mails unabhängig vom Server verschicken zu können?

----------

## schachti

 *anime-otaku wrote:*   

> grsecurity werde ich mir mal anschauen.....aber das sind doch patches für den Kernel wie ich gelesen hab...bringt mir leider nichts, da man bei einem vServer keinen Einfluss auf den Kernel hat. (zumindest gehe ich bisher davon aus).

 

Stimmt natürlich - bringt nur was bei einem "normalen" Server, bei dem Du Einfluß auf den Kernel hast.

 *anime-otaku wrote:*   

> aber was macht hardened-gcc gegenüber dem normalen gcc? Ist er einfach pingeliger was mögliche Sicherheitsfehler angeht und/oder macht er die binarys auch sicherer?

 

Der kompiliert automatisch mit Unterstützung für Stack Smashing Protection und Position Independent Executables. Mehr dazu findest Du unter http://www.gentoo.org/proj/en/hardened/. Offiziell ist der Support bei gcc-3.4.x stehen geblieben. Man kann aber auch einen aktuellen 4.x gcc patchen, siehe https://forums.gentoo.org/viewtopic-t-668246.html.

 *anime-otaku wrote:*   

> Als "Firewall" welche die Eingehenden Ports abcheckt...ist doch IpTables das richtige?...hoffentlich kann ich das hier benutzen

 

Eine Firewall ist in der Regel unnötig. Und ich weiß nicht, ob Du auf einem vServer Firewallregeln verwenden kannst.

----------

## SvenFischer

Also ich kann auf meinem vServer den Kernel nicht austauschen.

dieses Script zeigt Dir den tatsächlichen RAM Zustand an:

```

#!/bin/bash

x=$(cat /proc/user_beancounters |grep privvmpages|awk 'BEGIN{ cur=max=lim=0; }{ cur+=$2;

max+=$3;lim+=$5 } END {print cur*4/1024,max*4/1024,lim*4/1024}')

zugesichert=$(cat /proc/user_beancounters |grep oomguarpages|awk 'BEGIN{ cur=max=lim=0; }{ lim+=$4 } END { print lim*4/1024}')

momentan=$(echo $x| awk '{print $1}')

maximalgenutzt=$(echo $x| awk '{print $2}') maximalnutzbar=$(echo $x| awk '{print $3}')

echo "VPS Speichernutzung:"

echo "Momentan genutzt: $momentan MB"

echo "Zugesichert: $zugesichert MB"

echo "Maximal nutzbar: $maximalnutzbar MB"
```

----------

## DarKRaveR

 *Knieper wrote:*   

>  *DarKRaveR wrote:*   Was ich allerdings für unverzichtbar halte: ACL statt UID/GID Dateirechte ... 
> 
> Sehe ich nicht so. Er hat eigentlich ein recht einfaches Anwendungsschema, solch komplexe Rechte bringen ihm nichts. KISS gilt auch hier.
> 
> 

 

Okay, da mögen die Meinungen auseinandergehen, aber ich bevorzuge es, wenn webroots dem root user gehören und dann dem Apache nur explizit die Dateirechte gegeben werden, die er braucht, wäre er owner, kann er chown+chmod+overwrite fabrizieren, aber vielleicht bin ich zu paranoid   :Wink:  . Andererseits habe ich eh ein sehr spezifisches Setup ... Es kann sich aber wirklich lohnen ACLs zu verwenden.

----------

## Daimos

Also ich hab auch nen vServer und bin nicht 100% glücklich, dass ich keinen eigenen Kernel (hardened Sources) verwenden kann. Ich bin halt dem Anbieter ausgeliefert und muss darauf setzen, dass mein 2.6.18-xen anständig geconft ist. Weiterhin muss auch die dom0 (oder wie auch immer der "Wirt" läuft) vernünftig gemacht sein - ich hatte mal ein paar Tage nen vServer, wo /etc/passwd die login Daten von allen (!) vServer Benutzern enthielt. Das waren so um die 35 und ich gehe davon aus, dass das bei den anderen auch so war, was mich zu ner Sonderkündigung bewogen hat.

Frag mal beim Support nach, ob Du die Kernel-Module bekommen kannst, dann gehts auch mit iptables. Bei meiner Schüssel ging das auf Anfrage. 

Sinn und Unsinn eines Paketfilters:

Dagegen spricht, dass Du die Ports, wo ein Dienst läuft ohnehin auf machen musst und die Ports, wo nix läuft grundsätzlich auch nicht gedropt werden müssen. Die "Sicherheit" der offenen Ports liegt also in ner sauberen Config - mit oder ohne iptables. Dafür spricht, dass Du beispielsweise einzelne IPs komplett sperren kannst, ich halte mir damit besonders hartnäckige Spammer und Scriptkiddiez vom Hals. Als "Antwortmöglichkeit" nett, aber imho nicht wirklich zwingend.

Ein hardened Profil kostet etwas Leistung, aber das ist nix tragisches. Lohnt sich meiner Ansicht nach schon, weil Dir das schon einiges vom Leib hält, was stack buffer overflows angeht. Mich lässt es jedenfalls ruhiger schlafen.

SSH mäßig stimme ich meinen Vorrednern zu, einfach auf irgendnen Highport legen und root login verbieten. Hält brutefoce Angriffe ab und reicht für die meisten Scriptkiddiez schon aus, um es nicht weiter zu versuchen. Außerdem hält das die Logs sauberer. Key Auth ist mir zuviel Hantier, da ich öfter mal auf verschiedenen Kisten auf die Gurke drauf muss.

Anwendungen wie den Apachen oder nen Mailserver kann man (für ganz paranoide) in nen chroot einsperren. Jail ist das Stichwort, nach dem Du googeln solltest, ich hab mich damit nicht wirklich intensiv befasst.

Logs sind dafür da um gelesen zu werden, und zwar auch schon im laufenden Betrieb, und nicht erst, wenn etwas passiert ist. Dann solltest Du noch die Pakete immer aktuell halten, um Sicherheitslücken aufzufangen. Gerade bei Webapps ist das imho wichtig, weil die schon mal ein paar Lücken haben. 

Mit chkrootkit und rkhunter kann man auch ab und an mal nach rootkits suchen, ich mach das per cron.

100% Sicherheit gibt es nicht, aber wenn alles sinnvoll eingerichtet ist, dann sollte es ausreichen, dass ein Scriptkiddie irgendwann die Lust verliert und sich ein "weichereres" Ziel sucht.

----------

## Knieper

 *anime-otaku wrote:*   

> Was ist gegen Tomcat einzuwenden?

 

Der Ressourcenverbrauch und die Bugliste.

 *Quote:*   

> ...oder solls gleich ein Applicationserver a la JBoss sein?

 

Noe, am besten alles ohne das grosse J.

 *DarKRaveR wrote:*   

> 
> 
> Okay, da mögen die Meinungen auseinandergehen, aber ich bevorzuge es, wenn webroots dem root user gehören und dann dem Apache nur explizit die Dateirechte gegeben werden, die er braucht, wäre er owner, kann er chown+chmod+overwrite fabrizieren, aber vielleicht bin ich zu paranoid

 

Wieso hat er nicht nur Leserechte ueber die Gruppe und warum sollte root sich um Netzinhalte kuemmern?

----------

## Jorgo

Hi,

zusätzlich solltest Du OSSEC installieren.

http://www.ossec.net

Hierdurch werden die Hosts von Angreifern bei mehrmaligen Login versuchen temporär gesperrt.

Anleitung zu sshd Einrichtung:

http://wiki.hetzner.de/index.php/SSHd_Howto

----------

## DarKRaveR

 *Knieper wrote:*   

> 
> 
>  *DarKRaveR wrote:*   
> 
> Okay, da mögen die Meinungen auseinandergehen, aber ich bevorzuge es, wenn webroots dem root user gehören und dann dem Apache nur explizit die Dateirechte gegeben werden, die er braucht, wäre er owner, kann er chown+chmod+overwrite fabrizieren, aber vielleicht bin ich zu paranoid 
> ...

 

Im Prinzip hat er nur Leserechte und execute (wo nötig) via ACL. Ob  der Owner nun root oder ein ander user ist, ist erstmal egal (solange nicht apache), ich habe aber leider andere dienste, die auch lesen können müsen oder teilweise schreiben und ich wollte ungern alle dienste in eine gruppe packen   :Wink:  . Ich sage ja, verzwickter Fall.

----------

## TheSmallOne

 *DarKRaveR wrote:*   

> Auf die schnelle vornweg zu ssh:
> 
> 1.) nicht auf standardport binden (hält scripkiddies fern)
> 
> 2.) keine root logins zulassen, user mit wheel anlegen, und von diesem su-en - macht bruteforce auf root zwecklos
> ...

 

Also an und für sich würde ich doch sagen, dass Punkt 3 (und ggfl. Punkt 2) völlig ausreichend ist.

Wenn Zugang nur mit Key möglich ist, dann können sich die Scriptkiddies solange sie wollen die virtuellen Zähne an dem Ding ausbeißen, und ein Einschränken der IP ist dann m.E. auch unnötig. Das einzige was vielleicht nervt ist, wenn das Log mit Fehlermeldungen geflutet wird, aber mit dem richtigen Filter erscheinen die auch nicht mehr.

----------

## DarKRaveR

@TheSmallOne:

Es war etwas ungünstig formuliert - das sollte nich bedeuten alles gleichzeitig zwingend sei, daher sagte ich auch noch besser nur key auth - ich habe da wohl den fehler gemacht den Rest dazuzudenken und nicht hinzuschreiben, weil es mir 'klar' erchien, daß dadurch andere sachen tenenziell hinfällig werden würden.

Andererseits kann man auch wirklich alles zusammen mchen, wenn man denn mag - Das iptables+recent hälft übrigens das log flooding in Grenzen Anzeigefilter hin oder her und bietet zusätzlichen schutz  :Wink:  (Auch wenn ich nicht glaube, das jemand eine brute force Schlüselsuche veranstalten würde).

----------

## blu3bird

 *anime-otaku wrote:*   

> P.S.: Wie kann man bei nem vServer den noch verfügbaren Platzenplatz anzeigen lassen?^^....weil ein df findet nichts....abziehen über du?

 

```
echo "/dev/vzfs / unknown rw,usrquota,grpquota 0 0" >> /etc/mtab
```

danach sollte df funktionieren.

----------

