Русскоязычное сообщество Debian GNU/Linux

    Данная тема создана, чтобы собрать основные пункты для обеспечения безопасности и стабильной работы серверов на GNU/Linux и в частности Debian. В комментариях задаем вопросы/дополняем/исправляем недочеты, которые будут собраны в шапке темы.   

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

Доступ

Совет #1: Отдельный менеджмент интерфейс.

Допустим, у вас есть веб-сервер. Многие используют один адрес для основной работы и для администрирования. И при атаке на сервер с помощью нагрузки канала, доступ к серверу пропадает, канал рвется, остается надеяться на лучшее и видеть, как сервер тонет. И если атака с нарастающей мощностью, то у вас еще будет пару минут для защиты, но существуют атаки, которые моментально губят доступ и не оставляют возможности для защиты. Профилактика конечно необходима, необходимо иметь какие-то скрипты для автоматической защиты, но... запасной выход также необходим.
Так почему бы не использовать отдельный порт/адрес для администрирования? Адрес, который знаете только вы, который не будет затронут при атаке.


Совет #2: Замена дефолтного порта для ssh.

    Теперь поговорим о самом доступе. Чаще всего используется ssh. И тут нужно залатать некоторые дыры. Во первых, ssh по умолчанию использует 22 порт. Этим пользуются боты и это уже уязвимость. Конечно, можно задать супер-сложный пароль, но все же, защитой пренебрегать нельзя. И так, меняем порт для ssh на какой-нибудь другой.


sed -i 's/Port\ 22/Port\ 4897/g' /etc/ssh/sshd_config && /etc/init.d/ssh restart
   
Заменяем 4897 на какой-нибудь другой порт, по своему усмотрению. Теперь к серверу доступ можно будет получить только вводя в запросе ssh порт:

ssh x.x.x.x -p 4897









...

Цитата: doctor@tardis от 07 сентября 2015, 07:50:14Так почему бы не использовать отдельный порт/адрес для администрирования? Адрес, который знаете только вы, который не будет затронут при атаке.

что значит отдельный порт для администрирования? отдельное сетевое подключение? SNMP?

Начинать нужно всегда с малого - Устанавливаем fail2ban...

endru, отдельный eth-интерфейс с другим адресом.
Fail2ban - само собой, но я пока что говорил о доступе к серверу, а точнее администрировании.

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

---

Cообщение объединено 07 сентября 2015, 09:02:00

---

Кстати, очень важно в безопасности - делать хорошие пароли, потому что подбором ломают часто. Если fail2ban не стоит Например, пароль "44_Veselix_4ija" будет довольно сложно сломать перебором, а человеку будет довольно легко запомнить

Если у вас на сервере 2 интерфейса и один смотрит в локальную сеть, то да, можно всё вывести на него. А на внешний отдать только веб или что требуется.
Несколько пунктов:

• Отключаем доступ root по ssh, некоторые меняют порт.
• Устанавливаем fail2ban.
• Используем большие пароли и ключи, для доступа к системе.
• Используем как можно меньше пакетов, чем больше пакетов, там больше потенциальных дыр.
• Если используется паранаидальный режим, то устанавливаем OpenVPN и администрирование только через него.

извне закрываем все неиспользуемые порты, посредством iptables или другого брандмауэра.
не забываем о security обновлениях. естественно внимательно читаем changelog дабы не сломать чего.

Открыть содержимое (спойлер)

doctor@tardis, если соберете все дельные советы в головную тему, то можем и прикрепить её.

[свернуть]

doctor@tardis, слежу за обновлениями, и могу сразу сказать, что команда sed -i 's/22/4897/g' /etc/ssh/sshd_config && /etc/init.d/ssh restart потенциально опасна! Нет гарантий что в конфиге больше нет "22"!
нужно четко указывать, что мы меняем:
sed -i 's/Port\ 22/Port\ 4897/g' /etc/ssh/sshd_config && /etc/init.d/ssh restart

по совету №1:

Цитата: doctor@tardis от 07 сентября 2015, 07:50:14
Так почему бы не использовать отдельный порт/адрес для администрирования? Адрес, который знаете только вы, который не будет затронут при атаке.

будет куча вопросов. даже я не понял что конкретно предлагается сделать...

Цитата: doctor@tardis от 07 сентября 2015, 07:50:14Данная тема создана, чтобы собрать основные пункты для обеспечения безопасности и стабильной работы серверов на GNU/Linux и в частности Debian.

Основных пунктов для обеспечения безопасности не так уж много. И не только серверов, и не только в Debian. Это:

* Контроль портов.
* Работа с обычными "юникс" правами (DAC).
* Изоляция приложений, то бишь системы мандатного контроля доступа (MAC) и разнообразные контейнеры.
* Дополнительная защита памяти.

Вот вроде и все.
P.S. Про шифрование забыл.

endru, исправил скрипт) Писал для настроек по дефолту, но да, видимо все же лучше указывать более точное значение.

Насчет интерфейса. Когда берете у провайдера сервер(или виртуалку), скажем для хостинга веб сайта, вам дают айпишник, которому присвоят днс имя, откуда все будут заходить на сайт. Кроме того, с этого же адреса вы администрируете сайт. При дос атаке, подключиться по ssh к адресу будет проблематично, ибо канал нагружен. Миллионы пакетов приходят на этот интерфейс и ваш ssh просто не сможет подключиться.
Так почему бы не взять еще один интерфейс(eth1), с другим адресом. Пока будут атаковать eth0, вы через eth1 спокойно подключитесь и сделаете то что надо.

Отдельный менеджмент интерфейс будет также обнаружен сканером nmap как и основной. Также атака может вестись на несколько интерфейсов сразу. Смена пота также поможет только если атака ведётся автоматическими средствами на 22 порт. Поэтому советы бесполезные.
Горазда эффективно настроить доступ по SSH по ключам.

Цитата: dzhoser от 21 марта 2024, 09:03:15Отдельный менеджмент интерфейс будет также обнаружен сканером nmap как и основной. Также атака может вестись на несколько интерфейсов сразу. Смена пота также поможет только если атака ведётся автоматическими средствами на 22 порт. Поэтому советы бесполезные.
Горазда эффективно настроить доступ по SSH по ключам.

Согласен.
Отдельный менеджмент интерфейс имеет смысл только если он не выставлен в интернет, то бишь смотрит во внутреннюю сеть.
Определять SSH на нестандартном порту не так уж и сложно. Поэтому смена ssh порта - неудобство для тебя, а отсекает лишь самых начинающих скрипт кидди.
Проще fail2ban настроить, ну и доступ по ключам.

Вот ещё есть такое:

# /etc/hosts.allow: list of hosts that are allowed to access the system.
#                   See the manual pages hosts_access(5) and hosts_options(5).
#
# Example:    ALL: LOCAL @some_netgroup
#             ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you're going to protect the portmapper use the name "portmap" for the
# daemon name. Remember that you can only use the keyword "ALL" and IP
# addresses (NOT host or domain names) for the portmapper, as well as for
# rpc.mountd (the NFS mount daemon). See portmap( and rpc.mountd(
# for further information.
#
postfix: ALL# All servers worldwide
sshd: 10.24.,192.168.1.12# Local net + Admin PC
dovecot: 10.24.,192.168.1.12# Local net + Admin PC
ALL: 192.168.1.12# Admin PC

PbI6A, поясните пожалуйста, что такое 10.24.?

10.24. - начало ip адресов 10.24.*.* - некая внутренняя сеть предприятия.

Для защиты серверов необходимо сделать аудит системы. Сканером например Lynis. Если администрация позволит и форумчанам будет интересно, создам отдельную тему.