В Thu, 28 Feb 2013 16:51:25 +0400 dimas <[email protected]> пишет:
> > Заведомо бредовые запросы на 80й порт смысла отсекать нет т к сервер > > на них будет отвечать скорее всего 404й ошибкой. > идея в том, чтобы веб-сервер как раз не грезить такой фигней. т.к. > iptables все равно задействован, мне кажется, логично было бы > отсекать на этом уровне все, что не "GET /* HTTP...." > > > Если домашний комп будет смотреть в инет под внешним ip напрямую, то > > наверное имеет смысл сделать фильтр iptables на белый список портов > > к которым можно конектится извне. > ну, как-то так и планиурется. что-то типа: > если с 192.168.0.* - разрешить > (тут еще возможные допущения) > если на 80/443 порт - разрешить > (туда же нужные для p2p порты) > остальные входящие - под запрет и в бан > может быть, с --connlimit еще стоит поиграться. и с количеством > запросов за единицу времени (через --recent как-то делается) > кстати, а есть ли смысл банить негодяев по mac-адресу, а не по айпи, > который сегодня один, а завтра другой? > > > Для торректов и прочиз p2p польза от прямых соединений будет > > весомая. Т е теперь можно будет качать с клиентов, которые сидят за > > NAT. > понял, спасибо > > > Я это делал средствами iptables, но как уже точно не смогу > > вспомнить. Думаю лучше начать с > > http://www.opennet.ru/docs/RUS/iptables/ > понимание работы iptables какое-никакое есть. просто пишут, что > генерировать десятки-сотни записей типа: > -A INPUT --src <ip каждого гада> -j DROP > как бы не лучший вариант, будет тормозить адово при большом > количестве записей. в общем-то, в описании к ipset и сказано, что он > как раз для таких дел придуман и разруливает их гораздо быстрее. > > да, еще вот интересно: что эффективнее с точки зрения нагрузки: DROP > или REJECT? логика подсказывает, что дроп, т.к. атакующий не получает > ответа и ждет довольно продолжительное время, пока не отвалиться по > таймауту. а при отказе он может тупо долбить снова и снова с весьма > малым интервалом. только вот дропнутый пакет удаляется сразу из > очереди, или как? > > а, еще вспомнил: про SYN-флуд и SYN-куки стоит заморачиваться? > > По поводу iptables стоит почитать вот эту статью - http://ru.wikibooks.org/wiki/Iptables#.D0.9C.D0.B0.D1.80.D0.BA.D0.B8.D1.80.D0.BE.D0.B2.D0.BA.D0.B0_.D1.81.D0.BE.D0.B5.D0.B4.D0.B8.D0.BD.D0.B5.D0.BD.D0.B8.D0.B9 судя по описанию, можно маркировать соединения (а не пакеты), и необходимости во множестве -A INPUT --src <ip каждого гада> -j DROP не будет. Да и работать это все будет идеологически правильно, без обвязки коровскими скриптами на изменение iptables. Я когда реализовывал, делал по этой статье. Для защиты от ддоса я бы использовал TARPIT. Выдает очень хорошие результаты при сканировании портов =) Банить по mac адресу бессмысленно т к все пакеты, которые приходят к вам на роутер/домашний сервер имеют mac не отправителя пакета, а ближайшего маршрутизатора, который отправил в вашу септь пакет. Т е забанив мак - забанятся все пакеты, которые проходят через него. С SYN флудом не сталкивался, но опять-же после прочтения статьи на викиучебнике думаю многие вопросы как это реализовать отпадут. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20130228171202.092ca395@arch97
