Следующая ситуация.
Вы только начали настраивать сетевой фильтр, и ввели команды
iptables -P INPUT DROP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
Вопрос: можно ли зайти на сайт mail.ru
В 90% случаев вы мне пишите: нет, нельзя. Нужно еще открыть 443 и 53 порты.
На что следует мой вопрос: разве mail.ru хостится на вашей машине?
Давайте разберем, как это работает.
То, что запрос с вашего компьютера будет улетать на 443/TCP-порт сервера mail.ru, думаю, объяснять не надо.
Вопрос, на какой порт вашей машины прилетит вам ответ.
И здесь надо сказать следующее: если сервер слушает один из общеизвестных портов (22/UDP, 25/TCP, 53/UDP, 80/TCP, 443/TCP), то клиентское приложение, когда открывает соединение, использует один из динамических портов.
В GNU/Linux этот диапазон можно посмотреть в файле /proc/sys/net/ipv4/ip_local_port_range
Смотрим:
Соответственно, когда вы в браузере открываете вкладки, одну за другой, то приложение, открывая исходящее соединение, получает один из динамических портов.
32768/TCP
32769/TCP
32770/TCP
32771/TCP
и т.д.
Если соединение первой вкладкой было закрыто, а потом вы нажали на ссылку и перешли, будет открыто новое соединение.
И будет задействован очередной случайный порт
32777/TCP
Допустим это и было обращение с вашего компьютера к mail.ru
Для простоты допустим, что адрес mail.ru вы посмотрели еще до начала настройки сетевого фильтра, например, с помощью команды nslookup
Допустим, вы прописали его в /etc/hosts
Убедимся, что именно этот IP-адрес отзывается при попытке пинга
Теперь открываем браузер и вводим mail.ru
Результат немного предсказуем. Колесико крутится, ничего не грузится, вместо мейла красуется стандартный для гугл хрома логотип Гугл.
Почему так происходит?
Браузер открывает сессию.
Выведем список сокетов, и отфильтруем по IP-адресу mail.ru
Обратите внимание, статус SYN-SENT. Клиент отправил первый сегмент на 443/TCP порт на адрес mail.ru (c флагом SYN)
mail.ru попытался ответить (с флагом SYN-ACK, если Вы знаете, как работает протокол TCP), но его ответ был направлен на вашу машину на TCP-порт 38356
Такой порт не разрешен. Потому что разрешен только 80!
И разрешение 443 ничего не даст.
И разрешение 38356 тоже ничего не даст, потому как в следующий раз будет порт, например, 50196.
Можно, конечно весь диапазон разрешить
iptables -A INPUT -p tcp --dport 32768:60999 -j ACCEPT
И действительно, работает!
Только давать доступ извне к целым 28231 порту не лучшая идея.
Какой-нибудь руткит скачаете и запустит он слушающий порт по адресу 60666
Поэтому не нужно добавлять этот диапазон в однозначно разрешенные.
А если добавили, то удалите
iptables -D INPUT -p tcp --dport 32768:60999 -j ACCEPT
А вот то, что нужно, воспользоваться модулем conntrack с отслеживанием состояний. Он сам будет следить за сессиями, которые устанавливают локальные приложения (посылая во вне тот самый SYN, то, что вы увидели в списке сокетов в состоянии SYN-SENT), и если ответ строго в рамках этой сессии, будет пропускать. А как сессия будет завершена, больше не пропустит.
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Но и это еще не все. Удалим mail.ru из /etc/hosts
И если вдруг снова mail.ru не открывается , то потому, что не может найти по доменному имени mail.ru его IP-адрес.
Как же так?
Посмотрим, а не слушаются ли локально 53 порты?
И если открыты, то зачем?
Это локальный кеширующий DNS-сервер. То есть приложения обращаются не к DNS-серверу, который вы получили по DHCP, а как раз к приложению, работающему на вашем же компьютере, который слушает на интерфейсе loopback адрес 127.0.0.53
А у нас входящие запрещены (кроме 80/TCP ;)
Можно конечно 53/UDP и 53/TCP разрешить, но есть риск, что DNS-сервер будет слушать не 127.0.0.53 а на 0.0.0.0, а это означает, что злоумышленник может получить к нему доступ.
Так что делать?
Разрешить весь локальный трафик
iptables -A INPUT -i lo -j ACCEPT
Тогда любые приложения работающие локально, смогут общаться между собой.
Это не все настройки сетевого фильтра.
Но надеюсь, что сама настройка правила станет чуть проще?
Подписывайтесь на мой канал в дзен и будете в курсе новых моих статей по компьютерным сетям и ОС/Linux.
Всегда с вами,
Сергей Кручинин
преподаватель GNU/Linux и компьютерных сетей