8 votes

Y a-t-il un journal sous Linux qui indique si un port a été refusé ?

Supposons que j'ai un pare-feu actif ou une autre sécurité comme SE linux etc.

Maintenant, supposons que l'utilisateur veut se connecter au port 21 et Iptables ne le permet pas.

Maintenant, lorsque les utilisateurs sont refusés, ce message est-il enregistré quelque part pour que je puisse voir ce que la partie utilisée est bloquée ou pourquoi un port particulier est bloqué.

Plutôt que de creuser chaque paramètre pour trouver pourquoi je n'y arrive pas.

J'ai configuré le port ssh par défaut à 8022 mais je reçois un refus de connexion.

J'ai vérifié telnet et il écoute sur ce port. J'ai vidé iptables.

Y a-t-il un journal où je peux vérifier qui refuse la connexion ?

12voto

F. Hauri Points 969

Première réponse

Non. Il n'y a pas journal par défaut, montrant ceci, mais

Affichage de la configuration actuelle du pare-feu

Regardez comment votre pare-feu est configuré :

iptables -L

Cherchez Chain [INPUT|OUTPUT] policy d'abord. S'il y a autre chose que ACCEPT le port utilisé devra peut-être être exploré ACCEPT ed mousse...

iptables -L INPUT | grep `port=2[01]`

Pour afficher les règles explicites concernant les ports 20 et 21, mais attention, vous devrez peut-être lire toute la configuration du pare-feu, pour vérifier les règles suivantes multiport , user-defined chains Cela peut devenir difficile si vous ne savez pas comment faire. iptables du tout.

Un vide ouvert La configuration du pare-feu pourrait ressembler à ceci :

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

voir :

man iptables

Savoir ce qui pourrait bloquer quelque chose dans vos règles

J'utilise cette astuce :

touch /tmp/tmp_iptable_stat.txt
getChanges() {
    pushd /tmp >/dev/null
    for table in $(</proc/self/net/ip_tables_names);do
        echo $RANDOM: - $table
        iptables -t $table -nvxL --line-number
      done |
        diff -u tmp_iptable_stat.txt - |
        tee >(patch -p0) |
        sed '
            s/^+[0-9]*: - /TABLE /p;
            s/^+//p;
            d'
    popd >/dev/null
}

Qu'un premier appel à getChanges va vider toutes les tables et les compteurs. Les appels ultérieurs à la même fonction n'imprimeront que les règles où les compteurs sont modifiés. Cela peut aider à trouver quelle règle bloque quelque chose.

Montre l'état actuel des piles réseau :

La pile réseau du noyau peut être vidée par

netstat -tan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN
tcp        0   2364 192.168.1.1:21          192.168.1.35:49179      ESTABLISHED

pour les sockets TCP ou

netstat -uan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      

pour les sockets UDP.

Comme mon FTP utilisation du serveur TCP sockets, j'ai pu voir qu'un échange est actuellement établi entre mon serveur et mon hôte ...35 ( le serveur a actuellement 2364 paquets à envoyer au client. peut-être un fichier, peut-être une liste... )

Suivi du trafic sur une interface spécifique

Au lieu d'utiliser log vous pouvez regarder ce qui se passe sur votre interface :

tcpdump -i ethX

Cela permettra d'obtenir des informations utiles sur le trafic sur ethX mais comme par défaut et pour être plus humain lisible cet outil va essayer de résoudre le nom de chaque IP. Il peut donc y avoir un certain délai entre l'événement lui-même et le dump sur le terminal. Donc :

tcpdump -ani ethX

n'essaiera pas de résoudre (opt -n ) des IP et des noms de services et affichera TOUS ( -a ) des paquets traversant l'interface.

plus finement :

tcpdump -ani ethX port 21 or port 20
09:17:58.264453 IP 192.168.1.1.21 > 192.168.24.91.45951: Flags [S.], seq 3593971599, ack 1942867644, win 5792, options [mss 1460,sackOK,TS val 1168768120 ecr 62841986,nop,wscale 7], length 0
09:17:58.299693 IP 192.168.1.35.56485 > 192.168.1.1.21: Flags [S], seq 3334605998, win 5840, options [mss 1368,sackOK,TS val 1936641509 ecr 0,nop,wscale 7], length 0
09:17:58.299728 IP 192.168.1.1.21 > 192.168.1.35.56485: Flags [S.], seq 980554936, ack 3334605999, win 5792, options [mss 1460,sackOK,TS val 1168768129 ecr 1936641509,nop,wscale 7], length 0
...

Plus de détails : ... use -v or -vv for full protocol decode

tcpdump -anvvi ethX port 21 or port 20
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
09:22:40.047486 IP (tos 0x0, ttl 62, id 31488, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.24.91.46011 > 192.168.1.1.21: Flags [S], cksum 0x5985 (correct), seq 3989081263, win 14600, options [mss 1368,sackOK,TS val 62912431 ecr 0,nop,wscale 6], length 0
09:22:40.047525 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.1.21 > 192.168.24.91.46011: Flags [S.], cksum 0x926d (correct), seq 2283473829, ack 3989081264, win 5792, options [mss 1460,sackOK,TS val 1168838566 ecr 62912431,nop,wscale 7], length 0
09:22:40.817248 IP (tos 0x0, ttl 62, id 31489, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.24.91.46011 > 192.168.1.1.21: Flags [.], cksum 0xd6e9 (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 62912442 ecr 1168838566], length 0
09:22:40.817567 IP (tos 0x0, ttl 62, id 31490, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.24.91.46011 > 192.168.1.1.21: Flags [F.], cksum 0xd6e3 (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 62912447 ecr 1168838566], length 0
...

Où vous pourriez suivre chaque opération.

2voto

Carling Points 229

Si vous avez LOG sur votre règle iptables alors vous devriez obtenir une entrée de journal dans /var/adm/messages . Voici un exemple :

# --- Log new connections:
-A INPUT -m state --state NEW -j LOG  --log-prefix "NEW: " --log-level info

Une règle comme celle-ci dans le jeu de règles de vos tables IP pourrait vous aider à démarrer :

# Enable port 8022 (ssh) but rate limit it:
-A INPUT -p tcp -m tcp --dport 8022 ! --syn -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8022 --syn -m limit --limit 3/minute -j ACCEPT

La commande sestatus vous dira si selinux est activé :

[root@seadog ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

Les messages de selinux vont à /var/log/audit/audit.log par défaut.

En semanage (trouvée dans rpm : policycoreutils-Python) peut également être utile pour lister les ports que selinux contrôle :

root@seadog log]# semanage port -l
SELinux Port Type              Proto    Port Number

afs_bos_port_t                 udp      7007
afs_client_port_t              udp      7001
afs_fs_port_t                  tcp      2040
afs_fs_port_t                  udp      7000, 7005
afs_ka_port_t                  udp      7004
afs_pt_port_t                  udp      7002
afs_vl_port_t                  udp      7003
agentx_port_t                  tcp      705

TCP Wrapper peut également être activé. Vérifiez /etc/hosts.allow y /etc/hosts.deny des fichiers.

Essayer ces éléments dans une machine virtuelle est un excellent moyen d'apprendre à les assembler et de gagner en confiance avant de mettre vos règles en production.

2voto

user9517 Points 113163

Avec iptables et SElinux désactivés, il n'y aura probablement pas de journaux à lire. Je ne comprends pas bien où telnet s'inscrit dans ce scénario car il n'a rien à voir avec ssh. La politique SELinux actuelle ne bloque que les connexions ssh sur les ports non standard inférieurs à 1023, il est donc peu probable que ce soit cela.

En Connection refused signifie généralement que rien n'écoute sur le port demandé. Vous pouvez vérifier si quelque chose écoute en utilisant netstat

netstat -tunlp | grep 8022
tcp        0      0 0.0.0.0:8022        0.0.0.0:*           LISTEN      2178/sshd
tcp6       0      0 :::8022             :::*                LISTEN      2178/sshd

L'image ci-dessus montre que sshd écoute sur le port 8022 sur toutes les interfaces IPv4 et IPv6.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X