CentOS 7 SSH Port ändern, stärkere Cipher, SELinux konfigurieren

Das Ändern des Ports bei SSH ist keine Spielerei, sondern kann anhand von einer einfachen grundlegenden Idee ausgehend, dem Angreifer das Leben ein wenig erschweren. Bei dem Spaß spielen ein Firewallscript mit Honig, der SSHd und SELinux eine gemeinsame Rolle.

Grund der Änderung des Ports bei SSH

Mit dem Umsetzen des Portes des Dienstes SSH erschwere ich das Scannen meines Servers.
Die einfachen Scanmethoden versuchen die üblichen Verdächtigen wie Telnet (21), SSH (22) , SMTP (25), HTTP (80), HTTPs (443), Kerberos (543) etc abzuklopfen und dort die laufenden Dienste zu analysieren.

Durch das Ändern des Ports von SSH, 22, auf einen der Ports über 1024 mache ich mir diesen Umstand zu nutze und erschwere das automatisierte Scannen meines Servers. Natürlich unterbindet dies nicht den gezielten kompletten Scan, aber nach dem Lesen des kompletten Textes dürfte man verstehen worauf hinaus möchte.

Da der Port 22 nun zur freien Verfügung für andere Dienste steht, lasse ich ein ipfilterscript laufen, welches jeden Versuch sich mit Port 22 zu verbinden auch gleich in eine Sperrung der sich zu verbindenden IP übergeht. Ein Scan weiterer Ports des Servers ist erst einmal unmöglich. Der Aufwand der Scriptkiddies aus einer großen Liste nochmals meinen Server herauszufischen ist ein Mehraufwand, welcher kaum unternommen werden wird.

Logwatch meldet mir einen solchen Block der IP:
Logwatch meldet mir einen solchen Block der IP

 

Fazit: Mit dem Umsetzen des Ports der Secureshell erschwere ich die Scaneigenschaften meines Servers durch Bots und automatisierte Scripts, kann einen Honigtopf setzen und muss dazu nur die Regeln von Selinux und der Firewall ändern.

Änderung des Ports und SELinuxregeln

Die Portänderung wird wie bei jeder mir bekannten Distribution in der Datei /etc/ssh/sshd_config vorgenommen. Hier wird der Eintrag Port 22 auf Port DEINEPORTNUMMER geändert.

Hier sollte auch gleich, wie in der Anleitung „Sichere sshd Verschlüsselung in Debian Wheezy“ beschrieben, der Verschlüsselungsalgorithmus gerändert werden. SSH sollte auf keinen Fall jetzt schon neu gestartet werden, denn sonst ist ein Fiasko vorprogrammiert.

Würde man SSH nun neu starten, würde der Dienst einfach absterben. SELinux, vollkommen dazu berechtigt und seiner Aufgabe folgend, unterbindet den Dienst mit dem neuen Port anhand seines Regelwerkes.

[root@teiko yum]# journalctl -x
Feb 09 17:41:29 $TOLLERSERVERNAME sshd[560]: error: Bind to port NEUERPORT on 0.0.0.0 failed: Permission denied.
 Feb 09 17:41:29 $TOLLERSERVERNAME sshd[560]: error: Bind to port NEUERPORT on :: failed: Permission denied.
 Feb 09 17:41:29 $TOLLERSERVERNAME sshd[560]: fatal: Cannot bind any address.

Um SELinux nun eine Regeländerung des SSHports mitzuteilen, sind die Werkzeuge für die Interaktion mit SELinux nötig. Wenn diese noch nicht installiert wurden, muss dies jetzt nachgeholt werden:

[root@teiko yum]# yum -y install policycoreutils-python

Per semanage wird der neue Port dem Regelwerk von SELinux bekannt gegeben und nochmals überprüfen, ob die Änderungen auch vorgenommen wurden:

[root@teiko yum]# semanage port -a -t ssh_port_t -p tcp NEUERPORT
[root@teiko yum]# semanage port -l | grep ssh
[root@teiko yum]# ssh_port_t tcp NEUERPORT, 22

Mit der Löschung des Standardports in den Richtlinien von SELinux kann man sich macht man sich leider keine Freunde, denn dies wird wie folgt kommentiert:

[root@teiko yum]#  semanage port -d -t ssh_port_t -p tcp 22
 ValueError: Port tcp/22 ist in der Richtlinie festgelegt und kann nicht gelöscht werden

Erstellen neuer Firewallregeln

Für den firewalld wäre dies:

[root@teiko yum]# firewall-cmd --permanent --zone=public --add-port=NEUERSSHPORT/tcp
[root@teiko yum]# firewall-cmd --reload

Wer möchte kann den Service auch in die Datei /etc/firewalld/services/ eintragen , da jene ein Override für die definierten Dienste in /usr/lib/firewalld/services/ ist. Mehr Auskunft zu diesem Thema ist in dem  Kapitel 4.5. Using Firewalls von RedHat zu finden.

! Mit firewalld lässt sich das untere Script nicht in diesen Form nutzen, sondern es müsste umgeschrieben werden. !

Neustart

Nach der Änderung des Verschlüsselungsalgorithmus muss noch eine Neugenerierung der Schlüssel durch die Löschung der alten Schlüssel erzwungen werden. Nun kann der SSHserver neu gestartet werden.

[root@teiko yum]# rm -r /etc/ssh/ssh*key
[root@teiko yum]# systemctl restart sshd.service

Zu einem Test kann man sich nun auf einer anderen Kommandozzeile, ohne die laufenden Sitzung zu beenden, an seinem Server anmelden und schauen ob der Login funktioniert ssh -pNEUERPORT USERNAME@SERVERIP/NAME.

 Honigtopf

Das am Anfang genannte Script gibt es in einem Gist auf Github und ist hier zu finden:

 

Danke für das Lesen und viel Spaß

8 Comments

    1. Schrieb ich in dem Artikel, Dirk.

      Ein Scan weiterer Ports des Servers ist erst einmal unmöglich. Der Aufwand der Scriptkiddies aus einer großen Liste nochmals meinen Server herauszufischen ist ein Mehraufwand, welcher kaum unternommen werden wird.

      Inklusive dem Script und noch weiterer Maßnahmen haben ich sehr viel Ruhe am Server und gerade für kleine Maschinen ist dies sehr Entspannend.
      Ich sehe die Änderung des Ports alleine nicht als wichtig an, welches ich auch im dritten Absatz, bzw im zweiten Absatz wenn man das Intro nicht mitrechnet, betonte.
      Nur den Port zu ändern ist lächerlich, weitere Maßnahmen zu ergreifen ist Wichtig.
      Das ist für mich nur ein sehr sehr kleiner Teil meine Server zu schützen und Dein nmap in unter einer Minute funktioniert nicht, da ja vielleicht auch andere Ports das gleich Spiel nochmals mitmachen.
      Somit hast Du erst einmal eine massive Verzögerung des Scans, da Du schon bei der ersten Falschen Kontaktaufnahme geblockt wirst. Die geht n-male.
      Es greifen wie gesagt auch weitere Maßnahmen.
      Es wäre ja als würde ich mit mod_security versuchen andere wichtige IDS-Elemente nichtig zu machen. Jedes Teil hat seine Aufgabe.
      Und probiere es doch einfach mal selbst aus.
      Werfe das Script bei Dir auf den Server, ändere den Port und überfliege eine Woche mal Logwatch.
      Und die Logik erschliesst auch Dir, da bin ich mir sicher

      Grüsse

    1. Eine Machbarkeitsstudie ist es nicht, für mich ist es ein kleines Rad in meinem IDS.
      Und das sage ich nicht trotzig ;)
      Ich könnte mir ja auch OSSec oder sonstiges installieren, versuche aber gerade auf sehr kleinen Maschinen es doch etwas ruhiger anzugehen

  1. Nein, ich verstehe Dich schon richtig.

    Ich betreue einige sehr prominente Server im Netz und habe auf diesen das Bedrohungsszenario nicht. Daher ergibt sich für mich kein Zusatznutzen.

    Sollte sich das ändern, würde ich auf Deine Arbeit zurückkommen.

Schreibe einen Kommentar

You have to agree to the comment policy.