Existe algum registro no Linux que informa se alguma porta foi negada

3

Suponha que eu tenha o firewall ativo ou qualquer outra segurança como o SE linux etc.

Agora, suponha que o usuário deseje se conectar à porta 21 e o Iptables não permita isso.

Agora, quando os usuários são negados, essa mensagem é registrada em qualquer lugar, para que eu possa ver o que o partucular usado está bloqueado ou por que a porta específica está bloqueada.

Em vez de cavar cada configuração para descobrir por que não estou passando por isso.

Copiei a porta ssh padrão para 8022 , mas estou recebendo a recusa recusada.

Eu verifiquei o telnet e sua escuta nessa porta. Eu tenho iptables vazios.

Existe algum log onde posso verificar quem está recusando a conexão

    
por MOtaro Site 22.07.2013 / 07:37

3 respostas

6

Primeira resposta

Não. Não há log por padrão, mostrando isso, mas

Mostrando a configuração atual do firewall

Veja como o seu firewall está configurado:

iptables -L

Procure por Chain [INPUT|OUTPUT] policy primeiro. Se houver algo mais do que ACCEPT , a porta usada pode ter que ser explicitamente ACCEPT ed espuma ...

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

Para mostrar regras explícitas sobre a porta 20 e a porta 21, mas cuidado, você pode ter que ler toda a configuração do firewall, para verificar sobre multiport , user-defined chains , etc. isso pode ficar difícil se você não souber iptables de todo.

Uma configuração de firewall vazia aberta pode parecer com:

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

veja:

man iptables

Sabendo o que poderia bloquear algo em suas regras

Eu uso esse truque:

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
}

Uma primeira chamada para getChanges fará o dump de todas as tabelas e contadores. As chamadas subsequentes para a mesma função imprimirão apenas as regras onde o contador for modificado. Isso pode ajudar a descobrir qual regra está bloqueando alguma coisa.

Mostrando o estado atual das pilhas de rede:

A pilha de rede do kernel pode ser descartada por

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

para soquetes TCP ou

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

para soquetes UDP.

Como meu servidor FTP usa sockets TCP , eu pude ver que uma troca está estabelecida entre meu servidor e host . ..35 , (o servidor tem atualmente 2364 pacotes para enviar ao cliente. Talvez um arquivo, talvez uma lista ...)

Acompanhamento de tráfego em uma interface específica

Em vez de usar log , você pode ver o que acontece na sua interface:

tcpdump -i ethX

Isto despejará informações úteis sobre o tráfego em ethX , mas como por padrão e para ser mais humain readable , esta ferramenta tentará resolver o nome de cada IP. Portanto, pode haver algum atraso entre o evento e o dump no terminal. Então:

tcpdump -ani ethX

não tentará resolver (opt -n ) IPs e nomes de serviços e mostrará TODOS os pacotes ( -a ) que atravessam a interface.

mais finamente:

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

Mais detalhado: ... 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
...

Onde você pode seguir cada operação.

    
por 22.07.2013 / 09:26
2

Com o iptables e o SElinux desativados, provavelmente não haverá registros para leitura. Eu não entendo muito bem onde o telnet se encaixa nesse cenário, pois não tem nada a ver com o ssh. A política atual do SELinux bloqueia apenas as conexões ssh em portas não padrão abaixo de 1023, então é improvável que seja isso.

A mensagem Connection refused geralmente significa que nada está escutando na porta solicitada. Você pode verificar se algo está escutando usando 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

O exemplo acima mostra que o sshd está escutando na porta 8022 em todas as interfaces IPv4 e IPv6.

    
por 22.07.2013 / 08:12
2

Se você tiver LOG definido em sua regra iptables, então você deve obter uma entrada de log em /var/adm/messages . Aqui está um exemplo:

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

Uma regra como abaixo em seu conjunto de regras de tabelas de IP pode ajudar você a começar:

# 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

O comando sestatus dirá se o selinux está ativado:

[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

As mensagens do selinux vão para /var/log/audit/audit.log por padrão.

O comando semanage (encontrado em rpm: policycoreutils-python) também pode ser útil para listar quais portas o selinux está controlando:

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
O

TCP Wrapper também pode ser ativado. Verifique os arquivos /etc/hosts.allow e /etc/hosts.deny .

Experimentar essas coisas em uma máquina virtual é uma ótima maneira de aprender a juntar tudo e criar confiança antes de colocar suas regras em produção.

    
por 22.07.2013 / 07:57