> Заведомо бредовые запросы на 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-куки стоит заморачиваться? -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
