Комментарии 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.
Снижаем риск случайной ошибки при запуске тех команд / программ, где нам sudo не нужно.
Делаем неизвестным для атакующего ещё и имя пользователя. Но его, конечно, покреативнее надо назвать, чем автор статьи предлагает.
Да и в целом, стандартная же практика.
Менять порт SSH надо хотя бы для того, чтобы не засирались логи :))
А так да, выключение входа по паролю, разрешение входа только по ключам, и не надо запутывать всех дополнительными юзерами.
Флуд в логе не беда, его можно удобно грепать регуляркой и превентивно банить особо отличившиеся ботофермы ещё на входе, где-нить в районе бордера.
Не руками разумеется )
Флуд в логе очень сильно мешает, особенно если есть какой-нибудь logcheck.
Приходится менять порт примерно раз в полгода.
Плюс не увидел в статье ничего про fail2ban — очень помогает при набегах ботов.
И их там сотни 2 таких было
У меня есть некий самописный аналог распределенного f2b, работает на /22 уже лет 5 и подкопил некую базу и статистику. Бордер по bgp эту базу регулярно синхронизирует и дальше атаки до серверов уже не долетают, режутся прям на нем. Простыни типа вашей давно уже в логе не видел.
Но тут вопрос масштаба разумеется, единичную впску конечно проще прикрыть f2b или упороться в порт-кноккинг. Ну или просто hosts.allow заполнить и deny all. Прикрывать сеть - проще централизованно
Со сменой порта легко поиметь connectivity-problems при попытке доступа к своей VPS'ке из каких корпоративных интранетов и\или у особо упоротых провайдеров - причем узнать об этом можно в самый неподходящий момент. КМК больше вреда, чем пользы.
Были тут такие статьи, тут есть вариант сделать резервный вебшел shellina либо ttyd
Если нужен доступ к ssh из корп сетей, то уже нужно отталкиваться от конкретных настроек, т.к. я встречал проблемы с подключением по 22 порту из корп сети и помогала только перенастройка на 80/443 порт.
Стандартная практика - запрещать вход под рутом, как минимум удалённый. Первая же страница результатов поиска по словам "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 буквы в час. Ресурсов при этом не тратит почти, на графиках его не видно.
P.S. cheAtsheet :)
Запрещаем использовать дополнительные конфиги для безопасности, поэтому комментируем эту строчку.
#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
Запрещаем авторизацию по паролю, оставляя только по ключу
Еще стоит проверить, что в конфиге явно указано 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.
# locale ssh-keygen -t rsa -b 4096
А почему не стали использовать ed25519 и ключ безопастности для ssh ключа?
Хорошие базовые практики, сам аналогично делаю, лишь другими "словами". А хардить систему, я смотрю по комментариям, можно бесконечно.
подключение по ключам ничего по вашей инструкции не получилось. а получилось по другой: https://mhelp.pro/ru/kak-nastroit-ssh-sertifikaty-dlya-vkhoda-na-ubuntu-server/
дополнение к примечанию 2 - смысл брать ру хостинг для таких целей? берите забугорный, который только полату имеет в рубляъх, а сам зарегистрировать в европах условных, вот pq.hosting подходит
VPS cheatsheet