Я установил схему блокировки портов для защиты порта 22 с помощью правил iptable. Вдобавок к этому я установил некоторые правила "горшочка с медом", чтобы отключить блокировку портов для клиента на несколько минут, если они попадают в общие порты, которые не используются (например, порт 21), или порты, соответствующие последовательности стука. Кажется, это работает хорошо (я считаю, что это лучший вариант, чем изменение порта на что-то неясное). Для пароля SSHD вход в систему в любом случае отключен - требуется зашифрованная комбинация закрытого и открытого ключей.
На эта страница существует схема «поддона», согласно которой при поражении неиспользуемых портов клиент не может связываться ни с чем (даже с открытыми портами) в течение 60 секунд. Больше всего меня беспокоит то, что "--hitcount 3" запускается любым простым запросом к одному порту.
Итак, у меня вопрос: что вы думаете о такой установке? На веб-сервере слишком много "поддона" или в самый раз? Есть ли у вас какие-либо другие советы по безопасности брандмауэра, кроме сохранения политики отключения и открытия только того, что необходимо?
Редактировать: Я использую CentOS 5.7. Мы исходим из того, что «безопасность насколько это возможно в разумных пределах». Сервер должен соответствовать требованиям PCI / SAS (и другим подобным стандартам). В центре внимания будет брандмауэр, а не обязательно обнаружение уязвимостей отдельных служб (это другая тема). Все, что мне не хватает, связано с брандмауэром или чем-то внешним. Хотите, чтобы злоумышленнику было как можно сложнее получить доступ.
Полностью субъективное мнение здесь, но стучать портами я никогда так не интересовался.
Немного похоже на клудже, и я всегда беспокоился, что наступит время, когда он перестанет работать должным образом, или я обнаружу крайний случай, который заблокирует меня из моей системы.
Я обнаружил, что с отключенной аутентификацией по паролю и только с парами ключей SSH я редко вижу, чтобы один и тот же бот пробовал порт более нескольких раз. Это просто непрактично, когда есть так много других хостов, которыми можно владеть. До тех пор, пока люди не перестанут разрешать вход в систему по SSH с root-правами и полностью откажутся от аутентификации по паролю, низко висящие плоды все еще существуют и готовы к выбору киберпреступников.
На брандмауэре я обычно сбрасываю соединения с TCP 22, за исключением нескольких мест, так как я редко бываю там, где мне нужен прямой доступ к ящику (я просто VPN в том месте, где это возможно).
Я предполагаю, что это веб-сервер, да? Потратьте время на понимание требований ваших веб-приложений. Ваш типичный брандмауэр с отслеживанием состояния практически бесполезен для защиты от атак, которые происходят через порт 80, таких как внедрение SQL, XSS и т.п.
Я бы также установил надежное ведение журнала (регистрируйте все ваши SQL-запросы, если вы используете базу данных; настройте удаленный системный журнал для журналов вашего брандмауэра, журналов веб-сервера, auth.log, системных журналов, журналов веб-сервера и т. Д.)
Я бы установил прокси-сервер на другом хосте (если вы можете) и отбросил бы все исходящие сообщения с вашего веб-сервера через брандмауэр. Когда / если ваш ящик станет владельцем, злоумышленник не сможет установить прямое TCP / UDP-соединение в Интернете (обычно одна из первых вещей, которые злоумышленник захочет сделать, это установить оболочку для вашей системы), и если вы предупреждаете, вы сразу узнаете.
Единственный разрешенный исходящий HTTP-трафик должен выходить через прокси-сервер, и вы должны (по крайней мере, для сервера) иметь белый список подходящих доменов (например, репозиторий управления пакетами).
Это будет иметь большое значение; Предположим, что вы попадете в руки, и планируйте и защищайте соответственно.