Несколько правил по защите доступ к ssh серверу.

1. Добавляем в конфигурацию ssh сервера слушать еще один порт, помимо стандартного. (Для простоты запоминания можно использовать 4 повторяющихся цифры для всех своих серверов).

$ sudo vi /etc/ssh/sshd_config Port 22 Port xxxx

2. Ограничиваем обращения на 22 порт только доверенным ip адресам *например 8.8.8.8 (таких правил сделать можно несколько, работа/дом)

$ sudo vi /etc/sysconfig/iptables -A INPUT -s 8.8.8.8 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

3. Не забываем проверить не используется ли у нас ipv6, если используется, то закрываем лишнее

$ sudo vi /etc/sysconfig/ip6tables *filter:INPUT ACCEPT :FORWARD ACCEPT :OUTPUT ACCEPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p ipv6-icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A INPUT -j REJECT --reject-with icmp6-adm-prohibited -A FORWARD -j REJECT --reject-with icmp6-adm-prohibited COMMIT

Для того, чтобы использовать ssh только на определенном адресе достаточно в файле конфигурации sshd_config указать парметр ListenAddress (например ListenAddress 74.125.200.100). В таком случае ssh будет доступен только на этом адресе и не будет работать через ipv6

4. Используем файл конфигурация ssh на стороне клиента.

Расположение: ~/.ssh/config

# fix Write failed: broken pipe ServerAliveInterval 120 TCPKeepAlive no # для использования коротких имен Host dev-vps # ip адрес или публичное доменное имя хоста Hostname 127.0.0.3 # Под каким юзером осуществлять вход User developer # Файл ключа для авторизации (если используется) IdentityFile ~/.ssh/id_rsa.dev

И еще один пример использования файла конфигурации:
{<1>}

Host ssh-server-1 Hostname 1.2.3.4 User dev Port 1234 Host ssh-server-2 User root # Hostname 192.168.10.20 # nc without -q0 if RHEL based & with -q0 debian based IdentityFile ~/.ssh/id_rsa.work-pc ProxyCommand ssh -q0 ssh-server-1 nc -q0 192.168.10.20 22

И теперь при подключении на ssh-server-1 мы сразу прыгнем на нужны нам хост. (Удобно использовать например при разных ключах на серверах)

А так-же хипстерский прокси вариант:

{<2>}

Скачиваем клиент ngrok на сервер, который находится за файерволом. Запускаем бинарник и указываем какой порт нам нужно пробросить

Secure Shell можно найти повсюду. С момента выпуска в 1995 году, SSH получил широкое распространение как мощный протокол удаленного доступа для Linux.

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

1. Отключаем root логин.

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

Найдем /etc/ssh/sshd_config (возможно он находиться в другом каталоге, это зависит от дистрибутива). В нем определим место PermitRootLogin и заменим значение на "no":

PermitRootLogin no

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

Прочитав все выше написанное и реализовав на практике, мы в результате получим ключи для авторизации на сервере. Убедившись, что все работает, можно запретить интерактивный ввод:

PasswordAuthentication no
ChallengeResponseAuthentication no

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

Europa ~ # emerge -pv denyhosts
These are the packages that would be merged, in order:
Calculating dependencies... done!
app-admin/denyhosts-2.5 0 kB
Total size of downloads: 0 kB
europa ~ # emerge denyhosts

Документации по программе не очень много (если чего - есть, например ), однако все опции конфигурирования нормально описаны в конфигурационном файле.

Europa $ nano -w /etc/denyhosts.conf

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

После конфигурирования можно запустить программу демоном или через шедулер. В Gentoo демоном:

Rc-update add denyhosts default

Через cron, скажем каждые 10 минут:

Python /usr/bin/denyhosts -c /etc/denyhosts.conf

Вся радость DenyHost не только в блокировании хостов, пытающихся пробиться к вашему SSH серверу, но и в том, что можно синхронизировать свой "черный список" с серверами DenyHost. Таким образом создается коллективный список хостов, содержащий всех нападающих. Он предотвратит нападение в самом корне.

4. Изменяем номер порта.

Большинство попыток взлома идет от автоматических скриптов, сканирующих сеть на наличие SSH демонов. В подавляющем количестве случаев они пытаются вломиться на 22 порт, что только играет нам на руку. Изменив порт мы автоматически отсечем большинство попыток несанкционированного доступа.

В конфиге стоит поменять.

Стоит «засветиться» сервису в общедоступной сети, как мгновенной он становится объектом для атаки. Одна из проблем – попытка получения доступа с помощью перебора паролей (брутфорса). И SSH в данном случае не исключение.

Анализ файла логов аутентификации /var/log/auth.log или аналогов показывает, что попытка подбора пароля обычно производится сразу с нескольких IP и растянута по времени.

Защита от Брутфорса SSH

Защититься от этого можно по-разному:

• Используя возможности настройки демона SSH
• Пакетный фильтр
• Специальные приложения
• Port knocking

Самый простой и действенный способ – это изменить 22-й порт, используемый по умолчанию, например, на 2002-й, если это не мешает другим задачам. Вносим запись в /etc/ssh/sshd_config:

После этого попытки подбора паролей практически прекращаются. Бывают случаи, когда изменить порт нельзя. Как вариант, можно ограничить доступ по SSH определенным пользователям (в частности, root) или группе. В sshd_config за это отвечает ряд параметров: AllowUsers, AllowGroups, DenyUsers и DenyGroups. Удобно, что с логином можно указать IP или подсеть. Например, разрешим доступ пользователю admin и user, последнему только с одного IP:

Еще один действенный вариант защиты от перебора – использование для аутентификации сертификатов. Причем с помощью специального параметра match можно создать условный блок, в котором переопределить параметры глобальной секции. Например, запретим вход по SSH по паролю для пользователя root, разрешив всем остальным:

# всем разрешаем доступ по паролю
PasswordAuthentication yes
# root будет использовать только сертификат
match user root
PasswordAuthentication no
KbdInteractiveAuthentication no

Используя TCP Wrapper, также можем ограничить доступ к любому сервису только с определенных IP, для этого следует лишь прописать в файл /etc/hosts.allow или /etc/hosts.deny нужное правило. Разрешим в /etc/hosts.allow доступ только с нужной подсети:

sshd: 192.168.1.0/24: allow

Или в /etc/hosts.deny:

sshd: ALL: deny
sshd: ALL EXCEPT 192.168.1.0/24: allow

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

iptables -A INPUT -s !192.168.0.1 -p tcp -m tcp --dport 22 ↵
-j REJECT -reject-with icmp-port-unreachable

Фильтрация пакетов по портам и IP-адресам не очень эффективна, если Aдмин не привязан к рабочему месту. В этом случае помогут специальные утилиты: Fail2ban , Sshguard . Fail2ban изначально разрабатывался для защиты SSH. Хотя сегодня это уже фреймворк, который можно легко настроить под любые приложения. Принцип работы очень прост. Демон периодически проверяет журналы на наличие записей о любых подозрительных действиях. Затем подозрительный IP-адрес блокируется средствами iptables или TCP Wrapper. Через указанное в настройках время блокировка обычно снимается, чтобы случайно не заблокировать легальный узел. При срабатывании правила записывается событие в журнал /var/log/fail2ban.log, и может быть отправлен email.

Один процесс может контролировать сразу несколько сервисов, а в пакете поставляются готовые настройки для популярных приложений Linux. В настройках по умолчанию защищается только SSH.

В Ubuntu и Debian устанавливается командой:

$ sudo apt-get install fail2ban

Все настройки производятся в нескольких файлах, размещенных в каталоге /etc/fail2ban. В fail2ban.conf хранятся параметры запуска самого демона, в jail.conf описываются контролируемые сервисы (внутри секции SSH).

Enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

Фильтры и действия прописываются в файлах, размещенных в подкаталогах filter.d и action.d. По умолчанию все файлы имеют расширение.conf, их лучше не трогать (в т.ч. и jail.conf). Все изменения следует заносить в файл с расширением.local (например, jail.local), параметры которого замещают установки из первого, а при обновлении не будут потеряны. Для проверки работы фильтра можно использовать утилиту fail2ban-regex.

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

Конфигурационные файлы

• /etc/ssh/sshd_config - файл конфигурации сервера OpenSSH;
• /etc/ssh/ssh_config - файл конфигурации клиентской части OpenSSH;
• ~/.ssh/ - директория, в которой хранятся пользовательские SSH настройки;
• ~/.ssh/authorized_keys или ~/.ssh/authorized_keys - список ключей (RSA или DSA), которые используются для подключения к пользовательским аккаунтам;
• /etc/nologin - если данный файл существует в системе, то sshd запретит подключаться всем пользователям кроме root в систему;
• /etc/hosts.allow и /etc/hosts.deny - система запрета (часть безопасности). Работает по аналогии с ACL;
• SSH порт по умолчанию - 22

Не нужен - выключай

Если вашему серверу не требуется удаленное подключение по SSH, то обязательно отключите его. В таких системах как CentOS/RHEL делается это так:

Chkconfig sshd off yum erase openssh-server

Используйте SSH второй версии

Протокол SSH первой версии имеет проблемы с безопасностью, которые закрыты во второй версии. Поэтому, используйте вторую версию. Убедитесь, что в файле /etc/ssh/sshd_config указана опция Protocol 2 .

Ограничивайте SSH доступ

По умолчанию, все системные пользователи имеют возможность подключаться к системе по SSH. Рекомендуем ограничить SSH доступ в целях безопасности. Например, разрешить SSH для пользователей root, merion и networks:

AllowUsers root merion networks

С другой стороны, вы можете разрешить доступ всем пользователям, кроме указанных:

DenyUsers root merion networks

Время неактивности

Важно указывать время, в течение которого, неактивная сессия будет терминирована (завершена). Это можно сделать следующими опциями:

ClientAliveInterval 300 ClientAliveCountMax 0

В данной настройке мы указали время бездействия равным 300 секунд (5 минут).

Про файлы.rhosts

Дело в том, что данный файл содержит список хостов и пользователей. Если в данном файле содержится комбинация хоста и юзера, то данный пользователь сможет подключиться к системе по SSH без запроса пароля. Рекомендуем отключить эту «замечательную» фичу:

IgnoreRhosts yes

Никакой аутентификации на базе хоста!

Так называемая Host-Based Authentication позволяет пользователю с определенного хоста подключаться к серверу. Отключаем:

HostbasedAuthentication no

Прямое подключение через root

PermitRootLogin no

Сделайте баннер

Для каждого подключающегося сделайте баннер, в котором можно угрожать злоумышленникам, которые пытаются совершить несанкционированный доступ. За настройку баннера отвечает параметр Banner .

22 порт только изнутри!

Сделайте доступ к 22 порту системы только через цепочку фаервол правил. Лучше всего, оставить доступ только изнутри LAN. Например, в Iptables можно дать доступ для 192.168.11.0/24:

A RH-Firewall-1-INPUT -s 192.168.11.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT

Где слушать

По умолчанию SSH слушает подключения на всех доступных интерфейсах. Мы рекомендуем сменить порт по умолчанию и указать IP – адрес, на котором необходимо ожидать подключения. Например, мы укажем порт 962 и IP – адрес 192.168.11.24

Port 962 ListenAddress 192.168.11.24

Криптостойкие пароли

Используйте устойчивые к защите пароли. В сети множество инструментов, которые сгенерируют криптостойкий пароль онлайн, бесплатно и без смс:)

Запретить пустые пароли

Бывают пользователи без паролей. Их доступ к SSH так же необходимо запретить с помощью опции:

Port 962 PermitEmptyPasswords no

Анализируйте логи

Установите логирование событий в режим INFO или DEBUG – это позволит иметь расширенный контроль над системой:

LogLevel INFO

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас:(Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

В этой короткой заметке я собрал воедино способы повышения защищённости ssh сервера. Описаны самые основные и простые в исполнении приёмы, а более сложные лишь указаны для интересующихся читателей

Основные приёмы

Все действия производятся в конфигурационном файле sshd демона -- /etc/ssh/sshd_config . Ниже приведу часть своего конфигурационного файла с комментариями.

### Network ### # Используем нестандартный порт (>1024) port 5679 # Используем только IPv4 соединения # inet = IPv4, inet6 = IPv6, any = both AddressFamily inet # Можно принимать соединения только с определённых IP-адресов #ListenAddress 0.0.0.0 # Используем вторую версию протокола, т.к. первая подвержена # известным уязвимостям Protocol 2 # Отключаем перенаправление графики (X-сервер) до тех пор # пока она явно не понадобится вам X11Forwarding no # Отключаем Disable TCPKeepAlive и используем ClientAliveInterval вместо этого, # чтобы предотвратить атаки типа TCP Spoofing TCPKeepAlive no # Выкидваем пользователя через 10min (600 sec) неактивности ClientAliveInterval 600 ClientAliveCountMax 3 ### Key configuration files ### # HostKeys для протокола версии 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # Используем непривилегированный процесс для # обработки входящего от клиента трафика # sandbox - openSSH >= 5.9 ("yes" - для младших версий) UsePrivilegeSeparation sandbox # При изменении этих значений, требует удалить старый ключ # /etc/ssh/ssh_host_rsa_key{,.pub}, и создать новый # путём перезапуска sshd. # # Время жизни ключа, т.е. через какое время будет сгененрирован новый ключ # в случае, если предыдущий был использован. KeyRegenerationInterval 1h # сила ключа ServerKeyBits 2048 # Разрешаем авторизацию по публичному ключу PubkeyAuthentication yes # Место хранения доверенных ключей в каталоге пользователя AuthorizedKeysFile .ssh/authorized_keys ### Logging ### # Префикс для syslog SyslogFacility AUTH # уровень подробности сообщений для самого sshd LogLevel INFO ### Authentication ### # список разрешённых пользователей AllowUsers ivan # ограничиваем время для ввода пароля для ssh-ключа LoginGraceTime 30s # запрещаем удалённо входить под учётной записью root PermitRootLogin no # Включаем явную проверку прав файлов и директорий с ssh-ключами StrictModes yes # Сколько раз переспрашивать пароль при неверном вводе MaxAuthTries 3 # Запрещаем вход по пустому паролю PermitEmptyPasswords no # Запрещаем вход по паролю в принципе # (Используем публичный/приватный ключ вместо этого) PasswordAuthentication no # Отключаем использование "challenge-responce" авторизацию, # т.к. она бесполезна при использовании ключей ChallengeResponseAuthentication no # Так как мы не используем пароль, то и {PAM, login(1)} нам не нужены UsePAM no UseLogin no # Позволяем клиенту передавать лишь определённый набор переменных окружения # RH BZ#CVE-2014-2532 # ShellShock exploit AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT AcceptEnv LC_IDENTIFICATION LC_ALL

Это те параметры, что настраиваются в конфигурационном файле sshd. После изменения настроек требуется перезапустить сервис sshd.

Комментарии

• При использовании авторизации по ключу, ключ требуется предварительно сгенерировать на клиентской машине и скопировать публичный ключ на сервер. Пример:

client $ ssh-keygen client $ cat ~/.ssh/id_rsa.pub | ssh -p 5679 [email protected] "cat >> ~/.ssh/authorized_keys"

• В файле /var/log/auth.log будут находиться сообщения от sshd . В случае, если этот файл отсутствует, вам требуется настроить вашу систему логирования. пример для syslog и syslon-ng . Я использую syslog-ng , и мне потребовалось добавить следующие строки в файл /etc/syslog-ng/syslog-ng.conf:

destination authlog { file("/var/log/auth.log"); }; log { source(src); destination(authlog); };

и перезапустить сервис syslog-ng .

• При использовании нестандартного порта может потребоваться настроить ваш firewall (iptables, firewalld, etc).
  Пример настройки для iptables:

root# iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 5679 -j ACCEPT root# service iptables save root# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED tcp dpt:5679 ...

Если этого мало

Это лишь базовые настройки. Дополнительно можно настроить

• firewall (iptables)