Фантастика. Обычное соединение тоже может использоваться как скан. RTFM.

Просто не нужно отвечать на ping-запросы. Host is down => PROFIT!

Host is down => PROFIT!

nmap -Pn

man port knocking

гугли на тему модуля iptables под названием psd, находиться в xtables-addons

http://www.google.ru/search?q=iptables match recent port scan

Просто не нужно отвечать на ping-запросы

ага, и за это нужно нещадно ломать руки

portsentry

Почему? :)

Лорчую

если точнее, нужно не отвечать только на icmp echo request, на остальные отвечать нужно, ибо без этого отрубится MTU path discovery

потому что пинги - это первейший инструмент диагностики сети. Защищаться от сканирования портов посредством отключения пингов - расписаться в профнепригодности.

потому что это хреновейшая практика, при которой ломается весь смысл icmp, включая нерабочесть пинга через роутеры и прочие проблемы.

читаем man iptables в разделе TCPMSS про iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

This target is used to overcome criminally braindead ISPs or servers which block «ICMP Fragmentation Needed» or «ICMPv6 Packet Too Big» packets. The symptoms of this problem are that everything works fine from your Linux firewall/router, but machines behind it can never exchange large packets:

ICMP - не только пинги (К.О.). Речь шла только про echo request/reply, все остальные сервисные сообщения оставлены

да все равно, какбы, тупое решение - блокировать пинги. да и что вообще плохого в сканировании - тоже вопрос.

Как зашитится от сканирования портов?

Зачем?

плюсую. достали маршрутизаторы в интернете, которые не видны ни по ICMP- ни по UDP- трассе

блокировать пинги.

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

что вообще плохого в сканировании

Можно разрешать себя пинговать (ping -f, ага)
Можно делать -j REJECT, а не -j DROP в iptables (ну а что? Ведь надо обязательно ответить интересующемуся, что порт у нас закрыт)
Можно не скрывать версии сервисов
Можно не блокировать попытки сканирований и взломов
Можно повесить ssh на дефолтном порту с открытым рут-логином и паролем 123.
Можно продолжать этот список долго.

Но зачем?

Сервер не живет сам по себе, он предоставляет сервисы для сети. Когда кто-то интересуется «жив ли сервер?» - подразумевается «работает ли $servicename?». Вот и пусть проверка делается для конкретного сервиса - с обращением на конкретный порт по конкретному протоколу (nmap, netcat)

не надо перегибать палку

сканирование портов и взлом это разные вещи.

на пример я, сканирую порты, чтобы посмотреть какие ещё интересные сервисы предоставляет сервер, если мне интересно.

вобщем, кому нужно, все равно тебя ломанут... а кому не нужно - и пытаться не будут...

сканирование портов и взлом это разные вещи.

Но одно может предшествовать другому :)

чтобы посмотреть какие ещё интересные сервисы предоставляет сервер...

...а потом ломаешь подходящие и добавляешь машину в свою армию для захвата мира :))

кому нужно, все равно тебя ломанут.

Просто не стоит облегчать им жизнь )

а потом ломаешь подходящие и добавляешь машину в свою армию для захвата мира

меня проще просто попросить

А ты сам как определишь, лежит твой хост целиком или только пару сервисов прилегло? Да, дома можешь сколько угодно пользовать.

И да, советовали уже knock. А еще можно так поразмыслить над iptables, что порты будут отвечать только определенным IP.

А ты сам как определишь, лежит твой хост целиком или только пару сервисов прилегло

У меня железо держит десятка полтора виртуалок, которые через NAT проброшены на внешний IP, висящий на нулевой ноде. Если разрешать пинговать сервер - а толку? Что именно я буду пинговать? Нулевую ноду, которая сервисов не содержит? А пинговать виртаульные сервера за NAT'ом, естесственнно, не получится.

скан в 90% проводится ботами. ботов проще банить fail2ban например. Если же Вас хотят взломать целенаправлено то очень многое зависит от ситуации.

ботов проще банить fail2ban например.

Так и делаю

очень многое зависит от ситуации.

Это да

rrrrr

Засчита
зашитится

защита
защититься

Тоесть если упадет одна виртуалка, клиент позвонит Вам и скажет «а пинга нету» вам сразу станет ясно что упала его виртуалка? Если бы ответы были, то вы бы сразу знали куда копать. А с таким подходом как у Вас можно и сислог закопать.

«а пинга нету» вам сразу станет ясно что упала его виртуалка?

А если в моем случае он будет - о чем мне это должно сказать?

Распишись в профнепригодности. С таким подходом к безопасности админа надо бить ногами, а когда упадёт - добивать. И вот почему:

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

Блокирование пинга - закрытие от внешнего мира? Security through obscurity - у####щная концепция by design. Догадаешься сам, почему?

Можно разрешать себя пинговать (ping -f, ага)

Об ограничении пакетов, отсылаемых от определённого хоста за единицу времени, слышал? И ping -f тебе не грозит. Но от забивания канала ты не не сможешь защититься.

-j REJECT, а не -j DROP в iptables

За некоторыми исключениями что в этом плохого? Кстати,

Можно не скрывать версии сервисов

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

Можно не блокировать попытки сканирований и взломов

Не сопоставляй попытки сканирования и попытки взлома.

Можно повесить ssh на дефолтном порту с открытым рут-логином и паролем 123.

У меня висит ssh на дефолтном порту, иногда даже с рутом, да только авторизация только по ключам. И fail2ban отсекает тупых ботов. Где здесь дыра в безопасности?

Как зашитится от сканирования портов ?

можно попробовать написать цепочку правил iptables по которым, если с IP, происходит больше определенного числа коннектов на разные порты в единицу времени, то перенаправлять его на цепочку временного бана, тут понадобиться модуль ipt_recent для iptables

И вот почему

Странные рассуждения, основанные на придуманных для меня аргументах. «И вот почему» (с):

Об ограничении пакетов, отсылаемых от определённого хоста за единицу времени, слышал? И ping -f тебе не грозит.

Слышал.

Но от забивания канала ты не не сможешь защититься.

Тогда зачем помогать забивать исходящий (безотносительно ping'ов - любыми ответами, не относящимися к делу)?

что в этом плохого?

Ответил выше

если только у тебя не старый дырявый сервис без заплаток.

Я не говорил, что прячу версии из-за того, что пользуюсь неактуальным софтом

Потому что если на тебе решат проверить все известные уязвимости - тебя скрытие версии не спасет

Целенаправлено - согласен (с оговоркой: опять-таки, не стоит облегчать поиск дыр в сервисах). Автоматически - может помочь. Или 0-day-уязвимости, для которых еще нет исправления, для тебя не существуют?

Не сопоставляй попытки сканирования и попытки взлома.

Уже отвечал выше. Если результаты первого чем-то заинтересуют, может последовать второе. Не стоит давать лишний повод для интереса.

Где здесь дыра в безопасности?

Про тебя речь не шла. Ибо, хоть и

У меня висит ssh на дефолтном порту, иногда даже с рутом

ты все же предпринял какие-то шаги для улучшения безопасности сервиса:

да только авторизация только по ключам. И fail2ban отсекает тупых ботов.

Но мой вариант мне нравится больше:

Status for the jail: ssh
|- filter
|  |- File list:        /var/log/auth.log 
|  |- Currently failed: 0
|  `- Total failed:     0
`- action
   |- Currently banned: 0
   |  `- IP list:       
   `- Total banned:     0

Status for the jail: apache-suhosin-short
|- filter
|  |- File list:        /var/log/user.log
|  |- Currently failed: 0
|  `- Total failed:     61
`- action
   |- Currently banned: 0
   |  `- IP list:
   `- Total banned:     39

В общем, пока я так и не увидел нормальных аргументов, почему я должен предоставлять кому-то информацию про устройство сервера, отвечать на ненужные для меня запросы и т.п. - только советы о том, что можно сделать и как оно бывает. Почему-то вышеотписавшие внезапно решили, что у меня вся безопасность строится на отключении echo request :). Я просто решил, что нет смысла разрешать то, что можно запретить без нарушения работы сервера.

1) Вас сломали

2) У провайдера есть авторедирект на какой-то редирект в случае отказа вашего железа

3) происходит перезагрузка и внезапно во время нее карточка сама решила ответить на пинг (да, бывало такое)

4) Происходит чертовщина (это Вы и подумаете)

5) над вами пошутили.

Понимаете-ли, если что-то было и этого не стало, определить почему обычно проще чем если этого небыло и вдруг появилось (или не появилось). Так что хватит вещать впустую про то как у вас все было-бы хорошо.