Pull to refresh
-1
Karma
0
Rating
Artiom Mocrenco @tjomamokrenko

Information Security Engineer

Разрешаем доступ к веб-серверу только через CloudFlare (iptables)

Для сабжа в CloudFlare есть Authenticated Origin Pulls. Что позволяет отклонять все запросы без клиентского сертификата, подписанного Cloudflare CA. Это решение желательно попробовать в первую очередь, потому что оно проще. По желанию, можно ограничить доступ на уровне сети, как сделал автор — это безопаснее, имхо, но сложнее сделать правильно.

Правильные ответы по криптографии: 2018 год

Плюс она ещё и не релизилась с 2011 года

Я думаю имеется ввиду libsodium — форк NaCl. Последний релиз Dec 13, 2017

Снижение доверия к Symantec PKI: рекомендации владельцам сайтов

Их сертификат на свой страх и риск можно вручную добавить в доверенные.

Также как на свой страх и риск можно запускать всё под root и игнорировать уведомления о слабых паролях, да и вообще делать много чего; только в последствии можно заработать утечку данных или Премию Дарвина.

Завтра 31 марта. Пожалуйста, сделайте бэкапы

Я завтра не работаю, завтра суббота ;)

POS, безопасность и вот это вот все. Разбираем уязвимости популярной Retail-системы

Почему для 3DES используется 1 ключ вместо 3-х?

Зачем солить HTTP-коллбэки

Да, я согласен с заголовком.


И где там про, что для дьявола и ангела есть коллизии, а для JSON нет? И насколько авторитетный это источник, чтобы подкреплять им свою (и клиентов) безопасность? Отдайте безопасность людям, которые в этом разбираются, как минимум в стандартах и хороших практиках. А то потом на API смотреть больно.

Зачем солить HTTP-коллбэки

Зачем солить HTTP-коллбэки

Можно сделать другую последовательность байт, которая будет иметь тот же MD5 хэш — но в случае JSON payload это приведет к невалидным данным.

Кто сказал?

Шпоры по сертификатам X.509

В статье много неточностей, но написана красиво. Пример неточности: использование и разъяснение `CN`, который устарел и был заменён `SAN`. Видно, что автор статьи не администрирует CA, а только читал теорию.

Двенадцать советов по повышению безопасности Linux

Не ошибаетесь, не нужен. Нужна только точная синхронизация времени. См. TOTP

Двенадцать советов по повышению безопасности Linux

к вероятности отсутствия доступа к машине с ssh надо приплюсовать еще вероятность отсутствия доступа к машине с vpn

согласен.


В принципе, в случае с SSH firewall не так важен, как в случае, к примеру, с веб админ-панелями и т.д. Т.к. площадь атаки на OpenSSH очень мала и сам сервис считается надёжным.


Так что да, согласен, для SSH не так обязательно ограничение доступа по сети, достаточно включить аутентификацию по ключу и сделать что-то с логами, если они беспокоют.


Другой вопрос, к примеру, это когда даже при наличии украденных/неавторизированных credentials человек не сможет подключиться. У меня такой случай был на практике при тестировании на проникновение. Firewall помог выиграть время.

Двенадцать советов по повышению безопасности Linux

Факт: SSH auth спам не остановится после изменения порта.

При ограничении доступа к SSH сервису по сети такой спам, если будет вообще, то будет приходить только от доверенных хостов, а там уже можно разбираться, кто это делает.

И всякие 0day идут мимо.

Двенадцать советов по повышению безопасности Linux

Воспользоватья прокси или VPN.


Используя VPN, у Вас (чаще всего) будет 1 IP адрес — адрес VPN концентратора для выхода в сеть интернет. Вот этот IP и добавляете в белый список. Таким образом, если Вы или ваши сотрудники подключаетесь из Китая, Панамы, или местного McDonald's'a — IP адрес будет доверенный.


То же самое, если, к примеру, нужен доступ к админ-панели wordpress, можно разрешить его только для IP адреса proxy или VPN. В случае, когда есть офис, можно добавить в белый список и статический IP офиса, другие доверенные сети и адреса.


Также используются bastion (gateway) хосты.


Понятно, что можно воспользоваться прокси или VPN, но это, по сути, и означает что мы сменили порт для подключения.

Нет, потому что у прокси и у VPN свои отдельные методы аутентификации.

Двенадцать советов по повышению безопасности Linux

Можно на уровне сети ограничить доступ к порту SSH только для доверенных сетей/хостов, и продублировать это на уровне хоста.

К примеру у меня на digitalocean настроено так, и никакого спама нет.

Смена порта помогает при массовых атаках, когда доступ по порту SSH открыт для всех. Чтобы избавиться от SSH auth спама достаточно использовать firewall. В различных ресусах для подготовки к CompTIA Security+ / ISC2 SSCP явно пишут, что смена порта не считается мерой безопасности.

Двенадцать советов по повышению безопасности Linux

Я тоже думал насчёт ограничения доступа к компиляторам. Утилита lynis, к примеру, предлагает это делать.

Дело в том, что если сервер x64, x86 или другой популярной архитектуры — атакующему не составит особого труда скомпилировать заранее 2 версии вредоносного ПО. Также, кроме ELF, можно, как правило, без ограничения выполнять shell, python, ruby, java, PHP и другие скрипты. Поэтому для себя решил, что ограничение доступа к компиляторам, если вообще этим заниматься, — один из последних пунктов в безопасности сервера.

Как мы делали гигантский объём связи для немаленькой охранной структуры

Детали бросаются в глаза. Не много ли деталей для «одного государственного предприятия, сотрудники которого охраняют более 2 000 различных объектов, включая стратегически важные.»?

Новые способы монетизации взломанных веб-ресурсов

Ну так если есть пароль к БД, почему не шифровать данные из БД…
1

Information

Rating
Does not participate
Registered
Activity