Für diejenigen, die sich selbst den Zugang zu ihren Servern von überall auf der Welt per SSH/RDP/anderweitig sichern möchten — ein kleiner RTFM/Spickzettel.

Wir müssen ohne VPN und andere extravagante Sachen auskommen, ganz einfach von jedem verfügbaren Gerät.

Und so, dass man sich nicht zu sehr mit dem Server belasten muss.

Alles, was dafür nötig ist — knockd, geschickte Hände und 5 Minuten Arbeit.

„Im Internet gibt es alles“, natürlich (sogar auf Habr), aber wenn es um die konkrete Umsetzung geht — da fängt das Problem an…

Wir werden am Beispiel von Fedora/CentOS üben, aber das spielt keine Rolle.

Der Spickzettel eignet sich sowohl für Anfänger als auch für alte Hasen, daher werden Kommentare gegeben, aber kürzer.

1. Server

installieren wir den knock-server:
yum/dnf install knock-server

wir konfigurieren ihn (zum Beispiel für ssh) — /etc/knockd.conf:

[options]
    UseSyslog
    interface = enp1s0f0
[SSHopen]
    sequence        = 33333,22222,11111
    seq_timeout     = 5
    tcpflags        = syn
    start_command   = iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
    cmd_timeout     = 3600
    stop_command    = iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
[SSHclose]
    sequence        = 11111,22222,33333
    seq_timeout     = 5
    tcpflags        = syn
    command         = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT

Der „öffnende“ Teil ist so konfiguriert, dass er sich nach 1 Stunde automatisch schließt. Wer weiß…

/etc/sysconfig/iptables:

...
-A INPUT -p tcp -m state --state NEW -m tcp --dport 11111 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22222 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 33333 -j ACCEPT
...

Vorwärts:

service iptables restart
service knockd start

Man kann RDP für einen virtuellen Windows Server einrichten (/etc/knockd.conf; den Schnittstellennamen nach Belieben ersetzen):

[RDPopen]
    sequence        = 44444,33333,22222
    seq_timeout     = 5
    tcpflags        = syn
    start_command   = iptables -t nat -A PREROUTING -s %IP% -i enp1s0f0 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.0.2
    cmd_timeout     = 3600
    stop_command    = iptables -t nat -D PREROUTING -s %IP% -i enp1s0f0 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.0.2
[RDPclose]
    sequence        = 22222,33333,44444
    seq_timeout     = 5
    tcpflags        = syn
    command         = iptables -t nat -D PREROUTING -s %IP% -i enp1s0f0 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.0.2

Alle unsere Kundeninteraktionen verfolgen wir auf dem Server mit dem Befehl iptables -S.

2. Leitfaden zu Stolperfallen

knockd.conf:

Im Handbuch ist auch alles enthalten (aber das ist ungenau), jedoch ist knockd relativ sparsam mit Nachrichten, daher muss man sehr aufmerksam sein.

Version
In den Repositories von Fedora/CentOS ist die aktuelle Version von knockd heute - 0.63. Wer UDP benötigt, sollte nach den Paketen 0.70 suchen.
Schnittstelle
In der Standardkonfiguration von Fedora/CentOS fehlt diese Zeile nicht vorhanden. Man muss sie manuell hinzufügen, sonst funktioniert es nicht.
timeout
Hier nach deinem Geschmack auswählen. Es muss genug Zeit für alle Anfragen bleiben — und der Port-Scan-Bot hat Schwierigkeiten (und es werden 146 % gescannt).
start/stop/command.
Wenn der Befehl einzeln ist — dann command, wenn zwei — dann start_command+stop_command.
Wenn du einen Fehler machst — wird knockd schweigen, aber nicht funktionieren.
proto
Theoretisch kann man UDP verwenden. In der Praxis habe ich TCP und UDP gemischt, und der Kunde am Strand in Bali konnte seine Tür erst beim fünften Versuch öffnen. Denn das TCP kam an, wenn es nötig war, aber bei UDP ist das nicht sicher. Aber das ist Geschmackssache.
sequence
Eine subtile Falle besteht darin, dass Sequenzen sich nicht überschneiden sollten… wie soll ich das sagen…

Zum Beispiel so:

open: 11111,22222,33333
close: 22222,11111,33333

Beim Ping 11111 öffnen wird auf den nächsten Ping auf 22222 gewartet. Doch bei diesem (22222) Ping wird es anfangen zu funktionieren close und alles wird kaputtgehen. Das hängt auch von der Verzögerung des Clients ab. So ist das ©.

iptables

Wenn in /etc/sysconfig/iptables das hier steht:

*nat
:PREROUTING ACCEPT [0:0]

uns nicht wirklich stört, dann ist das hier:

*filter
:INPUT ACCEPT [0:0]
...
-A INPUT -j REJECT --reject-with icmp-host-prohibited

doch störend.

Da knockd die Regeln am Ende der INPUT-Kette hinzufügt, erhalten wir einen Reject.

Und diesen Reject zu deaktivieren — das hieße, die Maschine allen Winden zu öffnen.

Um die Einstellungen in iptables nicht kompliziert zu gestalten (wie es viele Leute vorschlagen), machen wir es einfacher:

die Standardregel in CentOS/Fedora die erste Regel ("was nicht verboten ist, ist erlaubt") ersetzen wir durch das Gegenteil,
und die letzte Regel entfernen wir.

Das Ergebnis sollte sein:

*filter
:INPUT DROP [0:0]
...
#-A INPUT -j REJECT --reject-with icmp-host-prohibited

Natürlich kann man anstelle von DROP auch REJECT verwenden, aber mit DROP geht es Bots besser.

3. Client

Hier wird es meiner Meinung nach am interessantesten, da man nicht nur von jedem Ort aus arbeiten muss, sondern auch von jedem Gerät.

Grundsätzlich sind einige Clients auf Webseite der Website aufgeführt, aber das gehört auch zur Kategorie "im Internet gibt es alles". Daher liste ich auf, was hier und jetzt für mich verfügbar ist.

Bei der Auswahl eines Clients sollte darauf geachtet werden, dass er die Option zur Verzögerung zwischen den Paketen unterstützt. Ja, jeder Strand ist anders und 100 Megabit garantieren nicht, dass die Pakete in der richtigen Reihenfolge und zur richtigen Zeit an diesem Ort ankommen.

Und ja — bei der Einstellung der Verzögerung des Clients muss man selbst das richtige Maß wählen. Zu viel Timeout — die Bots greifen an, zu wenig — der Client kommt nicht nach. Zu viel Verzögerung — der Client kommt nicht nach oder es kommt zu Konflikten (siehe „Schritte“), zu wenig — die Pakete verirren sich im Internet.

Bei timeout=5s ist delay=100..500ms eine durchaus praktikable Option.

Windows

So komisch es auch klingt, aber einen funktionierenden Knock-Client für diese Plattform zu finden, ist ziemlich knifflig. Einen, der CLI unterstützt, delay und TCP hat — ohne Schnickschnack.

Eine Möglichkeit wäre zu versuchen, dies hier. Anscheinend ist Google bei mir nicht wirklich gut.

Linux

Hier ist alles einfach:

dnf install knock -y
knock -d   11111 22222 33333

MacOS

Am einfachsten ist es, den Port über Homebrew zu installieren:
brew install knock
und sich die benötigten Batchkommandos selbst zusammenzustellen:

#!bin/sh
knock -d <delay> <dst_ip> 11111 22222 33333

iOS

Eine funktionierende Option — KnockOnD (kostenlos, aus dem Store).

Android

„Knock on Ports“. Keine Werbung, sondern einfach, weil es funktioniert. Und die Entwickler sind recht reaktionsschnell.

P.S. Markdown auf Habré, das wünsche ich ihm irgendwann Gesundheit...

UPD1: dank einem guten Menschen fand sich ein funktionierender Client für Windows.
UPD2: ein weiterer guter Mensch erinnerte mich daran, dass es nicht immer hilfreich ist, neue Regeln am Ende von iptables zu setzen. Aber — es kommt darauf an.

Quelle: habr.com

Linux Tipps & Tricks: Server, öffne dich