Ничего не случится если сбрасывать все пакеты?

У тебя - нет. А у тех, кто запрашивает, могут быть ошибки. По большой
и светлой идее правильнее делать reject.

> По большой и светлой идее правильнее делать reject.

И с ненулевой долей вероятности рано или поздно поиметь DoS, например, от флуда...

Тут, в принципе, обычная стратегия примерно такова (относительно внешнего интерфейса):

1. Любые входящие пакеты запрещены -- DROP (проблемы быков Юпитера не волнуют, точной фразы не помню).

Ну ладно, не все, а те, которые заведомо не могут там появиться (если внешний адрес -- левый, то соответствующую сеть убираем): от сетей 192.168.0.0/16, 172.16.0.0/12, 127.0.0.0/8, 10.0.0.0/8, 0.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 204.152.64.0/23, 224.0.0.0/3. Причем не только входящие, а и исходящие.

2. Если хотим, чтобы нас могли пинговать, разрешаем нужные виды icmp (если не изменяет память, icmp echo).

3. Разрешаем входящие пакеты (инициирующие коннект) только к выставленным во внешний мир сервисам (с редиректом на соответствующую машину в DMZ), причем только требуемые протоколы (tcp, udp, icmp), а не все сразу.

4. Разрешаем входящие пакеты, являющиеся ответными на исходящие. Без понятия, как это в iptables, в OpenBSD PF это

pass out on $ExtIF inet proto tcp all flags S/SA modulate state

pass out on $ExtIF inet proto { udp, icmp } all keep state

А я пропускаю все icmp -- т.к. по крайней мере следующее мне кажется нужным:
1) хост в дауне
2) сеть недостижима
3) сервис недоступен
4) фрагментация
5) эхо-реплай
6) пинг в меня

>204.152.64.0/23, 224.0.0.0/3

а это кто такие?

Reserved addresses on the Internet

    192.168.0.0/16 (reserved for internal networks)
    172.16.0.0/12 (reserved for internal networks)
    10.0.0.0/8 (reserved for internal networks)
    0.0.0.0/8 (used strangely by some stacks for routing)
    127.0.0.0/8 (the localhost)
    169.254.0.0/16 (IANA use)
    192.0.2.0/24 (netblock for documentation authors)
    204.152.64.0/23 (Sun Microsystems cluster interconnects)
    224.0.0.0/3 (class D and E multicasts)

Из другого источника:

Anti-spoofing: Micro$oft Window$ will use addresses in the
169.254.0.0/16 range if they are set to DHCP and cannot find a DHCP server

Anti-spoofing: 192.0.2.0/24 has also been reserved for use as an
example IP netblock for documentation authors

Anti-spoofing: 204.152.64.0/23 is reserved by Sun Microsystems for
private cluster interconnects

Anti-spoofing: wipes out the "Class D and E" networks which is used
mostly for multicast traffic

Делаем заключение, что всей этой дряни НА ВНЕШНЕМ интерфейсе делать нечего.

спасибо

Может не в тему, но замечено, если делать REJECT, то паразитный трафик (я плачу за мегабайты и у меня реальный IP) набегает меньше, чем при DROP, эксперементировал оставлял на два дня и с тем и с тем действием на все входящие пакеты и исходящие пакеты (короче это время инет не юзал), статистика прова показала разницу в 8 раз, эксперемент я проводил около 4 раз.

Ну а насчёт DoS на REJECT, то мне кажется в реализации современного протокола ICMP заложено чтоб не отвечать если уж слишком тежело и не отвечать на каждый пакет если флуд идёт с одного хоста... Но я могу ошибаться...

У reject перед drop есть еще один минус:

Предположим, что у нас в DMZ (файрволл нужным образом редиректит нужные пакеты) есть почтовик и веб-сервер. ВСЕ остальные коннекты извне мы запрещаем. Теперь некий уродец нас сканит (причем методом CONNECT, как последний чайник).

Если мы применяем reject, то при попытке коннекта на "прикрытый" порт злоумышленник тут же получает TCP RST и переходит к следующему порту.

Если мы применяем drop, то злоумышленник ждет ответа, пока не истечет тайм-аут. Скорость сканирования падает на порядок.

Применение reject сообщает злоумышленнику: "да, тут есть хост, но с файрволлом". Drop же сообщает: "тут может быть хост, а может и не быть, хрен его знает, думай сам".

> но замечено, если делать REJECT, то паразитный трафик (я плачу за мегабайты и у меня реальный IP) набегает меньше, чем при DROP

Странно, ведь при drop мы никак не отвечаем на пришедший пакет, а при reject отсылаем обратно отлуп.

> не отвечать на каждый пакет если флуд идёт с одного хоста...

DDoS -- знакомо? Будет по одному пакетику с 10000 хостов...

Чтобы несколько смягчить дискуссию по поводу DoS при reject, скажем так: чем ТОЛЩЕ канал и слабее машина, тем проще получить DoS либо DDoS.

P.S. Дело привычек, кто как привык. Я -- отбрасывать ненужное молча (drop), не сообщая удаленной стороне, что "на этом порту все равно ничего нет" (reject). Лезешь "куда не надо" -- подожди до истечения тайм-аута.

> но замечено, если делать REJECT, то паразитный трафик (я плачу за мегабайты и у меня реальный IP) набегает меньше, чем при DROP

Я смотрел логи, при коннекте на порт, где пакеты дропаются, почему то приходят по 5-8 пакетов, прежде чем удалёная машина поймёт, что там ничего нет... При REJECT, при получении первого пакета, коннект сразу отваливается.

Похоже, что выбор DROP или REJECT - дело вкуса.
Лично я везде ставлю политику DROP, а дальше разберемся.
Еще один аргумент в пользу DROP - не во всех цепочках и таблицах iptables можно сделать REJECT, а DROP возможен всегда.

если ориентироваться на сканирование, то лучше DROP а если на реальные попытки какого-то совта ткнуться в неоткрытый порт, то лучше REJECT, т.к. избавит от повторных запросов сервер, (особенно по UDP), и от ненужного ожидания юзера "на том конце провода" (ведь в конечном счете "все для него"?)