Пример блокирования критической уязвимости CVE-2014-0160 в OpenSSL 1.0.1, позволяющей получить содержимое памяти удалённых серверных и клиентских приложений.
Отражаем в логе все heartbeat-запросы при помощи iptables и модуля u32:
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT"
Блокируем heartbeat-запросы:
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j DROP
Отслеживаем возможные атаки при помощи Wireshark:
tshark -i interface port 443 -R 'frame[68:1] == 18'
tshark -i interface port 443 -R 'ssl.record.content_type == 24'
- Блокирование попыток эксплуатации heartbeat-уязвимости в OpenSSL средствами iptables
- CVE-2014-0160 mitigation using iptables
Комментарии
imen
#cid89188
Ответить
Оно _могло_ иметь некоторый смысл 9 апреля.
Но не сейчас.
Первый вопрос: что за фича 'HEARTBEAT'? Кому, где и зачем она нужна?
(соответственно определяется поток легитимных запросов, мы же не будем брать пример с проприетарщиков, не допускающих мысли об ошибках типа false positives)
Итого, если нет возможности обновить пакет — его правильнее пересобрать с выключением фичи.
Но вообще-то к 14 апреля даже поддержка тырпрайс соизволила включить в репозитории исправленую версию пакета.
Так что пример может быть полезен только тем, кто вынужден использовать натуральную проприетарщину (в которой как известно работоспособность доминирует над правильностью решения) с недоступными исходниками и статической линковкой с уязвимыми версиями.
#cid89194
Ответить
Выложено, в основном, для демонстрации возможностей iptables.
imen
#cid89202
Ответить
#cid89194,
Строго говоря, не столько _собственно iptables, сколько модуля u32.
Который по моим наблюдениям является не то, чтобы стандартным.
В рамках задачи иллюстрации возможностей пакетного фильтра надо было начинать с описания метода ловли рыбы (добычи аргумента, соответствующего решаемой задаче), проверки правильности и ни в коем случае не пройти мимо проверки на false positives.
Но мой вопрос был не о логике работы _уязвимости_, а о _назначении_ фичи, ошибка в реализации которой была использована…