Comments 45
Правило: если услуга предоставляется бесплатно, значит товар это ты! Посмотрите на размер инсталяшки примитивных приложений типа фонарика - пара байт полезного функционала и сто мегабайт показывателей рекламы, а то и чего похуже!
Не вижу никакого смысла их блокировать, особенно с учётом того что с одного адреса приходит не больше 1-3 запросов и эти адреса в основном динамические, то есть в следующий раз это приложение выйдет на связь с нового айпи.
И, справедливости ради, через эти библиотеки необязательно пускают "грязный" траффик для взлома и атак, вполне могут и что-то нейтральное делать. Так что эти библиотеки это необязательно плохо.
Общего решения этой проблемы не вижу. Раньше предлагалась идея, что-то типа удорожания подключения. То есть для входа надо не только пароль предъявить, но и провести некоторое дорогостоящее вычисление, которое вполне под силу рядовому пользователю, но спамеру будет стоить слишком много из-за объёмов. Однако такого рода библиотеки обнуляют эту идею - пользователю это не будет стоить дорого, а пользователей миллионы...
Сейчас у себя - если я вижу активность с подсетки (больше 10 попыток перебора паролей с подсетки - я отправляю целиком подсеть /24 в долгий бан).
У меня такое делается скриптом раз в сутки.
А потом звонит начальство и устраивает разнос. Что типа бизнес стоит и миллионы теряются.
А всего то в офисе при переустановке долго не могли вспомнить пароль от почты.
Не нужно блокировать подбор паролей, по крайней мере на долго.
Решение от скрейперов - anubis: https://anubis.techaro.lol/
Или, если javascript нельзя - можно сделать через https://zadzmo.org/code/nepenthes/ - оно генерирует бесконечную сеть ссылок.
Пишем его url в robots.txt, добавляем невидимую ссылку себе на сайт. если видим url в логах - отправляем IP в бан после нескольких попыток.
Сейчас я считаю, что любая форма веб-скрейпинга должна рассматриваться как абьюзивное поведение, и серверы должны их все блокировать.
На GoDaddy если уберёшь из адресной строки путь к национальной версии сайта, которую он предлагает по IP, чтобы попасть на английскую, сразу блокирует.
А Гуглы и Яндексы надо блокировать при этом или нет?
Сейчас я считаю, что любая форма веб-скрейпинга должна рассматриваться как абьюзивное поведение
А я считаю, что абьюзивное поведение — это непредоставление машинночитаемого API к Вашим данным. Предоставили бы — сэкономили бы процессорное время, которое тратится на свистоперделки. Я бы предпочёл сгрузить CSV, чем парсить накорябанную левой ногой через правое ухо вебстраничку.
Резидентные прокси не особо и серый рынок. В основном их используют для парсинга результатов поиска Гугла, парсинга Амазона. Некоторые просто на собственные сайты заходят, чтобы проверить, как они с мобильника в какой-нибудь Колумбии работают.
Установленная на моём сервере задача cron проверяет журналы на предмет атак, используя скрипт оболочки, и каждое утро присылает мне письмо с командами скопировать/вставить для добавления этих гадких живностей в список фаервола.
Есть вариант "обучить" фаирвол самостоятельно обрабатывать подобные адреса, если достаточно защиты SSH. Ну и не забываем об "PasswordAuthentication no" и аутентификации по ключам.
nftables.conf
table inet filter {
set ssh_accept {
typeof ip saddr
timeout 8h
flags timeout, dynamic
policy memory
}
set ssh_stage1 {
typeof ip saddr
timeout 15m
flags timeout, dynamic
policy memory
}
set ssh_stage2 {
typeof ip saddr
timeout 35m
flags timeout, dynamic
policy memory
}
set black_hole {
typeof ip saddr
timeout 14d
flags timeout, dynamic
policy memory
}
chain input {
type filter hook input priority filter; policy drop;
ct state vmap { established: accept, related: accept, new: continue, invalid: drop }
iif lo accept
ip saddr @ssh_accept tcp dport 22 accept comment "SSH Login Success"
ip saddr @black_hole drop comment "Drop bruteforce"
ip saddr @ssh_stage2 tcp dport 22 add @black_hole { ip saddr } accept
ip saddr @ssh_stage1 tcp dport 22 add @ssh_stage2 { ip saddr } accept
tcp dport 22 add @ssh_stage1 { ip saddr } accept
icmp type echo-request limit rate 5/second accept
}
}
Не забываем себе подстелить соломку:
/etc/profile.d/ssh_accept.sh
nft add element "inet filter ssh_accept { ${SSH_CLIENT%% *} }" 2>/dev/null || true
nft delete element "inet filter ssh_stage1 { ${SSH_CLIENT%% *} }" 2>/dev/null || true
Скриптами можно подключить сервисы для обмена адресами:
https://www.blocklist.de/
https://www.projecthoneypot.org/
Чуть-чуть моей статистики по этому направлению
[root@msk0-mlbc:~]# uptime
04:23:39 up 5 days 4:31, 1 user, load average: 0.00, 0.00, 0.00
[root@msk0-mlbc:~]# nft list set inet filter black_hole | grep 'expires' | wc -l
335
Какая занятная штука nftables
, а ведь таки доведётся с iptables
переползать…
Я правильно же понимаю предлагаемую схему: SYN с произвольного IP на 22/tcp заносит этот адрес на 15 минут в ssh_stage1; повторный SYN в этом интервале переводит в ssh_stage2 на 35 минут, и третий SYN — в black_hole на 14 дней? А успешная авторизация по SSH добавляет client IP в ssh_accept на 8 часов и убирает из ssh_stage1 на всякий случай?
Я правильно же понимаю предлагаемую схему
Да, вы все верно описали. Схема получается достаточно гибкой, но, к сожалению, ее применение удобно только для SSH.
Не так уж и мало (учитывая популярность поиска доступа к SSH среди мамкиных хакеров)! Спасибо за идею, пожалуй перелицую её на MikroTik, в дополнение к существующим насторожкам (SYN на 23/tcp, 110/tcp, 143/tcp etc — сразу в black_list на неделю).
А port knocking не лучше ли?
Он просто другой.
На мой взгляд, оба решения самодостаточны в достижении поставленной цели -- защита ssh.
Но с порт-кнокингом следует иметь ввиду ситуации, когда по различным причинам до хоста не долетают пакеты по выбранным портам. (тут передаю привет горячо презираемому ЦМУ ССОП)
Он тоже хорош, но немного в другой плоскости — разумеется, его я тоже применяю.
Такое вот безапелляционно-превентивное помещение в black list хорошо вот с какой точки зрения: если некий evil host начинает меня тыкать куда не следует на L4 модели OSI (в надежде найти потенциальную уязвимость), то зачем мне ждать, когда он на L7 той же модели начнёт то же самое (всякие глупые веб-запросы и т.п.)?
не забываем об "PasswordAuthentication no" и аутентификации по ключам.
Вы держите свой ключ в голове? Завидую!
Нет. Я не использую ssh с недоверенных хостов.
Рассматриваю и эту ситуацию предупреждаю шифрованием доверенных хостов.
«Брелок сущ. — маленькая штуковина, предоставляющая вам возможность потерять все ключи одновременно» ©
Это проблема единственного брелока.
Вопрос не в том, что брелок теряете Вы — проблема в том, что весь ваш брелок единомоментно приобретает Ваш оппонент.
Чтобы моим "брелоком" смог воспользоваться посторонний, ему следует применить паяльник/утюг/etc. либо попытаться самостоятельно дешифровать luks-образ с устройства.
В случае паяльника или утюга мне будет без разницы в каком виде будут переданы креды -- паролем или ssh-ключом.
Ну вот мы и дошли до самой мякотки: у Вас брелок защищён паролем. Теперь остаётся понять, зачем во всей этой схеме лишняя сущность — собственно брелок.
– В спальне принимать пищу, – заговорил он слегка придушенным голосом, – в смотровой читать, в приёмной одеваться, оперировать в комнате прислуги, а в столовой осматривать. Очень возможно, что Айседора Дункан так и делает. Может быть, она в кабинете обедает, а кроликов режет в ванной. Может быть. Но я не Айседора Дункан!.. Я буду обедать в столовой, а оперировать в операционной!
Теперь остаётся понять, зачем во всей этой схеме лишняя сущность — собственно брелок.
Даже парольные менеджеры защищены одним мастер-паролем, а не каждый объект со своим паролем, отличным от защищаемого объекта.
И... что?
Я совершенно не запрещаю каждому дро извращаться как он хочет.
Тогда что вы пытались выяснить? Моя потребность в удобствах никак не определяет вашу необходимость в тех же удобствах.
Я пытался указать на то, что Вы даёте «универсальную» рекомендацию, не уточняя (а, возможно, и не осознавая), что она имеет границы применимости. А меня это безапелляционное «PasswordAuthentication no
» бесит.
Ну и не забываем об "PasswordAuthentication no" и аутентификации по ключам.
"Не забываем" -- следует читать, как "не забываем", а не "строго к исполнению".
А меня это безапелляционное «PasswordAuthentication no» бесит.
А не надо беситься по пустякам, нервы не бесконечные! PubkeyAuthentication yes
давно уже в best practices — надёжней, безопасней, удобней. И вполне логично при этом поставить PasswordAuthentication no
для уменьшения поверхности атаки (исключения возможны, сам держу пару хостов для входа в ситуации «ключей нет вообще никаких, но пароли помню»). Но в моём случае это осознанное исключение, подпёртое другими костылями.
Конечно, эту часть можно и автоматизировать.
Мы это давно сделали: https://diswall.stream
Такие ботнеты довольно умны. Обладая ресурсом в десятки тысяч обычно резидентных или мобильных IP-адресов, они ежедневно используют каждый из них ровно для одной попытки авторизоваться на почтовом сервере или установить SMTP-соединение.
У меня ботнет постоянно пытается найти уязвимость Wordpress, сканируя папки wp-admin/ wp-includes/ и тп. хотя у меня drupal.
Тоже сначала банил, каждый день айпи меняют. Думал сделать скрипт для автобана, но потом забил. Не могут даже определить, что за админка - школота какая-то в хакеров играет, стоит ли напрягаться.
Не могут даже определить
Так это не вручную делается, собирается статистика. Может кто-то маскируется под другую админку, а они все равно проверяют. Если мощностей с запасом вполне оправдано.
У меня был VPS сервер для экспериментов и один открытый порт, с которого я писал логи в текстовый файл, там мегабайты мусора накопилось, проверяли в основном что это прокси, что это порт админки или SQL сервер, или просто подключались несколько раз без запросов и отключались.
50к адресов /32 в блэклисте - интересно, оно не тормозит у автора?
Сейчас я считаю, что любая форма веб-скрейпинга должна рассматриваться как абьюзивное поведение, и серверы должны их все блокировать.
А я считаю, что борцы с веб-скрейпингом - небольшое зло. Хотелось бы больше свободы информации.
Ох уж эти скрытные ботнеты