Комментарии 105
iptables -P INPUT DROP
iptables -P FORWARD DROP
cowrie:22 > fai2ban
Можно обойтись и без fai2ban если хакер не будет знать на каком порту у вас SSH сидит. Это можно сделать вот так если добавить эти правила, они позволят заблокировать IP адреса хакеров кто сканирует ваш сервер
iptables -N BRUTESCAN # Создаем список "BRUTESCAN", строгие правила для проверки хакеров, проверяем brute force и сканирование портов
iptables -A BRUTESCAN -m recent --update --seconds 600 --hitcount 10 --name ScanPort -j DROP # Если на легитимный порт входит хакер который сканировал нас, мы его блочим
iptables -A BRUTESCAN -m conntrack --ctstate NEW -m recent --update --seconds 42000 --hitcount 16 --name BruteForce --rsource -j DROP # Если за последние ~11 часов с одного адреса было 16 или более новых соединений — блокируем этот адрес
iptables -A BRUTESCAN -m recent --set --name BruteForce -j ACCEPT # В противном случае - разрешаем, и при этом заносим в список IP откуда зашли
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport $MyPortSSH -m comment --comment "SSH" -j BRUTESCAN # Все попытки открыть новое соединение по SSH направляем на проверку
# начало анализа сканирования портов и добавления Хакеров в список↓ это последние строка ниже которой ничего не писать
# echo / > /proc/net/xt_recent/ScanPort # очистить список, если нужно сбросить счетчики
iptables -A INPUT -m recent --name ScanPort --seconds 10800 --hitcount 9 --update -m comment --comment "Block Hackers 3 hours" -j DROP # Если за последние 3 часа было 9 или более запросов на нерабочие порты - блокируем
iptables -A INPUT -m recent --name ScanPort --seconds 60 --hitcount 2 --update -m comment --comment "Block Hackers 60 sec" -j DROP # Если за последнюю минуту было 2 или более запросов на нерабочие порты - блокируем
iptables -A INPUT -m recent --set --name ScanPort -m comment --comment "Add Hackers to list" -j DROP # Всех, кто ломится в нерабочие порты - регистрируем
Интересная альтернатива fail2ban. Ещё стоит учитывать, что такой вариант не пишет логи, модуль recent работает на уровне ядра и просто хранит список IP в памяти.
Если нужны записи о блокировках, можно добавить правило с -j LOG или использовать fail2ban.
Пример правил:
iptables -A INPUT -m recent --name ScanPort --seconds 10800 --hitcount 9 --update -m comment --comment "Block Hackers 3 hours" -j LOG --log-prefix "PortScan blocked:"
iptables -A INPUT -m recent --name ScanPort --seconds 10800 --hitcount 9 --update -m comment --comment "Block Hackers 3 hours" -j DROP
Отличное решение! Пишет в /proc/net/xt_recent
Разбор по полям:
src=109.205.211.94 — IP-адрес, занесённый в список.
ttl: 248 — TTL (Time-To-Live) последнего пакета от этого IP.
last_seen: 5690581158 — время последнего пакета с этого IP в ед. счетчика ядра (jiffies).
oldest_pkt: 23 — количество старейших пакетов, сохранённых в списке (нумерация или счётчик).
После oldest_pkt идут метки времени последних пакетов (в jiffies). Например:
5690393555, 5690400954, 5690413095, ... 5690581158Я у себя протестировал, команды такие.
iptables -I INPUT 3 -i enp4s0 -p tcp -m multiport ! --dport пишем порты которые не хотим отслеживать в формате порт,порт или порт:порт -m recent --set --name ScanPort -m comment --comment "Add Hackers to list"
iptables -I INPUT 4 -i enp4s0 -p udp -m multiport ! --dport пишем порты которые не хотим отслеживать в формате порт,порт или порт:порт -m recent --set --name ScanPort -m comment --comment "Add Hackers to list"
iptables -A INPUT -m recent --name ScanPort --seconds 60 --hitcount 2 --update -m comment --comment "Block Hackers 60 sec" -j LOG --log-prefix "PortScan: "
iptables -A INPUT -m recent --name ScanPort --seconds 60 --hitcount 2 --update -m comment --comment "Block Hackers 60 sec" -j DROP
читал это до того как статью убрали, на прошлой неделе. тогда не успел сохранить себе. рад что статью вернули. спасибо
даже рекламы нет, и телеги. спасибо Вам, серьёзно.
Я указал разрешение подключения только с российских ip-шников и это сразу снизило количество попыток авторизации с десяток тысяч в неделю, до всего двух-трёх в неделю.
Сначала сделал fail2ban, всего одну попытку давал и разблокировка через месяц, но попыток было всё ещё много, уже не тысячи, но сотни.
Отличное решение! Географическая фильтрация действительно эффективный метод защиты, особенно если вы точно знаете, откуда будете подключаться.
Я указал разрешение подключения только с российских ip-шников и это сразу снизило количество попыток авторизации с десяток тысяч в неделю, до всего двух-трёх в неделю.
А как это сделать?
Я брал список подсетей с https://www.ipdeny.com/ipblocks/, а дальше в цикле
while IFS= read -r MASK; do sudo ufw allow from $MASK to any port 22; done < "by.zone"
Спасибо, поменял порт, и на 99% упало число новых попыток взлома в логах!
/var/log/auth.log — именно туда Linux записывает все попытки авторизации через SSH
$ ls /var/log/auth.log
ls: невозможно получить доступ к '/var/log/auth.log': Нет такого файла или каталогаВозможно, у вас другой дистрибутив.
Например, на CentOS / Fedora логи находятся в /var/log/secure .
Разные семейства Linux используют разные настройки логирования: Debian-подобные системы пишут в auth.log, а Red Hat в secure.
Также посмотреть логи SSH можно через команду:
sudo journalctl -u ssh
# или на CentOS/Fedora
sudo journalctl -u sshdЕсли же нужны неудачные попытки входа, можно отфильтровать вывод, например:
sudo journalctl -u sshd | grep "Failed password"
Из под sudo попробуйте, этот файл обычно недоступен для пользователя
Защита уровня "Новичок"
Не надо. Эффектвность Новичка оказалась посредственной.
А если серьезно, то зря редиски нехорошие люди изжили TARPIT из iptables без какой-либо альтернативы. Означенный модуль делал сканирование/подбор для жуликов существенно дороже. Зато теперь понятно, на чьей стороне создатели дистрибутивов. :)
Точно
Не надо. Эффектвность Новичка оказалась посредственной.
Хорошая шутка)
Да, TARPIT делал брутфорс менее удобным и ресурсоёмким, но при большом количестве "висящих" соединений есть риск исчерпать ресурсы сервера.
Констатирую: вы не имеете представления о работе Tarpit или вы на тёмной стороне - tarpit занимает ресурсы только на сервере атакующего.
Вы не совсем правы) Не зря я написал "при большом количестве "висящих" соединений".
Поясню:
В Linux каждое TCP-соединение - это сокет, который занимает дескриптор файла. По умолчанию у процесса, например, у демонов вроде sshd или httpd, есть лимит на число открытых дескрипторов, обычно от 1024 до 4096. TARPIT же не рвёт соединение, а держит его открытым. Если атакующий, например, ботнет, инициирует тысячи соединений в секунду, что в текущих реалиях легко достижимо, то сервер быстро исчерпает все доступные дескрипторы и перестаёт принимать новые соединения, включая легитимные. Это приведёт к DoS на самом сервере, где TARPIT, предназначенный для защиты, сам станет уязвимостью. Также каждое "залипшее" соединение ест память под TCP-буферы.
На тёмной стороне?
Нет такой давно авторизации, Логин и пароль.
Вы получите строку из 32 случайных символов, включая буквы, цифры и спецсимволы. Пароль такого уровня сложности не поддаётся подбору, даже если попыток будет сотни тысяч.
Пароль такого уровня не поддаётся ни запоминанию, ни вводу с первого раза. Последовав вашему совету, пользователь проклянёт вас на третий раз.
Забудьте уже о паролях, 20 лет как актуальны парольные фразы - фраза из 5 слов запоминается легко, подбор потребует сотни лет. Для уверенности можно вместо пробелов вставить цифры и значки (разные сайты часто требуют это).
Парольные фразы из набора слов, разделённых цифрами и значками, случайным образом генерирует программа pwqgen, и есть немало сайтов, генерирующих пароли этой программой.
К слову, некоторые сайты (например, mail.ru) считают пароль "Usage-Humble*lower_sound" хуже, чем пароль "5QmF7/EL", тогда как восьмизначный пароль на совсем не топовой видеокарте подбирается за несколько часов... (Оба пароля тут только что сгенерированы и нигде не использованы.)
Требования странные, конечно, но mail.ru вряд ли всё-таки будет несколько часов отвечать на попытки подобрать пароль, даже пользователю с топовой видеокартой.
Менеджер паролей. Никаких запоминаний, никакого ручного ввода. Ввод пароля только по "скопировать - вставить". В нормальных менеджерах паролей буфер обмена насильно очищается спустя несколько секунд после копирования.
скопировать
И пароль автоматически отправляется в какой-нибудь забытый свёрнутый VNC-сеанс 🙃
И куда тот сеанс ведет?
Если у вас "забытый свёрнутый VNC-сеанс", это чья проблема?
Никаких запоминаний, никакого ручного ввода.
У меня как-то после обновления на VDS пропала сеть, запросил KVM чтобы локально подключиться, работа с квм осуществлялась при помощи java-апплета, буфер не работал. Так вот, свой длинный и сложный пароль я не смог ввести с клавы с нескольких попыток. Пришлось тыкать в экранную клаву долго и мучительно. С тех пор стараюсь учитывать такой вариант, что придется руками вводить
Предлагаю вам самостоятельно попробовать "скопировать - вставить" что бы то ни было в Remote console iLO, DRAC, XCLarity, а также в консоль QEMU (VNC или SPICE).
А ещё интереснее - сделать фотографию пароля и идти с ней в серверную вводить пароль с физической консоли. Когда у вас в пароле неразличимы O и 0 и (или) 1 и l, и у вас пароль - строка с кодом base64 или ещё каким бессмысленным набором символов.
Парольная фраза хороший вариант.
Пароль такого уровня не поддаётся ни запоминанию, ни вводу с первого раза. Последовав вашему совету, пользователь проклянёт вас на третий раз.
Если у вас множество серверов, окружений, вы не будете хранить все пароли в голове. Для это используют специальные программы (password manager'ы), например, KeePass.
1. Не используйте "admin", "user", "test", "ubuntu", "guest", "root"
Вы забыли webmaster - частота проб на этот логин близка к root
Проверил логи 4-х серверов: максимальное количество неудачных попыток для webmaster - 18.
Топ пользователей из /var/log/auth.log одного сервера:
31203 admin
14824 root
4281 user
1172 ubuntu
882 debian
771 test
612 oracle
492 guest
384 centos
369 ftpuser
363 Config
357 ubnt
345 Blank
330 default
306 Nobody
305 postgres
291 hadoop
290 supervisor
286 Ubnt
286 support
286 Centos
282 User
282 operator
282 Guest
282 Admin
272 Unknown
270 git
265 Operator
265 blank
254 Support
252 Test
249 Debian
245 Default
240 es
237 www
233 pi
232 config
231 steam
224 dev
211 mysql
210 Supervisor
209 gitlab
204 deploy
201 Root
196 ftp
195 nginx
178 app
174 uftp
174 esuser
174 dolphinscheduler
168 wang
168 elastic
159 tom
158 lighthouse
157 flask
156 sonar
153 tomcat
147 elasticsearch
135 oscar
134 developer
129 docker
126 user1
121 jenkins
120 test2
114 apache
107 gpadmin
103 demoи отключить прямой SSH-доступ к root.
Точнее, оставить только вход по ключам.
И пользователю - тоже вход только по ключам. Тогда и на подбор паролей будет наплевать. (Минус - если потерять все ключи для рута, на сервер будет невозможно попасть, но тут уже никто не мешает хранить любое число резервных копий ключей. Можно даже напечатать и в сейф положить.)
Зачем вообще логиниться под рутом? Хоть с паролем, хоть по ключу. Всегда захожу обычным пользователем, потом повышаю привиллегии.
Если на машине просто нет не root пользователя, например.
Для той же VPS с xray-core даже не вижу смысла в этом, просто по ключу захожу и норм.
В бытность моей сертификации по RHEL, работа под рутом считалась обыденностью... даром, что более 15 лет прошло - до сих пор от этой пагубной привычки не избавился - первая команда после логина до сих пор "sudo bash", а на "никому не нужных серверах" я сразу под рутом захожу (да, не по паролю, а по ключу, но соли это не отменяет - если бы заходил под непривилегированным пользователем, для успешного взлома нужен был бы и ключ и пароль).
Немного не понятен следующий момент. ЗАЧЕМ оставлять вход по паролю через SSH?
PasswordAuthentication no
ssh-keygen -t ed25519
по-моему решает вообще все проблемы, нет? Нет необходимости изобретать логины, смены портов, файлбан и прочее?
Как только отключается парольный вход, количво атак равняется 0.
тогда статью не растянешь бесполезную.
если еще учесть что fail2ban петонячий и кушает прилично ресурсов. как и iptables/etc при гиганских списках тоже грузит ос.
Немного не понятен следующий момент. ЗАЧЕМ оставлять вход по паролю через SSH?
В статье я как раз рекомендую использовать SSH-ключи вместо паролей - это описано в пункте 2 (SSH-ключи вместо паролей)
Скрытый текст
Уровень "Стандарт" (рекомендуется):
Аутентификация только по SSH-ключам
2. SSH-ключи вместо паролей
Это отключит вход по паролю и включит аутентификацию только по ключам.
по-моему решает вообще все проблемы, нет? Нет необходимости изобретать логины, смены портов, файлбан и прочее?
Как только отключается парольный вход, количво атак равняется 0.
Это не так. Даже при отключённой аутентификации по паролю боты и сканеры всё равно будут продолжать "стучаться" в порт SSH. Каждое такое подключение требует обработки TCP-handshake, key exchange, что расходует CPU и память.
Как пример эффективности, смена порта снизила число атак с 58 000 до 2 700.
Стоит также помнить о уязвимостях в сервисах. Например, уязвимость в том же OpenSSH CVE-2024-6387 (июль 2024), которая позволяла без какой-либо аутентификации (ключей, паролей) исполнять произвольный код с привилегиями root на атакуемом сервере.
Необходим комплексный подход к защите. Поэтому в конце статьи я пишу: "Принцип многоуровневой защиты - не полагайтесь на один метод"
ЗАЧЕМ оставлять вход по паролю через SSH?
Сейчас расскажу зачем так, кроме того что в некоторых компаниях (тупо использовать логин и пароль) так принято))
Допустим у вас есть хост, выступающий в роли бастиона к некоторому защищаемому ресурсу. Оговорю сразу, что в плане безпасности сервер бастиона наворочен, начиная с настроенного аудита системных вызовов, политик SELinux, дополнительных настроек в systemctl и избыточного логирования всего происходящего на сервере. С самого сервера Бастион можно выполнять строго определённые действия (например, подключение к базе данных поверх SSH).
Ничего сложного нет нагенерить ключи и потом открытый ключ класть на сервере бастиона, а приватный отправлять пользователю. Как раз на последнем моменте начинается интересное знакомство с компьютерной грамотностью коллег и человеческим фактором))
Некоторые коллеги прекрасно знают, куда в их ОС нужно положить приватный ключ, как его беречь и для чего он вообще нужен. У других "лапки" и свои особенности расположений ключей в зависимости от ОС (Linux, Windows, MacOS ), и тут может случиться веселье с длительными объяснениями что, куда и зачем. Так же остаётся открытый вопрос защиты доступа к этим ключам. Другими словами, во весь рост всплывает проблема под названием человеческий фактор. Поэтому приходится идти на такие упрощения в доступе, чтобы предоставить доступ и не околеть при этом:
- почтой отправляется методичка по тому, как запустить на рабочей машине SSH в зависимости от ОС, инструкция по настройке подключения в зависимости от приложения (например, для pgAdmin и DBeaver) и логин пользователя;
- в корпоративном мессенжере отправляется пароль.
Согласен, ключи - это хорошо и удобно (особенно на элиптических кривых хороши), пока не встаёт во весь рост куча проблем с их распространением в массовых количествах и обновлением.
Кроме этого при настроенном взаимодействии сервера Бастион с внутрикорпоративной системой поставки авторизации (IdP) упрощается процесс администрирования доступами. Ну и далеко не все IdP поддерживают хранение ключей на своей стороне.
Посмотрел логи на своем. 8763 попытки подбора за 3 дня
Боты не дремлят! Уже применили что-нибудь из статьи?
Ключи ssh уже использую, ufw- всегда, fail2ban поленился. А вот аудитом прошелся, посмотрел, на что ругается и смирился :)
Отлично) SSH-ключи и ufw уже обеспечивают хорошую защиту.
Можно ещё сменить порт SSH на нестандартный. На практике это значительно сокращает количество автоматических атак.
А какая разница сколько ботов попробовали стандартный пароль? Зачем их вообще считать?
Количество попыток входа помогает понять, насколько сервер подвержен атакам. Если их становится слишком много, это создаёт нагрузку, забивает логи и может привести к снижению производительности. Т.е. это сигнал о том, что стоит принять дополнительные меры защиты.
А вы можете подтвердить это как-то? Повторяемыми тестами или чем-то таким?
Вот мой тезис: Количетсво попыток логина (попытками взлома я это назвать не могу) зависит только от количества ботов сканирующих интернет. Типичное количество таких попыток никак не аффектит производительность даже минимального впс на 1 ядро. Даже если их станет в 10 раз больше они все равно не будут видны на любых графиках нагрузки.
Ну и следствие: Делать ничего не надо. Это наведение хаоса на пустом месте. Держим минимально достаточную систему.
Провайдер не рекомендует менять порт, чтобы иметь возможность использовать его консоль. Поэтому SSH порт не менял.
На другом сервере пошел по шагам, как у Вас написано. И такой конфиг не работает, если логи пишутся не в файл auth.log, а в журнал. Я убрал logpath, и поставил "backend = systemd" и "journalmatch = _SYSTEMD_UNIT=ssh.service". Тогда заработал Fail2ban.
У меня выделенный IP, поставил правило ufw, что все что не с моего IP - в блок. Теперь до ssh в таком конфиге никому вообще не добраться, и fail2ban тоже не имеет смысла получается.
Просто использовать только ключи. И больше ничего не надо. Пусть подбирают сколько угодно.
И не надо всю эту муть городить.
SSH-ключи надёжны и их нужно использовать, но полностью полагаться только на них - плохая идея. Возможно, вы ещё не сталкивались с крупными атаками: множественные автоматические переборы могут сильно нагружать сервер.
В опыте работы в облачном хостинге я не раз видел, как такие атаки приводили к высокой загрузке CPU и даже "ложили" серверы. Именно поэтому я пишу в конце статьи: "Принцип многоуровневой защиты — не полагайтесь на один метод".
Как сделать систему более уязвимой, нагородить огород. Вместо использовать ключи.
1) Сделал не стандартный порт, фьють 99% к безопасности
2) Сделал юзера - бабушкой, еще 99,99%%
3)Сделал ВПН, но зачем с ним строго, и так все безопасно, а ВПН со слабым паролем и без ключа. Минус 99,99% от безопасности.
Если ВПН нужен со стойким паролем, а лучше ключом. Почему сразу не сделать SSH с ключом?
И не делать остального, потому что не надо. Чем сложнее, тем больше ошибок.
Да в принципе все это бесполезно по большей части. Регулярно обновлять софт, не иметь лишних открытых портов, запоминающуюся парольную фразу на 12+ символов и все, это взломать брутфорсом нереально, ключ/сложный пароль требуют хранения, это дополнительная точка отказа, оно не надо для обычных пользователей. Менять порт? У хостера по умолчанию так было, спустя пол года пришлось порты сканировать и ставить обратно 22, ибо где он хранился я уже забыл. Юзер - да, обязательно, но не для безопасности от бутфорса, а для защиты от случайных ошибок при работе.
Как сделать систему более уязвимой, нагородить огород. Вместо использовать ключи.
Это справедливо для избыточной сложности. Но базовый набор (ключи + смена порта + Fail2Ban + обновления) - это не rocket science, это 30 минут настройки один раз.
Альтернатива "только ключи и всё" работает до первого инцидента.
Отличная статья, спасибо вам! Кстати, а есть ещё подобные статьи под Windows? Я понимаю, что иногда люди делают нетипичные и нерациональные решения, но вот, допустим, надо - а винда сама по себе представляет собой дуршлаг, если совсем не озаботиться минимальной безопасностью. Найдется чтиво? Благодарю!
Минимум 20 символов — чем длиннее, тем сложнее взлом.
откуда данные про 20 символов?
Я, конечно, согласен что чем длиннее тем лучше (гусары молчать!), но откуда все же 20 символов?
Если верить Hive Systems, которые уже несколько лет проводят сравнения времени взлома пароля от его длины, то пароль из 8 символов (цифры, заглавные, незаглавные и спец символы) будет взламываться 164 года системой из 12 видео карт 5090.
https://youtu.be/fXLWxcpbfFk?si=_AfEkqPjYMjDjQyj&t=119
Я когда держал свой сервер + базу SQL произошло такое: взломали учётку SQL, снесли все таблицы, якобы их зашифровали и просили выкуп, благо SQL был почти пустой и ничего такого там не было, но меня конечно позабавило, SQL таблицы ломают тоже как не в себя
Уважаемый maxithubs. Пытаюсь запустить AIDE по Вашему мануалу. Уперся в ошибку после команды:
sudo aide --config=/etc/aide/aide.conf --check
Ошибка, что группа Full is not defined, несмотря на то, что скурпулезно придерживался Вашей инструкции. Посмотрите пожалуйста, может Вы что-то упустили в своем гайде. Заранее спасибо. Еще ругался на комментарии # в файле system_paths.conf, но тут я хотя бы удалил все #комментарии.
Выполнил шаги из инструкции, указанная ошибка не воспроизводится.
По всей видимости, группа Full не определена в основном конфиге.
Убедитесь, что в файле /etc/aide/aide.conf в самом начале присутствуют следующие строки:
# Определение наборов правил
Normal = R+p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
Full = R+a+c+m+u+g+s+sha512
# Подключение нашего конфига
@@include /etc/aide/aide.conf.d/system_paths.conf
Можете подсказать, поменял порт в конфиге сервера, перестала работать амнезия впн. Где найти конфиг амнезия впн на сервере? что бы вписать туда новый порт.
странно, AmneziaVPN паботает по своим портам UDP. Может вы фаерволом прикрыли порты?sudo docker ps поможет увидить используемые контейнерами порты. Да она поднимается на серврах в конейнерах
делаете резавную копию, появляется фалик "AmneziaVPN.backup", открываете его просто блокнотом, в самом низу видите 22й порт, меняете его, восстанавливаете резевную копию
Так можно же просто запретить все ssh подключения, кроме как с твоего айпи, так и нагрузки из-за перебора паролей не будет. Только у тебя должен быть белый айпи а то неприятная ситуация будет.
Неприятная ситуация будет в любом случае, провайдер может без предупреждения сменить ip. Такое применимо если есть резервный доступ
Не все интернет-провайдеры предоставляют статический IP-адрес, некоторые делают это только как платную дополнительную услугу. Также, если подключаться к серверу с разных устройств или сетей, такой способ будет неудобен.
Для этого отлично подойдёт WireGuard
Не в России.
Не упомянули атаки на название пользователей по различному ПО например ко мне логинились redis rabbitmq и прочее..
А вообще, когда в первый раз я посмотрел логи на VDS то удивился как много атак.. думал что до меня сервер принадлежал кому то не хорошему, менял ИП адреса у сервера - не помогало. То есть либо пулы адресов занесены в списки атак либо их подбирают "вручную" перебором.
redis rabbitmq
Зачем вы вообще открываете доступ к ним из интернета?
речь про свежеустановленный сервер... стучатся по всем возможным возможностям
На свежеустановленном сервере никаких redis и rabbitmq тем более не существует
С чего это? Он может быть сгенерирован из своего готового образа, облачные провайдеры свободно допускают такое и рекламируют как сервис.
Ну если вы в своём готовом образе сами сознательно добавили дыру, то вы просто очень глупенький, наверное?
Мне вот интересно, а каким образом они находят новоиспеченный сервер ?
adduser --disabled-password --gecos "" "$USERNAME"usermod -aG sudo "$USERNAME"
Если пользователю не задан пароль, то sudo он использовать не сможет, увы.
Прочитал про aide и вспомнилась утилитка от DrWeb под MS-DOS, которая делала ровно то же самое (а вроде и называлась вроде как Aida, но это не точно). Запускалась каждый раз при старте системы и сканировала файловую систему на изменения. Очень эффективная защита. Чуть что в системе поменялось на жестком диске в 40Мб, сразу как на ладони. На 286 компе еще использовал ее. Эх были времена
ADInf (Advancet Disk Infoscope) она называлась, если мы про одно и то же... ну и она была не совсем "от DrWeb" - скорее "от ДиалогНаука"...
По Вашей наводке прогуглил тему и был удивлён тем, что данный ревизор всё ещё жив. Из близких по духу утилит пользуюсь, разве что, AVZ, да и то, "очень не каждый год".
# Редактируем конфигурацию SSHsudo nano /etc/ssh/sshd_config
На ubuntu 24.10 Это не работает. Незнаю зачем это сделали но порт можно теперь
поменять только через сокет. sudo nano /etc/ssh/sshd_config.d/10-custom-ssh.conf
sudo systemctl edit ssh.socket и т д.
файлтубан всем хорош. Вот бы еще мог банить по именам сайтов. :)
Нормальный тарпит который я использую на 22 порту: endlessh. Он не жрет
ресурсы ОС так как не устанавливает соединения. Он использует особеность
ssh долго держать бота за ноздрю. Хотя счас боты этому обученны. Сами
отцепляются через 10-40 секунд. Но, на хитрую есть с винтом. Как я заметил
боты нападают сразу на порт 20-30 конектов. Чтобы продержать дольше
висяком помогает такая конструкция: iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 1 -j DROP
Статья интересная, к ней еще было бы неплохо собрать инфу о используемых ботнетом вордлистах.
Еще я как-то привык думать, что сообщество инфобеза давно отказалось от смены портов для повышения защиты, но аргументы автора я понял, на маленьких серверах для личного пользования может так и проще.
Классная статья, узнала много нового. Для меня как для студента еще отличная мини лаба на виртуальных машинах.
Как защитить свой VDS сервер: 53 000 попыток взлома за 5 дней