Мы живём в опасное время: едва ли не каждый день обнаруживаются новые уязвимости, на их основе создают эксплойты, под ударом может оказаться и обычный домашний компьютер на Linux, и сервер, от которого зависит огромная организация. Возможно, вы уделяете внимание безопасности и периодически обновляете систему, но обычно этого недостаточно. Поэтому сегодня мы поделимся двенадцатью советами по повышению безопасности Linux-систем на примере CentOS 7.
Защита терминала
Для того, чтобы повысить безопасность системы, можно защитить консольный доступ к ней, ограничив root-пользователя в использовании определённых терминалов. Сделать это можно, задав терминалы, которые может использовать суперпользователь, в файле
/etc/securetty.Рекомендуется, хотя это и не обязательно, позволить суперпользователю входить в систему только из одного терминала, оставив остальные для других пользователей.
Напоминания о смене пароля
В наши дни сложный пароль — вещь совершенно необходимая. Однако, ещё лучше, когда пароли регулярно меняют. Об этом легко забыть, поэтому хорошо бы задействовать какой-нибудь системный механизм напоминаний о возрасте пароля, и о том, когда его надо поменять.
Мы предлагаем вам два способа организации подобных напоминаний. Первый заключается в использовании команды
chage, второй — в установке необходимых значений по умолчанию в /etc/login.defs.Вызов команды
chage выглядит так:$ chage -M 20 likegeeksТут мы используем ключ
-M для того, чтобы установить срок истечения актуальности пароля в днях.Использовать эту команду можно и без ключей, тогда она сама предложит ввести необходимое значение:
$ chage likegeeksВторой способ заключается в модификации файла
/etc/login.defs. Вот пример того, как могут выглядеть интересующие нас значения. Вы можете изменить их на те, которые нужны вам:PASS_MAX_DAYS 10
PASS_MIN_DAYS 0
PASS_WARN_AGE 3Помните о том, что вам, если вы играете роль администратора, следует способствовать тому, чтобы пользователи применяли сложные пароли. Сделать это можно с помощью pam_cracklib.
После установки этой программы, вы можете перейти в
/etc/pam.d/system-auth и ввести примерно следующее: password required pam_cracklib.so minlen=12 lcredit=-1 ucredit=-1 dcredit=-2 ocredit=-1Уведомления sudo
Команда
sudo, с одной стороны, упрощает жизнь, а с другой, может стать причиной проблем с безопасностью Linux, которые могут привести к непоправимым последствиям. Настройки sudo хранятся в файле /etc/sudoers. С помощью этого файла можно запретить обычным пользователям выполнять некоторые команды от имени суперпользователя. Кроме того, можно сделать так, чтобы команда sudo отправляла электронное письмо при её использовании, добавив в вышеупомянутый файл следующее:mailto yourname@yourdomain.comТакже надо установить свойство
mail_always в значение on:mail_always onЗащита SSH
Если мы говорим о безопасности Linux, то нам стоит вспомнить и о службе SSH. SSH — это важная системная служба, она позволяет удалённо подключаться к системе, и иногда это — единственный способ спасти ситуацию, когда что-то идёт не так, поэтому об отключении SSH мы тут не говорим.
Тут мы используем CentOS 7, поэтому конфигурационный файл SSH можно найти по адресу
etc/ssh/sshd_config. Сканеры или боты, которых используют атакующие, пытаются подключиться к SSH по используемому по умолчанию порту 22.Распространена практика изменения стандартного порта SSH на другой, неиспользуемый порт, например, на
5555. Порт SSH можно изменить, задав нужный номер порта в конфигурационном файле. Например, так:Port 5555Кроме того, можно ограничить вход по SSH для root-пользователя, изменив значение параметра
PermitRootLogin на no:PermitRootLogin noИ, конечно, стоит отключить аутентификацию с применением пароля и использовать вместо этого публичные и приватные ключи:
PasswordAuthentication no
PermitEmptyPasswords noТеперь поговорим о тайм-аутах SSH. Проблему тайм-аутов можно решить, настроив некоторые параметры. Например, следующие установки подразумевают, что пакеты, поддерживающие соединение, будут автоматически отправляться через заданное число секунд:
ServerAliveInterval 15
ServerAliveCountMax 3
TCPKeepAlive yesНастроив эти параметры, вы можете увеличить время соединения:
ClientAliveInterval 30
ClientAliveCountMax 5Можно указать то, каким пользователям разрешено использовать SSH:
AllowUsers user1 user2Разрешения можно назначать и на уровне групп:
AllowGroup group1 group2Защита SSH с использованием Google Authenticator
Для ещё более надёжной защиты SSH можно использовать двухфакторную аутентификацию, например, задействовав Google Authenticator. Для этого сначала надо установить соответствующую программу:
$ yum install google-authenticatorЗатем запустить её для проверки установки:
$ google-authenticatorТак же нужно, чтобы приложение Google Authenticator было установлено на вашем телефоне.
Отредактируйте файл
/etc/pam.d/sshd, добавив в него следующее:auth required pam_google_authenticator.soТеперь осталось лишь сообщить обо всём этом SSH, добавив следующую строку в файл
/etc/ssh/sshd_config:ChallengeResponseAuthentication yesТеперь перезапустите SSH:
$ systemctl restart sshdКогда вы попытаетесь войти в систему с использованием SSH, вам предложат ввести код верификации. Как результат, теперь SSH-доступ к вашей системе защищён гораздо лучше, чем прежде.
Мониторинг файловой системы с помощью Tripwire
Tripwire — это замечательный инструмент для повышения безопасности Linux. Это — система обнаружения вторжений (HIDS).
Задача Tripwire заключается в том, чтобы отслеживать действия с файловой системой, следить за тем, кто меняет файлы, и когда происходят эти изменения.
Для того, чтобы установить Tripwire, нужен доступ к репозиторию EPEL. Это задача несложная, решить её можно следующими командами:
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После установки репозитория EPEL, вы сможете установить и Tripwire:
$ sudo yum install tripwireТеперь создайте файл ключей:
$ tripwire-setup-keyfilesВам предложат ввести сложный пароль для файла ключей. После этого можно настроить Tripwire, внеся изменения в файл
/etc/tripwire/twpol.txt. Работать с этим файлом несложно, так как каждая строка оснащена содержательным комментарием.Когда настройка программы завершена, следует её инициализировать:
$ tripwire --initИнициализация, в ходе которой выполняется сканирование системы, займёт некоторое время, зависящее от размеров ваших файлов.
Любые модификации защищённых файлов расцениваются как вторжение, администратор будет об этом оповещён и ему нужно будет восстановить систему, пользуясь файлами, в происхождении которых он не сомневается.
По этой причине необходимые изменения системы должны быть подтверждены с помощью Tripwire. Для того, чтобы это сделать, используйте следующую команду:
$ tripwire --checkИ вот ещё одна рекомендация, касающаяся Tripwire. Защитите файлы
twpol.txt и twcfg.txt. Это повысит безопасность системы.У Tripwire есть множество параметров и установок. Посмотреть справку по ней можно так:
man tripwireИспользование Firewalld
Firewalld — это замена для
iptables, данная программа улучшает сетевую безопасность Linux. Firewalld позволяет вносить изменения в настройки, не останавливая текущие соединения. Файрвол работает как сервис, который позволяет добавлять и менять правила без перезапуска и использует сетевые зоны.Для того, чтобы выяснить, работает ли в настоящий момент
firewalld, введите следующую команду:$ firewall-cmd --state
Просмотреть предопределённые сетевые зоны можно так:
$ firewall-cmd --get-zones
Каждая из этих зон имеет определённый уровень доверия.
Это значение можно обновить следующим образом:
$ firewall-cmd --set-default-zone=<new-name>Получить подробные сведения о конкретной зоне можно так:
$ firewall-cmd --zone=<zone-name> --list-allПросмотреть список всех поддерживаемых служб можно следующей командой:
$ firewall-cmd --get-services
Затем можно добавлять в зону новые службы или убирать существующие:
$ firewall-cmd --zone=<zone-name> --add-service=<service-name>
$ firewall-cmd --zone=<zone-name> --remove-service=<service-name>Можно вывести сведения обо всех открытых портах в любой зоне:
$ firewall-cmd --zone=<zone-name> --list-portsДобавлять порты в зону и удалять их из неё можно так:
$ firewall-cmd --zone=<zone-name> --add-port=<port-number/protocol>
$ firewall-cmd --zone=<zone-name> --remove-port=<port-number/protocol>Можно настраивать и перенаправление портов:
$ firewall-cmd --zone=<zone-name> --add-forward-port=<port-number>
$ firewall-cmd --zone=<zone-name> --remove-forward-port=<port-number>Firewalld — это весьма продвинутый инструмент. Самое примечательное в нём то, что он может нормально работать, например, при внесении изменений в настройки, без перезапусков или остановок службы. Это отличает его от средства
iptables, при работе с которым службу в похожих ситуациях нужно перезапускать.Переход с firewalld на iptables
Некоторые предпочитают файрвол
iptables файрволу firewalld. Если вы пользуетесь firewalld, но хотите вернуться к iptables, сделать это довольно просто.Сначала отключите
firewalld:$ systemctl disable firewalld
$ systemctl stop firewalldЗатем установите
iptables:$ yum install iptables-services
$ touch /etc/sysconfig/iptables
$ touch /etc/sysconfig/ip6tablesТеперь можно запустить службу
iptables:$ systemctl start iptables
$ systemctl start ip6tables
$ systemctl enable iptables
$ systemctl enable ip6tablesПосле всего этого перезагрузите компьютер.
Ограничение компиляторов
Атакующий может скомпилировать эксплойт на своём компьютере и выгрузить его на интересующий его сервер. Естественно, при таком подходе наличие компиляторов на сервере роли не играет. Однако, лучше ограничить компиляторы, если вы не используете их для работы, как происходит в большинстве современных систем управления серверами.
Для начала выведите список всех бинарных файлов компиляторов из пакетов, а затем установите для них разрешения:
$ rpm -q --filesbypkg gcc | grep 'bin'
Создайте новую группу:
$ groupadd compilerGroupЗатем измените группу бинарных файлов компилятора:
$ chown root:compilerGroup /usr/bin/gccИ ещё одна важная вещь. Нужно изменить разрешения этих бинарных файлов:
$ chmod 0750 /usr/bin/gccТеперь любой пользователь, который попытается использовать
gcc, получит сообщение об ошибке.Предотвращение модификации файлов
Иммутабельные файлы не может перезаписать ни один пользователь, даже обладающий root-правами. Пользователь не может модифицировать или удалить такой файл до тех пор, пока установлен флаг иммутабельности, снять который может лишь root-пользователь.
Несложно заметить, что эта возможность защищает вас, как суперпользователя, от ошибок, которые могут нарушить работу системы. Используя данный подход, можно защитить конфигурационные файлы или любые другие файлы по вашему желанию.
Для того, чтобы сделать любой файл иммутабельным, воспользуйтесь командой
chattr:$ chattr +i /myscript
Атрибут иммутабельности можно удалить такой командой:
$ chattr -i /myscript
Так можно защищать любые файлы, но помните о том, что если вы обработали таким образом бинарные системные файлы, вы не сможете их обновить до тех пор, пока не снимите флаг иммутабельности.
Управление SELinux с помощью aureport
Нередко система принудительного контроля доступа SELinux оказывается, по умолчанию, отключённой. Это не влияет на работоспособность системы, да и работать с SELinux довольно сложно. Однако, ради повышения безопасности, SELinux можно включить, а упростить управление этим механизмом можно, используя
aureport.Утилита
aureport позволяет создавать отчёты на основе лог-файлов аудита.$ aureport --avc
Список исполняемых файлов можно вывести следующей командой:
$ aureport -x
Можно использовать
aureport для создания полного отчёта об аутентификации:$ aureport -au -i
Также можно вывести сведения о неудачных попытках аутентификации:
$ aureport -au --summary -i --failed
Или, возможно, сводку по удачным попыткам аутентификации:
$ aureport -au --summary -i --success
Утилита
aureport значительно упрощает работу с SELinux.Использование sealert
В дополнение к
aureport вы можете использовать хороший инструмент безопасности Linux, который называется sealert. Установить его можно так:$ yum install setoolsТеперь у нас есть средство, которое будет выдавать оповещения из файла
/var/log/audit/audit.log и даст нам дополнительные сведения о проблемах, выявленных SELinux.Использовать его можно так:
$ sealert -a /var/log/audit/audit.log
Самое интересное тут то, что в оповещениях можно найти советы о том, как решать соответствующие проблемы.
Итоги
Надеемся, приведённые здесь советы помогут вам сделать вашу установку Linux безопаснее. Однако, если речь идёт о защите информации, нельзя, применив те или иные меры, считать, что теперь вам ничто не угрожает. К любым программным средствам защиты всегда стоит добавлять бдительность и осторожность.
Уважаемые читатели! Знаете ли вы какие-нибудь простые, но неочевидные способы повышения безопасности Linux?
Комментарии (74)
darken99
06.12.2017 14:02Смена порта SSH давно считается бесполезной техникой и даже вредной
Loki3000
06.12.2017 14:21+3А кем считается и почему?
Мой небольшой опыт показывает что эта мера, как минимум, сильно разгружает логи.
tjomamokrenko
06.12.2017 14:29+3Можно на уровне сети ограничить доступ к порту SSH только для доверенных сетей/хостов, и продублировать это на уровне хоста.
К примеру у меня на digitalocean настроено так, и никакого спама нет.
Смена порта помогает при массовых атаках, когда доступ по порту SSH открыт для всех. Чтобы избавиться от SSH auth спама достаточно использовать firewall. В различных ресусах для подготовки к CompTIA Security+ / ISC2 SSCP явно пишут, что смена порта не считается мерой безопасности.Loki3000
06.12.2017 14:43+1Как-то вы делаете вывод на основании одного очень частного случая. Хорошо когда есть возможность ограничить доступ по подсети или вообще по ip, а когда нужен доступ из разных мест? Да еще с динамическим ip (с мобильного, например). Понятно, что можно воспользоваться прокси или VPN, но это, по сути, и означает что мы сменили порт для подключения. Был 22 — стал 1723.
DistortNeo
06.12.2017 15:32Хорошо когда есть возможность ограничить доступ по подсети или вообще по ip, а когда нужен доступ из разных мест?
В моём случае SSH, OpenVPN и Nginx повешены на 443 порт с мультиплексированием через sslh. Потому что при поездках, особенно в Китай, другой возможности достучаться до сервера просто нет.
Мусор в логах проблемой не считаю.
tjomamokrenko
06.12.2017 15:38Воспользоватья прокси или VPN.
Используя VPN, у Вас (чаще всего) будет 1 IP адрес — адрес VPN концентратора для выхода в сеть интернет. Вот этот IP и добавляете в белый список. Таким образом, если Вы или ваши сотрудники подключаетесь из Китая, Панамы, или местного McDonald's'a — IP адрес будет доверенный.
То же самое, если, к примеру, нужен доступ к админ-панели wordpress, можно разрешить его только для IP адреса proxy или VPN. В случае, когда есть офис, можно добавить в белый список и статический IP офиса, другие доверенные сети и адреса.
Также используются bastion (gateway) хосты.
Понятно, что можно воспользоваться прокси или VPN, но это, по сути, и означает что мы сменили порт для подключения.
Нет, потому что у прокси и у VPN свои отдельные методы аутентификации.
Loki3000
06.12.2017 15:54Да никто не спорит что два забора надежнее чем один. Проблема тут в том, что мы вынуждены строить второй забор там, где он не всегда нужен, а достаточно было бы перекрасить первый забор в другой цвет.
tjomamokrenko
06.12.2017 16:01Факт: SSH auth спам не остановится после изменения порта.
При ограничении доступа к SSH сервису по сети такой спам, если будет вообще, то будет приходить только от доверенных хостов, а там уже можно разбираться, кто это делает.
И всякие 0day идут мимо.Loki3000
06.12.2017 16:12+2Факт: остановится.
Как я уже говорил, я не спорю что два забора надежнее одного, но с ростом сложности растет и количество точек отказа: теперь, чтобы в нужный момент оказаться без доступа к ssh, к вероятности отсутствия доступа к машине с ssh надо приплюсовать еще вероятность отсутствия доступа к машине с vpn.tjomamokrenko
06.12.2017 16:31+1к вероятности отсутствия доступа к машине с ssh надо приплюсовать еще вероятность отсутствия доступа к машине с vpn
согласен.
В принципе, в случае с SSH firewall не так важен, как в случае, к примеру, с веб админ-панелями и т.д. Т.к. площадь атаки на OpenSSH очень мала и сам сервис считается надёжным.
Так что да, согласен, для SSH не так обязательно ограничение доступа по сети, достаточно включить аутентификацию по ключу и сделать что-то с логами, если они беспокоют.
Другой вопрос, к примеру, это когда даже при наличии украденных/неавторизированных credentials человек не сможет подключиться. У меня такой случай был на практике при тестировании на проникновение. Firewall помог выиграть время.
mickvav
06.12.2017 23:46На уровне фаерволла есть волшебный connlimit — больше N соединений с одного ip-ника в минуту — шагом марш в ipset бан.
weirded
07.12.2017 07:46Китайские боты — распределённая система и обычно брутфорсят с разных IP. Кстати, fail2ban и подобные не умеют случаем добавлять не IP, а подсеть этого IP с заданным префиксом?
legioner
07.12.2017 13:47может, если использовать ipset + поменять тип ipset на net и добавить префикс в настройках действия
Revertis
06.12.2017 14:56+31. При ограничении доступа по айпи/сетям вы не сможете срочно подключиться к серверу из поездки с телефона, например. Либо сложно определить весь пул подсетей у некоторых операторов, а при переподключении к интернету у вас вдруг может смениться сеть.
2. Смена порта на другой, выше нескольких тысяч, например 33333, уменьшает количество желающих подключиться к вашему серверу на порядки. Следил за этим с помощью denyhosts, он присылал письма.
3. Кроме того, тут совершенно забыли о таких продуктах как fail2ban и denyhosts. У последнего вообще существует система обмена забаненными, которая у вас автоматом банит тех, кто массово подбирает пароли на других серверах, в других странах.htol
06.12.2017 15:491. Для этого всегда должны быть «Jump host». Следить за ними намного проще, чем за тысячами vps/ec2, на которые не заходишь годами. Jump host в своюб очередь можно так же закрыть фаерволом, а доступ к нему получать исключительно через vpn.
2. Не помогает ни как, если атака нацелена специально на вас.
3. В некоторых случаях, которые появлялись уже неоднократно, достаточно одного раза. Но штука полезная, если нет других вариантов.
pansa
06.12.2017 20:29Вы что советуете!? Нельзя давать сервисам порты выше 32к, там начинается диапазон эфимерных портов! При удачном стечении останитесь без сервиса.
mickvav
06.12.2017 23:48Подкрутить /proc/sys/net/ipv4/ip_local_port_range и всего делов-то.
pansa
07.12.2017 00:11Во-первых, комментарий не содержал даже намёка на то, что надо еще крутить, из чего совершенно очевидно, что комментатор про проблему не знает.
Во-вторых, никто не говорил, что этот диапазон нельзя менять. Но это очевидно плохая практика и совершенно бездумный совет.
ITLav
06.12.2017 23:463. Кроме того, тут совершенно забыли о таких продуктах как fail2ban и denyhosts.
Это у которого сайт не обновлялся 5 лет, а новых релизов не выходило 10 лет?
Там что-то явно случилось с проектом:
stats.denyhosts.net/stats.html
darken99
06.12.2017 17:23+1Отвечу цитатой:
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 секунд.jok40
06.12.2017 19:16Смена порта SSH давно считается бесполезной техникой и даже вредной
Можно поподробнее насчёт «вредности»?iig
06.12.2017 19:24Лишнее неудобство, если хостов в хозяйстве значительно больше чем 1, и все зачем-то на разных портах. Немного меньше спама в логах — вот и весь профит.
sumanai
06.12.2017 19:43Не знаю, как это делается в Linux, но в винде у себя я могу использовать парольные менеджеры или сохранять информацию о входе в SSH клиенте. То есть один раз введя порт, я его больше не ввожу и даже не помню, на каком порту висит мой сервер.
iig
06.12.2017 19:58Если рабочих мест больше чем одно (стационарный комп, ноут, мобильник)? Администраторов больше чем один?
Настройки подключения клиент запомнит, да. Но все равно хранение дополнительной информации добавляет забот в первую очередь администратору. Вместо запомнить только $HOSTNAME — запоминать пару $HOSTNAME:$PORT. Можно пойти дальше, логиниться на каждый сервер с уникальным $LOGIN и уникальным $SSH_KEY. Но зачем, если есть и более удобныеменее неудобныеспособы.sumanai
06.12.2017 20:17Если рабочих мест больше чем одно (стационарный комп, ноут, мобильник)?
Синхронизация? Нет, не слышал.
Вместо запомнить только $HOSTNAME — запоминать пару $HOSTNAME:$PORT.
А пароли вы все наизусть знаете? Просто я не умею запоминать сотни паролей вида LG2XcOJP1zq8lj61qPA2, и их всё равно вводит мой менеджер паролей. А раз вводятся пароли, то ничто не мешает добавить туда порт, хост, кузькину мать, менеджер всё запомнит и сделает как нужно.iig
06.12.2017 20:29Расскажите про синхронизацию паролей между windows-linux-android-macos ;).
Все, конечно же, решаемо. Но для ssh давно придуман доступ по ключу. Да и ваши несловарные пароли подобрать невозможно. Так какой же профит в смене порта?sumanai
06.12.2017 22:18Расскажите про синхронизацию паролей между windows-linux-android-macos ;).
Я юзаю KeePass, мне между windows-android хватает, но клиенты есть и под другие ОС.
Но для ssh давно придуман доступ по ключу.
Который тоже можно хранить в менеджере.
Так какой же профит в смене порта?
Отвечу вашими же словами
Немного меньше спама в логах — вот и весь профит.
AllexIn
06.12.2017 20:36«Немного меньше спама в логах — вот и весь профит»
А этого мало?
все зачем-то на разных портах
А зачем всё на разныз портах? Наша задача убрать автоматические долбилки, профита от того, что у нас все SSHки будут висеть на уникальных портах — никакого. Порт должен быть уникальным, но в рамках нашего решения, а не в прицнипе.iig
07.12.2017 11:18Наша задача убрать автоматические долбилки
Задача надуманная, и к безопасности слабо относится. При наличии отсутствия слабых паролей "долбилка" всего лишь засветит свой IP адрес, который правильно было бы скормить в fail2ban — и другие атаки с этого хоста уже не получатся.
jok40
07.12.2017 07:57Немного меньше спама в логах — вот и весь профит.
Нет, не весь. Сейчас я расскажу Вам про ещё один. Помните WannaCry? Он распространялся через зиродей уязвимость в протоколе SMB (TCP-порт 445). Подобная уязвимость вполне может существовать и в протоколе SSH. Через N дней/месяцев/лет какой-нибудь Джон До может обнаружить её и нацарапать новый WannaCry для SSH, который будет сканировать весь диапазон IP-адресов и ломиться во все открытые порты 22. Про результат, думаю, рассказывать не надо. Простейшая смена стандартного SSH-порта на нестандартный многократно понизит вероятность попадания под удар при подобной атаке.iig
07.12.2017 11:38Простейшая смена стандартного SSH-порта на нестандартный многократно понизит вероятность попадания под удар при подобной атаке.
Возможно. Но после первой волны (по стандартному порту) обязательно будет вторая, которая будет шарашить прицельно, и не факт, что к тому времени ваш секретный порт не будет никому неинтересен. Зато у вас будет иллюзия безопасности: "никакие боты к нам не ломятся, можно раслабиться,
мы в домике". А еще могут изобрести квантовый компьютер на 100500 кубит, и все RSA ключи превратятся в тыкву…
polearnik
07.12.2017 11:49если джон доу достаточно умен чтоб нацарать 0-day exploit для ssh то думаю у него хватит мозгов дописать функцию поиска ssh порта на атакуемой машине
pansa
07.12.2017 20:58наглое сканирование портов довольно быстро пресекается автоматикой.
Не то, что я За смену потрта ssh, но вот со сканом не все так просто.
AllexIn
08.12.2017 17:471) Скан портов не нужен — зачем палится лишними действиям, если полно компов с стандартными портами?
2) скан можно задетектить и забанить еще до его окончания. Хотя злоумышленник и может продолжить сканирование с нового IP, но это всё равно будет медленней и сложнее. Что уменьшает вероятность.
Temmokan
07.12.2017 13:18It depends.
Вариант применения: слушать попытки соединения по стандартному порту и «тестировщиков» таких сразу отправлять на временный бан, тем же ipset.
Большую часть горе-хакеров или порт-сканнеров подобной методикой удаётся быстро и автоматически изолировать. Меньше сору, меньше вздору.
mrobespierre
06.12.2017 16:37вы бегите подальше из тех мест, где так считается (и не слушайте тех, кто из тех мест)
iborzenkov
06.12.2017 17:35я наоборот убежал от таких менял порта, они даже по ключам осилить не могли — по паролю ходили, зато порт поменяли, на всех серваках разный, кроме пароля еще и порт помни :)
но это было давно, лет 7 назад, больше таких не встречалmrobespierre
07.12.2017 03:13я надеюсь, вы понимаете, что прямой корреляции между «уметь сменить порт» и «не уметь запретить парольную аутентификацию» нет, более того, существует обратная? если бы вы как я и многие коллеги в этом треде анализировали логи множества разных серверов на протяжении нескольких лет, то знали бы, что смена порта снижает количество неудачных попыток входа по ssh в тысячи, иногда десятки тысяч раз. ну а если бы вы вламывались в чужие системы (сам я конечно так не делал, но вот один друг рассказывал...), то знали бы как усложняет жизнь нестандартный порт (сканы nmap-ом в духе -p1-65535 о-о-о-чень затягиваются по сравнению с обычными)
kotomyava
07.12.2017 19:44Да не существует обратной. Из моей довольно немалой практики, там где изменён порт всё настроено совершенно наивно и безграмотно, практически всегда, увы…
И если вам и придётся потратить немножко времени на автоматизированный скан портов (кстати, до 65536 и, не надо, обычно, 2022, 3022 и немного дальше можно просканить, а потом, и подробнее уже если случайно там была фантазия), то потом будет куда проще в остальном. =)
tjomamokrenko
06.12.2017 14:23Я тоже думал насчёт ограничения доступа к компиляторам. Утилита lynis, к примеру, предлагает это делать.
Дело в том, что если сервер x64, x86 или другой популярной архитектуры — атакующему не составит особого труда скомпилировать заранее 2 версии вредоносного ПО. Также, кроме ELF, можно, как правило, без ограничения выполнять shell, python, ruby, java, PHP и другие скрипты. Поэтому для себя решил, что ограничение доступа к компиляторам, если вообще этим заниматься, — один из последних пунктов в безопасности сервера.
demimurych
06.12.2017 14:26+4Некоторые предпочитают файрвол iptables файрволу firewalld
Это неверно. Что iptables что firewalld всего лишь надстройки над netfilter который и является фаерволом.skystart
07.12.2017 08:13firewalld это надстройка над iptables, который надстройка над netfilter…
Правда, firewalld еще и надстройка над ipset…
glebfm
06.12.2017 14:57cracklib же проверяет пароль на наличие его в словаре, который с собой носит. Это в лучшем случае вторичная мера. Лучше использовать passwdqc или pwquality. Я думал, что в rh пользуются именно pwquality.
iig
06.12.2017 16:02Политика безопасности должна быть первичной. А инструменты из статьи могут ее обеспечивать (или не обеспечивать). То же шаманство с запретом компилятора (при наличии в системе десятка интерпретаторов и без ограничения доступа к ним тоже) — не особо осмысленно.
LESHIY_ODESSA
06.12.2017 16:18А насколько сейчас актуален — Port Knocking?
YourChief
07.12.2017 21:26Вполне актуален, когда стоит задача скрыть сам факт наличия каких-то служб на сервере. Существуют современные реализации, открывающие порт по UDP-пакету с HMAC-подписью общего ключа, времени и команды открытия порта: linuxsecurity.expert/tools/pyknock
В таком виде эту технику можно использовать как альтернативу вписывания всех доверенных хостов в список разрешённых в файрволе — пусть они прокладывают себе путь сами.
broken-ufa
06.12.2017 16:38А почему не вспомнили про старый добрый TCP Wrappers?
/etc/hosts.allow
sshd: $some_trusted_IP: allow
sshd: 127.0.0.1: allow
sshd: ALL: deny
И не надо никуда порт SSH перевешывать
И еще, по мне идея использовать гуглоаутентификацию для SSH так себе затея, а вдруг Интернета не будет? Надо наверное держать одноразовые пароли на этот случай на бумажке все равно?iborzenkov
06.12.2017 17:21гугло-аутентификатору интернет не нужен — он по часам работает
Вы без интернета куда коннектится будите кстати? на соседний комп разве что.broken-ufa
06.12.2017 17:50Не знал, что оно так)
Вот например с консоли подключиться к физической машине или к виртуалке при возникновении каких либо проблем со связью, я имел ввиду.
savostin
06.12.2017 17:37Google Authenticator'у не нужен инет, если не ошибаюсь.
tjomamokrenko
06.12.2017 17:42Не ошибаетесь, не нужен. Нужна только точная синхронизация времени. См. TOTP
YourChief
07.12.2017 21:28Там даже не очень точная нужна, в пределах 30 секунд. Конкретно этот аутентификатор можно настроить на ещё более грубые пределы.
mrobespierre
06.12.2017 16:44+1опять 25: запрет входа root'ом не делает систему безопаснее, ну не делает и всё. эта рекомендация имеет очень простую основу: если злоумышленник знает имя пользователя (а root универсален для большинства систем), то ему нужно подобрать только пароль, а если не знает, то и то, и другое (что существенно увеличивает количество возможных комбинаций). вот только ключи (или билетики кербероса например) подобрать невозможно (в общем случае), а разрешение парольной аутентификации через ssh (или оставление разрешения по умолчанию) вопрос о безопасности в принципе снимает.
PaulAtreides
06.12.2017 23:07Если у сервера несколько администраторов, запрет входа под рутом персонализирует любые действия. Логин рута, при этом, полезно записать на бумажке, запечатать в конверт и убрать в сейф. На случай, если все эти администраторы однажды будут ехать в одном автобусе и решат, что там, куда он едет — лучше, чем на работе.
mrobespierre
07.12.2017 03:06всё верно, «догнать концы» по имени пользователя проще, чем по ip, вот только это разговор об ответственности и профпригодности (если сотрудник профессионал, то все работы будут согласованы с начальством, а обо всех косяках будет сразу доложено, и поиски будут не нужны), а не о безопасности (тема статьи)
evgenWebm
06.12.2017 21:03Абсолютно все советы по безопасности, оторванные от контекста, являются ничем иным как бесполезной тратой времени.
Как автора статьи и так же читателя.
P.S. Для общего образования тоже слабо подходит.
BOPOHA
06.12.2017 21:42Ребята, стыдно такое переводить.
Да, относительно перевода, только одно режет слух:
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.rpmwget, а почему не курл? ну то такое, НО почему не 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$— это что, от юзера? Ну да, может быть… у автора…
Ладно, а что будет после очередного обновления пакетов? Наша песня хороша, начинай с начала?
Да и вообще, зачем прод серверах компоненты для сборки?
PaulAtreides
06.12.2017 23:47Авторы таких статей после смерти попадают в персональный парольный ад, где им каждые 20 дней меняют пароль от двери туалета на какой нибудь максимально сложный. Всем остальным эта деятельность бесполезна и даже вредна. Об этом уже написано в первой ветке.
По поводу ключей, спор сродни тупоконечникам и остроконечникам: в отличие от пароля, ключ, с одной стороны, нельзя подобрать. Но с другой стороны, вы должны понимать, что ваш компьютер внезапно становится универсальным средством доступа к серверу. А многие ли из вас ставят пароль на сам ключ?.. Так, что хороший пароль ненамного хуже ключа. А лучше, когда аутентификация двухфакторная: есть ключ, но на 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}'
Показывает пути к файлам с ключами и имена@хосты внутри.pansa
07.12.2017 00:17Интересно, вот только сегодня с коллегами обсуждали =)
Ключи лучше не только, что их не подобрать, но ещё и не собрать коллекцию логинов, подменив sshd на взломанном сервере.
А пароль на ключ должен быть обязательно, это не обсуждается даже.
Кстати, 2FA через google auth при авторизации по ключу — не запрашивает код аутентификатора. Только если входить по паролю. Так что статья не корректа еще и в этом плане.
Machine79
07.12.2017 02:30Занятно! Особенно про Sudo и отправку на почту, я как то и не задумывался о таком. Хорошая мысля приходит как всегда...=)
alexstup
07.12.2017 11:49Когда серверов штук 500, некоторые пункты меняются.
Не написано про fail2ban.
mike_y_k
07.12.2017 15:47Как затравка хорошего обзора по результатам обсуждения…
Стоит критичнее подойти к тексту и набору средств.
fail2ban как минимум стоит добавить.
Ну и конечно нужны оценки по эффективности и цели для каждого средства.
amarao
07.12.2017 18:28Увольте копирайтера, читать глаза болят. Особенно про «терминалы». Называть tty терминалом — это круто.
nmk2002
Последние тенденции парольной аутентификации — в отказе от требования регулярной смены паролей и требований сложности. Менять пароли следует в случае подозрения в компрометации, а не на регулярной основе.
Очень хорошая статья на эту тему: Passwords Evolved: Authentication Guidance for the Modern Era. Кажется, где-то был перевод на Хабре, но я не смог найти.
NSA-bot
Вот: habrahabr.ru/company/everydaytools/blog/334600