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

https://likegeeks.com/linux-security-tricks/
  • Перевод
imageМы живём в опасное время: едва ли не каждый день обнаруживаются новые уязвимости, на их основе создают эксплойты, под ударом может оказаться и обычный домашний компьютер на 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?
RUVDS.com 556,16
RUVDS – хостинг VDS/VPS серверов
Поделиться публикацией
Похожие публикации
Комментарии 84
  • +13
    Последние тенденции парольной аутентификации — в отказе от требования регулярной смены паролей и требований сложности. Менять пароли следует в случае подозрения в компрометации, а не на регулярной основе.
    Очень хорошая статья на эту тему: Passwords Evolved: Authentication Guidance for the Modern Era. Кажется, где-то был перевод на Хабре, но я не смог найти.
  • +2

    Смена порта SSH давно считается бесполезной техникой и даже вредной

    • +7
      А кем считается и почему?
      Мой небольшой опыт показывает что эта мера, как минимум, сильно разгружает логи.
      • +2
        Можно на уровне сети ограничить доступ к порту SSH только для доверенных сетей/хостов, и продублировать это на уровне хоста.

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

        Смена порта помогает при массовых атаках, когда доступ по порту SSH открыт для всех. Чтобы избавиться от SSH auth спама достаточно использовать firewall. В различных ресусах для подготовки к CompTIA Security+ / ISC2 SSCP явно пишут, что смена порта не считается мерой безопасности.
        • +2
          Как-то вы делаете вывод на основании одного очень частного случая. Хорошо когда есть возможность ограничить доступ по подсети или вообще по ip, а когда нужен доступ из разных мест? Да еще с динамическим ip (с мобильного, например). Понятно, что можно воспользоваться прокси или VPN, но это, по сути, и означает что мы сменили порт для подключения. Был 22 — стал 1723.
          • +1
            Хорошо когда есть возможность ограничить доступ по подсети или вообще по ip, а когда нужен доступ из разных мест?

            В моём случае SSH, OpenVPN и Nginx повешены на 443 порт с мультиплексированием через sslh. Потому что при поездках, особенно в Китай, другой возможности достучаться до сервера просто нет.


            Мусор в логах проблемой не считаю.

            • –1

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


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


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


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


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

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

              • +1
                Да никто не спорит что два забора надежнее чем один. Проблема тут в том, что мы вынуждены строить второй забор там, где он не всегда нужен, а достаточно было бы перекрасить первый забор в другой цвет.
                • –1
                  Факт: SSH auth спам не остановится после изменения порта.

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

                  И всякие 0day идут мимо.
                  • +4
                    Факт: остановится.

                    Как я уже говорил, я не спорю что два забора надежнее одного, но с ростом сложности растет и количество точек отказа: теперь, чтобы в нужный момент оказаться без доступа к ssh, к вероятности отсутствия доступа к машине с ssh надо приплюсовать еще вероятность отсутствия доступа к машине с vpn.
                    • +1
                      к вероятности отсутствия доступа к машине с ssh надо приплюсовать еще вероятность отсутствия доступа к машине с vpn

                      согласен.


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


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


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

              • 0
                На уровне фаерволла есть волшебный connlimit — больше N соединений с одного ip-ника в минуту — шагом марш в ipset бан.
                • 0

                  Китайские боты — распределённая система и обычно брутфорсят с разных IP. Кстати, fail2ban и подобные не умеют случаем добавлять не IP, а подсеть этого IP с заданным префиксом?

                  • 0
                    fail2ban, насколько понимаю, не умеет использовать ipset. Так что там при росте числа «запрещённых» скорость работы всей системы может ощутимо замедлиться.
                    • 0
                      штатно умеет
                      • +1
                        Научилась, значит. Тем проще, меньше велосипедов изобретать.
                    • 0
                      может, если использовать ipset + поменять тип ipset на net и добавить префикс в настройках действия
                • +5
                  1. При ограничении доступа по айпи/сетям вы не сможете срочно подключиться к серверу из поездки с телефона, например. Либо сложно определить весь пул подсетей у некоторых операторов, а при переподключении к интернету у вас вдруг может смениться сеть.
                  2. Смена порта на другой, выше нескольких тысяч, например 33333, уменьшает количество желающих подключиться к вашему серверу на порядки. Следил за этим с помощью denyhosts, он присылал письма.
                  3. Кроме того, тут совершенно забыли о таких продуктах как fail2ban и denyhosts. У последнего вообще существует система обмена забаненными, которая у вас автоматом банит тех, кто массово подбирает пароли на других серверах, в других странах.
                  • –1
                    1. Для этого всегда должны быть «Jump host». Следить за ними намного проще, чем за тысячами vps/ec2, на которые не заходишь годами. Jump host в своюб очередь можно так же закрыть фаерволом, а доступ к нему получать исключительно через vpn.
                    2. Не помогает ни как, если атака нацелена специально на вас.
                    3. В некоторых случаях, которые появлялись уже неоднократно, достаточно одного раза. Но штука полезная, если нет других вариантов.
                    • 0
                      Вы что советуете!? Нельзя давать сервисам порты выше 32к, там начинается диапазон эфимерных портов! При удачном стечении останитесь без сервиса.
                      • 0
                        Подкрутить /proc/sys/net/ipv4/ip_local_port_range и всего делов-то.
                        • 0
                          Во-первых, комментарий не содержал даже намёка на то, что надо еще крутить, из чего совершенно очевидно, что комментатор про проблему не знает.
                          Во-вторых, никто не говорил, что этот диапазон нельзя менять. Но это очевидно плохая практика и совершенно бездумный совет.
                      • 0
                        3. Кроме того, тут совершенно забыли о таких продуктах как fail2ban и denyhosts.

                        Это у которого сайт не обновлялся 5 лет, а новых релизов не выходило 10 лет?
                        Там что-то явно случилось с проектом:
                        stats.denyhosts.net/stats.html
                        • 0
                          Если это он, то не так уж и мёртв.
                    • +2

                      Отвечу цитатой:


                      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 секунд.

                      • +2
                        Смена порта SSH давно считается бесполезной техникой и даже вредной
                        Можно поподробнее насчёт «вредности»?
                        • –1

                          Лишнее неудобство, если хостов в хозяйстве значительно больше чем 1, и все зачем-то на разных портах. Немного меньше спама в логах — вот и весь профит.

                          • 0
                            Не знаю, как это делается в Linux, но в винде у себя я могу использовать парольные менеджеры или сохранять информацию о входе в SSH клиенте. То есть один раз введя порт, я его больше не ввожу и даже не помню, на каком порту висит мой сервер.
                            • +1

                              Если рабочих мест больше чем одно (стационарный комп, ноут, мобильник)? Администраторов больше чем один?
                              Настройки подключения клиент запомнит, да. Но все равно хранение дополнительной информации добавляет забот в первую очередь администратору. Вместо запомнить только $HOSTNAME — запоминать пару $HOSTNAME:$PORT. Можно пойти дальше, логиниться на каждый сервер с уникальным $LOGIN и уникальным $SSH_KEY. Но зачем, если есть и более удобные менее неудобные способы.

                              • +3
                                Если рабочих мест больше чем одно (стационарный комп, ноут, мобильник)?

                                Синхронизация? Нет, не слышал.
                                Вместо запомнить только $HOSTNAME — запоминать пару $HOSTNAME:$PORT.

                                А пароли вы все наизусть знаете? Просто я не умею запоминать сотни паролей вида LG2XcOJP1zq8lj61qPA2, и их всё равно вводит мой менеджер паролей. А раз вводятся пароли, то ничто не мешает добавить туда порт, хост, кузькину мать, менеджер всё запомнит и сделает как нужно.
                                • –2

                                  Расскажите про синхронизацию паролей между windows-linux-android-macos ;).
                                  Все, конечно же, решаемо. Но для ssh давно придуман доступ по ключу. Да и ваши несловарные пароли подобрать невозможно. Так какой же профит в смене порта?

                                  • +2
                                    Расскажите про синхронизацию паролей между windows-linux-android-macos ;).

                                    Я юзаю KeePass, мне между windows-android хватает, но клиенты есть и под другие ОС.
                                    Но для ssh давно придуман доступ по ключу.

                                    Который тоже можно хранить в менеджере.
                                    Так какой же профит в смене порта?

                                    Отвечу вашими же словами
                                    Немного меньше спама в логах — вот и весь профит.
                            • +1
                              «Немного меньше спама в логах — вот и весь профит»
                              А этого мало?

                              все зачем-то на разных портах

                              А зачем всё на разныз портах? Наша задача убрать автоматические долбилки, профита от того, что у нас все SSHки будут висеть на уникальных портах — никакого. Порт должен быть уникальным, но в рамках нашего решения, а не в прицнипе.
                              • 0
                                Наша задача убрать автоматические долбилки

                                Задача надуманная, и к безопасности слабо относится. При наличии отсутствия слабых паролей "долбилка" всего лишь засветит свой IP адрес, который правильно было бы скормить в fail2ban — и другие атаки с этого хоста уже не получатся.

                                • 0
                                  Бан по IP в 2017? Звучит очень странно.
                                  • +1

                                    В 2017 году iptables с -j DROP утратил актуальность?
                                    Универсальных рецептов на все случаи жизни не существует, да.

                              • 0
                                Немного меньше спама в логах — вот и весь профит.
                                Нет, не весь. Сейчас я расскажу Вам про ещё один. Помните WannaCry? Он распространялся через зиродей уязвимость в протоколе SMB (TCP-порт 445). Подобная уязвимость вполне может существовать и в протоколе SSH. Через N дней/месяцев/лет какой-нибудь Джон До может обнаружить её и нацарапать новый WannaCry для SSH, который будет сканировать весь диапазон IP-адресов и ломиться во все открытые порты 22. Про результат, думаю, рассказывать не надо. Простейшая смена стандартного SSH-порта на нестандартный многократно понизит вероятность попадания под удар при подобной атаке.
                                • 0
                                  Простейшая смена стандартного SSH-порта на нестандартный многократно понизит вероятность попадания под удар при подобной атаке.

                                  Возможно. Но после первой волны (по стандартному порту) обязательно будет вторая, которая будет шарашить прицельно, и не факт, что к тому времени ваш секретный порт не будет никому неинтересен. Зато у вас будет иллюзия безопасности: "никакие боты к нам не ломятся, можно раслабиться, мы в домике". А еще могут изобрести квантовый компьютер на 100500 кубит, и все RSA ключи превратятся в тыкву…

                                  • 0
                                    После первой волны будет время на обновление.
                                  • 0
                                    если джон доу достаточно умен чтоб нацарать 0-day exploit для ssh то думаю у него хватит мозгов дописать функцию поиска ssh порта на атакуемой машине
                                    • 0
                                      наглое сканирование портов довольно быстро пресекается автоматикой.
                                      Не то, что я За смену потрта ssh, но вот со сканом не все так просто.
                                      • 0
                                        1) Скан портов не нужен — зачем палится лишними действиям, если полно компов с стандартными портами?
                                        2) скан можно задетектить и забанить еще до его окончания. Хотя злоумышленник и может продолжить сканирование с нового IP, но это всё равно будет медленней и сложнее. Что уменьшает вероятность.
                                    • 0
                                      It depends.

                                      Вариант применения: слушать попытки соединения по стандартному порту и «тестировщиков» таких сразу отправлять на временный бан, тем же ipset.

                                      Большую часть горе-хакеров или порт-сканнеров подобной методикой удаётся быстро и автоматически изолировать. Меньше сору, меньше вздору.
                              • 0
                                вы бегите подальше из тех мест, где так считается (и не слушайте тех, кто из тех мест)
                                • 0

                                  я наоборот убежал от таких менял порта, они даже по ключам осилить не могли — по паролю ходили, зато порт поменяли, на всех серваках разный, кроме пароля еще и порт помни :)
                                  но это было давно, лет 7 назад, больше таких не встречал

                                  • +3
                                    я надеюсь, вы понимаете, что прямой корреляции между «уметь сменить порт» и «не уметь запретить парольную аутентификацию» нет, более того, существует обратная? если бы вы как я и многие коллеги в этом треде анализировали логи множества разных серверов на протяжении нескольких лет, то знали бы, что смена порта снижает количество неудачных попыток входа по ssh в тысячи, иногда десятки тысяч раз. ну а если бы вы вламывались в чужие системы (сам я конечно так не делал, но вот один друг рассказывал...), то знали бы как усложняет жизнь нестандартный порт (сканы nmap-ом в духе -p1-65535 о-о-о-чень затягиваются по сравнению с обычными)
                                    • –2
                                      Да не существует обратной. Из моей довольно немалой практики, там где изменён порт всё настроено совершенно наивно и безграмотно, практически всегда, увы…
                                      И если вам и придётся потратить немножко времени на автоматизированный скан портов (кстати, до 65536 и, не надо, обычно, 2022, 3022 и немного дальше можно просканить, а потом, и подробнее уже если случайно там была фантазия), то потом будет куда проще в остальном. =)
                              • 0
                                Я тоже думал насчёт ограничения доступа к компиляторам. Утилита lynis, к примеру, предлагает это делать.

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

                                  firewalld — это не замена iptables. Это интерфейс к iptables.

                                  • +6
                                    Некоторые предпочитают файрвол iptables файрволу firewalld

                                    Это неверно. Что iptables что firewalld всего лишь надстройки над netfilter который и является фаерволом.
                                    • 0
                                      firewalld это надстройка над iptables, который надстройка над netfilter…
                                      Правда, firewalld еще и надстройка над ipset…
                                    • 0

                                      cracklib же проверяет пароль на наличие его в словаре, который с собой носит. Это в лучшем случае вторичная мера. Лучше использовать passwdqc или pwquality. Я думал, что в rh пользуются именно pwquality.

                                      • +1

                                        Политика безопасности должна быть первичной. А инструменты из статьи могут ее обеспечивать (или не обеспечивать). То же шаманство с запретом компилятора (при наличии в системе десятка интерпретаторов и без ограничения доступа к ним тоже) — не особо осмысленно.

                                        • +3
                                          А насколько сейчас актуален — Port Knocking?
                                          • 0
                                            Вполне актуален, когда стоит задача скрыть сам факт наличия каких-то служб на сервере. Существуют современные реализации, открывающие порт по UDP-пакету с HMAC-подписью общего ключа, времени и команды открытия порта: linuxsecurity.expert/tools/pyknock

                                            В таком виде эту технику можно использовать как альтернативу вписывания всех доверенных хостов в список разрешённых в файрволе — пусть они прокладывают себе путь сами.
                                          • +1
                                            А почему не вспомнили про старый добрый TCP Wrappers?
                                            /etc/hosts.allow
                                            sshd: $some_trusted_IP: allow
                                            sshd: 127.0.0.1: allow
                                            sshd: ALL: deny
                                            И не надо никуда порт SSH перевешывать

                                            И еще, по мне идея использовать гуглоаутентификацию для SSH так себе затея, а вдруг Интернета не будет? Надо наверное держать одноразовые пароли на этот случай на бумажке все равно?
                                            • +1

                                              гугло-аутентификатору интернет не нужен — он по часам работает
                                              Вы без интернета куда коннектится будите кстати? на соседний комп разве что.

                                              • 0
                                                В этой стране внезапно можно оказаться в интранете этой страны.
                                                • 0

                                                  Не знал, что оно так)
                                                  Вот например с консоли подключиться к физической машине или к виртуалке при возникновении каких либо проблем со связью, я имел ввиду.

                                                • +1
                                                  Google Authenticator'у не нужен инет, если не ошибаюсь.
                                                  • +1
                                                    Не ошибаетесь, не нужен. Нужна только точная синхронизация времени. См. TOTP
                                                    • 0
                                                      Там даже не очень точная нужна, в пределах 30 секунд. Конкретно этот аутентификатор можно настроить на ещё более грубые пределы.
                                                • +3
                                                  опять 25: запрет входа root'ом не делает систему безопаснее, ну не делает и всё. эта рекомендация имеет очень простую основу: если злоумышленник знает имя пользователя (а root универсален для большинства систем), то ему нужно подобрать только пароль, а если не знает, то и то, и другое (что существенно увеличивает количество возможных комбинаций). вот только ключи (или билетики кербероса например) подобрать невозможно (в общем случае), а разрешение парольной аутентификации через ssh (или оставление разрешения по умолчанию) вопрос о безопасности в принципе снимает.
                                                  • 0
                                                    Если у сервера несколько администраторов, запрет входа под рутом персонализирует любые действия. Логин рута, при этом, полезно записать на бумажке, запечатать в конверт и убрать в сейф. На случай, если все эти администраторы однажды будут ехать в одном автобусе и решат, что там, куда он едет — лучше, чем на работе.
                                                    • 0
                                                      всё верно, «догнать концы» по имени пользователя проще, чем по ip, вот только это разговор об ответственности и профпригодности (если сотрудник профессионал, то все работы будут согласованы с начальством, а обо всех косяках будет сразу доложено, и поиски будут не нужны), а не о безопасности (тема статьи)
                                                  • +2
                                                    Абсолютно все советы по безопасности, оторванные от контекста, являются ничем иным как бесполезной тратой времени.
                                                    Как автора статьи и так же читателя.

                                                    P.S. Для общего образования тоже слабо подходит.
                                                    • +3

                                                      Ребята, стыдно такое переводить.
                                                      Да, относительно перевода, только одно режет слух:


                                                      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

                                                      $ — это что, от юзера? Ну да, может быть… у автора…
                                                      Ладно, а что будет после очередного обновления пакетов? Наша песня хороша, начинай с начала?
                                                      Да и вообще, зачем прод серверах компоненты для сборки?

                                                      • +1
                                                        Авторы таких статей после смерти попадают в персональный парольный ад, где им каждые 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}'


                                                        Показывает пути к файлам с ключами и имена@хосты внутри.
                                                        • 0
                                                          Интересно, вот только сегодня с коллегами обсуждали =)
                                                          Ключи лучше не только, что их не подобрать, но ещё и не собрать коллекцию логинов, подменив sshd на взломанном сервере.
                                                          А пароль на ключ должен быть обязательно, это не обсуждается даже.

                                                          Кстати, 2FA через google auth при авторизации по ключу — не запрашивает код аутентификатора. Только если входить по паролю. Так что статья не корректа еще и в этом плане.
                                                          • 0
                                                            Одно «но»: имя@хост в конце ключа может не иметь к реальному происхождению и/или использованию ключа никакого отношения. А так да, удобный поиск.
                                                          • 0
                                                            Занятно! Особенно про Sudo и отправку на почту, я как то и не задумывался о таком. Хорошая мысля приходит как всегда...=)
                                                            • 0
                                                              Отлично, парни! Спасибо! Обязательно у себя сделаю.
                                                              • 0
                                                                Когда серверов штук 500, некоторые пункты меняются.
                                                                Не написано про fail2ban.
                                                                • 0
                                                                  Как затравка хорошего обзора по результатам обсуждения…
                                                                  Стоит критичнее подойти к тексту и набору средств.
                                                                  fail2ban как минимум стоит добавить.
                                                                  Ну и конечно нужны оценки по эффективности и цели для каждого средства.
                                                                  • 0
                                                                    Увольте копирайтера, читать глаза болят. Особенно про «терминалы». Называть tty терминалом — это круто.
                                                                    • –2
                                                                      Помните о том, что вам, если вы играете роль администратора, следует способствовать тому, чтобы пользователи применяли сложные пароли.

                                                                      А можеть все же без пароля?!

                                                                      • 0
                                                                        WEB-хостинг. Куча клиентов + разработчикам надо ходить под разными аккаунтами (не даю я им под рутом ничего делать ибо нефиг). Соответственно отрубить авторизацию по паролю — не вариант. Просто добавить доступ по ключу — не вижу смысла. Приведённые выше несловарные пароли запоминаю довольно быстро считая необходимой проф.деформацией.
                                                                        Сделал так: SSH на нестандартном порту + fail2ban. Факты: после смены порта автоматические долбилки отвалились. После установки fail2ban логи стали заметно чище. Профит в том, что теперь анализ логов стал проще. А когда тебе по нескольку раз в день нужно получать ответ на вопрос «кто откуда и зачем заходил?» профит считаю жирным лично для себя.
                                                                        Астериски в других компаниях\домашний медиа-сервер — порт перенесён, fail2ban, на роутере правила ограничивающие доступ только с определённых IP. Ну глупости это — пытаться с телефона в поездке что-то там поадминить (интернет не стабильный, экран маленький, входящий звонок невовремя). На крайний случай должен быть человек в офисе\дома который ответит на звонок и всё сделает точно как сказано. А если такого человека нет, то в целом не так всё важно, чтобы не потерпеть несколько часов пока вы доберётесь до удобного рабочего места, подключитесь к офисной сети и всё сделаете как белый человек с большим монитором, клавиатурой и чашкой кофе.
                                                                        И да, пароль на ключ — обязателен т.к. ваш ключ могут просто украсть.
                                                                        • 0
                                                                          анализ логов стал проще

                                                                          Если логи читает человек — да, меньше логов — проще читать. Анализатору все равно.


                                                                          по нескольку раз в день нужно получать ответ на вопрос «кто откуда и зачем заходил?»

                                                                          IDS с этим вопросом справится лучше.

                                                                        • 0
                                                                          iig: спасибо! Некоторое время назад искал детектор атак, наткнулся на Suricata, но не осилил понять что это и как правильно использовать. Сейчас вдумчиво прочитал пару мануалов и описаний — прикольная вещь. Попробую. А то каждый раз одно и тоже:
                                                                          — Алло! У нас сайт уже неделю не работает из-за вас!
                                                                          — Минуту… Вчера работал — сами проверяли и с ним работали.
                                                                          И в конце выясняется, что клиент зашёл, ничего не делал (а чего заходил?..) и оно само. Но все уже успели свою порцию пинков от руководства получить. Студия маленькая, пинки долетают быстро :-(
                                                                          • 0
                                                                            У нас сайт уже неделю не работает из-за вас!

                                                                            nagios же.

                                                                            • 0
                                                                              Nagios пасёт весь сервер в целом и не в курсе, что где-то какой-то баннер съехал или кусок текста пропал. Так-то все страницы отдают нормальный код 200. Но для большинства заказчиков нет разницы между кодами 200 и поехал текст или 4XX\5XX. Для них всё просто: выглядит не так как ожидалось = сайт не работает. Причём время у них так-же идёт как то иначе. Например при обновлении движка надо сайт временно перевести в режим обслуживания. Ответственному со стороны заказчика сообщили о времени проведения процедуры, оно забыло сообщить своему руководству. Процедура прошла штатно и потребовала минуты 3. Но под конец этих 3 минут будет звонок и вопли, что уже несколько дней сайт не работает от слова «совсем».
                                                                              • 0

                                                                                Немного капитанства ;).
                                                                                Административные проблемы должны решаться административными способами.
                                                                                В договоре с клиентом что-то написано про порядок выполнения регламентных работ?

                                                                                • 0
                                                                                  Конечно написано. Конечно мы их проводим в нерабочее время и обязательно предупреждаем о тои, что будем делать то и это и по времени столько. Но как уже писалось выше — взаимодействуем мы со старшим помощником младшего заместители ИО директора по развитию. А звонит нам генеральный директор. Ну есть у них такая привычка — сидеть на своём сайте и в случае чего звонить не своему сотруднику который непосредственно отвечает за развитие сайта, а нашему генеральному. А тот соответственно так-же не всегда в курсе на каком сайте что делается и разговор выглядит так как писалось выше. К сожалению в небольших городах у небольших студий работающих с не самыми крупными клиентами есть вполне себе крупные проблемы создаваемые на пустом месте именно клиентами. Поэтому к вопросам контроля за действиями клиента требования повышенные чтобы хоть на штрафы и скандалы не попадать.

                                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                          Самое читаемое