Порт SSH заблокирован iptables - но все еще может войти в порт SSH с любого адреса
У меня это происходит на нескольких серверах с одинаковыми правилами брандмауэра, поэтому я подозреваю, что что-то упустил в конфигурации iptables, но не знаю, что не так. Это происходит на некоторых серверах CentOS, а также на моих серверах Ubuntu. Я использовал iptables в течение многих лет и думал, что знаю, что делаю ... очевидно, не тот случай.
У меня SSH работает на нестандартном порту (2022). У меня есть правила брандмауэра, разрешающие доступ для моих личных IP-адресов с последующей блокировкой определенных портов, включая 2022, а затем следует правило запретить все. За последние 3 недели мои журналы показывают неудачные попытки входа в систему по SSH с внешних IP-адресов, которых нет в моем списке принятия. У меня есть служба VPN на моем ноутбуке, поэтому я могу попробовать войти в систему из разных стран, IP-адресов и т. Д., И брандмауэр больше не блокирует меня, как раньше. Я использовал свой мобильный телефон в качестве точки доступа, поэтому я мог убедиться, что у меня есть случайный IP-адрес, который должен быть заблокирован, но я все еще мог войти в ssh. Я использовал nmap со случайных IP-адресов, и он показывает порт 2022 как ОТКРЫТЫЙ.
Я не уверен, что может происходить, брандмауэр, используемый для правильной блокировки SSH на запрещенных IP-адресах, и я не думаю, что я внес какие-либо изменения до того, как это началось, и у меня нет ничего похожего на fail2ban, что усложняет ситуацию. Я даже проверил руткиты, но ничего не обнаружил. Я много гуглил, но результаты поиска настолько шумные с не совсем релевантными ответами, что я отказался и решил опубликовать вопрос здесь и, надеюсь, получить более подробное руководство.
На этом сервере работает ubuntu 14.04.6 LTS
Мои разрешенные IP-адреса находятся в диапазонах 209.xxx и 216.xxx Вот мои правила iptables (iptables -L -n):
ACCEPT all -- 127.0.0.1 0.0.0.0/0
ACCEPT all -- 209.xxx.xxx.1 0.0.0.0/0
ACCEPT all -- 209.xxx.xxx.2 0.0.0.0/0
ACCEPT all -- 209.xxx.xxx.3 0.0.0.0/0
ACCEPT all -- 209.xxx.xxx.4 0.0.0.0/0
ACCEPT all -- 209.xxx.xxx.5 0.0.0.0/0
ACCEPT all -- 209.xxx.xxx.6 0.0.0.0/0
ACCEPT all -- 216.xxx.xxx.1 0.0.0.0/0
ACCEPT all -- 216.xxx.xxx.2 0.0.0.0/0
ACCEPT all -- 74.xxx.xxx.2 0.0.0.0/0
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00
RETURN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 1/sec burst 2
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x3F
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:465
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:995
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:2022
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
--------------------------------
Типичные журналы сервера показывают сбои, например:
Jul 26 05:29:38 SERVERNAME sshd[3536]: Invalid user postgres from 159.89.231.172
Jul 26 05:29:39 SERVERNAME sshd[3536]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=159.89.231.172
Jul 26 05:29:40 SERVERNAME sshd[3534]: Failed password for mysql from 159.89.231.172 port 56352 ssh2
Jul 26 05:29:40 SERVERNAME sshd[3534]: Received disconnect from 159.89.231.172: 11: Normal Shutdown, Thank you for playing [preauth]
Jul 26 05:29:40 SERVERNAME sshd[3538]: reverse mapping checking getaddrinfo for usa1.getlark.com [159.89.231.172] failed - POSSIBLE BREAK-IN ATTEMPT!
Вот сценарий, который я создал для реализации правил с комментариями:
APPEND="sudo /sbin/iptables -A INPUT"
INSERT="sudo /sbin/iptables -I INPUT"
OUTPUT="sudo /sbin/iptables -A OUTPUT"
# drop old rules and start from scratch
sudo /sbin/iptables -F
sudo /sbin/iptables -X
# allow local host
$INSERT -s 127.0.0.1 -j ACCEPT
# Allow full access to our approved IPs first:
$APPEND -s 209.xxx.xxx.1 -j ACCEPT
$APPEND -s 209.xxx.xxx.2 -j ACCEPT
$APPEND -s 209.xxx.xxx.3 -j ACCEPT
$APPEND -s 209.xxx.xxx.4 -j ACCEPT
$APPEND -s 209.xxx.xxx.5 -j ACCEPT
$APPEND -s 209.xxx.xxx.6 -j ACCEPT
$APPEND -s 216.xxx.xxx.1 -j ACCEPT
$APPEND -s 216.xxx.xxx.2 -j ACCEPT
$APPEND -s 74.xxx.xxx.2 -j ACCEPT
# drop Null packets
$APPEND -p tcp --tcp-flags ALL NONE -j DROP
# block syn flood attack
$APPEND -p tcp --syn -m limit --limit 1/s --limit-burst 2 -j RETURN
# block recon/Xmas Packets
$APPEND -p tcp --tcp-flags ALL ALL -j DROP
# don’t lock me out if I screwed up:
$APPEND -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Allow/Block our legit services
$APPEND -p tcp --dport 80 -j ACCEPT
$APPEND -p tcp --dport 110 -j DROP
$APPEND -p tcp --dport 143 -j DROP
$APPEND -p tcp --dport 443 -j ACCEPT
$APPEND -p tcp --dport 465 -j DROP
$APPEND -p tcp --dport 993 -j DROP
$APPEND -p tcp --dport 995 -j DROP
$APPEND -p tcp --dport 2022 -j DROP
# LAst Rule - Block everything else
$APPEND -j REJECT --reject-with icmp-host-prohibited
Из-за моей репутации новичка, мне нужно задать здесь разъяснения.
Можете ли вы отредактировать свой вопрос, чтобы он также содержал политику по умолчанию для цепочки INPUT? Я спрашиваю из-за этой строки:
RETURN tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 1/sec burst 2
Я не эксперт, но я никогда не видел, чтобы это использовалось на верхнем уровне. Хотя мог быть только я. Что сказано о RETURN в man-странице iptables:
RETURN означает прекращение обхода этой цепочки и возобновление выполнения следующего правила в предыдущей (вызывающей) цепочке. Если достигнут конец встроенной цепочки или соблюдается правило во встроенной цепочке с целевым RETURN, цель, указанная политикой цепочки, определяет судьбу пакета.
Я подозреваю, что ваша проблема может иметь какое-то отношение к этой функции.
Автор оригинала принял мой предыдущий ответ, но вот более подробный:
Я немного диагностировал и отлаживал. Вот что я сделал в первую очередь:
- Установил Ubuntu 14.04 как виртуальную машину VMware
- Модифицировал / etc / ssh / sshd_config для чтения:
Порт 2022 - Перезагруженная машина
- Выделенный IP-адрес виртуальной машины, который был 192.168.241.171
Затем я взял ваш сценарий брандмауэра и удалил записи xxx. Я называю модифицированный скрипт "оригинальным" скриптом.
Я выполнил пару циклов перезагрузки / модификации скрипта / запуска скрипта / подключения Putty. Вот сценарии и результаты:
- Никаких изменений в "исходный" скрипт: Подключение Putty к порту 192.168.241.171 2022 было успешным
- Удален раздел
$ APPEND -p tcp --syn -m limit --limit 1 / s --limit-burst 2 -j ВОЗВРАТиз "оригинальный" скрипт: соединение Putty с 192.168.241.171 порт 2022 было заблокировано - Добавлен перед
#allow local host "this: / sbin / iptables -P INPUT DROP` в " исходный " скрипт: Соединение Putty к порту 192.168.241.171 2022 было заблокирован - Добавлен перед
#allow local host "this: / sbin / iptables -P INPUT ACCEPT` в " исходный " скрипт: Соединение шпатлевки с портом 192.168.241.171 2022 был успешным
Думаю, я знаю, что произошло. Пользователь забыл установить политику по умолчанию для цепочки INPUT как DROP. В некоторых примерах блокировки син-флуд с использованием оператора RETURN ожидается, что политика цепочки INPUT по умолчанию установлена на DROP, и пользователь адаптировал такой пример без установки политики. Я также предполагаю, что скрипт брандмауэра никогда не работал полностью, и что защищало sshd от внешних пользователей, это нестандартный порт 2022 (но теперь злоумышленники также стучат в 2022).
PS. Если кто-то меняет политику по умолчанию, это следует делать в нерабочее время, чтобы свести на нет немедленные последствия для людей, а затем тестировать и адаптировать к новым проблемам, если таковые имеются.
Мне сложно дать однозначный ответ, учитывая предоставленные данные, но мой подход будет заключаться в следующем:
- Урезать iptables до двух правил: Разрешить один IP диапазон адресов (тот, из которого вы подключаетесь) и запретите все остальное. Будьте осторожны, чтобы не заблокировать доступ к серверу ! Доступ к консоли или план резервного копирования могут спасти жизнь. Если вы достаточно уверены, вот пример того, как действовать. Действуйте с осторожностью!:
Вы можете вводить команды, подобные:
sudo iptables-save > /tmp/original-rules.txt
sudo iptables -F
sudo iptables -X
sudo iptables -A INPUT -s 209.xxx.xxx.1 -j ACCEPT
sudo iptables -A INPUT -j DROP
Вышеупомянутая последовательность команд сохраняет ваши существующие правила, выполняет базовую очистка всех цепочек, добавление одного IP-адреса или диапазона адресов в цепочку INPUT и добавление правила отбрасывания «любое» в цепочку INPUT.
Восстановление исходных правил может быть достигнуто с помощью:
sudo iptables-restore < /tmp/original-rules.txt
- Проверить два- установка правила:
2a. Если это сработает, значит, проблема заключается в исходных правилах. Постепенно продолжайте добавлять правила и тестируйте их, пока не будете удовлетворены. Вы также можете использовать запись в журнал , чтобы понять, какое правило выполнено.
2b. Если ваш сервер все еще доступен, имея только два правила с любого другого IP-адреса, кроме разрешенного вами, то вы знаете, что это не проблема правил, а что-то не так с самим iptables. Возможно, он загружается неправильно или в памяти выполняется предыдущее состояние iptables.