Pour ceux qui veulent accéder à leurs serveurs depuis n'importe quel endroit dans le monde via SSH/RDP/autres — un petit RTFM/guide.

Nous devons nous passer de VPN et d'autres subtilités, depuis n'importe quel appareil à portée de main.

Et sans trop de complications avec le serveur.

Tout ce dont vous avez besoin, c'est de knockd, des mains habiles et de 5 minutes de travail.

«Il y a tout sur Internet», bien sûr (même sur Habr), mais quand il s'agit d'une mise en œuvre concrète — c'est là que les choses commencent…

Nous allons nous exercer sur un exemple Fedora/CentOS, mais ce n'est pas le plus important.

Le guide conviendra aussi bien aux débutants qu'aux experts, donc il y aura des commentaires, mais plus courts.

1. Serveur

• installez le knock-server :
  yum/dnf install knock-server

• configurez-le (par exemple pour 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

  La partie «d'ouverture» est configurée pour se fermer automatiquement après 1 heure. Au cas où…

• /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
  ...

• en avant :

  service iptables restart
  service knockd start

• vous pouvez ajouter RDP sur un Windows Server virtuel qui tourne (dans /etc/knockd.conf ; le nom de l'interface à adapter selon les préférences) :

  [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

  Nous suivons toutes nos requêtes de clients sur le serveur avec la commande iptables -S.

2. Guide des erreurs

knockd.conf :

Il y a aussi tout dans les manuels (mais ce n'est pas sûr), cependant, knockd — est un partenaire plutôt avare en messages, donc il faut être très attentif.

• version
  Dans les dépôts Fedora/CentOS, la dernière version de knockd est 0.63. Qui veut du UDP — cherchez les paquets 0.70.
• interface
  Dans la configuration par défaut de Fedora/CentOS, cette ligne absente. Ajouter manuellement, sinon ça ne fonctionnera pas.
• timeout
  Ici, à adapter selon les préférences. Il faut que le client ait le temps pour tous les pings — et que les bots de scan de ports soient déroutés (car ils vont scanner à 146%).
• start/stop/command.
  Si l'équipe est unique, alors c'est command, si elle est double, alors c'est start_command+stop_command.
  Si vous vous trompez, knockd restera silencieux, mais ne fonctionnera pas.
• proto
  Théoriquement, on peut utiliser UDP. En pratique, j'ai mélangé tcp et udp, et le client depuis la plage à Bali a pu ouvrir son portail seulement au cinquième essai. Car TCP arrivait quand il le fallait, mais pour UDP, ce n'est pas garanti. Mais c'est une question de goût, encore une fois.
• sequence
  Les pièges non évidents résident dans le fait que les séquences ne doivent pas se chevaucher... comment dire...

Par exemple, cela :

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

Pour le coup, 11111 open attendra le prochain coup à 22222. Cependant, à cause de ce (22222) coup, il commencera à fonctionner close et tout se cassera. Cela dépend aussi du délai du client. C'est comme ça ©.

iptables

Si dans /etc/sysconfig/iptables, il y a cela :

*nat
:PREROUTING ACCEPT [0:0]

si cela ne nous gêne pas trop, alors il y a cela :

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

Cela gêne.

Puisque knockd ajoute des règles à la fin de la chaîne INPUT, nous allons recevoir un reject.

Et désactiver ce reject signifie ouvrir la machine à tous les vents.

Pour ne pas se tromper dans iptables sur ce qu'il faut mettre où (comme les gens le suggèrent), faisons plus simple :

• par défaut dans CentOS/Fedora la première règle (« ce qui n'est pas interdit est permis ») sera remplacée par l'inverse,
• et nous retirons la dernière règle.

Au final, cela devrait donner :

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

On peut, bien sûr, faire REJECT au lieu de DROP, mais avec DROP, les bots auront une vie plus agréable.

3. Client

À cet endroit, c'est le plus intéressant (de mon point de vue), car il faut travailler non seulement depuis n'importe quelle plage, mais aussi depuis n'importe quel appareil.

En principe, plusieurs clients sont listés sur site le projet, mais cela fait partie de cette série « tout se trouve sur Internet ». Donc je vais énumérer ce qui fonctionne ici et maintenant sous ma main.

Lors du choix d'un client, il est essentiel de s'assurer qu'il supporte l'option delay entre les paquets. Oui, chaque plage est différente, et 100 mégabits ne garantissent pas que les paquets arriveront dans le bon ordre et au bon moment depuis cet endroit.

Et oui, lors de la configuration du client, il faut ajuster le délai soi-même. Trop de timeout et les bots attaqueront, trop peu et le client ne sera pas à l'heure. Trop de delay et le client ne sera pas à l'heure ou il y aura des conflits de coups (voir « pièges »), trop peu et les paquets se perdront dans les internets.

Avec timeout=5s, une option fonctionnelle est delay=100..500ms

Windows

Aussi drôle que cela puisse paraître, trouver un client knock cohérent pour cette plateforme est plutôt non trivial. Un qui supporte CLI, delay, TCP — et sans fioritures.

Comme option, vous pouvez essayer cela ici. Manifestement, mon Google n'est pas très bon.

Linux

Ici, c'est très simple :

dnf install knock -y
knock -d   11111 22222 33333

MacOS

Le plus simple est d'installer le port depuis homebrew :
brew install knock
et de se créer les scripts nécessaires du type :

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

iOS

Une option fonctionnelle — KnockOnD (gratuit, dans le magasin).

Android

« Knock on Ports ». Ce n'est pas de la publicité, c'est juste qu'il fonctionne. Et les développeurs sont assez réactifs.

P.S. Le markdown sur Habr, bien sûr, qu'il ait un jour la santé…

MÀJ1: grâce à une bonne personne un client opérationnel pour Windows. : encore une autre
UPD2bonne personne a rappelé que mettre de nouvelles règles à la fin des iptables n'est pas toujours utile. Mais – ça dépend. Pour ceux qui veulent se donner, à eux-mêmes, un accès à leurs serveurs de n'importe où dans le monde par SSH/RDP/autre – un petit RTFM/guide. Nous devons nous passer de.

Source : habr.com