Re: домашний хостинг
> Заведомо бредовые запросы на 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-куки стоит заморачиваться?
Reply to: