Hallo, so, ich habe jetzt Gentoo gelöscht und SuSE auf meinen Webserver installiert. Nun habe ich in /var/log/messages gesehen, dass sich da jemand einloggen wollte. Wie sichert man so einen Server richtig ab? Bisher habe ich nur die nötigsten Pakete installiert, und es sind nur drei Ports offen (80, 22, 8080). Dann wollte ich einen weiteren User mit root-Rechten anlegen, aber in die Gruppe "root" aufnehmen, reicht wohl nicht, damit man den Benutzer root deaktivieren kann. Weiterhin habe ich in sshd_config "PermitRootLogin no" eingetragen. Nun kann ich mich jedoch nicht mehr mit root einloggen, wie gewünscht, aber auch der andere User der Gruppe root funktioniert nicht. Blöderweise funktioniert auch su von einen normalen User aus nicht mehr. Habe mich also ausgesperrt (peinlich, peinlich) Könnte das letztere Problem daran liegen, dass ich in den "Einstellungen zur Sicherheit" von yast bei den Dateirechten "paranoid" ausgewählt habe? Werde also nachher erstmal zur Arbeit fahren müssen, um zumindest den ssh-Zugang für root wieder zu aktivieren. Wäre für Tipps dankbar. MfG Kay
On Thu, 15 Sep 2005, Kay Patzwald wrote:
Dann wollte ich einen weiteren User mit root-Rechten anlegen, aber in die Gruppe "root" aufnehmen, reicht wohl nicht, damit man den Benutzer root deaktivieren kann.
Der User braucht die UID 0. Alle User mit UID 0 sind 'root'. Ich weiss nicht ob man den User 'root' deaktivieren kann, aber Du kannst ihm als Passwort '*' setzen, dann ist ein Login auch ausgeschlossen. Da sollte aber ein alternativer root vorher verfuegbar sein.
Weiterhin habe ich in sshd_config "PermitRootLogin no" eingetragen. Nun kann ich mich jedoch nicht mehr mit root einloggen, wie gewünscht, aber auch der andere User der Gruppe root funktioniert nicht.
Ja ist imo korrekt. So gesetzt soll von aussen kein root auf der Maschine agieren koennen. Es bedarf dann einer Administration vor Ort.
Blöderweise funktioniert auch su von einen normalen User aus nicht mehr. Habe mich also ausgesperrt (peinlich, peinlich) Könnte das letztere Problem daran liegen, dass ich in den "Einstellungen zur Sicherheit" von yast bei den Dateirechten "paranoid" ausgewählt habe?
IMO Waere ein su in dem Fall gleichzusetzen mit einem root-login und es ist deshalb ausgeschlossen. (cmiiw)
Werde also nachher erstmal zur Arbeit fahren müssen, um zumindest den ssh-Zugang für root wieder zu aktivieren.
Ja gute Idee. ;) Im Prinzip war dein Ansatz schon richtig, aber halt nicht praktikabel wenn Du den Server remote administrieren musst. by, DVC
Dominic Valerie Casare, Donnerstag, 15. September 2005 10:40:
Weiterhin habe ich in sshd_config "PermitRootLogin no" eingetragen. Nun kann ich mich jedoch nicht mehr mit root einloggen, wie gewünscht, aber auch der andere User der Gruppe root funktioniert nicht.
Ja ist imo korrekt. So gesetzt soll von aussen kein root auf der Maschine agieren koennen. Es bedarf dann einer Administration vor Ort.
Das stimmt nicht. Man kann den root-Login sperren, und trotzdem per su zu root werden. Auf meiner Maschine sieht das so aus: # cat /etc/ssh/sshd_config | grep -i root PermitRootLogin no Sodann ein rcsshd restart, und alles tut. -- Andre Tann
On Thu, 15 Sep 2005, Andre Tann wrote:
Ja ist imo korrekt. So gesetzt soll von aussen kein root auf der Maschine agieren koennen. Es bedarf dann einer Administration vor Ort. Das stimmt nicht. Man kann den root-Login sperren, und trotzdem per su zu root werden.
Oha, haette ich nicht gedacht. Untergraebt das nicht das ganze Konzept? Einen Useraccount auf einem Server zu bekommen koennte doch noch einfacher sein als gleich den root-login zu knacken. Der User kann dann in Ruhe mit su sein Glueck versuchen... Danke fuer den Hinweis btw. by, DVC
Dominic Valerie Casare, Donnerstag, 15. September 2005 11:25:
Oha, haette ich nicht gedacht. Untergraebt das nicht das ganze Konzept? Einen Useraccount auf einem Server zu bekommen koennte doch noch einfacher sein als gleich den root-login zu knacken. Der User kann dann in Ruhe mit su sein Glueck versuchen...
Du mußt den Benutzernamen und dessen Paßwort, und sodann das root-Paßwort erraten. Im anderen Fall mußt Du nur das root-Paßwort erraten. Ob man generell ein su für normale Nutzer, die über ssh gekommen sind, verbieten kann, weiß ich nicht. Die Frage wäre ohnehin, ob es einen Sicherheitsgewinn darstellte. -- Andre Tann
On Thu, 15 Sep 2005 11:17:06 +0200, Andre Tann <atann@gmx.net> wrote:
Dominic Valerie Casare, Donnerstag, 15. September 2005 10:40:
Weiterhin habe ich in sshd_config "PermitRootLogin no" eingetragen. Nun kann ich mich jedoch nicht mehr mit root einloggen, wie gewünscht, aber auch der andere User der Gruppe root funktioniert nicht.
Ja ist imo korrekt. So gesetzt soll von aussen kein root auf der Maschine agieren koennen. Es bedarf dann einer Administration vor Ort.
Das stimmt nicht. Man kann den root-Login sperren, und trotzdem per su zu root werden. Auf meiner Maschine sieht das so aus:
# cat /etc/ssh/sshd_config | grep -i root PermitRootLogin no
Sodann ein rcsshd restart, und alles tut.
Aber warum funktioniert dann su bei mir nicht mehr?
Am 15.09.2005 12:01 schrieb Kay Patzwald:
Aber warum funktioniert dann su bei mir nicht mehr?
Evtl. liegt das an den paranoid-Einstellungen die du oben genannt hast. Nur als Schuss ins Blaue. OJ -- Ich verstehe nichts von Musik. In meinem Fach ist das nicht nötig. (Elvis Aaron Presley, amerikanischer Schauspieler und Musiker, 1935-1977)
Johannes Kastl schrieb:
Am 15.09.2005 12:01 schrieb Kay Patzwald:
Aber warum funktioniert dann su bei mir nicht mehr?
Evtl. liegt das an den paranoid-Einstellungen die du oben genannt hast. Nur als Schuss ins Blaue.
Es ist in der Tat so, dass (bei der 9.1 hier zumindest) Das Suid-Bit bei /bin/su fehlt. Als root anmelden kann man sich dann zwar noch, allerdings funktioniert das su von den usern aus nicht mehr. chmod 4755 `which su` sollte helfen. Wenn du die Sicherheitseinstellungen nicht ändern möchtest, kannst du das vielleicht einfach in die /etc/permissions.local eintragen. Gruß Sören
Nun habe ich in /var/log/messages gesehen, dass sich da jemand einloggen wollte. Wie sichert man so einen Server richtig ab?
Ich schlage vor root das einloggen zu verbieten (damit man 2 Passwörter finden muss), mit AllowGroups die Zugehörigkeit zu einer bestimmten Gruppe zu forden (dann fallen alle bekannten Accounts weg, falls die mal aus versehen ein Passwort haben). Wie wäre es noch mit einer Spassbremse in /etc/sysconfig/scripts/SuSEfirewall-custom im Abschnitt fw_custom_after_antispoofing() iptables -N sshd_bf iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j sshd_bf iptables -A sshd_bf -j LOG --log-prefix "sshd_brute_force " iptables -A sshd_bf -j DROP Wer mehr als 3 Anmeldeversuche innerhalb einer Minute macht wird erstmal eine Minute ausgesperrt. Habe noch keinen Scanner gehabt der nach der Sperre wiederkam.
On Thu, 15 Sep 2005 11:38:19 +0200, Holger Krull <holger.krull@gmx.de> wrote:
Nun habe ich in /var/log/messages gesehen, dass sich da jemand einloggen wollte. Wie sichert man so einen Server richtig ab?
Ich schlage vor root das einloggen zu verbieten (damit man 2 Passwörter finden muss), mit AllowGroups die Zugehörigkeit zu einer bestimmten Gruppe zu forden (dann fallen alle bekannten Accounts weg, falls die mal aus versehen ein Passwort haben). Wie wäre es noch mit einer Spassbremse in /etc/sysconfig/scripts/SuSEfirewall-custom im Abschnitt fw_custom_after_antispoofing()
iptables -N sshd_bf iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j sshd_bf iptables -A sshd_bf -j LOG --log-prefix "sshd_brute_force " iptables -A sshd_bf -j DROP
Nachdem nun in der dritten Nacht in Folge jemand versucht hat, in den Server einzubrechen, interessiere ich mich doch für diese Spaßbremse. Kann jemand erläutern, was diese Befehle genau bedeuten?
Wer mehr als 3 Anmeldeversuche innerhalb einer Minute macht wird erstmal eine Minute ausgesperrt. Habe noch keinen Scanner gehabt der nach der Sperre wiederkam.
Kay Patzwald wrote:
Wie wäre es noch mit einer Spassbremse in /etc/sysconfig/scripts/SuSEfirewall-custom im Abschnitt fw_custom_after_antispoofing()
iptables -N sshd_bf iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j sshd_bf iptables -A sshd_bf -j LOG --log-prefix "sshd_brute_force " iptables -A sshd_bf -j DROP
Nachdem nun in der dritten Nacht in Folge jemand versucht hat, in den Server einzubrechen, interessiere ich mich doch für diese Spaßbremse. Kann jemand erläutern, was diese Befehle genau bedeuten?
Am besten, du ackerst dich mal durch ein paar Tutorials für iptables durch. Nach ein paar von den Dingern kommt so langsam das Begreifen. (^-^) Die erste Regel erstellt die neue Chain "sshd_bf". Die zweite Regel stellt einen Zähler für ssh Kontakte auf. Die dritte Regel leitet die Kontaktversuche in die Chain sshd_bf um, wenn der Zähler in den letzten 60 Sekunden 4 Hits bekommen hat. Die vierte Regel (für sshd_bf) logged den Kontaktversuch zum Syslog. Die fünfte Regel bricht den Kontakt ab. Wenn ein Script also eine Reihe von Namen und Passwörtern durchprobiert, dann ist bei dem vierten Versuch innerhalb von 60 Sekunden Feierabend. Alle ssh Kontaktversuche werden geblockt. Dies gilt übrigens auch für deine eigenen! Wenn du auf ssh angewiesen bist, dann reicht es für einen Denial of Service also aus, alle 10 Sekunden einen ssh Kontakt zu deiner Maschine zu öffnen. Vielleicht wäre es sinnvoll, statt dessen eine Regel zu setzen, die für eine begrenzte Zeit die IP blockt. Wenn die Maschine zwei Interfaces hat mit intern/extern könnte man diese Regel auch nur für das externe Interface setzen. Es gab mal eine Zeit, wo selbstständig reagierende Firewalls der Hit waren und diese automatische Regeln zum Sperren von IPs/Diensten hatten. Einige Spaßvögel haben dann Wege gefunden, das die Regeln dann plötzlich die IPs ihrer eigenen Nameserver oder ähnlich wichtige Server geblockt haben. Seitdem ist es etwas stiller geworden um solche Automatismen. Ich finde es gut, dass du vor dem aktiven Einsatz einer solchen Regel versuchst, die Funktion zu vestehen. Acker dich am besten mal durch die Manpage von iptables durch und versuche dann, das SuseFirewall2 Script zu verstehen. Wenn du das geschafft hast, hast du ein sehr hilfreiches Wissen erworben. (^-°) Sandy
Holger Krull schrieb:
Wie wäre es noch mit einer Spassbremse in /etc/sysconfig/scripts/SuSEfirewall-custom im Abschnitt fw_custom_after_antispoofing()
iptables -N sshd_bf iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j sshd_bf iptables -A sshd_bf -j LOG --log-prefix "sshd_brute_force " iptables -A sshd_bf -j DROP
Wer mehr als 3 Anmeldeversuche innerhalb einer Minute macht wird erstmal eine Minute ausgesperrt. Habe noch keinen Scanner gehabt der nach der Sperre wiederkam.
@Sandy Drobic: Dies Bremse blockiert nicht alle ssh-Verbindungen sondern nur den Angreifer Im Einzelnen:
iptables -N sshd_bf Neue Chain erstellen, Name ist sshd_bf
iptables -A sshd_bf -j LOG --log-prefix "sshd_brute_force " iptables -A sshd_bf -j DROP
Die Regeln für die neue Chain, erstens wird der Vorgang geloggt und dann das Paket weggeworfen Hier kommen Ausnahmeregeln rein, falls man Rechner hat von denen tatsächlich mehrere neue Verbindungen pro Minute kommen. (iptables -A sshd_bf -p tcp -m tcp --src 193.99.144.85 -j RETURN)
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set
Die eigentliche Treffer Regel Hier wird der Chain INPUT , Tabelle filter (das ist default) eine Regel hinzugefügt die -p tcp --dport TCP Verbindung nach Port 22 erwischt -m state --state NEW Modul state Treffer nur bei neuer Verbindung -m recent --name SSH --set Das Modul trägt die Absenderadresse in die Tabelle SSH ein, ist diese schon vorhanden wird der Eintrag aufgefrischt. Das ist die eigentliche Aktion dieser Regel, und der Grund warum die DROP Regel hinterher auch nur den Absender erwischt.
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j sshd_bf
Verzweigung zur Chain sshd_bf und zwar nur -p tcp --dport wenn das ein TCP Paket für Port 22 ist -m recent Das Modul recent wird gefragt --update Treffer wenn die Absenderadresse in der Liste ist --seconds 60 Und der letzte Eintrag dieser Adresse nicht länger als 60 Sekunden zurück liegt --hitcount 4 Und das jetzt der vierte Treffer ist (3 Versuche frei, der vierte und folgende werden geblockt --rttl das ganze gilt nur wenn die TTL (time to live) identisch mit derjenigen des ersten --set ist (darüber kann man diskutieren ich weiss, hilft aber gegen DOS) --name SSH alles nur für die Tabelle SSH -j wir springen zu sshd_bf Wer mehr als 100 ausstehende Verbindungen erwartet muss die Tabelle des recent Moduls vergrössern. modprobe ipt_recent ip_list_tot=1000 #falls zuviele Verbindungen recent hat sonst nur 100 Einträge
Hallo Kay, hallo Leute, Am Donnerstag, 15. September 2005 10:01 schrieb Kay Patzwald:
Nun habe ich in /var/log/messages gesehen, dass sich da jemand einloggen wollte.
Du redest von SSH-Login(versuchen)? Die gibt es in letzter Zeit massig. Auf dem von mir betreuten Server habe ich inzwischen SSH so eingestellt, dass der Login ausschließlich mit SSH-Key möglich ist. Ich glaube kaum, dass jemand einen 1024-bit-Key "zufällig" knackt ;-) Ich habe nichtmal den direkten Root-Login per SSH (Key!) verboten, allerdings mit command=... in der authorized_keys (-> man sshd) auf rsync-Aufrufe fürs Backup beschränkt. Lesetipp: 9.7. Wie kann ich den Login ausschließlich mit SSH-Keys erlauben? http://suse-linux-faq.koehntopp.de/q/q-ssh-keyonly.html (die anderen Texte im SSH-Kapitel sind evtl. auch für Dich interessant.)
Wie sichert man so einen Server richtig ab? Bisher habe ich nur die nötigsten Pakete installiert, und es sind nur drei Ports offen (80, 22, 8080).
Wofür 8080? Ist das ein Zweitport für Apache oder irgendein Proxy?
Dann wollte ich einen weiteren User mit root-Rechten anlegen, aber in die Gruppe "root" aufnehmen, reicht wohl nicht, damit man den Benutzer root deaktivieren kann.
Wie Du inzwischen erfahren hast, muss der andere User auch die UID 0 haben. Ich sehe in dieser Maßnahme allerdings keinen rechten Sinn - nicht der Username sollte die Hürde sein, sondern das Passwort. Den Usernamen kann übrigens jeder mit einem lokalen Account selbst rausbekommen: getent passwd |grep :0:
Weiterhin habe ich in sshd_config "PermitRootLogin no" eingetragen. Nun kann ich mich jedoch nicht mehr mit root einloggen,
Klar, das ist der gewünschte Effekt ;-)) Gruß Christian Boltz -- Wenn man keine Vögel mag, ist es völlig in Ordnung, mit Kanonen auf Spatzen zu schiessen. [Ratti in suse-linux]
On Fri, 16 Sep 2005 00:50:37 +0200, Christian Boltz <suse@cboltz.de> wrote:
Hallo Kay, hallo Leute,
Am Donnerstag, 15. September 2005 10:01 schrieb Kay Patzwald:
Nun habe ich in /var/log/messages gesehen, dass sich da jemand einloggen wollte.
Du redest von SSH-Login(versuchen)? Die gibt es in letzter Zeit massig. Auf dem von mir betreuten Server habe ich inzwischen SSH so eingestellt, dass der Login ausschließlich mit SSH-Key möglich ist. Ich glaube kaum, dass jemand einen 1024-bit-Key "zufällig" knackt ;-)
Das habe ich jetzt auch so eingerichtet. Man kann sich nur noch per Zertifikat einloggen. Passwort-Authentifizierung habe ich komplett deaktiviert, und auch root darf sich nicht mehr einloggen. Damit ich als normaler Nutzer aber noch su verwenden kann, habe ich die Dateirechte wieder auf "Sicher" gestellt. :-)
Ich habe nichtmal den direkten Root-Login per SSH (Key!) verboten, allerdings mit command=... in der authorized_keys (-> man sshd) auf rsync-Aufrufe fürs Backup beschränkt.
Lesetipp: 9.7. Wie kann ich den Login ausschließlich mit SSH-Keys erlauben? http://suse-linux-faq.koehntopp.de/q/q-ssh-keyonly.html (die anderen Texte im SSH-Kapitel sind evtl. auch für Dich interessant.)
Wie sichert man so einen Server richtig ab? Bisher habe ich nur die nötigsten Pakete installiert, und es sind nur drei Ports offen (80, 22, 8080).
Wofür 8080? Ist das ein Zweitport für Apache oder irgendein Proxy?
Ist für den Tomcat.
Dann wollte ich einen weiteren User mit root-Rechten anlegen, aber in die Gruppe "root" aufnehmen, reicht wohl nicht, damit man den Benutzer root deaktivieren kann.
Wie Du inzwischen erfahren hast, muss der andere User auch die UID 0 haben. Ich sehe in dieser Maßnahme allerdings keinen rechten Sinn - nicht der Username sollte die Hürde sein, sondern das Passwort.
Den Usernamen kann übrigens jeder mit einem lokalen Account selbst rausbekommen: getent passwd |grep :0:
OK, darauf habe ich jetzt sowieso verzichtet.
Weiterhin habe ich in sshd_config "PermitRootLogin no" eingetragen. Nun kann ich mich jedoch nicht mehr mit root einloggen,
Klar, das ist der gewünschte Effekt ;-))
Gruß
Christian Boltz
participants (8)
-
Andre Tann -
Christian Boltz -
Dominic Valerie Casare -
Holger Krull -
Johannes Kastl -
Kay Patzwald -
Sandy Drobic -
Sören Wengerowsky