iptables защита от исходящего спама

[demsl]

подскажите пожалуйста, можно ли с помощью файерволла защититься от потенциальных спам-ботов в локалке? пользователи выходят в нет через ubuntu-шлюз с postfix.
что-то вроде
iptables -A FORWARD -p tcp -s $внутренний_IP_шлюза --dport 25 -j ACCEPT
iptables -A FORWARD -p tcp --dport 25 -j DROP

или это решается сугубо настройкой постфикса?

[arkhnchul]

только постфикса. файрвол только разрешает/запрещает коннекты на порт.

[MrClon]

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

[demsl]

да и в конторе со своей почтой это вполне допустимый вариант

вот как раз у меня контора со своей почтой)

Можно блокировать пользователю соединения по 25-у порту если он попытается открыть одновременно более n соединений по этому самому порту (спам-боты как правило так и делают на сколько я знаю).

а как это сделать технически?

[MrClon]

Можно блокировать пользователю соединения по 25-у порту если он попытается открыть одновременно более n соединений по этому самому порту (спам-боты как правило так и делают на сколько я знаю).

а как это сделать технически?

Не знаю, не интересовался. Но можно, правда возможно не силами iptables, а силами например фряшного фаервола.

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

[arkhnchul]

можно закрыть изнутри 25 порт, и DNAT-ом какой-нибудь другой натить на 25 постового сервера. Боты на 25 лазят в основном, а не пытаются искать, где там висит сервер.

а как это сделать технически?

connlimit в iptables.

[Ленивая Бестолочь]

можно все соединения на 25й порт переадресовывать на ваш почтовый сервер. на котором держать очень зверскую резалку спама.
таки образом почта будет отправляться прозрачно для пользователей (пользователь будет думать, что шлёт через smtp.mail.ru, а уходит через вас), а боты пройдут лесом. однако таким образом потеряете возможность отправки почты с адресов, spf записи которых установлены в жесткую политику (на практике таких мало, можно и забить на них).

[demsl]

можно все соединения на 25й порт переадресовывать на ваш почтовый сервер.

это наверно подходящий вариант. в крайнем случае - увижу, от кого спам валит в логах.

как это реализовать?

[patrius]

подскажите пожалуйста, можно ли с помощью файерволла защититься от потенциальных спам-ботов в локалке? пользователи выходят в нет через ubuntu-шлюз с postfix.
что-то вроде
iptables -A FORWARD -p tcp -s $внутренний_IP_шлюза --dport 25 -j ACCEPT
iptables -A FORWARD -p tcp --dport 25 -j DROP

или это решается сугубо настройкой постфикса?

Из данного заключаю, что со спецификой работы iptables ты знаком не сильно.
Поэтому прежде чем читать дальше Внимательно изучаем это

да и в конторе со своей почтой это вполне допустимый вариант

вот как раз у меня контора со своей почтой)

Можно блокировать пользователю соединения по 25-у порту если он попытается открыть одновременно более n соединений по этому самому порту (спам-боты как правило так и делают на сколько я знаю).

а как это сделать технически?

Присоединюсь. Жестко заблокировать возможность работы с внешними почтовыми серверами.
* вообще или только кому-то разрешить/запретить решай сам.

можно все соединения на 25й порт переадресовывать на ваш почтовый сервер.

это наверно подходящий вариант. в крайнем случае - увижу, от кого спам валит в логах.
как это реализовать?

В случае пропуска трафика iptales -j LOG

Я рекомендую таки запретить общение с наружными серверами. Таким образом решение проблемы потенциального спам бота полностью перекладывается на postfix. В котором, например, можно запретить отсылку более 10и сообщений в час.

[demsl]

Я рекомендую таки запретить общение с наружными серверами.

кому не жалко, напишите пожалуйста правило для iptables

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

[sash-kan]

что-то вроде
$ sudo iptables -I FORWARD -i <внутренний интерфейс шлюза> --dport 25 -j REJECT

-I — вставить в начало цепочки (я ведь не знаю, что у вас там написано в других правилах этой цепочки).

[Ленивая Бестолочь]

это наверно подходящий вариант. в крайнем случае - увижу, от кого спам валит в логах.

как это реализовать?

ну, если пересылать всю почту на ваш почтарь, то как-то так:
sudo iptables -t nat -I PREROUTING -p tcp -i <внутренний интерфейс шлюза> --dport 25 -j DNAT --to-destination <внутренний адрес вашего почтовика>:25

[sash-kan]

это наверно подходящий вариант. в крайнем случае - увижу, от кого спам валит в логах.

как это реализовать?

ну, если пересылать всю почту на ваш почтарь, то как-то так:
sudo iptables -t nat -I PREROUTING -p tcp -i <внутренний интерфейс шлюза> --dport 25 -j DNAT --to-destination <внутренний адрес вашего почтовика>:25

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

[patrius]

Я рекомендую таки запретить общение с наружными серверами.

кому не жалко, напишите пожалуйста правило для iptables

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

А потом мы удивляемся всяким ерундам )))
Запретить трафик от почтового клиента наружу проще ввсего строкой типа
iptables -I FORWARD 1 -p tcp --dport 25 -j DROP
Тут следует заметить, что в веб интерфейсам сие не относиться.

demsl, лично тебе советую или учить мат часть по администрированию, или менять работу по собственному, пока не поперли в шею.

[demsl]

А потом мы удивляемся всяким ерундам )))
Запретить трафик от почтового клиента наружу проще ввсего строкой типа
iptables -I FORWARD 1 -p tcp --dport 25 -j DROP
Тут следует заметить, что в веб интерфейсам сие не относиться.

demsl, лично тебе советую или учить мат часть по администрированию, или менять работу по собственному, пока не поперли в шею.

в моём первом посте:

iptables -A FORWARD -p tcp --dport 25 -j DROP

и это человек говорит мне

Из данного заключаю, что со спецификой работы iptables ты знаком не сильно.

ps отличие -I и -A мне понятно

offtop: мы с Вами брудершафт не пили, а для советов о смене работы у Вас инфы недостаточно)



Ленивая Бестолочь, sudo iptables -t nat -I PREROUTING -p tcp -i <внутренний интерфейс шлюза> --dport 25 -j DNAT --to-destination <внутренний адрес вашего почтовика>:25

если <внутренний интерфейс шлюза> = <внутренний адрес вашего почтовика>, правило такое же?

[Ленивая Бестолочь]

если провайдером клиенту выдана инструкция: используйте такой-то сервер для отсылки, значит, на 25-й порт вовне будут стучаться либо вирусы/трояны/боты, либо те, кто инструкций не читает.

ну Саша, ты идеалист. имхо это уже вопрос религии - переделывать iptables на шлюзе или мозг тем, кто не читает инструкции ;-)

если <внутренний интерфейс шлюза> = <внутренний адрес вашего почтовика>, правило такое же?

угумс, можно такое же.

[KiWi]

это наверно подходящий вариант. в крайнем случае - увижу, от кого спам валит в логах.

как это реализовать?

ну, если пересылать всю почту на ваш почтарь, то как-то так:
sudo iptables -t nat -I PREROUTING -p tcp -i <внутренний интерфейс шлюза> --dport 25 -j DNAT --to-destination <внутренний адрес вашего почтовика>:25

+ SNAT нужен.

[javasc]

+ SNAT нужен.

iptables -t nat -A POSTROUTING -s ip_адрес -j SNAT --to-source ip_адрес

[sash-kan]

ну Саша, ты идеалист. имхо это уже вопрос религии - переделывать iptables на шлюзе или мозг тем, кто не читает инструкции

я реалист. и если слегка задуматься и прикинуть варианты, то можно убедиться, что выбора «кого именно переделывать« просто нет.
итак, карты на стол.
мы запрещаем клиентам выход на 25-й порт вовне и побуждаем их пользоваться нашим смартхостом.
вопрос: заворачивать исходящий smtp-трафик на наш смартхост или не заворачивать?
разделим тех, кто будет стучаться во внешний мир на две условные категории: «ботнеты» и «тормоза».
1. «ботнеты». есть ли смысл облегчать им жизнь и попутно создавать проблемы себе? проблемы две:
1.1. повышение нагрузки на сервер, вычисляющий спам.
1.2. затраты времени (на вычистку из б.л.) и увеличение недовольства клиентов при попадания смартхоста в блэклисты, когда удачливый ботнет «пробьёт» наш спам-фильтр.
2. «тормоза». в подавляющем большинстве случаев они пользовались каким-нибудь транзитным smtp-сервером (mail.ru, ya.ru, yahoo.com и т.д. и т.п.) с авторизацией. но я рассмотрю и вариант, когда клиент без авторизации стучался на конечные smtp-серверы (в голову приходит только какой-нибудь быдло-офисный гейт). наш смартхост может быть настроен в двух вариантах: с авторизацией и без (с авторизацией — случай, imho, уникальный, но я не буду сбрасывать и его со счёта). итого получаем четыре варианта:
2.1. и смартхост и целевой smtp — с авторизацией. понятно, что логин/пароль не сойдутся и клиент обломается.
2.2. смартхост с авторизацейе, целевой smtp — без. облом у клиента.
2.3. смартхост без авторизации, целевой smtp — с авторизацией. насколько я понимаю тонкости протокола smtp, клиент опять-таки обломается.
2.4. и смартхост и целевой smtp — без авторизации. ура! кажется, в этом (imho, достаточно редком случае), клиент успешно отправит письмо. порадуемся же за него!

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

я не прав?

p.s. что-то мне подсказывает, что вариант 2.4. тоже не всегда прокатит. smtp-сервер ведь представляется. и mua, увидев, что приветствие исходит не от того сервера, куда он стучится, может и «поворотить нос». тут, видимо, уже от mua зависит.

[sash-kan]

и ещё добавка для «нелюбителей» клиентов:
не делайте drop. делайте reject. это же ваши клиенты.

[Ленивая Бестолочь]

2.3. смартхост без авторизации, целевой smtp — с авторизацией. насколько я понимаю тонкости протокола smtp, клиент опять-таки обломается.

ну вот тут ты не прав как раз.
"целевой smtp" в процессе обмена почтой учавствовать не будет вообще.
то бишь. например шлёт vasya@firma.ru письмо на petya@mail.ru.
раньше слал он через smtp.firma.ru, который просил пароль.
а теперь письмо будет перехватывать smtp.nash-isp.ru и доставлять его на smtp.mail.ru.
smtp.firma.ru проезжает мимо всего процесса доставки.

p.s. что-то мне подсказывает, что вариант 2.4. тоже не всегда прокатит. smtp-сервер ведь представляется. и mua, увидев, что приветствие исходит не от того сервера, куда он стучится, может и «поворотить нос». тут, видимо, уже от mua зависит.

да не должен. только если с авторизацией не напортачить.
самая проблема может быть в том, что если клиент будет хотеть авторизацию надо с ним мяхше. :-)
а не говорить ему - пароль не правильный иди нафиг. никаких нафиг, иди к нам сюда :-)
ещё есть микроскопическое кол-во граждан к сертификатами.

1. «ботнеты». есть ли смысл облегчать им жизнь и попутно создавать проблемы себе? проблемы две:
1.1. повышение нагрузки на сервер, вычисляющий спам.
1.2. затраты времени (на вычистку из б.л.) и увеличение недовольства клиентов при попадания смартхоста в блэклисты, когда удачливый ботнет «пробьёт» наш спам-фильтр.

ну да, да, конечно так оно и есть. вопрос в том, насколько человек доверяет своему фильтру. может быть у них покупная приблуда кака-нибудь. или просто всё крайне жестоко настрено. я не обещал, что будет легко ;)
но в любом случае - перед этим делом спамфильтр надо настроить очень хорошо, т.к. появляется шанс попасть в блеклисты.

+ SNAT нужен.

да, спасибо, точно.

[demsl]

итог -
iptables -A FORWARD -p tcp --dport 25 -j REJECT ?

[sash-kan]

ну вот тут ты не прав как раз.
"целевой smtp" в процессе обмена почтой учавствовать не будет вообще.
то бишь. например шлёт vasya@firma.ru письмо на petya@mail.ru.
раньше слал он через smtp.firma.ru, который просил пароль.
а теперь письмо будет перехватывать smtp.nash-isp.ru и доставлять его на smtp.mail.ru.
smtp.firma.ru проезжает мимо всего процесса доставки.

вот тут я как раз прав. по результатам теста.
тестовый mua — штатный thunderbird из какой-то там последней убунты. тестовый mta — вероятно, какой-то postfix, небось, красношапочный.
сервер не требует авторизации, в mua проставлено «авторизоваться». mua: «не удалось бла-бла-бла».

p.s. в обыкновенной провайдерской сети подавляющее (грубо и жестоко подавляющее) количество соединений на 25-й порт будет от «ботнетов». ещё раз повторюсь другими словами: выбор не между "будем/не будем чуть облегчать жизнь «тормозам»", а "будем/не будем создавать себе море проблем и облегчать жизнь ботнетам". впрочем, конечено, «каждый выбирает для себя…» © Юрий Левитанский.

[Ленивая Бестолочь]

итог -
iptables -A FORWARD -p tcp --dport 25 -j REJECT ? idea.gif

ну если запрещаете совсем, то да.

вот тут я как раз прав. по результатам теста.
тестовый mua — штатный thunderbird из какой-то там последней убунты. тестовый mta — вероятно, какой-то postfix, небось, красношапочный.
сервер не требует авторизации, в mua проставлено «авторизоваться». mua: «не удалось бла-бла-бла».

я написал про то, что проблема будет с авторизацией, она решается, если конечно хочется её решить. настройкой провайдерского mta.

[demsl]

итог -
iptables -A FORWARD -p tcp --dport 25 -j REJECT ? idea.gif

ну если запрещаете совсем, то да.

а если не совсем - то (просто подводя итог)

iptables -t nat -I PREROUTING -p tcp -i <внутренний интерфейс шлюза> --dport 25 -j DNAT --to-destination <внутренний адрес вашего почтовика>:25
iptables -t nat -A POSTROUTING -s ip_адрес -j SNAT --to-source ip_адрес

во второй строчке "ip_адрес" - оба раза <внутренний адрес вашего почтовика> или -s <локалка/24> --to-source <внутренний адрес вашего почтовика> ?