15
Debian Server absichern
Hallo zusammen,
ich weiß das Thema ist bestimmt schon mal besprochen worden. Trotzdem würde ich mein Vorhaben gern nochmal
mit erfahreneren Nutzern absprechen, also bitte steinigt mich nicht sofort
Ich würde gern ein paar Dienste meines Debian 7 Server (steh bei mir zu Hause) aus dem Internet erreichbar machen. Ich habe auch schon
ein paar Sachen zusammengetragen, die andere zum Schutz ihres Servers gemacht haben:
/home /var /tmp usw. auf eigene Partition
iptables Firewall einrichten (macht das Sinn wenn der Server bei mir zu Hause hinter ner IPFire steht? Das ist dosch schon ne Paketfirewall die ja schon alle Ports nach außen schließt)
fail2ban installieren/konfigurieren
ssh root login verbieten, normalen User und su benutzen
ssh login mit zertifikat und pw
automatische systemupdates per crontab
rkhunter und chkrootkit regelmäßig per crontab
calmav virenscanner
Dazu kommt dann noch das spezifische Absichern der Dienste, in meinem Fall NGINX, PHP und Mysql.
Was ist sonst noch grundlegend Sinnvoll?
Vielen Dank für eure Hilfe
Grüße xoxyss
ich weiß das Thema ist bestimmt schon mal besprochen worden. Trotzdem würde ich mein Vorhaben gern nochmal
mit erfahreneren Nutzern absprechen, also bitte steinigt mich nicht sofort
Ich würde gern ein paar Dienste meines Debian 7 Server (steh bei mir zu Hause) aus dem Internet erreichbar machen. Ich habe auch schon
ein paar Sachen zusammengetragen, die andere zum Schutz ihres Servers gemacht haben:
/home /var /tmp usw. auf eigene Partition
iptables Firewall einrichten (macht das Sinn wenn der Server bei mir zu Hause hinter ner IPFire steht? Das ist dosch schon ne Paketfirewall die ja schon alle Ports nach außen schließt)
fail2ban installieren/konfigurieren
ssh root login verbieten, normalen User und su benutzen
ssh login mit zertifikat und pw
automatische systemupdates per crontab
rkhunter und chkrootkit regelmäßig per crontab
calmav virenscanner
Dazu kommt dann noch das spezifische Absichern der Dienste, in meinem Fall NGINX, PHP und Mysql.
Was ist sonst noch grundlegend Sinnvoll?
Vielen Dank für eure Hilfe
Grüße xoxyss
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 243704
Url: https://administrator.de/contentid/243704
Printed on: April 19, 2024 at 12:04 o'clock
15 Comments
Latest comment
Moin,
das dient der betriebssicherheit udn nicht der Sicherheit gegenüber den Angreifern.
iptables sollte man imerm draufhaben, für den Fall, daß die Angreifer die anderen Hürden überwunden haben. bei Festungen hatte man früher auch einige Verteidigungslinien.
jepp
jepp
nur mit passphrasegeschütztem zertifikat und und paßwort-authentifikation abschalten.
nope. nur sicherheitsrelevante Updates. Alles andere nur manuell.
ist o.k.
nunja, kann nciht schaden, aber ncith wirklich notwendig.
Logdateien regelmäßig durchschauen, ggf mit logcheck helfen lassen.
lks
/home /var /tmp usw. auf eigene Partition
das dient der betriebssicherheit udn nicht der Sicherheit gegenüber den Angreifern.
iptables Firewall einrichten (macht das Sinn wenn der Server bei mir zu Hause hinter ner IPFire steht? Das ist dosch schon ne
Paketfirewall die ja schon alle Ports nach außen schließt)
Paketfirewall die ja schon alle Ports nach außen schließt)
iptables sollte man imerm draufhaben, für den Fall, daß die Angreifer die anderen Hürden überwunden haben. bei Festungen hatte man früher auch einige Verteidigungslinien.
fail2ban installieren/konfigurieren
jepp
ssh root login verbieten, normalen User und su benutzen
jepp
ssh login mit zertifikat und pw
nur mit passphrasegeschütztem zertifikat und und paßwort-authentifikation abschalten.
automatische systemupdates per crontab
nope. nur sicherheitsrelevante Updates. Alles andere nur manuell.
rkhunter und chkrootkit regelmäßig per crontab
ist o.k.
calmav virenscanner
nunja, kann nciht schaden, aber ncith wirklich notwendig.
Was ist sonst noch grundlegend Sinnvoll?
Logdateien regelmäßig durchschauen, ggf mit logcheck helfen lassen.
lks
Klingt logisch, danke für deine Antwort 
Hallo,
was mir einfallen würde:
IDS (snort/suricata)
MySQL nur an localhost binden
CHROOT für SSH/NGINX
https://www.debian.org/doc/manuals/securing-debian-howto/
Gruß,
Gersen
was mir einfallen würde:
IDS (snort/suricata)
MySQL nur an localhost binden
CHROOT für SSH/NGINX
https://www.debian.org/doc/manuals/securing-debian-howto/
Gruß,
Gersen
Hi,
danke für die Antwort, werde ich mir anschauen.
Kurze Frage zu iptables ich hab gesehen es gibt zwei verschiene Methoden entweder über nen Script oder über ein rule set zum Beispiel /etc/iptables.up.rules gibts da Unterschiede? Was ist denn zu bevorzugen?
danke für die Antwort, werde ich mir anschauen.
Kurze Frage zu iptables ich hab gesehen es gibt zwei verschiene Methoden entweder über nen Script oder über ein rule set zum Beispiel /etc/iptables.up.rules gibts da Unterschiede? Was ist denn zu bevorzugen?
Ich nutze shorewall zur Konfiguration der iptables - weil ich es für intuitiver halte.
Hier noch ein vielleicht nützlicher Link.
Hier noch ein vielleicht nützlicher Link.
Danke für eure Hilfe. Was haltet ihr denn von folgendem iptables Script: http://wiki.debianforum.de/Einfaches_Firewall-Script
Ist das brauchbar oder eher nicht?
ich habe das Script schon mal Zeile für Zeile durchgeschaut was ich nicht versteh ist:
Wozu ist das?
Ist das brauchbar oder eher nicht?
ich habe das Script schon mal Zeile für Zeile durchgeschaut was ich nicht versteh ist:
# Set the nat/mangle/raw tables' chains to ACCEPT
$IPTABLES -t nat -P PREROUTING ACCEPT
$IPTABLES -t nat -P OUTPUT ACCEPT
$IPTABLES -t nat -P POSTROUTING ACCEPT
$IPTABLES -t mangle -P PREROUTING ACCEPT
$IPTABLES -t mangle -P INPUT ACCEPT
$IPTABLES -t mangle -P FORWARD ACCEPT
$IPTABLES -t mangle -P OUTPUT ACCEPT
$IPTABLES -t mangle -P POSTROUTING ACCEPTWozu ist das?
Das Skript hat seinen Ursprung (wenn Du den Weg über die Referenz, das Forum zurückverfolgt) hier. Da ist auch etwas mehr kommentiert.
Diese Tipps und Ratschläge sind alle sehr gut.
Ist diese Linux Maschine Virtuell ?
Will nur darauf hinaus, nicht das deine Linux Maschine dann extrem gut abgesichert ist
und dein Rechner wo die Maschine dann virtuell läuft nicht.
Lg
Ist diese Linux Maschine Virtuell ?
Will nur darauf hinaus, nicht das deine Linux Maschine dann extrem gut abgesichert ist
und dein Rechner wo die Maschine dann virtuell läuft nicht.
Lg
Hey,
danke für deine Antwort. Ja der Server läuft virtuell auf einem Hyper-V.
Gibts denn da noch was was man tun kann?
danke für deine Antwort. Ja der Server läuft virtuell auf einem Hyper-V.
Gibts denn da noch was was man tun kann?
Wenn der Server virtuell ist,
solltest du halt drauf achten das nicht dein Hostsystem (Windows) unsicher ist.
Welcher Art von Hyper-V benutzt du ?
Hyper-V Rolle auf einen Server/Client
Oder hast du einen Hyper-V Server laufen (keine GUI)
solltest du halt drauf achten das nicht dein Hostsystem (Windows) unsicher ist.
Welcher Art von Hyper-V benutzt du ?
Hyper-V Rolle auf einen Server/Client
Oder hast du einen Hyper-V Server laufen (keine GUI)
Windows Server 2012 mit Hyper-V Rolle GUI ist ausgeschalten
Also du hast einen Server 2012 und du hast die Rolle Hyper-V installiert.
Was ich nicht verstehe ist was meinst du mit keine GUI ?
Ist aber auch egal.
Wichtig ist nur das auch der Server 2012 gesichert ist.
Da man ja sonst im schlimmsten Fall auf dem Server kommen könnte.
Und da dort das virtuelle Linux läuft ist es angreifbar.
Ist der Server von außen erreichbar ?
Oder gibt es andere Windows/Linux Maschinen die von außen erreichbar sind ?
Was ich nicht verstehe ist was meinst du mit keine GUI ?
Ist aber auch egal.
Wichtig ist nur das auch der Server 2012 gesichert ist.
Da man ja sonst im schlimmsten Fall auf dem Server kommen könnte.
Und da dort das virtuelle Linux läuft ist es angreifbar.
Ist der Server von außen erreichbar ?
Oder gibt es andere Windows/Linux Maschinen die von außen erreichbar sind ?
Man kann unter Windows 2012 die grafische Oberfläche jederzeit aktivieren/deaktivieren um z.B. Performance zu sparen.
Der Hyper-V Host an sich ist von Außen nicht erreichbar. Alles was von außen erreichbar ist, befindet sich in einer DMZ (über ne IPFire).
Ich weiß man sollte nicht unbedingt LAN und DMZ auf dem selben Host virtualisieren...
Der Hyper-V Host an sich ist von Außen nicht erreichbar. Alles was von außen erreichbar ist, befindet sich in einer DMZ (über ne IPFire).
Ich weiß man sollte nicht unbedingt LAN und DMZ auf dem selben Host virtualisieren...
Es war von meiner Seite aus nur ein Hinweiß.
Es ist eh eigentlich eher unwahrscheinlich das ein Angreifer
über andere Systeme auf ein System zugreifen wo virtualisiert wird
um auf eine virtuelle Maschine zuzugreifen.
Aber ich wollte halt drauf hinweißen.
Lg
Es ist eh eigentlich eher unwahrscheinlich das ein Angreifer
über andere Systeme auf ein System zugreifen wo virtualisiert wird
um auf eine virtuelle Maschine zuzugreifen.
Aber ich wollte halt drauf hinweißen.
Lg
Ist ja auch nett von dir
Ich wollte nur dagen, dass ich schon gelesen habe das es nicht wirklich optimal ist, ich bin aber der Meinung das man bei einem Heimnetzwerk auch die Kirche im Dorf lassen kann.
Ich werde die Server die direkt aus dem Internet erreichbar sind weiter optimieren das sollte dann vorerst langen. Dann ist da ja auch noch die DMZ die zu überwinden wäre. Das Angriffsszenario das aus einem VM-Container ausgebrochen wird wir werde ich vernachlässigen.
Ich wollte nur dagen, dass ich schon gelesen habe das es nicht wirklich optimal ist, ich bin aber der Meinung das man bei einem Heimnetzwerk auch die Kirche im Dorf lassen kann.
Ich werde die Server die direkt aus dem Internet erreichbar sind weiter optimieren das sollte dann vorerst langen. Dann ist da ja auch noch die DMZ die zu überwinden wäre. Das Angriffsszenario das aus einem VM-Container ausgebrochen wird wir werde ich vernachlässigen.
