Для сабжа в CloudFlare есть Authenticated Origin Pulls. Что позволяет отклонять все запросы без клиентского сертификата, подписанного Cloudflare CA. Это решение желательно попробовать в первую очередь, потому что оно проще. По желанию, можно ограничить доступ на уровне сети, как сделал автор — это безопаснее, имхо, но сложнее сделать правильно.
Их сертификат на свой страх и риск можно вручную добавить в доверенные.
Также как на свой страх и риск можно запускать всё под root и игнорировать уведомления о слабых паролях, да и вообще делать много чего; только в последствии можно заработать утечку данных или Премию Дарвина.
И где там про, что для дьявола и ангела есть коллизии, а для JSON нет? И насколько авторитетный это источник, чтобы подкреплять им свою (и клиентов) безопасность? Отдайте безопасность людям, которые в этом разбираются, как минимум в стандартах и хороших практиках. А то потом на API смотреть больно.
В статье много неточностей, но написана красиво. Пример неточности: использование и разъяснение `CN`, который устарел и был заменён `SAN`. Видно, что автор статьи не администрирует CA, а только читал теорию.
к вероятности отсутствия доступа к машине с ssh надо приплюсовать еще вероятность отсутствия доступа к машине с vpn
согласен.
В принципе, в случае с SSH firewall не так важен, как в случае, к примеру, с веб админ-панелями и т.д. Т.к. площадь атаки на OpenSSH очень мала и сам сервис считается надёжным.
Так что да, согласен, для SSH не так обязательно ограничение доступа по сети, достаточно включить аутентификацию по ключу и сделать что-то с логами, если они беспокоют.
Другой вопрос, к примеру, это когда даже при наличии украденных/неавторизированных credentials человек не сможет подключиться. У меня такой случай был на практике при тестировании на проникновение. Firewall помог выиграть время.
Факт: SSH auth спам не остановится после изменения порта.
При ограничении доступа к SSH сервису по сети такой спам, если будет вообще, то будет приходить только от доверенных хостов, а там уже можно разбираться, кто это делает.
Используя VPN, у Вас (чаще всего) будет 1 IP адрес — адрес VPN концентратора для выхода в сеть интернет. Вот этот IP и добавляете в белый список. Таким образом, если Вы или ваши сотрудники подключаетесь из Китая, Панамы, или местного McDonald's'a — IP адрес будет доверенный.
То же самое, если, к примеру, нужен доступ к админ-панели wordpress, можно разрешить его только для IP адреса proxy или VPN. В случае, когда есть офис, можно добавить в белый список и статический IP офиса, другие доверенные сети и адреса.
Также используются bastion (gateway) хосты.
Понятно, что можно воспользоваться прокси или VPN, но это, по сути, и означает что мы сменили порт для подключения.
Нет, потому что у прокси и у VPN свои отдельные методы аутентификации.
Можно на уровне сети ограничить доступ к порту SSH только для доверенных сетей/хостов, и продублировать это на уровне хоста.
К примеру у меня на digitalocean настроено так, и никакого спама нет.
Смена порта помогает при массовых атаках, когда доступ по порту SSH открыт для всех. Чтобы избавиться от SSH auth спама достаточно использовать firewall. В различных ресусах для подготовки к CompTIA Security+ / ISC2 SSCP явно пишут, что смена порта не считается мерой безопасности.
Я тоже думал насчёт ограничения доступа к компиляторам. Утилита lynis, к примеру, предлагает это делать.
Дело в том, что если сервер x64, x86 или другой популярной архитектуры — атакующему не составит особого труда скомпилировать заранее 2 версии вредоносного ПО. Также, кроме ELF, можно, как правило, без ограничения выполнять shell, python, ruby, java, PHP и другие скрипты. Поэтому для себя решил, что ограничение доступа к компиляторам, если вообще этим заниматься, — один из последних пунктов в безопасности сервера.
Детали бросаются в глаза. Не много ли деталей для «одного государственного предприятия, сотрудники которого охраняют более 2 000 различных объектов, включая стратегически важные.»?
Для сабжа в CloudFlare есть Authenticated Origin Pulls. Что позволяет отклонять все запросы без клиентского сертификата, подписанного Cloudflare CA. Это решение желательно попробовать в первую очередь, потому что оно проще. По желанию, можно ограничить доступ на уровне сети, как сделал автор — это безопаснее, имхо, но сложнее сделать правильно.
Я думаю имеется ввиду libsodium — форк NaCl. Последний релиз Dec 13, 2017
Также как на свой страх и риск можно запускать всё под root и игнорировать уведомления о слабых паролях, да и вообще делать много чего; только в последствии можно заработать утечку данных или Премию Дарвина.
Да, я согласен с заголовком.
И где там про, что для дьявола и ангела есть коллизии, а для JSON нет? И насколько авторитетный это источник, чтобы подкреплять им свою (и клиентов) безопасность? Отдайте безопасность людям, которые в этом разбираются, как минимум в стандартах и хороших практиках. А то потом на API смотреть больно.
jwt
Кто сказал?
согласен.
В принципе, в случае с SSH firewall не так важен, как в случае, к примеру, с веб админ-панелями и т.д. Т.к. площадь атаки на OpenSSH очень мала и сам сервис считается надёжным.
Так что да, согласен, для SSH не так обязательно ограничение доступа по сети, достаточно включить аутентификацию по ключу и сделать что-то с логами, если они беспокоют.
Другой вопрос, к примеру, это когда даже при наличии украденных/неавторизированных credentials человек не сможет подключиться. У меня такой случай был на практике при тестировании на проникновение. Firewall помог выиграть время.
При ограничении доступа к SSH сервису по сети такой спам, если будет вообще, то будет приходить только от доверенных хостов, а там уже можно разбираться, кто это делает.
И всякие 0day идут мимо.
Воспользоватья прокси или VPN.
Используя VPN, у Вас (чаще всего) будет 1 IP адрес — адрес VPN концентратора для выхода в сеть интернет. Вот этот IP и добавляете в белый список. Таким образом, если Вы или ваши сотрудники подключаетесь из Китая, Панамы, или местного McDonald's'a — IP адрес будет доверенный.
То же самое, если, к примеру, нужен доступ к админ-панели wordpress, можно разрешить его только для IP адреса proxy или VPN. В случае, когда есть офис, можно добавить в белый список и статический IP офиса, другие доверенные сети и адреса.
Также используются bastion (gateway) хосты.
Нет, потому что у прокси и у VPN свои отдельные методы аутентификации.
К примеру у меня на digitalocean настроено так, и никакого спама нет.
Смена порта помогает при массовых атаках, когда доступ по порту SSH открыт для всех. Чтобы избавиться от SSH auth спама достаточно использовать firewall. В различных ресусах для подготовки к CompTIA Security+ / ISC2 SSCP явно пишут, что смена порта не считается мерой безопасности.
Дело в том, что если сервер x64, x86 или другой популярной архитектуры — атакующему не составит особого труда скомпилировать заранее 2 версии вредоносного ПО. Также, кроме ELF, можно, как правило, без ограничения выполнять shell, python, ruby, java, PHP и другие скрипты. Поэтому для себя решил, что ограничение доступа к компиляторам, если вообще этим заниматься, — один из последних пунктов в безопасности сервера.