A porta 3306 do MySQL foi bloqueada no csf e ainda pode telnet para a porta 3306 do host externo

Question

Temos um Centos 6 VPS que foi recentemente migrado para uma nova máquina dentro da mesma empresa de hospedagem. Está rodando o WHM / cPanel e tem o csf / lfd instalado. O csf é configurado principalmente com configuração baunilha. Eu não sou especialista em iptables, csf não me decepcionou antes. Se uma porta não estiver na lista TCP_IN, ela deve estar bloqueada no firewall pelo iptables.

Meu problema é que eu posso fazer telnet para a porta 3306 de um host externo, mas acho que o iptables deveria estar bloqueando o 3306 por causa das regras do csf. Agora estamos falhando em uma verificação de segurança devido a essa porta aberta. (esta saída é ofuscada para proteger os inocentes: www.ourhost.com é o host com o problema do firewall)

[root@nickfenwick log]# telnet www.ourhost.com 3306
Trying 158.255.45.107...
Connected to www.ourhost.com.
Escape character is '^]'.
HHost 'nickfenwick.com' is not allowed to connect to this MySQL serverConnection closed by foreign host.

Portanto, a conexão é estabelecida e o MySQL recusa a conexão devido à sua configuração. Eu preciso que a conexão de rede seja recusada no nível do firewall, antes que chegue ao MySQL.

Usando a interface de usuário da Web do csf do WHM, vejo que a 'Configuração de Firewall' inclui uma linha TCP_IN razoavelmente sensata:

TCP_IN: 20,21,22,25,53,80,110,143,222,443,465,587,993,995,2077,2078,2082,2083,2086,2087,2095,2096,8080

(vamos ignorar que eu poderia cortar isso um pouco por enquanto, minha preocupação é que 3306 não está listado nessa lista)

Quando o csf é reiniciado, ele registra a quantidade usual de saída à medida que configura as regras do iptables, por exemplo, o que parece bloquear todo o tráfego e, em seguida, permitir portas específicas como SSH em 22:

[cut]
DROP  all opt -- in * out *  0.0.0.0/0  -> 0.0.0.0/0  
[cut]
ACCEPT  tcp opt -- in !lo out *  0.0.0.0/0  -> 0.0.0.0/0  state NEW tcp dpt:22 
[cut]

Eu posso ver que o iptables está rodando, service iptables status retorna uma longa lista de regras de firewall.

Aqui está minha Chain INPUT seção de service iptables status , esperamos que seja o suficiente para mostrar como o firewall está configurado.

Table: filter
Chain INPUT (policy DROP)
num  target     prot opt source               destination         
1    acctboth   all  --  0.0.0.0/0            0.0.0.0/0           
2    ACCEPT     tcp  --  217.112.88.10        0.0.0.0/0           tcp dpt:53 
3    ACCEPT     udp  --  217.112.88.10        0.0.0.0/0           udp dpt:53 
4    ACCEPT     tcp  --  217.112.88.10        0.0.0.0/0           tcp spt:53 
5    ACCEPT     udp  --  217.112.88.10        0.0.0.0/0           udp spt:53 
6    ACCEPT     tcp  --  8.8.4.4              0.0.0.0/0           tcp dpt:53 
7    ACCEPT     udp  --  8.8.4.4              0.0.0.0/0           udp dpt:53 
8    ACCEPT     tcp  --  8.8.4.4              0.0.0.0/0           tcp spt:53 
9    ACCEPT     udp  --  8.8.4.4              0.0.0.0/0           udp spt:53 
10   ACCEPT     tcp  --  8.8.8.8              0.0.0.0/0           tcp dpt:53 
11   ACCEPT     udp  --  8.8.8.8              0.0.0.0/0           udp dpt:53 
12   ACCEPT     tcp  --  8.8.8.8              0.0.0.0/0           tcp spt:53 
13   ACCEPT     udp  --  8.8.8.8              0.0.0.0/0           udp spt:53 
14   LOCALINPUT  all  --  0.0.0.0/0            0.0.0.0/0           
15   ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
16   INVALID    tcp  --  0.0.0.0/0            0.0.0.0/0           
17   ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
18   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:20 
19   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:21 
20   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
21   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:25 
22   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:53 
23   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80 
24   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:110 
25   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:143 
26   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:222 
27   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443 
28   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:465 
29   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:587 
30   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:993 
31   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:995 
32   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:2077 
33   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:2078 
34   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:2082 
35   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:2083 
36   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:2086 
37   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:2087 
38   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:2095 
39   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:2096 
40   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:8080 
41   ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:20 
42   ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:21 
43   ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:53 
44   ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:222 
45   ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:8080 
46   ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 8 
47   ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 0 
48   ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 11 
49   ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 3 
50   LOGDROPIN  all  --  0.0.0.0/0            0.0.0.0/0           

Qual é a próxima coisa a verificar?

    

Answer 1

Eu não tenho certeza do que o LOGDROPIN ou o acctboth estão definindo, mas eis como eu faria isso.

1. Se você não precisa do MySQL para aceitar conexões remotas, eu primeiro mudaria a configuração do MySQL para ligar a 127.0.0.1 ao invés de 0.0.0.0 ou seu endereço IP. Isso limitará todo o acesso do mysql ao host local, e acredito que seja o padrão para novas instalações do MySQL. (Isso não responde à sua pergunta IPTABLES, mas provavelmente deve ser feito de qualquer maneira.)

2. Para rastrear seu problema IPTABLES, sugiro usar a funcionalidade IPTABLES TRACE, que informará exatamente quais regras estão sendo percorridas. Existe um diagrama de fluxo de pacotes bacana. A partir disso, você pode ver que a tabela bruta possui cadeias de OUTPUT e PREROUTING integradas. Isso também pressupõe que você esteja usando um > Kernel 2.6.23, ou tenha compilado seus próprios com as opções apropriadas.

Você adicionaria algo como:

iptables -t raw -A OUTPUT -p tcp --dport 3306 -j TRACE
iptables -t raw -A PREROUTING -p --dport 3306 tcp  -j TRACE

para que o kernel rastreie as conexões do mysql. Você deve ser capaz de ver quais regras específicas os pacotes percorreram nos logs. Se essa caixa já tiver tráfego nessa porta, talvez você também queira filtrar seu endereço IP nas regras acima para mostrar menos ruído.

Além disso, aqui está uma excelente postagem sobre rastreamento de iptables .

Espero que isso ajude!