Sur AWS, dois-je ouvrir les ports dans le pare-feu d'une instance EC2 ainsi que le groupe de sécurité?

8

Si je change mon port SSH de 22 à 23453, je ne peux plus faire de ssh.

Plus en détail, j'utilise une instance Red Hat EC2 sur Amazon Web Services. Il s'agit du deuxième changement que j'ai effectué lors d'une nouvelle installation (le premier changement consistait à ajouter un utilisateur non root).

Je peux ssh in fine en utilisant Git Bash et un fichier local .ssh / config, je modifie la ligne dans / etc / ssh / sshd_config qui dit actuellement

#Port 23453

dire

Port 23453

puis redémarrez sshd avec

sudo service sshd restart

J'ajoute ensuite une ligne "Port 23453" mon fichier .ssh / config

Host foo 
Hostname my-ec2-public-DNS
Port 23453
IdentityFile my ssl key

Si j'ouvre un autre shell Git Bash (sans fermer ma connexion existante) et tente de ssh dans mon instance (avec ssh foo), je vois l'erreur suivante:

ssh: connect to host my-ec2-public-DNS port 23453: Bad file number

Le groupe de sécurité attaché à cette instance a deux entrées, à la fois TCP

22 (SSH) 0.0.0.0/0

23453 0.0.0.0/0

Ma meilleure supposition est que le port est toujours bloqué par mon pare-feu.

La sortie de sudo iptables -Lest la suivante

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Ce qui me semble assez ouvert.

MISE À JOUR

Après avoir ajouté une règle iptables

iptables -A INPUT -p tcp --dport 23453 -j ACCEPT

et réessayer, toujours pas de chance.

Sortie de iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:23453

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Qui semble suffisamment ouvert. Je ne sais pas exactement comment rechercher les paquets qui entrent ou l'activité sur le port. Mais la sortie de netstat -ntlp(en tant que root)

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State PID/Program name
tcp        0      0 0.0.0.0:56137               0.0.0.0:*                   LISTEN      948/rpc.statd
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      930/rpcbind
tcp        0      0 127.0.0.1:631               0.0.0.0:*                   LISTEN      1012/cupsd
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      1224/master
tcp        0      0 0.0.0.0:23453               0.0.0.0:*                   LISTEN      32638/sshd
tcp        0      0 :::36139                    :::*                        LISTEN      948/rpc.statd
tcp        0      0 :::111                      :::*                        LISTEN      930/rpcbind
tcp        0      0 ::1:631                     :::*                        LISTEN      1012/cupsd
tcp        0      0 :::23453                    :::*                        LISTEN      32638/sshd

Ce qui me semble montrer sshd sur 23453.

J'ai vérifié à nouveau que l'instance a le port ouvert dans le groupe de sécurité (Port: 23453, Protocole: tcp, Source: 0.0.0.0/0)

Quoi d'autre peut provoquer l'échec de la connexion via SSH?

À votre santé

AUTOPSIE

Je peux maintenant me connecter. C'était une règle manquante dans iptables. La sortie de iptables -Lmaintenant ressemble à ceci:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:23453 state NEW
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ssh amazon-ec2 iptables redhat amazon-web-services Andrew Martin
la source
Pour tous ceux qui ne voient pas la différence entre le troisième iptables -L(ssh fonctionne) et le second iptables -L(ssh est bloqué). Regardez l'ordre des règles dans la chaîne INPUT (les 6 lignes sous la première "cible"), elles sont lues de haut en bas, donc dans le deuxième ensemble de règles, "REJECT all" est frappé avant "ACCEPT tcp dpt: 23453 ". Le troisième ensemble de règles a l'entrée ACCEPT au-dessus, et donc avant, l'entrée REJECT.
Andrew Martin

Réponses:

12

Votre pare-feu d'instance n'a pas ce port ouvert. Essayez la commande suivante:

iptables -I INPUT 3 -s 0.0.0.0/0 -d 0.0.0.0/0 -p tcp --dport 23453 -m state --state New -j ACCEPT

Notez que les règles iptables doivent être enregistrées pour persister après un redémarrage. Sur RHEL, c'est:

/sbin/service iptables save
melsayed
la source
Cela a fonctionné. Si quelqu'un pouvait me dire une différence importante entre la règle iptables de @ melsayed et la règle iptables de Frank, je serais très reconnaissant. En outre, je suppose que cela signifie que la réponse à ma question ultime est "Oui, sur AWS, vous devez ouvrir les ports dans les pare-feu d'instance ec2 ainsi que leurs groupes de sécurité". Merci tout le monde.
Andrew Martin
J'ai essayé de commenter la réponse de Frank mais je n'ai pas encore assez de représentants :)
melsayed
2
Fondamentalement, la commande iptables de Frank ajoute (-A) une nouvelle règle qui permettrait la connexion à ce port. Le problème est qu'il ajoute la règle à la fin de la liste des règles iptables. La dernière règle de la liste iptables rejette tout ce qui n'est pas explicitement autorisé avant. Puisque les règles iptables sont appliquées dans l'ordre, la connexion est mise en correspondance et rejetée avant même d'arriver à la nouvelle règle.
melsayed
2
J'ai inséré une nouvelle règle dans la liste, à la 3ème position (-I INPUT 3). Qui est mis en correspondance avant la règle de rejet à la fin, permettant ainsi la connexion. Comme Frank l'a mentionné, vous pouvez utiliser iptables -nvL pour voir le nombre de paquets correspondant à chaque règle, ce qui facilite le débogage d'une telle configuration.
melsayed
/sbin/service iptables savene fonctionne pas pour moi, même avec sudo.
huertanix
2

Ajouter une règle iptables 

iptables -I INPUT 1 -p tcp --dport 23435 -j ACCEPT

qui accepte le trafic de n'importe quel hôte, par le port 23435, et essayez de ssh, si vous voyez des paquets ou une activité, cela signifie que les paquets atteignent votre serveur.

Si vous ne voyez aucun paquet, cela signifie que le groupe AWS Security n'a pas de règle pour autoriser votre port.

mais si vous voyez du trafic sur cette règle (par iptables -nvL), vous devez alors exécuter "netstat -ntlp" et vérifier si le démon SSH s'exécute sur le port 2435. et sur 0.0.0.0/0.

nous espérons que ces étapes permettront de résoudre le problème. si toujours non, alors dites-moi.

Farhan
la source
1

Êtes-vous sûr que le groupe de sécurité est correctement défini? Avez-vous cliqué sur "Appliquer les modifications"? Beaucoup de gens oublient d'appliquer leurs modifications :)

«Numéro de fichier incorrect» signifie généralement des délais d'attente de connexion et votre configuration iptables semble correcte.

Waleed Hamra
la source
Je suis tombé une fois sur l'écueil "appliquer les changements". Plus jamais. :)
Andrew Martin
-1

Au cas où quelqu'un tomberait sur ce sujet parce qu'il a changé le port par défaut de ssh, voici une solution qui a fonctionné pour moi:

  1. Pour contourner un pare-feu d'entreprise, j'ai modifié le port sur 80 /etc/ssh/sshd_conf.
  2. Malheureusement, Apache était déjà installé sur cette instance, donc je ne pouvais plus ssh.
  3. J'ai détaché le volume de l'instance.
  4. l'a attaché à une autre instance
  5. monté, changé le port dans le fichier de configuration
  6. le détacher, le rattacher à l'ancienne instance
  7. redémarré: tout va bien: D
Homezar
la source