Как стать автором
Обновить

Комментарии 45

Даже для базовой настройки маловато будет.

Обновления недостаточно один раз накатить, их регулярность надо и потом как-то обеспечивать. И тут или unattended-upgrades настраиваем, или, если у нас там всё настолько mission critical, что любой простой из-за непротестированного обновления вообще неприемлем, - как-то организуем процесс сложнее, но позаботиться об этом надо.

Для Ubuntu полезно на каждые 5 серверов заводить новый аккаунт Ubuntu Pro (ну или если у Вас всё серьёзно - купить подписку) и привязываться к нему, чтобы получить livepatch.

Раз уж мы про безопасность - то можно добавить к списку для установки и настройки fail2ban.

Опять же, что за сервер без мониторинга, так что сюда же - установка Prometheus Node Exporter, Zabbix Agent или что там по вкусу.

Отправку почты через SMTP relay неплохо бы настроить, ну и адрес админа в нужные конфиги вбить, чтобы сервер, если что захочет по почте сообщить, имел такую возможность.

И в завершение оформить всё это плейбуком Ansible - вот тогда будет красота :)

Для Ubuntu полезно на каждые 5 серверов заводить новый аккаунт Ubuntu
Pro (ну или если у Вас всё серьёзно - купить подписку) и привязываться к
нему, чтобы получить livepatch.

Идея хорошая, но мне кажется для vps для пет проекта многовато будет)

Раз уж мы про безопасность - то можно добавить к списку для установки и настройки fail2ban

Добавлю, спасибо!)

Опять же, что за сервер без мониторинга, так что сюда же - установка Prometheus Node Exporter, Zabbix Agent или что там по вкусу.

Отправку почты через SMTP relay неплохо бы настроить, ну и адрес админа в
нужные конфиги вбить, чтобы сервер, если что захочет по почте сообщить,
имел такую возможность.

И в завершение оформить всё это плейбуком Ansible - вот тогда будет красота :)

Хорошая мысль, но опять же мне кажется многовато для маленького сервачка под пет. Но настройка всего этого как мне кажется тянет на еще один туториал :) Спасибо за наводку!

Поделитесь своим плейбуком? ;)

"Колея это только моя - выбирайтесь своей колеёй!" :)
Мой плейбук - он мой, там много чего специфичного для моих конкретных потребностей. Если что конкретно интересует - пишите (лучше в личку, я комменты к старым постам редко смотрю).

Ну вот из неочевидного, для примера - такой кусок "bashsible" (антипаттерн, ага) для настройки того самого Ubuntu Pro (ubuntu_pro_account и ubuntu_pro_token задаются в group_vars, на каждые 5 хостов в пределах бесплатного лимита своя учётка и своя группа):

кусок плейбука
- name: Enable Ubuntu Pro
  when: ansible_distribution == 'Ubuntu'
  become: true
  block:
    - name: Check Ubuntu Pro Status
      ansible.builtin.shell:
        cmd: "pro status | grep 'Account:'"
      register: pro_not_attached
      changed_when: false
      failed_when: false
    - name: Check Ubuntu Pro Account
      ansible.builtin.shell:
        cmd: "pro status | grep 'Account: {{ ubuntu_pro_account }}'"
      register: pro_other_account
      changed_when: false
      failed_when: false
    - name: Detach Ubuntu Pro
      when: pro_not_attached.rc == 0 and pro_other_account.rc == 1
      ansible.builtin.shell:
        cmd: "echo y | pro detach"
    - name: Attach Ubuntu Pro
      when: pro_not_attached.rc == 1 or pro_other_account.rc == 1
      ansible.builtin.command:
        cmd: "pro attach {{ ubuntu_pro_token }}"
      register: pro_attached_success
      changed_when: pro_attached_success.rc != 2
      failed_when: pro_attached_success.rc != 0 and pro_attached_success.rc != 2

Ну или unattended-upgrades, тут вариант для убунт 20.04 и 22.04 и дебиана 11 как минимум:

ещё кусок плейбука
- name: Set up automatic upgrades
  become: true
  block:
    - name: Install unattended-upgrades
      ansible.builtin.apt:
        name:
          - unattended-upgrades
          - apt-listchanges
        state: latest
        update_cache: true
      notify:
        - Cleanup apt
    - name: Configure automatic upgrades (1)
      ansible.builtin.copy:
        dest: /etc/apt/apt.conf.d/20auto-upgrades
        content: |
          APT::Periodic::Update-Package-Lists "1";
          APT::Periodic::Unattended-Upgrade "1";
        mode: 0644
        owner: root
        backup: true
    - name: Configure automatic upgrades (2)
      ansible.builtin.replace:
        path: /etc/apt/apt.conf.d/50unattended-upgrades
        regexp: '{{ item.key }}'
        replace: '{{ item.value }}'
        backup: true
      loop: "{{ common_unattended_upgrade_conf | dict2items }}"
      vars:
        common_unattended_upgrade_conf:
          '^/*(Unattended\-Upgrade\:\:Mail) .*$': '\1 "{{ admin_mail }}";'
          '^/*(Unattended\-Upgrade\:\:MailOnlyOnError).*$': '\1 "true";'
          # Found in some older configs
          '^/*(Unattended\-Upgrade\:\:MailReport).*$': '\1 "only-on-error";'
    - name: Configure automatic upgrades to accept all repos
      block:
        - name: Accept all repos (Debian)
          when: ansible_distribution == 'Debian'
          ansible.builtin.blockinfile:
            path: /etc/apt/apt.conf.d/50unattended-upgrades
            insertafter: '^/*Unattended-Upgrade\:\:Origins-Pattern'
            marker: "// {mark} ANSIBLE: {{ ansible_role_name }}"
            block: '        "origin=*,codename=*";'
            state: present
            backup: true
        - name: Accept all repos (Ubuntu)
          when: ansible_distribution == 'Ubuntu'
          ansible.builtin.blockinfile:
            path: /etc/apt/apt.conf.d/50unattended-upgrades
            insertafter: '^/*Unattended-Upgrade\:\:Allowed-Origins'
            marker: "// {mark} ANSIBLE: {{ ansible_role_name }}"
            block: '        "*:*";'
            state: present
            backup: true

Если я захожу на сервер, то чтобы что-то настроить или обновить. Значит мне нужны рут-права. Смысл создавать себе препоны в виде отдельного юзера, но с правами запускать что угодно без пароля через sudo? Тупость какая-то.

А если у меня там крутятся не совсем доверенные сервисы, то их как раз можно разнести по отдельным юзерам, без прав на sudo.

  1. Снижаем риск случайной ошибки при запуске тех команд / программ, где нам sudo не нужно.

  2. Делаем неизвестным для атакующего ещё и имя пользователя. Но его, конечно, покреативнее надо назвать, чем автор статьи предлагает.

Да и в целом, стандартная же практика.

НЛО прилетело и опубликовало эту надпись здесь

Менять порт SSH надо хотя бы для того, чтобы не засирались логи :))
А так да, выключение входа по паролю, разрешение входа только по ключам, и не надо запутывать всех дополнительными юзерами.

Флуд в логе не беда, его можно удобно грепать регуляркой и превентивно банить особо отличившиеся ботофермы ещё на входе, где-нить в районе бордера.

Не руками разумеется )

Флуд в логе очень сильно мешает, особенно если есть какой-нибудь logcheck.
Приходится менять порт примерно раз в полгода.
Плюс не увидел в статье ничего про fail2ban — очень помогает при набегах ботов.


Из недавнего

И их там сотни 2 таких было
image

У меня есть некий самописный аналог распределенного f2b, работает на /22 уже лет 5 и подкопил некую базу и статистику. Бордер по bgp эту базу регулярно синхронизирует и дальше атаки до серверов уже не долетают, режутся прям на нем. Простыни типа вашей давно уже в логе не видел.

Но тут вопрос масштаба разумеется, единичную впску конечно проще прикрыть f2b или упороться в порт-кноккинг. Ну или просто hosts.allow заполнить и deny all. Прикрывать сеть - проще централизованно

У меня была мысль сделать общую блэклист базу с детектом и добавлением на всех хостах. Но у меня сейчас 2 сервера (планируется еще один), решил не заморачиваться и просто вручную обновлять списки :)

Со сменой порта легко поиметь connectivity-problems при попытке доступа к своей VPS'ке из каких корпоративных интранетов и\или у особо упоротых провайдеров - причем узнать об этом можно в самый неподходящий момент. КМК больше вреда, чем пользы.

Были тут такие статьи, тут есть вариант сделать резервный вебшел shellina либо ttyd

Если нужен доступ к ssh из корп сетей, то уже нужно отталкиваться от конкретных настроек, т.к. я встречал проблемы с подключением по 22 порту из корп сети и помогала только перенастройка на 80/443 порт.

Да, и такое тоже бывает. Но "в целом" смена дефолтных портов для стандартных протоколов как представитель методов "security through obscurity" как по мне - не лучшая идея. Сканирование портов нонеча дешевое и быстрое...

Это не главный способ защиты, а просто мелочь, позволяющая отсечь какой-то процент не очень умных ботов, лишним не будет)

Это только чтобы отсечь тупых ботов, коих однако большинство. Не ради безопасности, а чтобы они не нагружали CPU запросами. Особенно заметно на соло VPS за 200 рублей.

Стандартная практика - запрещать вход под рутом, как минимум удалённый. Первая же страница результатов поиска по словам "why should you not use root" в гугле даёт такое количество описаний и обсуждений, что этого точно должно хватить для подобного вывода.

Заходя "для обслуживания" (раз уж у нас сервер, куда мы в принципе заходим вручную), мы тоже делаем много чего, не требующего административных прав. И не запускать от рута то, что можно от него не запускать, - как минимум не помешает. Собираем из исходников? Configure и make от пользователя, make install через sudo - стандартно. Используем питон? pip install от рута вообще весело конфликтует с модулями, поставленными через apt. Так что отдельный пользователь-администратор нам нужен, если мы на сервере руками копаемся.

Вход только по ключу, смена порта и fail2ban - безусловно. Про первое и второе написал сам автор, третье добавил я в первом своём комменте. Но это от всё только от ботов и прочих удалённых атак. Ограничение входа по IP не всегда применимо (хотя в случае с виртуалками, на которые всегда можно зайти через консоль в гипервизоре, логично вообще пускать по SSH только через VPN, а вот если сервер физический, да ещё без IP-KVM, тут сто раз подумаешь, как самому не лишиться доступа в нештатной ситуации). А нестандартное и несловарное имя пользователя в добавок к этому всему нам может помочь, скажем, в ситуации, если, флэшку с нашим ключиком у нас целенаправленно увели/отобрали/изъяли.

ключиком у нас целенаправленно увели/отобрали/изъяли

Вот тут не совсем понял: если увели то логично (только надо проследить чтобы это имя в коменте к ключу не засветилось), а если изъяли -то скорее всего вместе с нестандартным именем

А не надо хранить нестандартное имя на том же носителе, что и ключ. Его можно иметь одно на группу машин одного рода, и тогда и запомнить не грех.

Мы рассматриваем сценарий "отобрали" а это уже подразуемвает физическое воздействие вплоть до критического.

Просто хочу понять что имелось в ввиду

Имелось в виду - пришли с обыском в офис, забрали со стола админа флэшку. Терморектальный криптоанализ не применяли. Комп админа не изъяли или изъяли, но там всё зашифровано. А вот флэшка в ключиком, зараза, незашифрованная лежала, т.к. админ её с собой таскал на всякий пожарный случай. Вполне реальный сценарий, гораздо чаще в жизни встречается, чем более жёсткие варианты, если мы про обычные бизнес-разборки, а не про политику и т.п. Опера на обыске вообще особо ничего не расспрашивают, просто загребают всё, что отдалённо напоминает электронику (у меня док-станцию к ноуту без самогó ноута пытались тут изъять недавно :)

Тут, конечно, надо и админа за хранение ключика в таком виде дружно осудить всем коллективом. И на ключики passphrase ставить. И много что ещё. Но при важности всех остальных мер ещё одна лишней тоже не будет. Тем более отдельный от рута пользователь-админ по другим изложенным выше причинам всё равно пригодится, так несложно заодно и назвать его как-нибудь позаковыристее.

я прямо таки ушел гуглить как переименовать пользователя в системе

внезапно - да, стандартная практика. Здесь автор вообще предлагает удивить ботов и сделать root еще более не логинным, но тупых ботов отлуп по ключу вообще не останавливает, они тупо перебирают весь запас

НЛО прилетело и опубликовало эту надпись здесь

весь запас ИМЕН из списка

На этот случай есть забавный сервер SSH tar pit. Стоит на машине, занимает порт 22. Сначала имитирует успешный логин от SSH, а потом начинает отдавать консольный промпт со скоростью 2 буквы в час. Ресурсов при этом не тратит почти, на графиках его не видно.

Поправил)

  1. Запрещаем использовать дополнительные конфиги для безопасности, поэтому комментируем эту строчку.

    #includedir /etc/sudoers.d

О сколько чудных нам открытий дает man sudoers

Hidden text
Including other files from within sudoers
     It is possible to include other sudoers files from within the sudoers file currently being parsed using the
     @include and @includedir directives.  For compatibility with sudo versions prior to 1.9.1, #include and #includedir
     are also accepted.

     An include file can be used, for example, to keep a site-wide sudoers file in addition to a local, per-machine
     file.  For the sake of this example the site-wide sudoers file will be /etc/sudoers and the per-machine one will be
     /etc/sudoers.local.  To include /etc/sudoers.local from within /etc/sudoers one would use the following line in
     /etc/sudoers:

         @include /etc/sudoers.local

Вау, исправлю на удаление) Спасибо!

Если про "радости параноика" говорить - то надо еще какой file integrity checker настраивать - mtree, afick - что-нибудь такое. Для ssh можно хостовые ключи в DNS прописать - при наличии DNSSEC даже осмысленно. Плюс - сразу же бэкапом всего, имеющего ценность озаботиться, чтоб потом по потолку не бегать - пока бэкап не настроен, "сервер не готов".

Кстати, по ssh рекомендация использовать rsa ключ кмк не самая лучшая в наши дни идея, если нет явных ограничений по использованию каких-нибудь очень древних клиентов.

scp .ssh/id_rsa.pub root@your_ip:/home/super/.ssh/

Есть команда ssh-copy-id

Исправлю, спасибо!

Она и проверит существование добавляемого ключа, и наличие файла с ключами, права на папку и файл сделает нужными, и добавит к существующим, если есть другие. Вобщем правильно пользовать эту команду. И ключи делать уже не rsa, а ed25519 лучше.

Запрещаем авторизацию по паролю, оставляя только по ключу

Еще стоит проверить, что в конфиге явно указано KbdInteractiveAuthentication no или ChallengeResponseAuthentication no. Иначе такая команда может привести к удивительным результатам: ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no example.com

Выключаем пользователя root

А это лучше делать не через правку /etc/passwd руками, а через sudo chsh -s /sbin/nologin root. И еще рекомендую посмотреть ключи --expire и --lock для команды passwd.

KbdInteractiveAuthentication

ChallengeResponseAuthentication is a deprecated alias for this.

@len2367

# locale ssh-keygen -t rsa -b 4096

А почему не стали использовать ed25519 и ключ безопастности для ssh ключа?

Добавил информацию про ed25519

Хорошие базовые практики, сам аналогично делаю, лишь другими "словами". А хардить систему, я смотрю по комментариям, можно бесконечно.

дополнение к примечанию 2 - смысл брать ру хостинг для таких целей? берите забугорный, который только полату имеет в рубляъх, а сам зарегистрировать в европах условных, вот pq.hosting подходит

Прошу прощения, а зачем обязательно забугорный? Это же не для vpn, а для pet проектов

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории