Как IPTABLES оборвать уже установленное соединение?

conntrack -D -s адрес_источника -d твой_адрес -p tcp --sport исх_порт --dport твой_порт

conntrack -D -s адрес_источника -d твой_адрес -p tcp --sport исх_порт --dport твой_порт

Уточняю: в старых версиях conntrack (например, 0.9.6) был баг, не позволяющий использовать sport без dport и наоборот. В новых версиях, например, 0.9.13, его устранили, и можно спокойно писать

conntrack -D -d твой_адрес -p tcp --dport твой_порт 

Также замечу, что conntrack — это не базовый сетевой стек ведра, и удаление из него записи оборвет соединение только при правильно настроенном фаерволе.

Ещё есть tcpkill:

http://lists.debian.org/debian-russian/2003/10/msg00148.html

еще один вариант

iptables -I OUTPUT -p tcp --sport N -j DROP

соединение оборвется моментально т.к. софтина получит от ядра -EPERM

и да, обязательно добавить -d и --dport

локальное приложение при этом не получит уведомления о том что сокет уже того.

И я не согласен что «правильный» фаервол должен использовать conntrack.

>И я не согласен что «правильный» фаервол должен использовать conntrack.

Т.е. правильный фаервол должен быть stateless, как старый добрый ipchains?

Правильный фаервол должен решать поставленную задачу. Коннтрак нужен далеко не всегда.

>Правильный фаервол должен решать поставленную задачу. Коннтрак нужен далеко не всегда.

Вопрос стоит так: либо фаервол с поддержкой stateful-фильтрации (и прочих плюшек типа NAT и маршрутизации), и тогда conntrack необходим, либо чистый stateless-фаервол.

>И я не согласен что «правильный» фаервол должен использовать conntrack.

netfilter без conntrack имхо годится разве что для Его Императорского Величества Кунштов Камеры.
Нахрена нужен фаервол, который не умеет следить за соединениями?

>iptables -I OUTPUT -p tcp --sport N -j DROP

Если по дефолту дропать все INVALID-пакеты (что обычно и делается при правильно настроенном фаерволе), то вариант с conntrack дает аналогичный эффект :)

и да, обязательно добавить -d и --dport

dport добавлять как раз необязательно, потому что с этого адреса может быть куча коннектов с разных портов.

>локальное приложение при этом не получит уведомления о том что сокет уже того.

Как правильно отметил Cosmicman, при дропе исходящего пакета приложение получает отлуп. А дропать INVALID-пакеты — это азы мастерства.

Нахрена нужен фаервол, который не умеет следить за соединениями?

Тоже самое можно про любую фичу сказать, но это не значит что её обязательно надо использовать ради самого процесса использования.

Только если соединение просто висит и обмена трафиком нет то тут ни твой дроп не поможет ни tcpkill.

>Только если соединение просто висит и обмена трафиком нет то тут ни твой дроп не поможет ни tcpkill.

Да, тут только kill поможет :)
Только, как правило, такие соединения особого интереса не представляют. Систему они совершенно не грузят, и задосить так практически нереально. Ну а если процесс сошел с ума и наделал кучу зомбей, грохать надо процесс.

>Тоже самое можно про любую фичу сказать

Нахрена нужен чайник, который не умеет копать канавы?
Лично мне такой чайник вполне подходит, лишь бы воду кипятил :)
А вот чайник, не умеющий кипятить воду, мне нафиг не сдался.

stateful-фильтрация — одно из величайших достижений человечества по облегчению себе жизни, наравне с ssh, унитазами и горячей пищей. Меня до сих пор преследуют в кошмарах конфиги ipfw, сделанные красноглазой молодежью по манам тыща девятьсот лохматых годов, когда про keep-state и check-state никто и не слышал.

вот у меня vnc подвисал у kvm. Одновременно только одно соединение держит и без обмена трафиком оно висело... keep-alive, возможно, вылечил бы, не проверял.

Я не про это.

Меня как раз преследуют кошмарные конфиги фаервола на десятки строчек.

Вот у мну есть сервер, там conntrack не загружен и не используется фаерволом. По твоей логике у меня неполноценно настроен сервер.

Вот и спорю с этим утверждением, мне хватает ipset и hashlimit и всё работает много лет.

>Вот у мну есть сервер, там conntrack не загружен и не используется фаерволом. По твоей логике у меня неполноценно настроен сервер.

Есть подозрение, что если ты основательно поковыряешься в возможностях stateful-фильтрации, у тебя возникнет сильное желание улучшить эту конфигурацию :)

На мой взгляд, важнейшая фича stateful-парадигмы — возможность написать -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT и забыть нафиг про необходимость пропускать существующие соединения, сконцентрировавшись только на разрешении/запрещении новых.

Вот и спорю с этим утверждением, мне хватает ipset и hashlimit и всё работает много лет.

Хм, лично мне очень трудно представить себе задачу, для которой нужны ipset и hashlimit, но не нужен conntrack. Сам я, например, практически всегда использую hashlimit только для NEW-пакетов, так как досы обычно идут с открытием большого количества новых соединений. Конечно, keep-alive connections еще никто не отменял, но кастовать лимиты на рабочие соединения, имхо, не решение проблемы. Да даже и conntrack'овский connbytes для этого имхо удобнее.

А connlimit ты случайно не используешь? :) Он тоже через conntrack работает.

Вообще же я стараюсь по возможности нагораживать многоуровневые рубежи защиты: hashlimit, connlimit, geoip, ipset, NOTRACK, TARPIT, psd, CHAOS.

>вот у меня vnc подвисал у kvm. Одновременно только одно соединение держит и без обмена трафиком оно висело... keep-alive, возможно, вылечил бы, не проверял.

Ну так я ж говорю — kill. Горбатого могила исправит.

Емнип, линуховое ведро не позволяет просто так взять и грохнуть сокет.

Вот я про эти «многоуровневые» рубежи и говорю: оно не надо. Меня не парит соверщенно что придёт, например, пакет который не относится ни к какому соединению- оно мне ничего не сделает. Каждый раз когда меня пугают атаками смело даю(щас не дам, не хочу деанонимизации) айпишник моего сервера, пока ещё никто умнее флуда ничего не придумал, а от этого я и так прекрасно защищён. От всего остального фаервол не поможет. Или мне так с атаками не везёт, но флуда тупого в последнее время мало.

А connlimit ты случайно не используешь?

Иногда использую, но это легко может отсечь, например, людей, сидящих через мобилы. Тут надо аккуратно. Да и проще через nginx этим рулить в силу того что при атаке если будут засранцы они высыпут в nginx_error.log откуда их поведение можно легко проанализировать скриптом без всяких -j ULOG.

Зато вот таких багов у меня нет: http://forum.nginx.org/read.php?21,42139

>Вот я про эти «многоуровневые» рубежи и говорю: оно не надо. Меня не парит соверщенно что придёт, например, пакет который не относится ни к какому соединению- оно мне ничего не сделает. Каждый раз когда меня пугают атаками смело даю(щас не дам, не хочу деанонимизации) айпишник моего сервера, пока ещё никто умнее флуда ничего не придумал, а от этого я и так прекрасно защищён. От всего остального фаервол не поможет. Или мне так с атаками не везёт, но флуда тупого в последнее время мало.

Наверное, мы просто смотрим на проблему с разных точек зрения. Тебе нужно защитить от доса один веб-сервер, а мне чаще всего приходится защищать сложные объекты от самых различных видов атак. Поэтому тебе достаточно пары штатных средств, а мне и десятка их мало. И, наверное, окажись я на твоем месте, я так бы и остался параноиком :)

Но дело тут вовсе не в рубежах, это я просто к слову упомянул. Как я уже говорил выше, для меня самым большим плюсом stateful-парадигмы является возможность фильтровать только NEW-пакеты, зная, что обо всех остальных позаботится сама система.

Зато вот таких багов у меня нет: http://forum.nginx.org/read.php?21,42139

Я так и не понял, каково же там соотношение спирта (баг с обработкой TCP window scaling, который закрыли еще в 2.6.11) и керосина (клиентов и провайдеров, у которых пакеты за размер окна вылетают).

а мне чаще всего приходится защищать сложные объекты от самых различных видов атак.

Мы щас говорим о фаерволе который кроме как на уровне транспортных протокол дальше и не реботает. От этих проблем ядро и само может себя защитить. А от атак на уровне приложений это бесполезно.

А ещё ты пишешь что машину надо защищать только на эта установки соединений(NEW), а это неправильно. Можно гадостей и с установленным соединением настроить. Да и что можно на этапе установки соединения проверить? Пока все проверки что я видел сводились к сверке с чёрным списком в ipset и ограничением общего кол-ва установленных соединений.

Есть ещё всякая мастурбация c модулем string...

И откуда у тебя в rhel TARPIT? :)

я так бы и остался параноиком :)

Я абсолютно нормально отношусь к iptables вообще и conntrack в частности. Я с ним много экспериментировал как и со всякими conntrack-tools итп. А потом с опытом больше осознал какую задачу решаю, выяснил что я теряю при этом и сделал как сделал. Ну и конечно я смотрю со стороны своей специфики, вебсервера это защищаются нормально :).

В общем, если есть желание меня переубедить то приведи конкретный сценарий атаки от которой весь этот лес правил поможет и что не решат мои простые решения.

>Мы щас говорим о фаерволе который кроме как на уровне транспортных протокол дальше и не реботает. От этих проблем ядро и само может себя защитить. А от атак на уровне приложений это бесполезно.

А зачем ограничивать себя только транспортным уровнем? Имхо, из каждого средства защиты нужно выжимать все, на что оно способно. Само собой, с учетом разумных ограничений, налагаемых возрастающей трудностью создания и поддержки таких систем. То есть: если какая-то фича требует траха в три дня и три ночи и при этом прибавляет к защите очень немногое, то нафиг она нужна. Но если она делается легким движением руки и потом есть не просит — то пуркуа бы и не па? Именно такие принципы для меня являются приоритетными, а вовсе не «это фаервол, значит место ему на 3 и 4 уровнях, пусть сидит и не тявкает».

Тот же string, например. С таким сравнительно несложным скриптиком, как fwsnort, он позволяет создать неплохую замену классической свинке. Причем работать наверняка будет быстрее, ибо PCAP требует сравнительно долгих манипуляций с каждым пакетом. (Сам пока еще не тестил, только приглядываюсь.)

Можно гадостей и с установленным соединением настроить.

Можно. А как фаервол от этого поможет? Трафик hashlimit'ом резать? И кому от этого легче станет? Имхо тут рулят как-раз таки специализированные средства защиты. Тот же nginx для HTTP, например.

Да и что можно на этапе установки соединения проверить? Пока все проверки что я видел сводились к сверке с чёрным списком в ipset и ограничением общего кол-ва установленных соединений.

Ну, в общем, да.
— Черные списки в ipset и geoip.
— Скорость открытия новых соединений через hashlimit.
— Количество одновременно открытых соединений через connlimit.
— Выявление попыток сканирования портов через psd и/или recent.
Ну и пополнение блэклистов на основе работы последних трех пунктов.

И откуда у тебя в rhel TARPIT? :)

Вот centos, который админит nnz.
Вот xen, который работает на centos, который админит nnz.
Вот debian, который крутится в xen, который работает на centos, который админит nnz.
Вот xtables-addons, установленный на debian, который крутится в xen, который работает на centos, который админит nnz.

Я же параноик :)

В общем, если есть желание меня переубедить то приведи конкретный сценарий атаки от которой весь этот лес правил поможет и что не решат мои простые решения.

Защиту портов через knocking юзаешь?
Вот смотри: для stateless-фаервола на все время сеанса нужно держать открытым айпишник, с которого был стук, что позволяет кульхацкерам, сидящим с одного ната с тобой, спокойно ломать твой сервак (а в сочетании с hashlimit'ом — еще и мешать тебе работать). А для stateful достаточно добавить одно правило для NEW-пакета и убрать его по истечении заданного таймаута (скажем, 5 секунд).

Твою позицию я понял, дальше обсуждать не вижу смысла, это будет продолжаться до бесконечности.