LINUX.ORG.RU
ФорумAdmin

Настройка iptables

 , ,


0

1

Доброго времени суток.

Есть задача ограничить на сервере доступ до ssh (чтобы извне не был виден открытый 22 порт), кроме одного IP-клиента.

Но в то же время этот сервер будет использоваться как выход в интернет для клиента через ssh-туннель.

У меня получилось закрыть ssh, добавив разрешающее правило и запрет на всё остальное, но тогда и интернет не работает у клиента через сервер.

iptables -A INPUT -p tcp –dport 22 –source x.x.x.x -j ACCEPT iptables -P INPUT DROP

Как правильно будет прописать настройки чтобы у клиента появился интернет? Просто открыть range портов остальных?

Выход в инет через forward

anonymous ()

Изначально так и должно быть, это штатный режим работы iptables, ведь Вы забыли добавить самое главное правило:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Чтобы обновить правила через скрипт, сначала необходимо их полностью сбросить, после указать в строго определённом порядке(важно!):

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp –dport 22 –source x.x.x.x -j ACCEPT
iptables -P INPUT DROP

Выход в Интернет через SSH должен всегда работать, если он доступен на самой машине локально, так как пакеты идут через 127.0.0.1

Да, важное уточнение по поводу DROP\REJECT - первый попросту не отвечает неавторизованному клиенту, тогда как второй посылает явный сигнал о невозможности установить соединение.

Соответственно, первое лучше, если у вас небольшой сервер и вы хотите защитить его от сканирования. Второе лучше, если у вас высоконагруженный сервер, поскольку намного лучше защищает от DoS(клиент не будет пытаться несколько раз установить соединение).

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

поскольку намного лучше защищает от DoS(клиент не будет пытаться несколько раз установить соединение).

IMHO, все строго наоборот. DoS - это не перегрузка сети, это направленная атака на конкретный сервер. И тратя ресурсы на ответы на флудовые пакеты, Вы просто помогаете организаторам атаки положить Ваш сервер.

Выход в Интернет через SSH должен всегда работать, если он доступен на самой машине локально, так как пакеты идут через 127.0.0.1

Насколько я понял, речь идет об использовании данной машины в качестве шлюза для клиентов по ту сторону ssh-туннеля. А значит, цепочка INPUT никакого отношения к этому не имеет - тут нужно в FORWARD правила добавлять, как выше уже написали.

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

Насколько я понял, речь идет об использовании данной машины в качестве шлюза для клиентов по ту сторону ssh-туннеля

Но в то же время этот сервер будет использоваться как выход в интернет для клиента через ssh-туннель.

Кажется, ТС именно пытается сделать аналог приватного прокси-сервера. Ну да ладно, сам ответит когда-нибудь. Эти правила, кстати, я не поленился только что протестировать на локалхосте. Всё идеально работает.

IMHO, все строго наоборот. DoS - это не перегрузка сети, это направленная атака на конкретный сервер. И тратя ресурсы на ответы на флудовые пакеты, Вы просто помогаете организаторам атаки положить Ваш сервер.

Это довольно старый спор, однозначного универсального решения тут на деле-то и не существует. Но КМК(исхожу из собственного «боевого» опыта) именно при такой целенаправленной атаке ставится задача повесить сеть жертвы, так как один компьютер едва ли сможет «положить», к примеру, ЦПУ сервера-жертвы.

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

Вот чтобы от серьёзных атак защищаться исключительно с помощью iptables - надо быть отчаянным. Ну да речь не о том.

SM5T001 ()
Ответ на: комментарий от Serge10

IMHO, все строго наоборот. DoS - это не перегрузка сети, это направленная атака на конкретный сервер.

DoS это Denial of Service а каким образом реализовано роли не играет, один из вариантов DoS загадить вашу полосу.

И тратя ресурсы на ответы на флудовые пакеты, Вы просто помогаете организаторам атаки положить Ваш сервер.

А вот тут вы правы, если и так зафлудили, да мы ещё отвечать начнем, сами себе «закакиваем» полосу.
Про REJECT. Сам и не попадал, но вроде слышал по ОБС про истории успеха как раз с REJECT когда бот отваливает после получения ответа. Но ОБС на то и ОБС. Из личной практики только DROP и спасал.

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

Насколько я понял, речь идет об использовании данной машины в качестве шлюза для клиентов по ту сторону ssh-туннеля. А значит, цепочка INPUT никакого отношения к этому не имеет - тут нужно в FORWARD правила добавлять, как выше уже написали.

Вы правы что пакеты в туннеле (если только случайно ТС не обозвал туннелем socks, такое тоже бывает) пойдут через цепочку FORWARD. Но и замечания SM5T001 в части правил в INPUT так же верны, одно не заменяет другого.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 2)
Ответ на: комментарий от SM5T001

так как один компьютер едва ли сможет «положить», к примеру, ЦПУ сервера-жертвы.

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

Насколько я понимаю, DoS обычно устраивают через бот-сети. Забить канал и (или) CPU сервера с одного клиента, IMHO, нереально.

И Вы, конечно, правы в том, что радикально решить проблему DoS с помощью iptables нереально.

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

И Вы, конечно, правы в том, что радикально решить проблему DoS с помощью iptables нереально.

Для DDoS у меня были истории успеха, DDoS на dns который был на низкоскоростном канале, ipables спас на все 100%.

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