Настройка iptables

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

Изначально так и должно быть, это штатный режим работы 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(клиент не будет пытаться несколько раз установить соединение).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо, работает как надо.

p.s. да, имел в виду ssh -D

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

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

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

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

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

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