Comments 24
Совершенно бесполезная работа и трата ресурсов. Своих и чужих. Все проще.
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
# Что еще надо разрешить
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
# Всё
-A INPUT -j DROP
Для совсем параноиков строчку 2 убрать
И будете наблюдать как по 22 порту ломятся какие-нибудь китайцы. Хоть количество новых соединений ssh ограничьте.
можно как-то так любителей сканирования придавить
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j ACCEPT
Между прочим любители сканировать и подбирать пароли еще не так достают, как некоторые краулеры и боты способные нехило напрячь сервер по процессору и оперативке. Потому лучше применять еще что-то вроде nginx-ultimate-bad-bot-blocker.
Всякие лимитеры - это трата ресурсов, всякие таблицы которые могут переполниться, парсеры не туда посмотрят и так далее. Практика, которая как известно, критерий инстины, показывает, что никакой проблемы от китайцев и прочих сканеров на 22м не наблюдается. Поэтому хватает запретить логин root и логин по паролю, что бы спать спокойно и не обращать на это внимание.
Ровно до тех пор пока что-то действительно не произойдет и не понадобится разбирать логи, где будет куча "мусорных" записей.
Попытки перебрать пароли и сканирование портов в несколько потоков по вашему не отбирает ресурсы?
Или к примеру у вас web-приложение, которое открыто для клиентов, но совершенно не должно быть доступно ботам и злоумышленникам.
Ровно до тех пор пока что-то действительно не произойдет и не понадобится разбирать логи, где будет куча "мусорных" записей.
для этого есть всякие siem и прочие штуки. ну или grep на худой конец
Попытки перебрать пароли и сканирование портов в несколько потоков по вашему не отбирает ресурсы?
нет. пароли запрещены, а на все порты стоит DROP.
Или к примеру у вас web-приложение, которое открыто для клиентов, но совершенно не должно быть доступно ботам и злоумышленникам.
Для этого давно придумали кучу вариантов. Самый простой в реализации это использование сертификатов. Отстрел идет прямо на уровне ssl-stripping , не доходя до бизнес логики. Потом всякие логины, токены и прочие модные технологии. В общем, решения есть и все они работают не на уровне портов и айпи адресрв
$ sudo su -
Last login: Mon Aug 8 17:40:41 MSK 2022 on pts/0
Last failed login: Fri Sep 2 16:35:45 MSK 2022 from 183.250.249.170 on ssh:notty
There were 5888 failed login attempts since the last successful login.
Это с живого сервера, у которого 22й порт торчит в интернет без всяких лимитеров. За месяц 6 тыщ. У многих веб-сервер за секунду больше обрабатывает :)
Не выставляйте голым портом в интернет то, что не нужно. Начинать, IMHO, нужно с этого
Тут скорее защита от такого:
Бот сканит все порты, находит открытыми 80 и 443
Начинает подбирать эксплоиты к http-серверу.
Ну так если 80 и 443 не нужны - их не надо выставлять наружу. Если они нужны и выставлены специально - ничего не поможет
Если они нужны и выставлены специально - ничего не поможет
Не совсем не поможет - есть всякие IDS, IPS, WAF, UEBA и SIEM ("и много других страшных аббревиатур"). Можно, в принципе, в той же IPS сделать правило блокировки сканов портов... Можно WAF'ом защищать конкретно http/https.
Причём в простом случае можно обойтись без колхозов, что-то из указанного выше доступно "искаропки" для большинства дистрибутивов Linux/FreeBSD или роутерных решений (при том что есть платные варианты, да, там базы побольше и пооперативнее обновляются).
Трудно бороться с DDOS'ами. А уж с тётей SHODAN (Sentient Hyper-Optimized Data Access Network, если кто помнит :) ) уж как-нибудь можно.
Тут ведь прикол ещё что 80/443/22 проверят скорее всего первыми.
На данный момент в базе уже находится свыше 570 тысяч атакующих адресов IP из совершенно разных стран.
Может стоит их периодически "забывать", как это делает fail2ban. Не думаю что кому-то будет интересно перебирать порты или пароли со скоростью 1 в час.
Если заглянете на сайт, то увидите, что на данный момент забанены 17к из всех.
(deleted)
Я правильно понимаю, что любой, кто может отправить на ваш файрвол SYN-пакет с поддельным src IP, эффективно заблокирует вам любой IP, да хоть весь интернет?
Да, правильно. Только провайдеров, которые выпускают такие пакеты от себя почти не осталось в мире.
Увы, полно, недавно с этим сталкивался и это было больно. Расследовать, будучи представителем вендора, общающимся с админами провайдера, при том что бяку пропускает их вышестоящий было тяжело :)
По идее проблему IP спуфинга можно сгладить (не решить) несколькими очередями (отдельные ipset и правила -m set --match-set prev_queue -j SET --add-set next_queue) и отправлять в бан после 2-5 левых пакетов. При IP спуфинге, к слову, злоумышленник вряд ли получит ответ при сканировании. Но это отдельный вектор/цель атаки.
Замени -j LOG на -j SET --add-set blacklist и можно выкинуть сислог из схемы. А синхронизацию сделать на выхлопе ipset save blacklist. Сходу подводный камень можешь обойти – жми aggregate'ом до подсетей и префиксов, но так потребуется логика периодической перезаливки. И выстави hash:net. По maxelem и hashsize субъективный совет – лучше 1:1, в край 1:4. Коллизии в 30 штук при равномерном распределении и полном заполнении дешевле памятью закидать чем cpu, но 1 млн. счётчиков – это полужопка. 100-300к префиксов приемлемо будет, особенно вместе с аггрегейтом.
Привет с лорша, кстати :)
Полезно было бы дополнить статью конфигом nftables, идущему на замену iptables.
так вот к чему был этот опрос))
Как защититься от сканирования портов и Shodan?