Назад | Перейти на главную страницу

Порт MySQL 3306 заблокирован в csf, но все еще может подключаться к порту 3306 через Telnet с внешнего хоста

У нас есть Centos 6 VPS, который недавно был перенесен на новую машину в той же компании веб-хостинга. Он работает под управлением WHM / cPanel и имеет установленный csf / lfd. csf настроен в основном с ванильной конфигурацией. Я не эксперт по iptables, csf меня раньше не подводил. Если порта нет в списке TCP_IN, он должен быть заблокирован на брандмауэре с помощью iptables.

Моя проблема в том, что я могу подключиться к порту 3306 по Telnet с внешнего хоста, но я думаю, что iptables должен блокировать 3306 из-за правил csf. Сейчас мы не можем пройти проверку безопасности из-за этого открытого порта. (этот вывод запутан для защиты невиновных: www.ourhost.com - это хост с проблемой брандмауэра)

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

Таким образом, соединение установлено, и MySQL отклоняет соединение из-за своей конфигурации. Мне нужно, чтобы сетевое соединение было отклонено на уровне брандмауэра, прежде чем оно достигнет MySQL.

Используя веб-интерфейс csf WHM, я вижу, что «Конфигурация межсетевого экрана» включает довольно разумную строку TCP_IN:

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

(давайте проигнорируем, что я мог бы немного обрезать это сейчас, меня беспокоит то, что 3306 не перечисленные в этом списке)

Когда csf перезапускается, он регистрирует обычное множество выходных данных, поскольку он устанавливает правила iptables, например, что выглядит так, как будто он блокирует весь трафик, а затем разрешает определенные порты, такие как SSH на 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]

Я вижу, что iptables запущен, service iptables status возвращает длинный список правил брандмауэра.

Вот мой Chain INPUT раздел от service iptables status, надеюсь, этого достаточно, чтобы показать, как настроен брандмауэр.

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

Что дальше проверять?

iptables csf

Я не уверен, что определяют LOGDROPIN или acctboth, но вот как я бы это сделал.

Если вам не нужен MySQL для приема удаленных подключений, я бы сначала изменил конфигурацию MySQL для привязки к 127.0.0.1, а не к 0.0.0.0 или вашему IP-адресу. Это ограничит весь доступ mysql к локальному хосту, и я считаю, что это значение по умолчанию для новых установок MySQL. (Это не отвечает на ваш вопрос о IPTABLES, но, вероятно, это все равно нужно сделать.)
Чтобы отследить вашу проблему с IPTABLES, я бы предложил использовать функцию IPTABLES TRACE, которая точно скажет вам, какие правила проходят. Есть изящный диаграмма потока пакетов. Из этого вы можете видеть, что необработанная таблица имеет встроенные цепочки OUTPUT и PREROUTING. Это также предполагает, что вы используете ядро> 2.6.23 или скомпилировали собственное с соответствующими параметрами.

Вы бы добавили что-то вроде:

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

чтобы ядро отслеживало соединения mysql. Вы должны увидеть, какие именно правила проходили пакеты в журналах. Если в этом поле уже есть трафик через этот порт, вы можете также отфильтровать свой IP-адрес в приведенных выше правилах, чтобы показывать меньше шума.

Кроме того, вот отличный пост о трассировка iptables.

Надеюсь это поможет!