... Du bist mit deiner Lösung kein Stück gegen den Fall abgesichert, dass du dir einen Trojaner einfängst, der dir aus dem RAM SSH-Keys klaut und sich damit auf deinen Server einloggt. ...
Ok, das ist dann aber auf der Client Seite. Das Skript mach die Server Seite sicherer. Und wenn ein Trojaner in meinem RAM schnüffelt, hab ich ganz andere Probleme
Hier das Skript.
Auf eigene Gefahr, ihr solltet wissen,was ihr hier macht!
Anhang downloaden.
.txt umbenennen in .py.
In ein beliebiges Verzeichnis legen.
Ausführbar machen.
Im Skript die Zeilen zwischen ... # config # ... und .... # config end # ... anpassen
In /etc/rc.local vor dem exit 0 diese zwei Zeilen einfügen (natürlich angepasst):
iptables -I INPUT -p tcp --dport xx -j ACCEPT
/path/to/where/you/put/it/ssh2dyn.py &
#!/usr/bin/env python2.7
# -*- coding: utf-8 -*-
############################### config #####################
log = True
dyn = 'your_whatever.spdns.de'
prot = 'tcp'
port = 22
fallback_time = 60
verbose = False
############################### config end #####################
import subprocess, time, sys
def run_com(com, output=True):
global verbose
try:
if verbose:
out('Apply command: '+ com)
com_list = com.split(' ')
aw = subprocess.check_output(com_list)
if verbose:
out('Got answer: ' + aw + '\n')
return aw
except:
if verbose:
out('Got answer: No answer' + '\n')
return ''
def get_ip(dyn_addr):
try:
aw = run_com('host ' + dyn_addr + ' 1.1.1.1', False)
ip = ''
if aw:
ip = aw.split('has address ')[1].strip()
if verbose:
out('Current IP: ' + ip + '\n')
return ip
return ''
except:
return ''
def out(what):
global log
global waiting
print time.strftime("%d.%m.%Y %H:%M:%S ", time.localtime()) + what + '\n'
if log and not waiting:
f = open(sys.path[0] + '/ssh2dyn.log', 'a')
f.write(time.strftime("%d.%m.%Y %H:%M:%S ", time.localtime()) + what + '\n')
f.close()
waiting = True
run_com('clear')
out('#####################################################################')
out('Startup...')
before = verbose
verbose = True
run_com('iptables -L INPUT')
verbose = before
out('wait ' + str(fallback_time) + ' sec')
time.sleep(fallback_time)
waiting = False
f = open(sys.path[0] + '/ssh2dyn.log', 'w')
f.close()
verbose = False
run_com('iptables -L INPUT')
verbose = before
try:
run_com('iptables -D INPUT -p ' + prot + ' --dport ' + str(port) + ' -j ACCEPT')
except:
pass
old_ip = ''
ip = ''
while True:
ip = ''
while ip == '':
ip = get_ip(dyn)
if '1.1.1.1' in ip:
ip = ''
time.sleep(1)
if ip != old_ip or old_ip == '':
verbose = True
out('Got New IP:' + ip)
verbose = before
if not old_ip:
run_com('iptables -I INPUT -p ' + prot + ' --src ' + ip + ' --dport ' + str(port) + ' -j ACCEPT')
run_com('iptables -P INPUT DROP')
run_com('fail2ban-client stop sshd')
verbose = True
run_com('iptables -L INPUT')
verbose = before
old_ip = ip
else:
if ip != old_ip:
try:
run_com('iptables -D INPUT -p ' + prot + ' --src ' + old_ip + ' --dport ' + str(port) + ' -j ACCEPT')
except:
pass
try:
run_com('iptables -I INPUT -p ' + prot + ' --src ' + ip + ' --dport ' + str(port) + ' -j ACCEPT')
except:
pass
verbose = True
run_com('iptables -L INPUT')
verbose = before
old_ip = ip
verbose = before
time.sleep(1)Code
Naja, wenn du deinen SSH Server auf einem Port > als 1024 hast, kann der sshd Prozess von jedem Nutzer gestartet werden.
Insofern ist so ein High Port für mich nicht vertrauenswürdig - und ich würde mich hüten da irgendetwas einzugeben.
Nein, ich denke nur, von einem Nutzer mit meiner IP. Genau das will ich ja erreichen! Aber ich bin nicht unbelehrbar.
Aber coole Diskussion,genau, was ich wollte...
Naja, wenn du deinen SSH Server auf einem Port > als 1024 hast, kann der sshd Prozess von jedem Nutzer gestartet werden.
Insofern ist so ein High Port für mich nicht vertrauenswürdig - und ich würde mich hüten da irgendetwas einzugeben.
Was nützt denn das mit:
Chain INPUT (policy DROP)
ACCEPT tcp -- 77.22.33.151 0.0.0.0/0 tcp dpt:6666
vmk Gerne mehr Info, Wie gesagt, komme aus der Softwareecke...
Ist denn das jetzt Paranoia oder mehr Sicherheit, was ich mache?
Ja, natürlich ist das paranoid. Aber warum nicht! Das ist mho 'absolute Sicherheit'. Gut, dass du das durchschaut hast!!!! Das Passwort, was default von netcup erstellt wurde, hat mich laut auth-log ja schon vor der Bruteforce Attacke geschützt. Aber meine Paranoia lässt zu, dass ich kein Problem damit habe, aus Bequemlichkeit, root bei ssh zuzulsassen .
Das ist ein Gewinn. oder?
Danke für deine Meinung!
Intension: Ich habe aus Versehen meinen Linux vServer mal für 3 Monate mit zugelassenem Passwort-Login für ssh auf Port 22 laufen lassen. Unabsichtlicher Honeypot. Ist ja leicht denkbar, was da los war. Ellenlange Auth-Logs mit Brute Force Angriffen von IP's aus Russland, China und sonst wo. Konsequenz war natürlich, den Server komplett neu aufzubauen, obwohl es keinen Hinweis auf ein erfolgreichen Bruth Force Attacke gab. Den Server habe ich dann mit fail2ban abgesichert, den ssh Port verlegt und den Passwortlogin deaktiviert. Die bessere Methode wäre natürlich, den Zugriff von außen nur von einer (meiner) IP zuzulassen, da der Angreifer ja selbst mit fail2ban zumindest die Information bekommt, dass dort ein Server ist, auf dem ein Port geöffnet ist. Leider habe ich hier nur eine dynamische IP.
Erfahrung: Es gibt (fast) nichts, was sich nicht mit Python lösen lässt!
Voraussetzung: Der Server ist ein Linux Server. Ich habe das auf einem Debian 9 stretch getestet, sollte aber auch auf anderen Linux-Distributionen funktionieren. Python wird benötigt, das Skript ist in 2.7 geschrieben. UFW Firewall oder iptables sind installiert .Es besteht ein Account bei einem DynDns-Anbieter. Ich empfehle:
SPDYN die aktualisieren die IP innerhalb von Sekunden und es ist kostenlos und unbefristet.
Problem: Dieser Abschnitt dient ausschließlich der Erklärung. Alles Notwendige erledigt das Skript.
Am sichersten ist es natürlich, wenn der Server nur ssh-Anfragen von eurerClient-IP zulässt. Falls man eine feste IP hat, ist das ganze mit einem Einzeiler erledigt.
(Ich gehe davon aus, das die default-policy in iptables in der Chain INPUT auf DROP gesetzt ist, aber, wie gesagt, nur Erklärung, das Skript macht auch das für euch)
Der Einzeiler wäre für eine Feste Client Beispiel-IP 93.123.23.24 und dem Server-ssh Port 22:
iptables -I INPUT -p tcp --src 93.123.23.24 --dport 22 -j ACCEPTAb jetzt nimmt der Server, sofern keine andere Regel für Port 22 besteht, nur noch Anfragen für ssh von der Adresse 93.123.23.24 entgegen. Das ist save, solange ihr 'Eigentümer' der IP 93.123.23.24 seid.
Dumm nur, wenn es sich um eine dynamisch vom Provider zugeteilte IP handelt. Dann hat man sich beim nächsten IP-Wechsel äußerst wirksam von seinem Server ausgesperrt!!!!
Letzter Ausweg aus dieser Situation wäre dann das VNC-Popup im SCP unter 'Bildschirm'.
Lösung: Wenn man direkten Zugriff auf den Server mit Bildschirm und Tastatur hätte, wäre die Lösung technisch einfach, aber arbeitsintensiv. Bei einen Wechsel der IP von z.B. 93.123.23.24 auf 93.123.105.36 müsste man mit:
iptables -D INPUT -p tcp --src 93.123.23.24 --dport 22 -j ACCEPTdie 'alte' Regel löschen und mit:
iptables -I INPUT -p tcp --src 93.123.105.36 --dport 22 -j ACCEPTdie 'neue' Regel setzen.
Aber, das macht ja niemand, man kann seine Zeit sinnvoller verbringen
Außerdem sitzt ihr ja nicht vor eurem Server, was das Ganze auch nicht leichter macht.
Was macht also das Skript:
Das Skript wird beim Booten des Servers über rc.local gestartet. Es läuft dann im Hintergrund. Als erstes stellt es für eine frei wählbare Zeit einen Fallback-Zustand her, in dem ihr euren Server auf jeden Fall über ssh erreichen könnt. Das funktioniert über die folgende vom Skript automatisch gesetzte iptables Rule(Bsp. Port 22, ist aber frei wählbar):
iptables -I INPUT -p tcp --dport 22 -j ACCEPTSelbstverständlich heißt das nicht, das JEDER sich auf dem Server über ssh einloggen kann. Es gelten natürlich die von euch festgelegten Bedingungen(Passwort bzw. Zertifikat )
Dieser Fallback dient dazu, dass man, falls mal was schief geht beim Testen mit dem Skript, wieder über ssh auf den Server zugreifen kann. Innerhalb der Fallback-Zeit könnt ihr dann über:
ps -auxdie pid des Skriptes ermitteln das Skript killen und zur Fehlersuche auf die vom Skript angelegten Log-Dateien zugreifen.
Wird das Skript nicht gestoppt, legt es nach Ablauf der Fallback-Zeit wie folgt los:
Als erstes wird die Fallback-Regel(Port frei wählbar):
iptables -I INPUT -p tcp --dport 22 -j ACCEPTmittels:
iptables -D INPUT -p tcp --dport 22 -j ACCEPTgelöscht.
Jetzt ermittelt das Skript aus eurer Dyn-Adresse(frei wählbar) die IP z.B.93.123.23.24 und setzt die Regel:
iptables -I INPUT -p tcp --src 93.123.23.34 --dport 22 -j ACCEPTJetzt ist der ssh-Port eures Servers nur noch von eurer Client-IP erreichbar, für andere IP's nicht mehr.
Hier mal ein Beispiel der Ausgabe von:
iptables -t filter -L INPUT --line-numbers -nvor Ablauf der Fallback-Zeit(Auf meinem Server läuft ssh auf port 6666 siehe Zeile 3):
1 f2b-openvpn udp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 1194
2 f2b-sshd tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 6666
3 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:6666
4 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
...und hier der gleiche Befehl nach Ablauf der Fallback-Zeit:
Chain INPUT (policy DROP)
num target prot opt source destination
1 ACCEPT tcp -- 77.22.33.151 0.0.0.0/0 tcp dpt:6666
2 f2b-openvpn udp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 1194
3 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
...Hier sieht man, das der Port 6666 jetzt nur noch von der Client IP 77.22.33.151 erreichbar ist. Die sicherste Konfiguration, die denkbar ist(mho).
Andere Konfigurationen, wie der z.B. udp Port 1194 werden vom Skript nicht angefasst.
Dem aufmerksamen Beobachter wird aufgefallen sein, dass vor der Fallback-Zeit der ssh Port noch durch fail2ban abgesichert war. das ist schon ziemlich sicher, aber liefert einem potenziellen Angreifer die Information, dass es einen offenen Port 6666 gibt. Nach dem Ablauf der Fallback-Zeit bekommt der potenzielle Angreifer aber höchstens die Information, dass der Port 6666 gedropt wird.(Hier dürfen sich gerne! mal die Netzwerkspezialisten in der Diskussion austoben, auf welchem Layer das passiert, und welche genaue Information der Angreifer bekommt. (Ist nicht mein Spezialgebiet, komme eher aus der Software-Ecke.). Logische Konsequenz ist es also, dass das Skript automatisch fail2ban für den ssh-Port abschaltet. Falls fail2ban bei euerem Server nicht läuft, spielt das keine Rolle.
Sobald es zu einem IP-Wechsel auf der Client-Seite kommt, passt das im Hintergrund laufende Skript die iptables-rules entsprechend an. Bei dem oben empfohlenen dynip-Anbieter geht das innerhalb von Sekunden.
Ok, das sollte erst einmal erklären, was ich mache.
Stand heute ist, das Skript läuft auf meinem Server im Testbetrieb. Funktion 99 % Feinheiten 95%. Sobald beides auf 100% wird das hier public mit Anleitung.
Meinungen über die Sinnhaftigkeit sind schon jetzt willkommen.
Anleitung und Skript comming soon.
