[Linux.wiki] Защита ssh порта от атак.
Продолжаю изучать iptables.
Нашёл одну очень интересную статью (ссылка ниже).
Как можно защитить свой ssh порт от атак. В данном случае атака подразумевает собой перебор паролей к вашему серверу.
Количество комбинаций в принципе конечно и чисто теоретически подобрать пароль можно. Всё зависит от скорости работы и ресурсов. Например, сколько попыток можно совершить в секунду, минуту, час…
Частично это зависит от вашего сервера – сколько подключений он может выдержать. Лучше до этой проверки не доходить, а ограничить количество подключений к вашему ssh порту. Ограничить число соединений с какого-либо source ip-address.
Например, если произошло больше 4 подключений к вашему ssh порту за последние 5 минут с какого-то ip – забанить его на час. Если попытки будут продолжаться, то бан будет автоматически продеваться.
Получивщийся фильт выглядит следующий образом. Мои комментарии ниже.
# Сначала очищаю текущий правила в фильтрах, если таковые имеются:
sudo iptables -F
#1. Открываю доступ для уже установленных соединений и для пакетов приходящих в ответ на запросы самого сервера (лучше всегда добавлять).
sudo iptables -A INPUT -m conntrack —ctstate RELATED,ESTABLISHED -j ACCEPT
#2. Открываю доступ к порты ssh для надёжных ip. Если у вас дома постоянный адрес, например. В данном примере у меня ssh порт =2222.
sudo iptables -A INPUT -s 192.168.56.1/32 -p tcp —dport 2222 -j ACCEPT
#3. Открываю доступ к моему веб.серверу для всех.
sudo iptables -A INPUT -p tcp —dport 80 -j ACCEPT
#4. Создаю дополнительную цепочку (chaine) в которой буду обрабатывать часть пакетов по критерию (данном примере правило №8 будет заворачивать пакеты в эту цепочку).
sudo iptables -N BADGUY
#5. Пакеты повавшие в цепочку BADGUY маркируются как badguys и отбрасываются – по сути попадают в специальный список. См. файлы в /proc/net/xt_recent/
sudo iptables -t filter -A BADGUY -i eth1 -m recent —set —name badguys -j DROP
#6. Входящий пакет после прохождения правила 3 попадает под проверку данным правилом. Если пакет есть в списке badguys, то запись обновляется и продлевается на 1 час, пакет отбрасывается. Таким образом ip-address которые ранее были замечены в попытка частых подключений к ssh блокируются на час.
sudo iptables -A INPUT -i eth1 -p tcp —syn —dport 2222 -m recent —name badguys —update —seconds 3600 -j DROP
#7. Если пакет на был в списке badguys, например это первая попытка подключения к порту ssh/2222, то пакет просто вносится в список sshcheck. Больше никаких действий. Переход на следующее правило.
sudo iptables -A INPUT -i eth1 -p tcp —syn —dport 2222 -m recent —set —name sshcheck
#8. Если это 4 попытка подключения за последние 5 минут к порту ssh/2222, то пакет переходит к цепочке BADGUY, где делается отметка в badguys и пакет отбрасывается. Также далее в течение одного часа пакет от данного source-ip-address на порт ssh/2222 будут блокироваться по правилу 6.
sudo iptables -A INPUT -i eth1 -p tcp —syn —dport 2222 -m recent —name sshcheck —rcheck —seconds 300 —hitcount 4 -j BADGUY
#9. Если 4 попыток за 5 минут не было, но подключение 2ое за последние 30 секунд, то source-ip-address блокируется на 30 секунд (на порт ssh/2222).
sudo iptables -A INPUT -i eth1 -p tcp —syn —dport 2222 -m recent —name sshcheck —rcheck —seconds 30 —hitcount 2 -j DROP
Итого.
Злоумышленику придётся подбирать пароль в следующих условиях – максимум 3 попытки за 5 минут, иначе бан на 1 час. Итого в сутки можно попробовать максимум 864 комбинаций.
Вроде кажется много… Но ваш пароль можно будет подобрать за один день простым перебором, если он состоит из трёх цифр, например. Это очень плохо и нужно использовать более сложные пароли!
Если же вы используете только цифры и пароль например из 9 цифр, то потребутся миллион дней или около 2740 лет, чтобы их все перебрать в указанных условиях.
Если вы используете ещё буквы и ещё в разном регистре, плюс спец символы, то задача становится намного сложнее.
Конечно атака может быть проведена с разных source ip-address и тогда всё становится быстрее, но для этого используются доверенные адреса, подсети вашего провайдера, например.
См. так же [Linux.wiki] Как закрыть доступ к ssh с помощью iptables.
Вот мой iptables без пояснений:
sudo iptables -A INPUT -m conntrack —ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -s 192.168.56.1/32 -p tcp —dport 2222 -j ACCEPT
sudo iptables -A INPUT -p tcp —dport 80 -j ACCEPT
sudo iptables -N BADGUY
sudo iptables -t filter -A BADGUY -i eth1 -m recent —set —name badguys -j DROP
sudo iptables -A INPUT -i eth1 -p tcp —syn —dport 2222 -m recent —name badguys —update —seconds 3600 -j DROP
sudo iptables -A INPUT -i eth1 -p tcp —syn —dport 2222 -m recent —set —name sshcheck
sudo iptables -A INPUT -i eth1 -p tcp —syn —dport 2222 -m recent —name sshcheck —rcheck —seconds 300 —hitcount 4 -j BADGUY
sudo iptables -A INPUT -i eth1 -p tcp —syn —dport 2222 -m recent —name sshcheck —rcheck —seconds 30 —hitcount 2 -j DROP
Источник
[Linux.wiki] Как закрыть доступ к ssh с помощью iptables.
Для повышения безопастности своего сервера путём ограничения доступа к вашему серверу по определённым протоколам и/или ip-address можно воспользоваться утилитой iptables.
iptables – это утилита которая предназначена для фильтрации пакетов и NAT (из man page).
iptables — administration tool for IPv4 packet filtering and NAT
С помощью iptables можно закрыть полностью или ограничить доступ, например к какому-либо TCP/UDP порту на вашем сервере, можно закрыть доступ к вашему серверу с какого-либо адреса или наоборот, разрешить доступ к какому-либо порту/протоколу только с определённого ip.
Вариантов очень много.
В данном посте я буду рассматривать работу iptables для ограничения доступа к ssh.
Если вы периодически смотрите на файл auth.log
cat /var/log/auth.log | grep sshd
,то через какое-то время после установки вашего сервера сможете заменить периодические попытки подломить ваш сервер. Лично у меня в логах фиксируются попытки подключения и подбора пароля для пользователя root с китайских ip-address.
Пользователем root подключиться к моему серверу нельзя, но кто знает, узнают ли они мой логин. Вдруг подберут или какой-нибудь backdoor найдётся в sshd.
В общем можно ограничить доступ по ssh к вашему сервер только с определённых ip-address.
Например, вы хотите иметь доступ к вашему серверу с домашнего ip-address и с рабочего. Возможно с какого-либо диапазона адресов, если у вас дома нет постоянного адреса…
Итак создаёт простой фильтр для ограничения доступа к ssh (Допустим у вас ssh слушается на стандартном порту 22):
# сбрасываем все настройки iptables:
sudo iptables -F
# открываем доступ для уже установленных соединений (или для пакетов приходящих в ответ на запросы с вашего сервера).
# В данном примере правило не нужно, но лучше его иметь всегда, чтобы не потерять доступ к серверу.
sudo iptables -A INPUT -m conntrack —ctstate RELATED,ESTABLISHED -j ACCEPT
# Открываем доступ к серверу с адреса 192.168.56.2 к TCP порту 22:
# -j ACCEPT – разрешить доступ.
sudo iptables -A INPUT -s 192.168.56.2/32 -p tcp —dport 22 -j ACCEPT
# Открываем доступ с определённого диапазона адресов. Например, с диапазона адресов вашего провайдера домашнего Интернета:
sudo iptables -A INPUT -s 172.26.0.0/16 -p tcp —dport 22 -j ACCEPT
# Закрываем доступ к порту ssh/22 с любых других адресов:
sudo iptables -A INPUT -p tcp —dport 22 -j DROP
Если у вас есть виртуальный сервер, то доступ к нему в случае какой-либо проблемы вы сможете получить через консоль.
Если доступа к консоли нет, то сервер можно просто перезагрузить в личном кабинете(обычно такая возможность есть). После перезагрузки iptables обнулятся.
Когда всё работает так как нужно и вы разобрались в iptables, то можно сделать следующее для сохранения настроек и работы iptables после перезапуска сервера:
# создаём файл в которвый будем сохранять настройки iptables и экспортируем текущие настройки туда:
sudo sh -c «iptables-save > /etc/iptables.rules»
# переходим в сетевые настройки и добаляем к настройкам нужного интерфейса комманду “pre-up iprables-restore /etc/iptables.rules” для того чтобы сетевая служба сохраняла настройки iptables в случае отключения интерфейса.
sudo vim /etc/network/interfaces
auto eth0
iface eth0 inet dhcp
post-down iptables-save > /etc/iptables.rules
pre-up iprables-restore
Итоговый результат можно посмотерть так:
server:
$ sudo iptables-save
# Generated by iptables-save v1.4.21 on Mon Jul 14 18:40:29 2014
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [41:4148]
-A INPUT -m conntrack —ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.56.2/32 -p tcp -m tcp —dport 22 -j ACCEPT
-A INPUT -s 172.26.0.0/16 -p tcp -m tcp —dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp —dport 22 -j DROP
COMMIT
или так:
server:
$ sudo iptables -L -v —line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 406 26448 ACCEPT all — any any anywhere anywhere ctstate RELATED,ESTABLISHED
2 0 0 ACCEPT tcp — any any 192.168.56.2 anywhere tcp dpt:ssh
3 0 0 ACCEPT tcp — any any 172.26.0.0/16 anywhere tcp dpt:ssh
4 0 0 DROP tcp — any any anywhere anywhere tcp dpt:ssh
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 256 packets, 24466 bytes)
num pkts bytes target prot opt in out source destination
Источник
Настройка брандмауэра для SSH в Linux
Как правило «хостер» предоставляет Вам доступ по SSH с отключенным брандмауэром — его надо включить и настроить.
Конфигурационный файл OpenSSH находится в /etc/ssh/sshd_config — для просмотра без комментариев следует выполнить команду(ы):
1. Настройка Брандмауэра (netfilter) для SSH и тырем порт
По умолчанию для SSH соединения, используется порт ТСP-порт 22. Забегая перед следует сказать, что многие рекомендует его поменять, но я так не думаю. Смена порта не поможет, «любой» сканер без труда отыщет ваш порт куда вы его не запрятали. Способ смены порта хорошо известен и Хакеры пишут соответствующие скрипты. Ниже будут приведены меры безопасности, прочитав их вы можете решить стоит ли менять порт или нет. Чтобы узнать какой порт слушает демон (sshd) на сервере, нужно выполнить команду:
Применив директиву Port поменяв значение, вы укажете демону (sshd) порт который нужно слушать;
Теперь демон (sshd) будет слушать порт 8822, для подключения к серверу, нужно воспользоваться на клиентской машине командой:
Ключ ‘-p‘ указывает порт, вместо user пишем имя пользователя, 127.0.0.1 меняем на IP своего сервера.
C портами разобрались, теперь нужно настроить брандмауэр. Можно воспользоваться средствами TUI дистрибутива.
Внимание! Будьте внимательны и последовательны в ваших действиях ! Неправильные действия могут привести к потере удалённого доступа.
Для Red-Hat based:
Нужно открыть порты (SSH) ТСP-22, UDP-22 или соответственно открыть порт который указали в директиве Port
Заходим в /Безопасность и пользователи/ Брандмауэр / Разрешённые службы — добавляем «Сервер Secure Shell», если вы указали порт директивой Port то / Брандмауэр / Разрешенные службы /Дополнительно и добавляем порт TCP и UDP .
Для «ручной настройки» следует внимательно ознакомиться с правилами iptables и настройкой брандмауэра вашего дистрибутива.
Приведу пример открытия портов простыми правилами:
Внимание ! Следует понимать, что к примеру SuSEfirewall2 генерирует правила для iptables из конфигурационного файла /etc/sysconfig/SuSEfirewall2, в каждом дистрибутиве есть свои особенности управления брандмауэром.
2. Убираем «рута» и ещё кое что
Во многих дистрибутивах доступ «суперпользователю» по SSH открыт, это не совсем безопасно. За этим следит директива PermitRootLogin , чтобы посмотреть состояние:
В примере показано, что значение директивы PermitRootLogin является no , значит что, авторизация под root -ом запрещена. Стоит отметить, в большинстве случаях когда доступ разрешён для «суперпользователя» то вывод команды:
Это значит авторизация под root возможна, следует PermitRootLogin придать значения no .
По умолчанию доступ к серверу разрешён всем пользователям. Что бы изменить ситуацию нам в помощь служат директива AllowUsers
Приведены пользователи через пробел, которым разрешён доступ.
Будет разрешён доступ пользователям у кого имя начинается на luser.
Для разрешения групп(ы) служит директива AllowGroups :
Перечислены разрешённые группы через пробел.
Таким образом мы запретили «root» и указали каким именно пользователям/группам разрешён доступ.
3. Делаем вход по ключу
Для улучшения безопасности, рекомендуется авторизация по ключам. Для генерации ключей нужно выполнить команду:
Вам будет предложено ввести защитную фразу, если вы не хотите набирать её каждый раз перед авторизацией. Можете нажать «ввод». Учтите, если кто-нибудь завладеет ключом (непубличным), то он беспрепятственно авторизуется, я рекомендую использовать защитную фразу. После генерации ключей вы обнаружите в каталоге
- id_rsa — приватный ключ, клиентская часть
- id_rsa.pub — публичный ключ для сервера
Теперь нужно перенести ключ id_rsa.pub на сервер в файл
Для корректной работы нужно на северной части добавить или изменить параметры в /etc/ssh/sshd_confi :
Для запрета авторизации по паролям, добавляем в /etc/ssh/sshd_confi :
Будете внимательны, проверьте конфигурации, для вступления изменений в силу нужно сделать рестарт службы(демона) sshd :
4. Защита SSH
Для защиты от перебора пароля и назойливых «брутфорсеров», можно и нужно использовать denyhostdenyhosts ;
Для Red-Hat based:
После установки denyhost и запуска, все надоевшие клиенты будут посылаться в /etc/hosts.deny блокироваться.
Следует занести свой IP в файл /etc/hosts.allow — разрешённые адреса.
5. Советы для админов
/bin туда будем складывать скрипты :
Убеждаемся что в вашем профиле bash, переменная PATH содержит
Пишем скрипт, делаем исполняемым:
Теперь можем набрав gosrv.sh подключаться к серверу.
Как делать sudo это баян, расскажу как сделать автодополнение после sudo. Вставляем в
Источник
