Ubuntu Server Hardening

10/31/2015 12:14 Ares#1
Hi,
Ich suche alle möglichen Tipps / Tools zu Server Hardening auf Ubuntu 14.04 (außer SSH).
Gibt es noch mehr Möglichkeiten außer mod evasive und mod security? Inwiefern ist Verschlüsselung sinnvoll, AV-Programme, BastilleLinux usw.
10/31/2015 14:28 Zypr#2
Grüß dich,

zu SSH hätte ich aber noch was. Du könntest noch Portknocking oder besser, SPA (Single Packet Authorization) nutzen, um dich vor 0-Day Attacken zu schützen. Wenn zu es ganz sicher haben möchtest, dann kannst du auch noch eine 2-factor authentication nutzen. Sprich nachdem du dich am SSH-Server erfolgreich angemeldet hast, kommst du erst richtig rein, wenn du den Code eingibst (Funktioniert ohne zentrale Stelle, direkt über deinen Server und mit GoogleAuthenticator).

Du könntest neben deiner Firerwall zusätzlich noch eine vernünftige IP-Blacklist nutzen, siehe Ausschnitt meines Skripts:

[Only registered and activated users can see links. Click Here To Register...]

Wenn du einen sicheren Webserver möchtest, empfehle ich dir auch grundsätzlich auf Nginx zu gehen. Nicht, weil Apache nicht sicher ist, Nginx bietet einfach bessere und einfachere Methoden ;P

Ansonsten kannst du versuchen, alle Systeme zu chrooten, wobei das meiner Meinung nach schon zu viel des Guten ist. So lange die nicht unter Root laufen, passt es.

Hoffe ich konnte dir etwas helfen

LG
11/16/2015 10:23 Ares#3
Wie sieht es aus mit Apache hinter Nginx? Das ist meine derzeitige Konfiguration.
Bei welchen Dateien ist es sinnvoll, sie direkt durch nginx bedienen zu lassen? Momentan habe ich ac3 avi bmp bz2 css cue dat doc docx dts eot exe flv gif gz htm html ico img iso jpeg jpg js mkv mp3 mp4 mpeg mpg ogg pdf png ppt pptx qt rar rm svg swf tar tgz ttf txt wav woff woff2 xls xlsx zip.
11/16/2015 21:06 Zypr#4
Würden beide Webserver auf ein und dem selben System laufen oder hast du mehrere? So lange du nur ein System hast (Also z. Bsp. ein Server mit Nginx und einen anderen mit Apche oder beide Server auf einem System), bringt dir das rein gar nichts.. du profotierst nicht wirilich davon. Die Kombination aus Nginx + mehrere andere Server, ob es nun Apache oder Nginx Server sind, bringt dir nur ab mindestens 2 zusätzlichen Servern etwas. Der Sinn dabei ist Loadbalancing und Caching, sodass alle Server auf ein und den selben Cache zugreifen. Apache ist richtig konfiguriert bzw. kompiliert auch gut zu gebrauchen, nur muss man dafür etwas mehr tun als bei Nginx. Nginx an sich handelt z. Bsp. static files von Grund auf ziemlich gut und muss nicht extra angepasst werden. Wie bereits erwähnt, empfehle ich komplett auf Apache zu verzichten und direkt auf Nginx zu gehen.
11/16/2015 22:13 Ares#5
Also so wie ich das verstanden habe, gibt es auch auf einem Server allein einige Vorteile (CPU wird entlastet, etwas weniger RAM wird beansprucht, Apache Prozesse werden allgemein kürzer beansprucht, User mit kleiner Bandbreite laden schneller (z.B. GPRS, EDGE, 3G usw.)).
11/17/2015 04:34 Zypr#6
Vielleicht reden/schreiben wir auch einandner vorbei.. also sagen wir so, sofern es deinem Server an Ressourcen mangelt und du unbedingt bei Apache bleiben möchtest, solltest du lieber den Apache Server etwas optimieren und einen kostenfreien CDN-Service in Betracht ziehen, damit du möglichst viele deiner statischen Dateien, also Bilder, etc. dort ablagern kannst. Wenn du genug Ressourcen hast, dann könntest du Nginx als Reverse Proxy als frontend laufen lassen. Der kann dann deine statischen Dateien cachen.. das bringt dir aber nur etwas, wenn du memcache nutzt, ansonsten merkt man nichts davon. Wenn du deinen Inhalt hauptsächlich über https anbietest und dieser auch für Smartphone-Nutzer bereitgestellt werden soll, dann solltest du dir ChaCha/Poly anschauen:

[Only registered and activated users can see links. Click Here To Register...]

Hier ein Beispiel, wie du Apache aufpimpen kannst:

[Only registered and activated users can see links. Click Here To Register...]

Gibt es eigentlich einen besonderen Grund, wieso du unbedingt bei Apache bleiben möchtest? ;D
11/17/2015 08:35 Ares#7
Vielleicht lasse ich die Entwickler besser selbst sprechen:
[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]

Quote:
Originally Posted by Zypr View Post
Gibt es eigentlich einen besonderen Grund, wieso du unbedingt bei Apache bleiben möchtest? ;D
Never touch a running system ( ͡° ͜ʖ ͡°)
11/17/2015 14:47 Zypr#8
Der Thread ist aber schon sehr alt. Nginx ist auch was dynamischen Kontent angeht, viel schneller mit FPM als Apache mit mod_php oder aber auch mit FPM. Es gibt seit einer Weile eine noch schnellere Methode, dynamischen Kontent zu verarbeiten und anzuzeigen. Das Ganze heißt [Only registered and activated users can see links. Click Here To Register...]

Hier ein paar Tests (leider auch relativ alt):

[Only registered and activated users can see links. Click Here To Register...]

Hierbei wurde Apache auch gänzlich aus den Tests ausgeschlossen.. nicht ohne Grund.

Bezüglich never touch a running system: Das einzige, was im Vergleich zu Nginx geändert bzw. angepasst werden sollte, ist der .htaccess Inhalt. Bei dem Rest kann ich dir leider nicht zustimmen ;P
11/22/2015 13:00 Ares#9
Ich weiß dieses Thema artet mittlerweile in verschiedene Richtungen aus, aber da ich nicht immer einen neuen Thread erstellen will:
Kann sich jemand einen Reim auf diese Firewall Logs machen?
Code:
Nov 22 12:50:26 ******* kernel: [495908.748392] [UFW BLOCK] IN=eth0 OUT= MAC=00:**:**:**:**:**:**:**:**:**:**:**:**:** SRC=79.143.**.** DST=79.143.**.** LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=11388 DF PROTO=TCP SPT=33338 DPT=20244 WINDOW=29200 RES=0x00 SYN URGP=0
Die Verbindung wird alle 20 Sekunden geblockt. Ist offenbar ein Server vom gleichen Hoster wie meiner. Wenn ich das richtig sehe Port 20244.

Edit: Problem Nr.2:
Ich nutze Roundcube + den Atomic Basic ModSecurity Regelsatz. Immer wenn ich auf die Website zum einloggen gehe, bekomm ich eine 403 Forbidden Meldung.
11/22/2015 20:10 xinput.dll#10
Quote:
Originally Posted by Ares View Post
Ich weiß dieses Thema artet mittlerweile in verschiedene Richtungen aus, aber da ich nicht immer einen neuen Thread erstellen will:
Kann sich jemand einen Reim auf diese Firewall Logs machen?
Code:
Nov 22 12:50:26 ******* kernel: [495908.748392] [UFW BLOCK] IN=eth0 OUT= MAC=00:**:**:**:**:**:**:**:**:**:**:**:**:** SRC=79.143.**.** DST=79.143.**.** LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=11388 DF PROTO=TCP SPT=33338 DPT=20244 WINDOW=29200 RES=0x00 SYN URGP=0
Die Verbindung wird alle 20 Sekunden geblockt. Ist offenbar ein Server vom gleichen Hoster wie meiner. Wenn ich das richtig sehe Port 20244.

Edit: Problem Nr.2:
Ich nutze Roundcube + den Atomic Basic ModSecurity Regelsatz. Immer wenn ich auf die Website zum einloggen gehe, bekomm ich eine 403 Forbidden Meldung.
Zum Problem Nr. 2:


Wenn ich mich recht entsinne, dann taucht ein 403er dann auf, wenn deine config die Regelsätze nicht lädt.


Hast du zum konfigurieren ASL genutzt?
11/23/2015 00:17 Zypr#11
Zu Problem 1:

Soll/Darf die Verbindung denn aufgebaut werden? Falls ja, dann hast du irgendeine Art von Limitierung drin. Hast du UFW selbst konfiguriert oder irgendein fertiges Zeug benutzt? Normalerweise sollte die Verbindung nicht einfach so geblockt werden, es sei es steht in den iptables. Ist das der einzige Eintrag in dem syslog?



Zu Problem 2:

Irgendwie verarbeitet dein Webserver die Cookies nicht sauber. Benutzt du einen Loadbalancer oder Cacheserver, etc.? Jedenfalls kannst du das Problem evlt. lösen, indem du einfach prüfst, ob der Cookie noch valide ist.

An Stelle von Zeile #25 in der [Only registered and activated users can see links. Click Here To Register...] kannst du folgende Regel nutzen:

Code:
SecRule SESSION:VALID "!@eq 1" "t:none,setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/INVALID_SESSIONID-%{matched_var_name}=%{tx.0}"
Das war der alte Code im OWASP CRS, jetzt wurde die Regel einfach durch SESSION:IS_NEW ersetzt. Leider rafft dein Webserver irgendwie nicht, dass dein Cookie von deiner Applikation kommt und nicht im gleichen Step verändert worden ist.


Zu der zweiten Warnung, die Zeile 151 in der [Only registered and activated users can see links. Click Here To Register...] betrifft:

Du solltest, wie es auch in der Warnung steht, einen X-FRAME-OPTIONS Header setzten. Am besten natürlich SAMEORIGIN, also so:

In deiner httpd.conf Datei:

Code:
Header always append X-Frame-Options SAMEORIGIN

In der .htaccess:

Code:
Header append X-FRAME-OPTIONS "SAMEORIGIN"
Ansonsten kannst du grundsätzlich ein whitelisting tool dazu nutzen:

[Only registered and activated users can see links. Click Here To Register...]


Ich persönlich mag ModSecurity nicht.. deshalb kann ich dir - jetzt kommts - Nginx in Verbindung mit Naxsi empfehlen. Es gibt ein eigenes whitelisting tool inkl. Lernmodus.
11/23/2015 09:11 Ares#12
Quote:
Originally Posted by .HɅCKTIVIST View Post
Zum Problem Nr. 2:


Wenn ich mich recht entsinne, dann taucht ein 403er dann auf, wenn deine config die Regelsätze nicht lädt.


Hast du zum konfigurieren ASL genutzt?
Standardmäßig als Pleskerweiterung, wenn das irgendwie weiterhelfen sollte. Mir sagen nur ACL-Regeln was.

Quote:
Originally Posted by Zypr View Post
Zu Problem 1:

Soll/Darf die Verbindung denn aufgebaut werden? Falls ja, dann hast du irgendeine Art von Limitierung drin. Hast du UFW selbst konfiguriert oder irgendein fertiges Zeug benutzt? Normalerweise sollte die Verbindung nicht einfach so geblockt werden, es sei es steht in den iptables. Ist das der einzige Eintrag in dem syslog?
Nein, die Verbindung soll geblockt werden. Meine Frage war eher, ob ich das als irgendeine Art von Angriffsversuch werten soll oder ob das einfach eine Fehlkonfiguration des anderen Servers ist oder sonst was. Firewall hab ich komplett selbst konfiguriert.


Quote:
Originally Posted by Zypr View Post
Zu Problem 2:

Irgendwie verarbeitet dein Webserver die Cookies nicht sauber. Benutzt du einen Loadbalancer oder Cacheserver, etc.? Jedenfalls kannst du das Problem evlt. lösen, indem du einfach prüfst, ob der Cookie noch valide ist.

An Stelle von Zeile #25 in der [Only registered and activated users can see links. Click Here To Register...] kannst du folgende Regel nutzen:

Code:
SecRule SESSION:VALID "!@eq 1" "t:none,setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/INVALID_SESSIONID-%{matched_var_name}=%{tx.0}"
Das war der alte Code im OWASP CRS, jetzt wurde die Regel einfach durch SESSION:IS_NEW ersetzt. Leider rafft dein Webserver irgendwie nicht, dass dein Cookie von deiner Applikation kommt und nicht im gleichen Step verändert worden ist.


Zu der zweiten Warnung, die Zeile 151 in der [Only registered and activated users can see links. Click Here To Register...] betrifft:

Du solltest, wie es auch in der Warnung steht, einen X-FRAME-OPTIONS Header setzten. Am besten natürlich SAMEORIGIN, also so:

In deiner httpd.conf Datei:

Code:
Header always append X-Frame-Options SAMEORIGIN

In der .htaccess:

Code:
Header append X-FRAME-OPTIONS "SAMEORIGIN"
Ansonsten kannst du grundsätzlich ein whitelisting tool dazu nutzen:

[Only registered and activated users can see links. Click Here To Register...]


Ich persönlich mag ModSecurity nicht.. deshalb kann ich dir - jetzt kommts - Nginx in Verbindung mit Naxsi empfehlen. Es gibt ein eigenes whitelisting tool inkl. Lernmodus.
Schau ich mir mal an, danke. Hab leider noch nicht ganz rausfinden können, wie ich Nginx in Plesk als Hauptwebserver konfigurieren kann, ohne das Panel komplett auszuhebeln bzw. ohne, dass es da zu irgenwelchen Komplikationen kommen könnte. Momentan läuft er nur als Reverse Proxy.