необработанные сокеты, iptables и тот факт, что
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
Итак, я только что узнал, что эти милые правила ни хрена не делают, когда дело доходит до необработанных сокетов.
Я знаю, что для захвата необработанного сокета требуется разрешение root, поэтому меня не волнует, что цепочка OUTPUT не фильтруется (я уверен, что у меня нет программного обеспечения с бэкдором, работающим как SU).
а как насчет цепочки INPUT? разве неспособность контролировать входящие пакеты не опасна? если нет, то почему все утруждают себя отменой политики по умолчанию?
Необработанный сокет не создает какой-то конкретный тип трафика, который является «необработанным», отличным от TCP или UDP или чего-либо еще. Необработанный сокет принимает кадры L2 = Ethernet целиком, и приложение должно работать с верхними уровнями. Например, демон ISC DHCP использует необработанный сокет -, поэтому он не зависит от локальных iptables на том же хосте, но ISC dhcpd должен понимать IP и UDP и обрабатывать их самостоятельно.
Если у вас есть подозрительная соседняя машина (или виртуальная машина ), где известно, что какое-то программное обеспечение открывает необработанный сокет, вам не нужно «фильтровать необработанный трафик» -, вам просто нужно применить « наименьшая привилегия" = разрешить выбрать несколько портов TCP/UDP (и, возможно, несколько необходимых ICMP)и удалить все остальные. Не имеет значения, инициирует ли подозрительный хост свой трафик через необработанные сокеты или правильные сокеты TCP/UDP (, используя стек L3/4/5 соответствующей ОС). Или, если у вас есть какое-то программное обеспечение, использующее необработанный сокет на хосте, который вы хотите обезопасить, это программное обеспечение должно отсеивать интересующий его трафик и игнорировать остальной. Таким образом, необработанный сокет не является принципиальной дырой в безопасности входящего трафика.
Хороший пример — демон DHCP. Он слушает необработанный сокет, но в принципе проверяет только UDP, предназначенный для -известного порта 67. Он готов отвечать только на пакеты, соответствующие этим критериям. Он не будет отвечать на пакет TCP SYN на какой-то случайный порт, и на него не могут повлиять такие попытки подключения, законные или злонамеренные или что-то еще. Таким образом, если вы хотите открыть только порт UDP 67 dhcpd для подозрительной сети, вы можете в значительной степени применить iptables -A INPUT -i eth123 -j DROP, вам даже не нужно выборочно разрешать входящие UDP-порт 67, потому что необработанный сокет dhcpd все равно обойдет iptables -. только для собственного трафика.
Кроме того, использование необработанного сокета для передачи TCP — довольно глупая идея.Вам, вероятно, придется реализовать весь стек TCP в своем приложении = пустая трата усилий. Если вы просто не хотите провести некоторые атаки типа «новый, а не синхронизированный» и т. д., когда все, что вам нужно знать, — это правильный формат пакета для нацеливания, скажем, на дыру переполнения в конкретной реализации стека TCP (, тот, который вы пытаетесь атаковать).