Root Server Absichern

Hi,

in diesem Beitrag geht es Generell um das absichern eines Linux Server, einzelheiten werden später zu anderen Beiträgen verlinkt.

Ich gehe davon aus das man sich eben einen Root-Server bestellt hat (Debian/Ubuntu/usw.) und will jetzt loslegen.

Sollte man mehr als eine Domain haben und dazu auch noch mehrere E-Mailadressen  sollte eine Plattform wie Plesk dazu nutzen, da hier die Verwaltung viel einfacher ist und wenn man auch noch Kunden hat, können diese wie bei allen Hostern ihre Domain und E-Mail Adressen selbst Verwalten und hat dadurch weniger Stress.

Da ich selbst auch Plesk nutze (15 Domains und über 100 E-Mail Konten) werde ich das Thema auch an gehen.


Putty:

Als erstes brauchen wir mal Putty damit kann man via SSH auf seinen Server zugreifen.

Beim ersten Starten stellt man Putty wie folgt ein:

putty

Putty SSH terminal

IPVOMSERVER = Die IP die Du von deinem Provider erhalten hast und man sollte sich auch gleich noch einen 2. IP bestellen
Connection Type stellt man auf SSH, dadurch wird automatisch der Port 22 eingestellt.
Wenn man möchte kann man in der Feld Save Session einen Namen eintragen und mit Save abspeichern.
Links kann man unter Terminal -> Features die 2. Option von oben an klicken – Disable application Keypad mode , dann kann man unter Putty auch sein NUM Pad auf der Tastatur nutzen.

Links Window kann man einstellen wie viele Zeile im Fenster möglich sein sollten, ist beim Einrichten nicht so Wichtig aber wenn man sich dann mal Logfiles ansieht kann das ganz Nützlich sein, ich stelle hier immer min. 200000 ein.

Nach dem man nun auf Open geklickt hat wird man nach dem Benutzernamen gefragt, das ist am Anfang immer root.
Das Passwort bekommt man von seinem Provider oder man kann es auch selbst einstellen, diese ist danach einzugeben und schon ist man auf seinem Server.


Das erste Sicherheitsproblem:

Und hier haben  wir schon das erste Sicherheitsproblem!

– man kann sich als root direkt Anmelden
– SSH dienst ist über Port 22 zu erreichen
– jede IP die eingerichtet ist hört auf diesem Port mit

Und das ist das erste was wir ändern, wegen des letzten Punkts kann ich nur jeden Empfehlen eine 2. IP zu bestellen.

Der Grund ist relativ logisch, mit einer IP kann ich den Öffentlichen und Administrativen bereich nicht trennen, mit 2. IPs geht das (Management IP, Public IP).

Die 1. IP die man erhält ist die Primäre IP, diese ist z.B.: auch auf dem Nameserver deines Providers hinterlegt und wird unter ifconfig als eth0 Adresse angezeigt.

Wenn man sich eine 2. IP dazu holt wird diese nicht als eth1 sondern eth0.1 angelegt also als Virtuelle IP da die Server nur eine Netzwerkkarte haben geht das nicht anders zu lösen.

Bei mir sieht das dann so aus, je nach Provider kann sich dies aber unterscheiden, manche arbeiten mit DHCP und nicht statisch.

Wie man sehen kann eth0 ist meine Primäre oder auch Public IP eth0.1 ist nur eine Virtuelle IP, lo ist localhost und tun0 ist mein VPN, da komme ich auch noch dazu.

Da wie oben schon erwähnt wir dadurch die Möglichkeit haben (2.IP) das eigene Netzwerk zu trennen, sollte man diese Möglichkeit auch nutzen, ich würde nie einen Server mit nur einen IP betreiben.


SSH Server:

Also gehen wir jetzt in unsere SSHd config unserer SSH Server und sagen ihm das er nur noch auf eine Spezifische IP hören soll, auf einen anderen Port und wir sagen ihm auch welche Nutzter diesen Dienst nutzen dürfen.

Da wir , wie eben erwähnt, sagen wollen welche Nutzer SSH nutzen dürfen und welche nicht müssen wir erstmal einen Benutzer erstellen.

Ich habe jetzt mal schnell den Benutzer test angelegt, wie Du deinen Benutzer nennst ist dein ding.

Und macht Dir keinen Hoffnungen, den Benutzer habe ich sofort wieder gelöscht 🙂

Jetzt wird der SSH Server umgestellt, wie immer nutze ich nano – aptitude install nano – Falls Du das nicht auf deinem System hast.

Neue Keys erstellen:
http://www.manpagez.com/man/1/ssh-keygen/

Beim erstellen der Keys darauf achten das die Bitrate über 1024 ist und RSA + ECDSA reichen DSA sollte man weglassen.

Die Datei mit der Tastenkombination strg+o speichern und sshd mit /etc/init.d/ssh restart neustarten.

Nach dem Du diese config eingefügt oder deine config so angepasst (x = deine IP und AllowUsers musst Du deinen Benutzer eintragen) kannst Du den SSH Server neu starten.

Und keine Panik, deine aktive Session bleibt aktiv  und geht nicht verloren solange Du diese nicht beendest.

Mach jetzt eine neues Putty Fenster auf und Verbinde dich erneut mit deinem Server.

Wenn Du alles richtig gemacht hast wird das jetzt nicht funktionieren!

Und das auch der SSH Server nicht mehr auf deine Primäre IP zu erreichen ist sowie auf den Port 22 sondern auf den Port den Du in deiner config eingetragen hast.

Das heißt Du musst jetzt in Putty deine 2. IP und den Port eintragen die auch in einer SSH Server config steht.

Sobald Du das gemacht hast und die Daten richtig sind muss Du wieder eine Verbindungen mit deinem Server bekommen und dieser fragt dich nach deinem Benutzernamen.

Sollte es immer noch nicht gehen schau noch mal in deine config mit dem noch aktiven (alten) Putty Fenster und prüfe deine Daten.

Jetzt gib als Benutzername wieder root ein – Das funktioniert auch nicht mehr, wenn doch musst Du auch wieder in deine config rein gehen und nochmal alles Prüfen. *ACHTUNG* es kommt zwar die Passwortabfrage aber nach Eingabe des richtigen Passworts kommt die Meldung:

Und so soll das auch sein, also mach das neue Putty Fenster wieder zu und öffne ein neues, trage die 2. IP und den neuen SSH Port ein.

Bei der Abfrage des Benutzernamen nimmst Du jetzt test (aus meinem Beispiel, nutze den Benutzernamen den Du erstellt hast) und wenn die Passwort abfrage kommt gibst Du dein Passwort zu deinem Benutzer ein.

Jetzt musst Du wieder eine Verbindungen zu deinem Server haben, wenn nicht hast Du einen Fehler in deiner SSH Server config oder hast dich beim Benutzer anlegen vertan, bitte nochmal alles Prüfen.

Gut! Jetzt hast Du also deinen SSH Server umgestellt auf 2048Bit Verschlüsselung, er hört nur noch auf deine 2. IP und auf einen anderen Port den nur Du weißt.

Eine detaillierte Anleitung zum Einrichten des SSH Servers findest du auch bei mir und zwar hier.


Jetzt geht der Spaß aber noch weiter, als Server Betreiber kann man nicht Paranoid genug sein.

Auf der Webseite http://www.tcpiputils.com/ kannst Du prüfen welche IP Du hast, diese wird oben Links in der Ecke angezeigt und wenn Du auf diese klickst bekommst Du einige Information zu deiner IP-Adresse.

Dies benötigen wir jetzt den wir nutzen das alte System hosts.allow und hosts.deny von Debian um das System noch dichter zu bekommen.

Du öffnest erstmal deine hosts.allow

Und hier tragen  wir jetzt ein welche IP-Adressen oder auch Netzwerke Du erlauben willst.

Kurze Erläuterung:

sshd ist dein SSH Server (nur ssh ist der Client) localhost muss man eintragen sonst läuft der ganze Dienst nicht mehr, daher ein muss.

Für x kannst Du das Netzwerk deinen DSL Provider nutzen dazu gehst Du auf den Link oben und klickst auf deine IP dort wird Dir dann nicht nur Angezeigt über welchen Knotenpunkt Du im Moment gehst sondern auch wie das Netzwerk lautet in dem Du dich bewegst (bei T-Online meist ein /10 Netzwerk).

Bei mir ist das 79.192.0.0/10 – Telekom Netzwerk und ja /10 ist ein sehr großes Netzwerk aber da ja alle 24h sich meine IP ändert kann ich dadurch recht Sicher sein das ich immer wieder auf meinen Server komme (leider bewege ich mich nun in 3. Netzwerken, nerv).

Im Speziellen bei der Telekom verhält es sich so das die Telekom ihre Netzwerk auf ganz Deutschland FEST aufgeteilt hat(mit VDSL nicht mehr), das heißt Telekom Kunden haben für jede Region ein Festes Netzwerk, daher kann man recht einfach Feststellen aus welcher Region jemand ist wenn er/sie bei der Telekom ist.

Bei anderen Provider kann dies anders sein, hatte den Fall erst vor einer Woche bei Vodafone mitbekommen das hat sich das Netzwerk von heute auf morgen von 178.x.x.x auf 92.x.x.x geändert, was bei dieser art und  weise sehr verheerend sein kann.

Hier gibt es aber 2. Optionen – 1. Option man schaut über einige Wochen welche IP man jeden Tag neu bekommt oder die 2. Option das man es wie bei dem Eintrag für den FTP Server macht (2. Zeile) und zur Freigabe z.B.: .de benutzen sofern dein DSL Provider die Kennung am ende Nutzt.

Bei mir ist das t-ipconnect.de daher würde .de auch funktionieren.

Wenn aber dein Provider .net oder sonst irgend etwas benutzt oder .ch oder .at würde das auch gehen. Hat aber den Nachteile das du hier ein ganzes Land freigibst.

Kabelbetreiber machen das etwas anders, hier hat man quasi eine Statische IP die sich nur ändert wenn man den Router neustartet und auch hier kann es aber dann passieren das man eine IP aus einem anderen Netzwerk erhält aber ich habe auch schon mitbekommen das dies meisten nur dann passiert wenn es Probleme mit Knotenpunkten gibt, nach ein paar Stunden oder am nächsten Tag und einem neuen Router neustart kommt man wieder in das alte Netzwerk.

Ein Freund hatte sogar mal eine IP aus Österreich bekommen obwohl er bei Unitymedia ist, kam daher nicht mehr via FTP auf meine Kiste 🙂

Als 2. IP könnte man dann das Netzwerk auf seiner Arbeitsstelle eintragen damit man auch von dort mal schnell im Notfall via SSH auf seinen Server kommt.

Hier gilt das gleiche wie beim Privaten Anschluss oder man hat glück und arbeitet in einem größerem Unternehmen und die haben meistens eine Standleitung dann muss man sich hier keinen Kopf machen.

Und die 3. IP kann dann der VPN Server sein, damit du auch via VPN auf deinen Server kommst und das kann dann auch so eine art Notfall Verbindung sein, oder du gehst Grundsätzlich nur via VPN auf deinen Server, was zu empfehlen ist.

Habe fast vergessen zu erwähnen das man auch die 2. IP eintragen muss damit der Dienst sauber läuft wie localhost!

Zur 2. Zeile, die ist für den FTP Server, da ich ProFTP habe muss die Zeile dann auch entsprechend heißen, hat man einen anderen FTP Server muss dies angepasst werden.

Bei meinem Server werden nur Online Kennungen mit .de, .info und .net erlaubt und dazu noch einige IPs.

Hier ist jetzt wichtig das du nicht deine 2. IP einträgst sondern deine 1. (Primäre) IP, da ich keine Kunden im Ausland habe, muss ich hier keine weiteren Kennungen eintragen

Solltest du dies aber haben musst du diese noch hinzufügen.

Wie bei sshd kannst auch Netzwerke eintragen wie das deiner Firma und das Netzwerk deines VPN Servers.

Mit strg + o kannst du danach die Datei speichern und mit strg+ x schließen.

Jetzt geht es zur hosts.deny und mit nano /etc/hosts.deny öffnen.

Erläuterung:
Mit UNKNOWN wird alles geblockt was das System nicht kennt, damit ist gemeint alle was nicht in der hosts.allow steht.

Die nächste Zeile blockt alles was nicht in der hosts.allow steht und schreibt geblockte zugriffe in eine Logdatei.

Und den ganzen Spaß machen wir auch nochmal mit dem FTP Server das ist dann die 3. Zeile.

Nicht vergessen die Datei mit strg + o zu speichern und mit strg + x schließen, sollte was schief gelaufen sein wird die Verbindung direkt geschlossen und man kommt nicht mehr auf seinen Server.

Je nach Anbieter kann man jetzt via Console Port noch auf den Server zugreifen oder man muss sein System in den Recovery Modus booten und die Datei abändern.

Wie oben schon beschrieben ist diese Methode sehr hart und man muss darauf achten das alle Angaben stimmen sonst kann es zu Problemen kommen.

hosts.allow und hosts.deny nutze ich nur noch für FTP, SSH wird bei mir nur noch via Iptables geregelt.


Die Firewall – Iptables:

Als nächste ist dann schon die Firewall dran (iptables) mit GeoIP (xtables-addon) dazu habe ich schon einiges geschrieben und werde daher nur die Links einfügen von meinen anderen Blogs und dir mal einen kleinen Einblick in mein neues System geben.

Ja ich hab schon wieder alles neu gemacht 🙂

Links:
Iptables Grundlagen

Iptables und GeoIP

Iptables Templates

OpenVPN Server

Meine Chains
INPUT:

x.x.x.x steht für die 2. IP, wie man sehen kann sind nur Öffentliche Dienste wie Apache, DNS, E-Mail, FTP und TS3 über die Primäre IP zu erreichen alles was Administrativ ist geht über die 2. IP, da alles andere geblockt ist was nicht definiert ist sollte klar sein das Administrative Dienste auf der Primären IP geblockt werden und Öffentliche Dienste werden auf der 2. IP geblockt.

Dadurch hat man eine ganz klare Trennung und eine erhöhte Sicherheit und solange keiner die 2. IP kennt kann man diese auch nicht angreifen.

POP3,SMTP,DNS, IMAP,FTP und APACHE sollte klar sein daher habe ich dahinter keinen Kommentar geschrieben.

Da hast du mal einen kleinen Einblick in meine Firewall.

Mit dieser laufen auch die Wichtigen Dienste wie Apache, Postfix, DNS, Plesk und FTP.

Solltest du Dienste haben die ich nicht habe und die danach nicht mehr gehen musst du in deine Logfiles schauen um zu sehen welche Ports du eventuell noch auf machen musst, meistens reicht es aber diese nur für die Primäre IP zu erlauben, diese erkennt man daran das im Logfile Einträge eingestellt werden bei den die Source IP und Destination IP identisch sind als Beispiel mal
Monit:

ACCEPT tcp — 85.25.197.100 85.25.197.100 tcp dpt:2812 /* Monit */

Hier erlaube ich nur meiner Primären IP den Zugriff auf sich selbst auf dem Port 2812 ohne den Eintrag läuft Monit nicht sauber.

Damit das jetzt mit dem Logging sauber geht aber ich auch wieder etwas gelernt.

Öffne die Datei mit

Ändere die Zeile

zu

Damit geht alles in die syslog außer Warnungen

Füge die Zeile hinzu

Dies ist die generelle Logdatei in der alle DROPs geloggt werden, ich brauch die für Munin scripte, die mir ein Freund geschrieben hat.

Und füge hinzu:

Diese 3 Zeilen sorgen dafür das ICMP, UDP und TCP drops in verschieden Logdateien geschrieben werden, ich habe das aus dem Grund gemacht da meinem Freund aufgefallen ist, vor einigen Wochen, das er mehr TS3 Verbindungen mit iftop gesehen hat als User drauf waren.

Darauf hin  haben wir den Zugriff auf seinen TS3 Server limitiert und siehe da sein Server wurde via UDP Pakete gefloodet ohne ende.

Daher haben wir auch unser Iptables komplett umgestellt.

Ich habe das gleiche Problem und leider kann man dagegen nicht wirklich was machen.

Also wenn du auch einen TS3 Server hast – nutze nie den Standard Port 9987 sondern irgend einen über 10000 und gib nur diesen Frei, am besten begrenzt man den Port dann noch nur auf das Land oder Länder aus denen auch die User kommen den Rest mach dicht.

Den Port für die Lizenzdatei muss man nur einem Netzwerk freigeben und den Download Port gibt man die gleichen Länder frei wie für den TS3 Server selbst.

Seit dem wir das wissen und da sind wir nicht alleine werden pro Tag 100k-200k UDP Pakete gedropt und wir hatten vorher max. 30k Pakete ICM,UDP und TCP zusammen!

Abuse anzuschreiben macht keinen Sinn, die IPs sind meistens gespoofed, ich habe ca. 50 Provider angeschrieben und es kam immer der gleiche Text zurück“Wir haben auf dem Port keinen Traffic muss gespoofed sein“.

Also immer mal mit iftop und iptraf schauen was so los ist auf deinem Server.

Man muss die Dateien natürlich auch erstellen und kann diese via Logrotate dann auch noch täglich neu erstellen lassen.

Wie Ihr die Datei nennt ist egal, aber muss unter /etc/logrotate.d/ abgelegt werden.

Auszug aus meinen Logfiles:

  • SRC ist die Source IP (Quelle)
  • DST ist die Destination IP, also dein Server
  • PROTO ist das Protokol (ICMP,UDP,TCP)
  • SPT ist der Source Port (meisten Dynamisch)
  • DPT ist  der Destination Port (Lokaler Port)

Um fest zustellen auf welchen Dienst einer Versucht Zugriff zu bekommen kannst man unter folgenden Links mal nach schauen:

http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

http://www.speedguide.net/port.php

Bei Speedguide findet man auch Ports die von Trojaner genutzt werden oder von Diensten die nicht so geläufig sind wie Port 80.


DNS:

Jetzt hast erstmal eine gewisse Grundsicherheit hergestellt und hast ziemlich genau definiert wer auf was Zugreifen darf.

Jetzt muss der DNS Server abgesichert werden, da mit der Grundeinstellung dieser für DDOS Attacken ausgenutzt werden kann.

Wer Plesk nutzt kann dies über das Portal machen.

 

dns recrusion localhost

dns recrusion localhost

 

Du gehst auf Tools und Einstellungen ->DNS-Template Einstellungen -> DNS-Rekursionseinstellungen
und jetzt auf Localhost umstellen, Standard ist Any.
Damit ist sichergestellt das dein DNS Server nur noch anfragen beantwortet von Domains die er kennt. Kommt eine Anfrage für deine Domain die er nicht kennt wird die Anfrage gelöscht. Wie ich glaube schon einmal geschrieben habe wurde mal Versucht über IP und DNS spoofing die DNS Server von google.com zu flooten, dabei wurde ein traffic von 40gb/s erzeugt. Wie wurde das gemacht ? Ganz einfach ^^ Man hat an alle DNS Server die damals die Angreifer kannten eine DNS Anfrage gestellt und gaben als Absender google.com an, darauf hin haben die DNS Server ihre Antworten nicht an den Angreifer gesendet sondern an google.com. Da die Standardeinstellung von BIND any ist haben da sehr viele Server mit gemacht und so ist dieser massive Traffic zusammen gekommen.
Google hat verlauten lassen, das dies bemerkt wurde aber keinerlei Dienst eingeschränkt hätte, Respekt! 🙂

 

 

 

 

Im normal Fall reicht diese Einstellung man kann aber noch etwas mehr machen, dazu muss man die DNS config direkt anfassen.

Macht bitte vorher kein Backup von der Original Datei oder lasst diese in der Datei und kommentiert sie aus mit einer # am Anfang jeder Zeile!

Bei Debian liegt Datei unter /var/named/run-root/etc/named.conf

Also rein damit

Im Original sollte das so ausgesehen haben:

Erklärung:

Als erstes Fällt auf das ich eine Access-Liste erstellt habe (ACL) dies habe ich gemacht um es etwas übersichtlicher zu haben, muss man aber nicht so lange man nur mit localhost und localnets arbeitet, sobald man aber noch IPs oder Netzwerke einträgt muss du das wohl, wenn ich das richtig Verstanden habe.

Der Name dieser ACL ist „ok“ mehr nicht das Wort ok hat keine Funktion, der Name ist frei wählbar.

In der ACL lege ich fest wer alles Zugriff auf meinen DNS Server bekommt.
x.x.x.x/24 das ist das Netzwerk meines VPN Servers, ohne den Eintrag wird die syslog mit Fehler des DNS Server zu gespammt, hat man keinen VPN brauch es den Eintrag nicht und dann brauch man auch nicht die ACL.

Localhost und Localnets sollte jetzt klar sein.

Sobald jemand dagegen verstößt wird ein Eintrag in die Syslog gemacht und kommen von named, wenn man danach mal suchen möchte.

Nach dem speichern und schließen der Datei – Bind9 mit /etc/init.d/bind9 restart neu starten.


Name Server:

Nach dem du das erledigt hast ist als nächstes der Name-Server dran, dazu musst du in das Portal deines Providers sofern dieser das anbietet.

Bei der Telekom ging das, sowie bei Strato und Serve4you.

Was wollen wir hier machen ?

Wir wollen den Spam reduzieren.

Was man dazu wissen sollte ist das der meiste Spam von Bots kommt und diese verhalten sich nicht wie ein E-Mail Programm.

Das soll heißen das es den Bots darum geht so viele E-Mails wie möglich in kurzer Zeit zu versenden, daher machen diese sich nicht die Arbeit jeden MX Eintrag eines Server zu Prüfen sondern nehmen Pauschal den ersten oder letzten.

Der MX Eintrag auf dem Name und DNS Server geben an mit welche Priorität ein Server hat, hat man 5 Verschiedene Server kann man so eine Lastverteilung und Ausfallsicherheit erreichen.

Und jetzt kommt uns wieder die 2. IP zur Hilfe, denn wir erinnern uns, das wir bei dieser IP nur Administrative Dienste zulassen und alles andere Blocken auch E-Mail.

Die Einträge die wir jetzt auf dem Name-Server deines Provider machen muss bei jeder Domain erfolgen und kann nicht Pauschal gemacht werden, dies geht nur in Plesk über die DNS Templates oder wenn man kein Plesk hat muss man wieder in die named.conf und die bei jeder Domain zusätzlich Eintragen, aber ich zeige alles.

Im Portal deines Providers für deinen Server musst du erstmal die Seite finden über die du den Name-Server editieren kannst.

Solltest du diese nicht finden musst du eventuell mal den Support Anschreiben oder Anrufen.

Hier mal ein Beispiel mit 3 Einträgen man kann aber auch 5 oder 10 machen:

MX Einträge

Erster Wert ist der Typ also MX = Mail

Der zweite Wert ist die Priorität um so kleiner der Wert um so höher ist die Priorität

Der dritte Wert ist das Ziel als Domainnamen.

Jetzt muss der Name-Server noch wissen welches Ziel welche IP ist sonst geht da nichts.

  • mail hat den A Rekord der Primären IP
  • mx10 hat den A Rekord der 2. IP
  • mx30 hat auch den A Rekord der 2. IP

Also nochmal zur Wiederholung.

  • MX10 geht auf mx10.cheech-page.de und mx10 verweißt auf die 2.IP
  • MX20 geht auf mail.cheech-page.de und mail verweißt auf die Primäre IP
  • MX30 geht auf mx30.cheech-page.de und mx30 verweißt auf die 2.IP

Kommt also ein Bot an nimmt dieser den MX10 oder MX30 da diese der erste bzw. letzte MX Eintrag sind, da aber diese beiden Einträge auf die 2.IP Verweißen und auf dieser IP E-Mail geblockt ist werden diese E-Mails nicht durch kommen.

Sendet aber ein E-Mail Client/Server eine Nachricht prüft dieser alles MX Einträge also auch den MX20, dann fragt er erst MX10 ab und bekommt ein denied, also geht er geht er als nächstes zu MX20 und bekommt KEIN denied und schickt die E-Mail.

Auf die art und weiße blocke ich 20000 E-Mails am Tag, die vorher nur durch RBL Listen gefunden wurden oder gingen durch, was nicht wirklich schön war.

So jetzt müssen wir das ganze noch in Plesk bzw. auf dem DNS Server eintragen, ich mach das Beispiel wieder nur mit 3 Einträgen.

Im Plesk Portal gehst du auf Tools & Einstellungen -> DNS-Templates
dns-temp
Zur großen Ansicht Bild anklicken!

Im Grunde machst du die gleichen Einträge wie auf dem Name-Server deines Providers.

Du machst die 3 MX Einträge MX10, MX20 und MX30 wie im Screenshot, es kann auch sein das Du den Original editieren oder löschen musst.

Für den Rekord A muss man nur 2 Einträge machen da der mail. Eintrag schon vorhanden ist. Wichtig ist das man für den MX10 und MX30 die 2. IP nutzt, das ist die schwarze Box da stehen IPs dahinter bzw. die 2. IP jeweils.

Für die Primäre kann man sich den Eintrag sparen, diese wird durch den Wert <ip> gesetzt und da ist schon alles da.

Wenn man alles Eingetragen hat geht man oben rechts auf den Button: Änderungen am DNS-Template übernehmen.

Es kann auch sein das man danach noch gefragt wird ob man die Änderung am Template für alle Vorhandenen Domains übernehmen möchte, das muss man bestätigen, damit das für alle Domains auch so funktioniert.

Hat man noch ein Frisches System, wo von wir ja ausgehen, kommt die Meldung nicht bzw. höchstens für die Standard Domain die nach der Plesk Installation angelegt wird.

Jetzt kommen die Leute ohne Plesk.

Also so wie es aussieht macht da Plesk sein eigenes ding … Aber ich habe einen Link gefunden unter dem Ihr das nachlesen könnt.

http://wiki.ubuntuusers.de/DNS-Server_Bind

Und ja wieder Ubuntu Users aber das geht bei beiden Systemen gleich, also immer mut zur Lücke 🙂


Syscontroll:

Als nächstes geht es in die sysctl.conf zu finden ist diese in Ordner /etc hier können wir Netzwerktechnisch das System etwas optimieren.

Ich habe bei mir alles aus kommentiert mit einem # am Anfang jeder Zeile und habe am ende folgendes Eingefügt:

Mit sysctl -p werden die Daten neu eingelesen und mit sysctl -w sofort geschrieben ohne neustart des Systems.

Alles was IPv6 betrifft ist bei mir aus, ich finde zwar IPv6 gut aber beim Absichern vom Server und Diensten ist das doppelte arbeit und die will/wollte ich mir nicht machen.

Die restlichen Punkte für IPv4 sind fast selbst erklärend und habe die von Verschiedenen Seiten zusammen getragen.

forward ist für den Proxy und VPN Wichtig sonst geht da nichts.

rfc1337 ist ei Bug fix

rp steht für routing protokoll und bringt noch etwas mehr Sicherheit.


Tools:

Als letztes kommt jetzt noch Portsentry, dies ist ein Programm welches die Ports überwacht und auf Wunsch verschiedene Aktionen durch führt, ich lasse Portsentry die IPs via Iptables einfach blocken, dauerhaft.

Installation: aptitude install portsentry

Unter /ect/portsentry findest du jetzt 3 Dateien, die conf und 2 ignore listen.

In der /etc/portsentry/portsentry.ignore.static habe ich nichts eingestellt, die habe ich auf Standard gelassen und sollte folgende Einträge haben

In der /etc/portsentry/portsentry.ignore habe ich meine Primäre IP, 2. IP, Localhost und die IP meines VPN eingetragen

Bei der /etc/portsentry/portsentry.conf gibt es schon etwas mehr zum Lesen und Einstellen (ich trage jetzt nicht die ganze config ein sondern nur die bei denen ich was Eingestellt habe):

Ich denke mal das ist die Standard Einstellung

ADVANCED_EXCLUDE_UDP=“113,520,67″

Das sollte auf jeden fall aktiviert sein

Das ist die ignore Liste damit man nicht das System selbst aussperrt

RESOLVE_HOST = „1“

Habe ich auch aktiviert, man will ja wissen wer das ist.

Habe ich auch aktiviert sonst ist das ziemlich Sinnlos alles.

Mit dem Eintrag lasse ich keine Scans zu und es wird sofort geblockt man kann hier aber auch einen höheren Wert eintragen wenn man das möchte.

Das war es dann schon und man kann Portsentry starten mit /etc/init.d/portsentry start bzw. falls es schon läuft mit /etc/init.d/portsentry restart zum laufen bringen.

Sollte jemand jetzt einen Portscan machen wird dies in der syslog mit attackalert vermerkt:


Zugang:

Um eine Verbindung zu deinem Server zu bekommen kannst du jetzt über deine DSL Leitung gehen, über VPN und über eine SSH Tunnel.

Der schlechteste weg ist direkt über deine DSL Leitung, da du zwar via SSH auf deinen Server zugreifst aber trotzdem ungeschützt. Aber manchmal geht es nicht anders also sollte man diese Option nur nutzen wenn es nicht anders geht.

Ich Empfehle nur via VPN oder SSH Tunnel eine Verbindung zum Server herzustellen.

Den Link zum Einrichten des VPN findest du hier.

putty-tun
Für den SSH Tunnel kann man Putty nutzen in dem man in sein Profil geht unter Connection -> SSH -> Tunnels.
In dem Screenshot nutze ich den Tunnel für meinen Proxy, man kann hier aber auch mehr Einträge machen wie den Port für seinen SSH Server also einfach 3128 durch seinen SSH Port ersetzten.
Wenn man jetzt seine Verbindung öffnet wird auch gleich der SSH Tunnel aufgebaut.
Auf diesem weg kann man auch seine E-Mail Verbindung Tunnel aber ist so etwas unkomfortable.
Daher nutze ich Privat Bitvise mit dem Programm kann ich Festlegen für welche Ports ein SSH Tunnel aufgebaut werden soll, dies abspeichern und in den Windows Autostart schmeißen. Wenn man dann den Tunnel aufbauen will muss man nur noch auf Login klicken und alle Tunnel laufen. Wenn man Bitvise nutzt und die Tunnel für SSH, E-Mail aufbaut gibt man aber als IP oder Domain nicht mehr diese an sondern durch den Tunnel gibt man nur noch localhost an.

 

 

Beispiele:
Tunnel über Bitvise öffnen für SSH -> Putty öffnen -> localhost:portssh -> Verbinden

Tunnel über Bitvise öffnen für Port 25 -> E-Mail Programm öffnen -> Konto umstellen auf localhost:25 -> Abspeichern

Der ganze Spaß geht auch mit den Ports 146,587,995.993 und 3128 für den Proxy. Bei Proxy muss man über die Internetoptionen den Proxy Eintrag von seiner IP auch auf localhost umstellen.

Man kann das ganze auch kombinieren, da ich den SSH Tunnel und VPN nutze habe ich das Folgendermaßen am laufen.

Noch zur erklärung, ich nutze den SSH Tunnel nur noch für E-Mail da dies nicht sauber über den VPN läuft, zum einen liegt das an Windows zum anderen kann man keine VPN Verbindung „zu sich selbst“ aufbauen.

Ich habe also erstmal eine VPN Verbindung zu meinem Server, so weit so gut.


Sonstiges:

E-Mail via VPN muss man in seinem E-Mail Programm anstatt des Domain Namen die IP des VPN Servers nutzen (die VPN IP) und dem E-Mail Server muss man diese auch mitteilen in dem man die IP des VPN Server in die Postfix config einträgt.

Damit haben wir alles durch und auch Sicher es sei denn es kommt jemand durch unbekannte Sicherheitslücke.

Lest Euch dazu dann bitte noch zu den Verschiedenen Diensten wie Postfix, Squid (Proxy) und VPN folgende Beiträge durch:

Postfix

Squid

OpenVPN


Mod-Security unter Plesk:

Mit ModSecurity den Apache2 Server absichern unter Plesk:

Ich mach es recht kurz, Du gehst auf dein Plesk Portal und gehst auf Tools & Einstellungen und dort dann auf Web Application Firewall (ModSecurity)
mod_sec_1

 

 

 

 

 

 

 

Danach kannst Du diese Funktion aktivieren

mod_sec_2

 

 

 

 

 

 

 

 

Und bei Einstellungen lässt man aktuell noch den Atomic drin, Aktualisierung „Wöchentlich“ und Vordefinierte Werte reicht Ausgewogen.

OWASP ist zu krass eingestellt das man keine Seite mehr erreicht (besonders WP Seiten), wer OWASP nutzen will muss danach jeder Seite prüfen und das modsec:log prüfen welche Regel zugeschlagen hat und diese Manuell abschalten.

mod_sec_3

 

 

 

 

 

 

 

 

Bei OWASP wir hier eine Liste angezeigt mit Funktionen die man Abschalten kann.

mod_sec_4

 

 

 

 

 

 

 

 


Ich hoffe es ist alles Verständlich und Hilfreich, bei Fragen, unklarheiten oder Fehlern hinterlasst bitte einen Kommentar.

Danke
Cya
DocSchneidi ak Cheech

Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.