LINUX.ORG.RU

Защита ssh и nginx на одном порту средствами iptables

 , ,


2

4

Приветствую Вас, друзья.

В связи с публикацией средств шпионажа ЦРУ вспомнил о совей впс-ке: надо что-то делать с фаерволом. Руки никак не доходили, а там у меня караул.

На 443 порту крутится sslh, который перебрасывает соединения на ssh и nginx. Хочу средствами iptables сделать эффективную защиту ssh от назойливых переборщиков паролей (вход root сделан по сертификату, но есть и обычный пользователь с паролем, на случай отсутствия при себе сертификата). Временно фаервол настраивается так (выдержка):

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

iptables -I INPUT -p tcp -m osf --genre NMAP -j DROP
iptables -A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -m hashlimit --hashlimit 1/hour --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name SSH --hashlimit-htable-expire 300000 -j ACCEPT
При такой настройке www.ssllabs.com пишет, что не может достучаться до сервера. Прошу Вас подсказать правила, при которых не пострадает доступ к http(s).

★★

Здесь не надо иптаблесами, иначе будешь отбивать легальных юзеров вебни, сидящих за общим НАТом, например. Или вообще отбивать юзера, у которого просто браузер открыл три коннекта для скорости. Здесь надо подключать анализатор лога sshd на предмет неудачных попыток входа. Глянь в сторону fail2ban.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)

sslh мультиплексирует вход на два выхода
чтобы ограничить ssh и не ограничивать https ставь хэшлимиты в айпитэйблс на тот порт куда sslh прокидывает ssh протокол, то есть где у тебя слушает sshd.

imul ★★★★★
()
Ответ на: комментарий от thesis

fail2ban мне не знаком, придётся разбираться с нуля. С iptables относительно разобрался, хотел бы его использовать.

rmu ★★
() автор топика
Ответ на: комментарий от imul

В этом случае все, кто стучится на ssh, будут иметь ip 127.1, я пробовал. То есть, если кто-то левый будет стучаться в ssh, то и я не смогу войти.

rmu ★★
() автор топика
Ответ на: комментарий от imul

С Layer 7, видимо, ещё больше повозиться придётся, чем с fail2ban. Я ожидаю более простого в исполнении совета от опытного админа.

rmu ★★
() автор топика

Может быть есть возможность организовать простую двухфакторную аутентификацию, как это советует вики Fail2Ban?

rmu ★★
() автор топика
Ответ на: комментарий от rmu

Фейл2бан тебе точно также отрубит оба протокола. С fail2ban+L7 будет возможность отрубать только один. А так сделай очень длинный у надёжный пароль и не парься.

imul ★★★★★
()
Ответ на: комментарий от imul

Длинный пароль, который я не запомню, мне не подходит. Мне нужно сохранить доступ, даже когда нет своего компьютера под рукой. Для этого и нужен хороший фильтр.

Если бы sslh мог сохранять оригинальный ip у соединения - это бы решило задачу.

rmu ★★
() автор топика
Ответ на: комментарий от rmu

У sslh есть параметр --transparent, может быть это то, что мне нужно. Ушёл разбираться.

rmu ★★
() автор топика
Ответ на: комментарий от rmu

сделай ключи и таскай с собой на флэшке.

Iron_Bug ★★★★★
()
Ответ на: комментарий от imul

Фейл2бан тебе точно также отрубит оба протокола

Да и хрен с ними, что ж поделаешь.

thesis ★★★★★
()
Ответ на: комментарий от rmu

Я ожидаю более простого в исполнении совета от опытного админа.

Держи два:
1) Не шарить порт между демонами.
2) Прицепить вебшелл.

thesis ★★★★★
()

Конечно README ведь читать не принято.
С него:

Fail2ban

If using transparent proxying, just use the standard ssh rules. If you can't or don't want to use transparent proxying, you can set fail2ban rules to block repeated ssh connections from an IP address (obviously this depends on the site, there might be legitimate reasons you would get many connections to ssh from the same IP address...)

See example files in scripts/fail2ban.

# Add the following to your fail2ban jail.conf
# In Debian you'd append it to /etc/fail2ban/jail.local

[sslh-ssh]
enabled = true
filter = sslh-ssh
action = iptables-multiport[name=sslh,port="443"]
logpath = /var/log/messages
maxretry = 5
# Add the following to you fail2ban configuration file
# In Debian it'd go in /etc/fail2ban/filter.d/sslh-ssh.conf


# Fail2Ban filter for sslh demultiplexed ssh
#
# Doesn't (and cannot) detect auth errors,
# but many connection attempts from the same
# origin is reason enough to block.
#
# Verion: 2014-03-28

[INCLUDES]

# no includes

[Definition]

failregex = ^.+ sslh\[.+\]: connection from <HOST>:.+ to .+ forwarded
from .+ to .+:ssh\s*$

ignoreregex =

# Author: Evert Mouw <post@evert.net>
anonymous_sama ★★★★★
()
Ответ на: комментарий от flakka

Провёл сканирование с как с этой командой, так и без неё. Вывод nmap с параметрами O или A одинаковый. Задумался зачем это вообще нужно?

rmu ★★
() автор топика
Ответ на: комментарий от rmu

Длинный пароль, который я не запомню, мне не подходит

Авчемсл0жн0стьсделатьдлинныйзапоминающийсяgfhjkm?

anonymous
()
Ответ на: комментарий от rmu

Попробуй загрузить список сигнатур (брать их здесь) загружать так:

nfnl_osf -f /pathTo/pf.os

Или можешь попробовать модуль psd:

apt install -y xtables-addons-common
iptables -A INPUT -m psd -j DROP

flakka
()

А зачем тебе вообще sslh ?

Настраиваешь в веб-сервере ForwardProxy на localhost:22 и только на него и вперёд. Авторизацию по ключу, fail2ban настраиваешь, чтобы если коннект к SSH с локалноста, то ИП искал в апачевых логах. Ну и на 403 тоже. Всё, доступ будет как через 80/443 так и через 22 порт, если веб-сервер рухнет.

Или nginx не умеет HTTP CONNECT?

Stanson ★★★★★
()
Ответ на: комментарий от flakka

Задача вполне понятная: на 443 порту и ссш и хттпс, ссш нужно защитить, хттпс не должен пострадать.

Поясните, как будут использоваться сигнатуры?

rmu ★★
() автор топика
Ответ на: комментарий от rmu

Модулю который ты используешь (osf) нужны сигнатуры для детекта. По дефолту они на фряхе здесь: /etc/pf.os (если не ошибаюсь) а на debian/ubuntu их вообще нет поэтому возникло предположение что на дистрибутивах linux их нужно самому ручками подключить с сайта чтобы модуль корректно работал.

flakka
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.