ny_unity
Anmeldungsdatum: 7. September 2017
Beiträge: 20
|
Guten Morgen zusammen, ich habe einen VPS gemietet, den möchte ich gern absichern. Habe den SSH Port geändert, einen neuen User angelegt und Root deaktiviert. Jetzt wollte ich gern jeglichen traffic sperren, außer den SSH Port und einen weiteren. Gelesen habe ich es gibt zwei Arten wie iptables arbeitet, alles erlauben was nicht verboten ist, oder alles verbieten was nicht erlaubt ist. Das zweite gefällt mir besser 😉 Gelesen habe ich, dass für mich wie folgt das richtig wäre:
| iptables -F
iptables -P INPUT DROP
iptables -A INPUT -i lo -p all -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport Port1 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport PORT2 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport Port3 -j ACCEPT
iptables -A INPUT -j DROP
|
Doch wie speichere ich das und wie wird das ganze dann bei jedem Neustart wieder aktiviert? Und ist das so richtig wie ich es meine? Eine weitere Frage: kann man es so konfigurieren dass man SSH nur nutzen kann, wenn die IP Adresse auf einem dyndns liegt? Vielen Dank!
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
ny_unity schrieb: Das zweite gefällt mir besser 😉
Dann muss die default policy der INPUT chain aber nicht auf DROP sein. ny_unity schrieb: Doch wie speichere ich das und wie wird das ganze dann bei jedem Neustart wieder aktiviert?
Z. B. mit netfilter-persistent:
apt-cache show netfilter-persistent
man netfilter-persistent ny_unity schrieb: Eine weitere Frage: kann man es so konfigurieren dass man SSH nur nutzen kann, wenn die IP Adresse auf einem dyndns liegt?
Welche IP-Adresse soll auf einem dyndns liegen? Die source- oder die destination-IP-Adresse?
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8558
Wohnort: Münster
|
ny_unity schrieb: […] VPS […] absichern. Habe den SSH Port geändert, einen neuen User angelegt und Root deaktiviert.
Das sind sinnvolle Maßnahmen.
Jetzt wollte ich gern jeglichen traffic sperren, außer den SSH Port und einen weiteren. […] iptables
Es ist mit einem auf dem abzusichernden System laufenden Paketfilter technisch unmöglich, zu verhindern, dass unerwünschter Verkehr den Server erreicht. Dazu benötigt man einen Paketfilter auf einem dem Server vorgeschalteten System. Außerdem wird unerwünschter Verkehr, der keinem offenem Port zugeordnet werden kann, ohnehin vom Netzwerkstack verworfen. Lass also die Regeln für iptables in der INPUT-Chain einfach weg. Sie nutzen nichts, können aber schaden, da sie Ressourcen binden und somit die Angriffsfläche für denial-of-service Attacken vergrößern. Auf Servern ist der Einsatz von iptables nur in der OUTPUT-Chain sinnvoll, um z.B. zu verhindern, dass der Server an unerwünschte Kommunikationspartner antwortet oder um die Bandbreite für einzelne Clienten zu beschränken.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
kB schrieb: Außerdem wird unerwünschter Verkehr, der keinem offenem Port zugeordnet werden kann, ohnehin vom Netzwerkstack verworfen.
Aber auch das muss (und kann mit iptables) konfiguriert werden, denn sonst wird geantwortet (mit z. B. icmp).
213.xx.xx.4 > 192.168.178.22: ICMP 213.xx.xx.4 udp port 5###2 unreachable, length 36
|
ny_unity
(Themenstarter)
Anmeldungsdatum: 7. September 2017
Beiträge: 20
|
Hallo, vielen Dank für die Antworten. Dann lasse ich iptables weg. Zwecks dyndns: es sollte angefragt werden ob der anmeldende Benutzer die gleiche IP wie die des den hat, damit nur ich mich aus dem heimischen Netzwerk anmelden kann. Gibt es sonst noch sinnvolle Sicherheitsmaßnahmen?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
ny_unity schrieb: ... der anmeldende Benutzer die gleiche IP wie die des den hat, damit nur ich mich aus dem heimischen Netzwerk anmelden kann.
Das verstehe ich (noch) nicht. Kannst Du das etwas genauer erklären?
|
ny_unity
(Themenstarter)
Anmeldungsdatum: 7. September 2017
Beiträge: 20
|
Ok:
Meine FritzBox sendet nach jedem Trennung des Internets die aktuelle öffentliche IP an den dyndns.
Der VPS soll nur SSH Login gewähren, wenn diese Adresse vom dyndns sich versucht einzuloggen. Beispiel: ich bin jetzt zu Hause und habe 123.456.789.12 die gleiche die meine dyndns Adresse hat. Der VPS soll jetzt prüfen, dass nur diese Adresse Zugriff hat, keine andere IP. Hoffe das ich jetzt besser geschildert habe was ich will ☺
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
ny_unity schrieb: Meine FritzBox sendet nach jedem Trennung des Internets die aktuelle öffentliche IP an den dyndns.
Der VPS soll nur SSH Login gewähren, wenn diese Adresse vom dyndns sich versucht einzuloggen. Beispiel: ich bin jetzt zu Hause und habe 123.456.789.12 die gleiche die meine dyndns Adresse hat. Der VPS soll jetzt prüfen, dass nur diese Adresse Zugriff hat, keine andere IP.
Der VPS könnte z. B. mit einem cronjob (oder timer unit) alle 30 Minuten die aktuelle Auflösung von <host>.dyndns mit der lokal in einer Datei gespeicherten IP-Adresse vergleichen und bei Bedarf aktualisieren.
Die aktuelle IP-Adresse könnte dann in der /etc/hosts.allow (via Datei und wenn der sshd für die hosts.allow kompiliert/konfiguriert ist) oder in einer bei Bedarf zu aktualisierenden (neu laden) iptables-Regel benutzt werden.
D. h. aber auch, dass Du evtl. max 30 Minuten mal keinen Zugang zum sshd hast. Ich finde diese Lösung mit der erlaubten source-IP-Adresse aber nicht erforderlich.
|
ny_unity
(Themenstarter)
Anmeldungsdatum: 7. September 2017
Beiträge: 20
|
Ok, dann lasse ich das. Dachte so etwas ist schon implementiert. Gibts sonst noch was, was man für anfänglichen Schutz tun kann?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
ny_unity schrieb: Gibts sonst noch was, was man für anfänglichen Schutz tun kann?
Pubkey-authentication statt mit Passwort. Eine neu Gruppe anlegen, den User dort Mitglied machen und über die sshd_config, nur diese Gruppe erlauben. Wenn Server und Client es erlauben das ecn-Bit zu setzen, dann nur syn-Flag-Verbindungen mit gestztem ecn-Bit erlauben. Die meisten Port-Scanns und Verbindungsversuche sind ohne gestztes ecn-Bit. EDIT: Wenn Du nur ssh-Zugang zu deinem Server hast, solltest Du auch vorsichtig sein, dass Du dich nicht aussperrst.
D. h. die 1. ssh-Verbindung zum Server nicht unterbrechen, bevor mit der 2. ssh-Verbindung die geänderte Konfiguration des sshd-Servers (bzw. der Zugang zu diesem) nicht gründlich geprüft ist. Bei iptables-Regeln diese erst nach gründlicher Prüfung (Tests) persistent machen.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
ny_unity schrieb: Gibts sonst noch was, was man für anfänglichen Schutz tun kann?
Wenn es sich um einen aus dem öffentlichen Netz direkt erreichbaren Server handelt, bin ich an einigen Punkten anderer Meinung, als einige Schreiber zuvor. Das wären meine Erst-Maßnahmen zur Absicherung des Systems:
das Paket sudo ist faktisch ein hohes Sicherheitsrisiko, welches ich durch Deinstallation beseitigen würde ich würde unbedingt ein sehr anspruchsvolles root-Password vergeben auf dem System wären konsequent nur völlig unberechtige User angelegt, von denen sich definitiv keiner mit eigenem PWD root-Rechte aneignen kann die Anmeldung via SSH ist für root verboten die Anmeldung via SSH ist nur bestimmten Usern via persönlichen Cert/Key-File möglich ich würde unbedingt via nftables einen Paketfilter aktivieren, um sowohl eingehend temporäre Bannings bei wiederholten Attacken einer IP und generelles Blacklisting zu ermöglichen, als auch ausgehenden Traffic zu regulieren. ich würde alle Dienste deinstallieren, die nicht für den Betrieb des Systems unbedingt erforderlich sind ich würde keinerlei Software einsetzen, die nicht aus dem eigenen Repository der Distribution kommt Ich nehme mal an, dass der Server ohne grafisches Desktop-Envirionment installiert wurde... wenn nicht, würde ich ihn erneut und dann als reines Terminal-System installieren
Ich weiss, dass das jetzt teilweise widersprüchlich zu anderen Postern ist.... aber wer hat gesagt, dass Sicherheit einfach zu erreichen ist. Fakt ist, es gibt eine einfache und absolut effektive Anfangs-Maßnahme Deinen Server schon ziemlich wirksam zu schützen: Und zwar, in dem Du verhinderst, dass die Rechte eines angelegten Users dazu missbraucht werden können, das System zu kompromittieren. Und wenn die User selber diese Rechte nicht haben, können sie auch nicht missbraucht werden. jm2c
|
ny_unity
(Themenstarter)
Anmeldungsdatum: 7. September 2017
Beiträge: 20
|
Danke für die Antworten. Ich habe Root deaktiviert und einen weiteren User angelegt. Des Weiteren habe ich eine E-Mail Benachrichtigung eingestellt wenn per SSH angemeldet wird. Ich würde das ganze jetzt noch mit dem Zertifikat machen, dann denke ich, reicht es aus. Das mit dem Portscanner klingt noch gut. Kannst du dazu mehr erzählen? Danke!
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
ny_unity schrieb: Das mit dem Portscanner klingt noch gut. Kannst du dazu mehr erzählen?
Z. B. das ist die (noch nicht persistente) iptables-Regel (für den Server):
sudo iptables -I INPUT 1 -i <Interface> -p tcp --dport <Port> --tcp-flags SYN SYN -m ecn ! --ecn-tcp-cwr -m state --state INVALID,NEW -j DROP
(Interface und Port anpassen und ohne spitze Klammern). <EDIT:> Vorsicht, dass Du dich nicht aussperrst, mit iptables. </EDIT:> In Linux (Server und Client) kannst Du das ecn-Bit mit:
net.ipv4.tcp_ecn = 1
net.ipv4.tcp_ecn_fallback = 0
in der "/etc/sysctl.conf"-Datei (oder gleichwertig) setzen. Für Windows (oder anderes OS auf dem Client) siehe im Internet. Dann machst Du vom Client einen tcp-syn-ping ohne und mit ecn-Bit. Z. B.:
sudo nping -c 3 --tcp --flags syn --delay 1s -g 23456 -p <Port> <IP-Adresse-Server>
sudo nping -c 3 --tcp --flags syn,ecn,cwr --delay 1s -g 23457 -p <Port> <IP-Adresse-Server>
(Port und IP-Adresse anpassen und ohne spitze Klammern).
Oder mit dem ssh-Client anmelden (ohne und mit gesetztem ecn-Bit auf dem Client).
|