SSH Nur für diesen einen Host

4

4nD3r5

Mitglied
Hallo,
wollte mal nachfragen ob ich die SSH Verbindung vollständig blocken kann außer für die IP Adresse xyz die hinter der URL abc steht? Heißt das ich bei Putty z.B. einen Network Error "Connection Refused" bekäme, auch wenn der Port und alles richtig wäre, meine IP aber nicht mit der IP welche hinter der freigegebenen Domain steht übereinstimmt.

Geht das? Und wenn ja wie? habs mit hosts.allow und hosts.deny ausprobiert... nur irnwie tut sich da gar nichts... selbst wenn ich in die hosts.deny ALL : ALL reinschreibe und die .allow leer lasse und dann reboote komme ich sogar noch per SSH druf. (und alles andere geht auch obwohl das doch eigtl. gar ned gehen sollte?!?!?)

Gruß Dominik
 
Sperre den Login per Passwort, so das du nur mit nem Key reinkommst.
 
Alternativ einfach per iptables den SSH-Port (Default: 22) nur für diese IP freigeben.
 
ähm... hat da evtl. jemand den Befehl für mich oder kann mir sagen wie ich das in irgendeine Datei reinschreiben soll? hab mit IPTables noch ned gearbeitet... wäre nett
 
Code: 
# erstmal sicherstellen, dass man nicht rausgeworfen wird
iptables -A INPUT -m state --state ESTABLISHED,RELATED -p tcp --dport 22 -j ACCEPT
# setze Default-Policy fuer diesen Port auf DROP
iptables -A INPUT -m state --state NEW -p tcp --dport 22 -j DROP
# erlaube Verbindungen von <deine-ip>
iptables -A INPUT -m state --state NEW -p tcp -s <deine-ip> --dport 22 -j ACCEPT
So aus dem Kopf müsste es das sein. Wenn es nicht funktioniert, schau halt in die Manpage von iptables 'man iptables'. Hab jetzt nicht wirklich Lust mich durch die Manpage zu wuseln, nur weil du zu faul bist, bin ich nämlich auch. ;)
Wichtig: iptables muss als root ausgeführt werden.
 
#ListenAddress 0.0.0.0 wäre doch die Lösung direkt durch die ssh config..

/etc/ssh/sshd_config < -- config Datei
 
Damit bindet er den SSH-Server ja nur an eine spezifische IP des Servers, sofern dieser mehrere IPs hat. Das ermöglicht nicht, dass er nur von einer spezifischen IP aus auf den Server via SSH Zugriff bekommt. Der Server "lauscht" dann halt nur an dem Interface mit dieser IP.
 
Die Hostbased Authentication ist ja auch Standardmäßig abgeschaltet
Code: 
 38 HostbasedAuthentication no
 39 # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
 40 #IgnoreUserKnownHosts yes

Ist auch nicht so das gelbe vom Ei. Hostnamen lassen sich ja nach belieben vergeben.
 
iptables --list
Note: /etc/modules.conf is more recent than /lib/modules/2.6.18-ck1-rootserver/modules.dep
modprobe: QM_MODULES: Function not implemented

modprobe: QM_MODULES: Function not implemented

modprobe: Can't locate module ip_tables
iptables v1.2.11: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
Zum Vergrößern anklicken....

Was nun?
 
hi

oder du trägst es in der

/etc/hosts.allow ein, welche IP´s Zugriff haben

so long...
 
4nD3r5 schrieb:
Hallo,
[...]
habs mit hosts.allow und hosts.deny ausprobiert... nur irnwie tut sich da gar nichts... selbst wenn ich in die hosts.deny ALL : ALL reinschreibe und die .allow leer lasse und dann reboote komme ich sogar noch per SSH druf. (und alles andere geht auch obwohl das doch eigtl. gar ned gehen sollte?!?!?)

Gruß Dominik
Zum Vergrößern anklicken....

Wie bereits gesagt ... keine Ahnung wieso dem so ist aber es geht trotzdem
 
Kann es sein, dass es sich hier um einen Server von 1und1 handelt? ;) Da hatte ich nämlich auch schonmal genau das gleiche Problem. Hab den genau deswegen sofort gekündigt. Brauchte einen kommerziellen Treiber die Kiste und den wollten sie mir nicht geben, im WWW war er nirgends zu finden.

Du hast jetzt definitiv ein Problem, nämlich einen Server ohne iptables-Unterstützung im Kernel. Da hilft nur eines: neuen Kernel bauen.
 
nein habe einen Server von NGZ... das mit dem Kernel bauen hat mir heute schonmal jemand gesagt *g aber wie soll jemand der da nicht all zu viel ahnung von hat das machen? wieso gehen die hosts.allow und hosts.deny Dateien eigtl. nicht? gibt es dafür auch irgendwo einen "Schalter"?
gibt es noch eine andere Firewall die gut ist und die ich mir installieren kann?
 
Der SSH-Server nutzt diese hosts_access-Funktionen nicht. Diese werden primär vom Portmapper und von (x)inetd verwendet.
Und nein, es gibt keine bessere Firewall als iptables, da nur diese direkt in den Kernel integriert ist, wodurch sie nicht einfach wie eine Applikationsfirewall von einem Angreifer ausgeschaltet werden kann. Allerdings stellt sich mir die Frage, warum du dir anmaßt einen Server zu verwalten, wenn du selbst von dir sagst, dass du nicht allzuviel Ahnung hast. Server sind kein Spielzeug und wenn die Kiste aufgrund deiner mangelnden Kenntnisse mal gehackt wird, kann das ziemlich teuer für dich werden, wenn z.B. der Angreifer den Server zum Spammen oder Warez verteilen missbraucht. Leg dir also schon 7000-8000 Euro auf die hohe Kante, damit du dich nicht in Schulden stürzt, wenn das mal eintritt. Kernel bauen sollte für den Admin eines Servers Routine sein.
 
habe gerade mal in das sbin Verzeichnis geschaut und festgestellt das dort die datei iptables liegt, allerdings mit nem * davor.

Ach ja und die andere Sache ist... ich bin mir dieses Risikos durchaus bewusst und deshalb prüfe ich auch alles mögliche täglich.
Das ist auch der Grund warum ich schon einige Dinge geändert habe von denen ich mehr Ahnung habe, um genau das halt zu vermeiden
 
Zuletzt bearbeitet:
Der '*' vor dem Dateinamen bedeutet lediglich, dass es sich um eine ausführbare Datei handelt. Aber nur weil das Programm installiert ist, heisst das noch lange nicht, dass im Kernel auch iptables-Unterstützung drin ist. Das Programm ist nur zum Setzen der Regeln da. Die Firewall selbst wird über die entsprechenden LKM vom Kernel realisiert.

Tip für deinen Server: Bastel gleich einen Stack-Smashing-Guard in den Kernel (Openwall o.ä.) und setze dir Snort als IDS auf. Erstelle ausserdem mit AIDE eine Datei-Integritätsdatenbank, die du dir zu Hause auf einen USB-Stick packst, damit du mitbekommst, wenn Dateien geändert wurden. Ausserdem sollte chkrootkit regelmässig aktualisiert werden und es sollte min. einmal am Tag laufen, damit du das Einschleusen eines Rootkits möglichst schnell bemerkst. Zusätzlich sollte 'tiger' einmal am Tag laufen um sicherzustellen, dass nicht irgendwelche Kernel-Trojaner oder versteckte Prozesse eingeschleust werden. Dass man als Shell für Systemuser (www-data, daemon, nobody u.ä.) /bin/false eintragen sollte, versteht sich hoffentlich von selbst. Eine gültige Shell sollten nur root und die User haben, die Shell-Zugriff haben sollen.
 
Zuletzt bearbeitet:
dann werde ich die nächsten tage viel lesen weil ich gehe mal davon aus das ich mir schon nen buch durchlesen muss oder gibt es ein wirklich gutes Tut. im Inet?
 
Das alles kann man nicht in ein einziges Howto packen. Da wirst du schon ein paar mehr lesen müssen.
 
Ja ich meinte eigtl. auch nur die Scache mit dem Kernel bauen
 
Anmelden, um zu antworten.

Ähnliche Themen

Keine socket connections auf Debian lenny
Keine socket connections auf Debian lenny: Hallo! Ich habe hier ein kleines Problem mit einem Debian Server. Heute morgen als ich mich wie gewohnt per SSH einloggen wollte bekam ich ein: ssh...

Neueste Themen

Zurück
Oben