MySQL порт 3306 заблокирован в csf, но все еще может подключаться к порту 3306 с внешнего хоста
У нас есть Centos 6 VPS, который недавно был перенесен на новый компьютер в рамках той же хостинговой компании. Он работает WHM/cPanel и имеет установленный csf/lfd. csf настроен в основном на ванильный конфиг. Я не эксперт по iptables, CSF не подводил меня раньше. Если порт отсутствует в списке TCP_IN, он должен быть заблокирован на брандмауэре с помощью iptables.
Моя проблема в том, что я могу подключиться к порту 3306 с внешнего хоста, но я думаю, что 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
Что еще нужно проверить?
1 ответ
Я не уверен, что определяют 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.
Надеюсь это поможет!