Comments 84
Очень хорошая статья на эту тему: Passwords Evolved: Authentication Guidance for the Modern Era. Кажется, где-то был перевод на Хабре, но я не смог найти.
Смена порта SSH давно считается бесполезной техникой и даже вредной
Мой небольшой опыт показывает что эта мера, как минимум, сильно разгружает логи.
К примеру у меня на digitalocean настроено так, и никакого спама нет.
Смена порта помогает при массовых атаках, когда доступ по порту SSH открыт для всех. Чтобы избавиться от SSH auth спама достаточно использовать firewall. В различных ресусах для подготовки к CompTIA Security+ / ISC2 SSCP явно пишут, что смена порта не считается мерой безопасности.
Хорошо когда есть возможность ограничить доступ по подсети или вообще по ip, а когда нужен доступ из разных мест?
В моём случае SSH, OpenVPN и Nginx повешены на 443 порт с мультиплексированием через sslh. Потому что при поездках, особенно в Китай, другой возможности достучаться до сервера просто нет.
Мусор в логах проблемой не считаю.
Воспользоватья прокси или VPN.
Используя VPN, у Вас (чаще всего) будет 1 IP адрес — адрес VPN концентратора для выхода в сеть интернет. Вот этот IP и добавляете в белый список. Таким образом, если Вы или ваши сотрудники подключаетесь из Китая, Панамы, или местного McDonald's'a — IP адрес будет доверенный.
То же самое, если, к примеру, нужен доступ к админ-панели wordpress, можно разрешить его только для IP адреса proxy или VPN. В случае, когда есть офис, можно добавить в белый список и статический IP офиса, другие доверенные сети и адреса.
Также используются bastion (gateway) хосты.
Понятно, что можно воспользоваться прокси или VPN, но это, по сути, и означает что мы сменили порт для подключения.
Нет, потому что у прокси и у VPN свои отдельные методы аутентификации.
При ограничении доступа к SSH сервису по сети такой спам, если будет вообще, то будет приходить только от доверенных хостов, а там уже можно разбираться, кто это делает.
И всякие 0day идут мимо.
Как я уже говорил, я не спорю что два забора надежнее одного, но с ростом сложности растет и количество точек отказа: теперь, чтобы в нужный момент оказаться без доступа к ssh, к вероятности отсутствия доступа к машине с ssh надо приплюсовать еще вероятность отсутствия доступа к машине с vpn.
к вероятности отсутствия доступа к машине с ssh надо приплюсовать еще вероятность отсутствия доступа к машине с vpn
согласен.
В принципе, в случае с SSH firewall не так важен, как в случае, к примеру, с веб админ-панелями и т.д. Т.к. площадь атаки на OpenSSH очень мала и сам сервис считается надёжным.
Так что да, согласен, для SSH не так обязательно ограничение доступа по сети, достаточно включить аутентификацию по ключу и сделать что-то с логами, если они беспокоют.
Другой вопрос, к примеру, это когда даже при наличии украденных/неавторизированных credentials человек не сможет подключиться. У меня такой случай был на практике при тестировании на проникновение. Firewall помог выиграть время.
Китайские боты — распределённая система и обычно брутфорсят с разных IP. Кстати, fail2ban и подобные не умеют случаем добавлять не IP, а подсеть этого IP с заданным префиксом?
2. Смена порта на другой, выше нескольких тысяч, например 33333, уменьшает количество желающих подключиться к вашему серверу на порядки. Следил за этим с помощью denyhosts, он присылал письма.
3. Кроме того, тут совершенно забыли о таких продуктах как fail2ban и denyhosts. У последнего вообще существует система обмена забаненными, которая у вас автоматом банит тех, кто массово подбирает пароли на других серверах, в других странах.
2. Не помогает ни как, если атака нацелена специально на вас.
3. В некоторых случаях, которые появлялись уже неоднократно, достаточно одного раза. Но штука полезная, если нет других вариантов.
3. Кроме того, тут совершенно забыли о таких продуктах как fail2ban и denyhosts.
Это у которого сайт не обновлялся 5 лет, а новых релизов не выходило 10 лет?
Там что-то явно случилось с проектом:
stats.denyhosts.net/stats.html
Отвечу цитатой:
changing the SSH port from 22 to another port is basically "security by obscurity" and only carries with it minimal advantages.
The main advantage is less botnet/automated traffic will come in on port 22 looking to run SSH attacks. However, it is fairly trivial for a real attacker, or a botnet with a more astute programmer running it; to run a port scan against all the ports. Port 20,000 (or whatever number) will clearly respond with an SSH handshake, and thus they'll try attacks on that port. End of security advantages.
Если вы никому сильно не интересны то смена порта вам уменьшит кол-во мусора в логах.
В противном случае без применения остальных рекомендаций ваш порт с SSH найдут за 5 секунд.
Смена порта SSH давно считается бесполезной техникой и даже вреднойМожно поподробнее насчёт «вредности»?
Лишнее неудобство, если хостов в хозяйстве значительно больше чем 1, и все зачем-то на разных портах. Немного меньше спама в логах — вот и весь профит.
Если рабочих мест больше чем одно (стационарный комп, ноут, мобильник)? Администраторов больше чем один?
Настройки подключения клиент запомнит, да. Но все равно хранение дополнительной информации добавляет забот в первую очередь администратору. Вместо запомнить только $HOSTNAME — запоминать пару $HOSTNAME:$PORT. Можно пойти дальше, логиниться на каждый сервер с уникальным $LOGIN и уникальным $SSH_KEY. Но зачем, если есть и более удобные менее неудобные способы.
А этого мало?
все зачем-то на разных портах
А зачем всё на разныз портах? Наша задача убрать автоматические долбилки, профита от того, что у нас все SSHки будут висеть на уникальных портах — никакого. Порт должен быть уникальным, но в рамках нашего решения, а не в прицнипе.
Немного меньше спама в логах — вот и весь профит.Нет, не весь. Сейчас я расскажу Вам про ещё один. Помните WannaCry? Он распространялся через зиродей уязвимость в протоколе SMB (TCP-порт 445). Подобная уязвимость вполне может существовать и в протоколе SSH. Через N дней/месяцев/лет какой-нибудь Джон До может обнаружить её и нацарапать новый WannaCry для SSH, который будет сканировать весь диапазон IP-адресов и ломиться во все открытые порты 22. Про результат, думаю, рассказывать не надо. Простейшая смена стандартного SSH-порта на нестандартный многократно понизит вероятность попадания под удар при подобной атаке.
Простейшая смена стандартного SSH-порта на нестандартный многократно понизит вероятность попадания под удар при подобной атаке.
Возможно. Но после первой волны (по стандартному порту) обязательно будет вторая, которая будет шарашить прицельно, и не факт, что к тому времени ваш секретный порт не будет никому неинтересен. Зато у вас будет иллюзия безопасности: "никакие боты к нам не ломятся, можно раслабиться, мы в домике". А еще могут изобрести квантовый компьютер на 100500 кубит, и все RSA ключи превратятся в тыкву…
Не то, что я За смену потрта ssh, но вот со сканом не все так просто.
2) скан можно задетектить и забанить еще до его окончания. Хотя злоумышленник и может продолжить сканирование с нового IP, но это всё равно будет медленней и сложнее. Что уменьшает вероятность.
Вариант применения: слушать попытки соединения по стандартному порту и «тестировщиков» таких сразу отправлять на временный бан, тем же ipset.
Большую часть горе-хакеров или порт-сканнеров подобной методикой удаётся быстро и автоматически изолировать. Меньше сору, меньше вздору.
я наоборот убежал от таких менял порта, они даже по ключам осилить не могли — по паролю ходили, зато порт поменяли, на всех серваках разный, кроме пароля еще и порт помни :)
но это было давно, лет 7 назад, больше таких не встречал
И если вам и придётся потратить немножко времени на автоматизированный скан портов (кстати, до 65536 и, не надо, обычно, 2022, 3022 и немного дальше можно просканить, а потом, и подробнее уже если случайно там была фантазия), то потом будет куда проще в остальном. =)
Дело в том, что если сервер x64, x86 или другой популярной архитектуры — атакующему не составит особого труда скомпилировать заранее 2 версии вредоносного ПО. Также, кроме ELF, можно, как правило, без ограничения выполнять shell, python, ruby, java, PHP и другие скрипты. Поэтому для себя решил, что ограничение доступа к компиляторам, если вообще этим заниматься, — один из последних пунктов в безопасности сервера.
firewalld — это не замена iptables. Это интерфейс к iptables.
Некоторые предпочитают файрвол iptables файрволу firewalld
Это неверно. Что iptables что firewalld всего лишь надстройки над netfilter который и является фаерволом.
cracklib же проверяет пароль на наличие его в словаре, который с собой носит. Это в лучшем случае вторичная мера. Лучше использовать passwdqc или pwquality. Я думал, что в rh пользуются именно pwquality.
Политика безопасности должна быть первичной. А инструменты из статьи могут ее обеспечивать (или не обеспечивать). То же шаманство с запретом компилятора (при наличии в системе десятка интерпретаторов и без ограничения доступа к ним тоже) — не особо осмысленно.
В таком виде эту технику можно использовать как альтернативу вписывания всех доверенных хостов в список разрешённых в файрволе — пусть они прокладывают себе путь сами.
/etc/hosts.allow
sshd: $some_trusted_IP: allow
sshd: 127.0.0.1: allow
sshd: ALL: deny
И не надо никуда порт SSH перевешывать
И еще, по мне идея использовать гуглоаутентификацию для SSH так себе затея, а вдруг Интернета не будет? Надо наверное держать одноразовые пароли на этот случай на бумажке все равно?
Ребята, стыдно такое переводить.
Да, относительно перевода, только одно режет слух:
Firewalld — это замена для iptables, данная программа улучшает сетевую безопасность Linux.
слово "программа", лучше сказать, например, "проект".
Но, сама статья, технически слабая.
Например, мои претензии к оригиналу:
Port 5555
Ну, ок поменяли, а "ssh_port_t tcp 22" остался на месте? рестартнем sshd и… о забыли про selinux?
wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-9.noarch.rpm
$ rpm -ivh epel-release-7-9.noarch.rpm
wget, а почему не курл? ну то такое, НО почему не HTTPS?
А вообще есть вот что: https://lists.centos.org/pipermail/centos-announce/2014-September/020526.html
ДА, просто yum install epel-release -y !
Для начала выведите список всех бинарных файлов компиляторов из пакетов,
а затем установите для них разрешения:
rpm -q --filesbypkg gcc | grep 'bin'
Всех Бинарныйх? Или исполняемых???
Исполняемые, можно найти так:
rpm -qlv gcc | grep ^-rwx
$ groupadd compilerGroup
$ chown root:compilerGroup /usr/bin/gcc
$ chmod 0750 /usr/bin/gcc
$ — это что, от юзера? Ну да, может быть… у автора…
Ладно, а что будет после очередного обновления пакетов? Наша песня хороша, начинай с начала?
Да и вообще, зачем прод серверах компоненты для сборки?
По поводу ключей, спор сродни тупоконечникам и остроконечникам: в отличие от пароля, ключ, с одной стороны, нельзя подобрать. Но с другой стороны, вы должны понимать, что ваш компьютер внезапно становится универсальным средством доступа к серверу. А многие ли из вас ставят пароль на сам ключ?.. Так, что хороший пароль ненамного хуже ключа. А лучше, когда аутентификация двухфакторная: есть ключ, но на sudo будь добр пароль.
А ещё про ключи довольно часто забывают. Вот недавно нашел сервер, где администратор, чтобы упростить себе жизнь, засунул свои ключи прямо в /root/.ssh (и, соответственно, разрешил доступ руту по ssh). Давно ушел тот администратор, пользователя ему отключили, а вот проверить, не остались ли где его ключи, никто не догадался. А потом инцидент с доступом рута и вот думай — то ли есть какой нибудь 0-day на повышение привилегий, то ли ключик спёрли.
Вот мой однострочник для проверки имеющихся ключей
find / -name authorized_keys | perl -nae 'chomp; print "$_ "; $a = `cat $_`; while ($a =~ /[^ ]+ ([^\s]+)\n(.*)/){print "$1\n";$a=$2}'Показывает пути к файлам с ключами и имена@хосты внутри.
Ключи лучше не только, что их не подобрать, но ещё и не собрать коллекцию логинов, подменив sshd на взломанном сервере.
А пароль на ключ должен быть обязательно, это не обсуждается даже.
Кстати, 2FA через google auth при авторизации по ключу — не запрашивает код аутентификатора. Только если входить по паролю. Так что статья не корректа еще и в этом плане.
Не написано про fail2ban.
Сделал так: SSH на нестандартном порту + fail2ban. Факты: после смены порта автоматические долбилки отвалились. После установки fail2ban логи стали заметно чище. Профит в том, что теперь анализ логов стал проще. А когда тебе по нескольку раз в день нужно получать ответ на вопрос «кто откуда и зачем заходил?» профит считаю жирным лично для себя.
Астериски в других компаниях\домашний медиа-сервер — порт перенесён, fail2ban, на роутере правила ограничивающие доступ только с определённых IP. Ну глупости это — пытаться с телефона в поездке что-то там поадминить (интернет не стабильный, экран маленький, входящий звонок невовремя). На крайний случай должен быть человек в офисе\дома который ответит на звонок и всё сделает точно как сказано. А если такого человека нет, то в целом не так всё важно, чтобы не потерпеть несколько часов пока вы доберётесь до удобного рабочего места, подключитесь к офисной сети и всё сделаете как белый человек с большим монитором, клавиатурой и чашкой кофе.
И да, пароль на ключ — обязателен т.к. ваш ключ могут просто украсть.
— Алло! У нас сайт уже неделю не работает из-за вас!
— Минуту… Вчера работал — сами проверяли и с ним работали.
И в конце выясняется, что клиент зашёл, ничего не делал (а чего заходил?..) и оно само. Но все уже успели свою порцию пинков от руководства получить. Студия маленькая, пинки долетают быстро :-(
У нас сайт уже неделю не работает из-за вас!
nagios же.
Немного капитанства ;).
Административные проблемы должны решаться административными способами.
В договоре с клиентом что-то написано про порядок выполнения регламентных работ?
Если от подборов по SSH то можно использовать параметр ограничения попыток ввода пароля или же PAM (auth required pam_tally2.so file=/var/log/tallylog deny=5 unlock_time=800 root_unlock_time=10)
По брандмауэрам если сервер в цод -е то нет смысла он является доверенной зоной если смотрит в ИНЕТ ставим железный MЭ включенный брандмауэр жрет до 5-7% ресурсов ОС. По аудиту поделитесь настройками. ПО SELinux Зачем вам мандатный доступ ролевой бы реализовать. тем более он опять же жрет ресурсы до 5%.
Двенадцать советов по повышению безопасности Linux