Ип почтового сервера заблокирован гуглом, яндексом и даже мейлом.

Бизнес же. Ну как пиндосы: сделать плохо у других, что бы у себя (в сравнении) было хорошо ))

1) отправились ни туда

2) все равно его не бросите

3) не знаете, как дойти

4) застряли в деталях

5) не тот, за кого себя выдаете

Недавно прочел на Википедии про Сашу Грей.

Она сказала так: Я ничего не жду от жизни, потому что так проще жить.

Еще мои девизы на сегодня:

Знание-сила. Ф. Бэкон.

Спопокойствие, только спокойствие!!! Don`t panic!!!

Pirates don`t run (Если за ними не гонятся)

УМВРЧЯДНТ

Логика и здравый смысл - это сила!!!

Всё будет хорошо и даже лучше!!!

Продолжение следует...

А почему они так?

Люди! :)

Всегда пользуюсь iptables. Что я делаю не так?..

Наверное некоторым пофик этот прибамбас. Мне так отличный инструмент! Воткнул спамерские сети в бан и спокоен. Зачем цацкатся с отечественными спамерами которые скупают оптом IP Нидерландов, французов, немцев. Убийство сетей Польши Бразилии Латвии и пр. не считаю зазорным. Особенно поляков у которых туча релеев у каждого провайдера. Чему наши спамерюги очень рады.

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

Бывает такая фигня, что письма-то нужны вашим пользователям. Другой вопрос, что в сложных ситуациях «почетную миссию» поиска админа той стороны можно возложить на самих пользователей :) Но и здесь бывают исключения, и тогда приходится заниматься этим самому.
И так же про исключения, по моей практике свойственно забугорным большим корпорациям, «админа»(обычно это аутсорс компания) нашли, явно указываешь на ошибки, в ответ только одно «у нас это все утверждено на самом высоком уровне, у нас все работает, ничего менять не будем, разбирайтесь у себя». Вот тут ничего не остается как добавлять в исключения.

ЗЫ Напомнили, в части исключений, но не криво настроенные почтари. Бывает когда по совокупности шкворца письма улетают в спам. Один из примеров, в какой-то момент счета от билайн полетели в спам, причем как на шаред хостингах, так и на своих «поддиванных». Проще добавить в исключения, чем разбираться с пчелами.

Я застал это время ;). Первые мои почтовые серверы так и работали. И, как ни странно, без всяких проблем

Вот он один и «первых», кто предоставил спамерам возможность работать. )
Дивная история. В конце 90-х скосячил при перенастройке сендмыла у одного из клиентов оставив его в openrelay. Контора моего друга занималась рассылкой рекламы самих себя (железом торговали), вот они и подыскивали новые openrelay т.к. старые достаточно часто улетали в bl. И вот блина они достаточно шустро наткнулись на мой же косячный и произвели рассылку )

Недавно прочел на Википедии про Сашу Грей.

Вас так вдохновил просмотр её творчества, что даже решили узнать о ней побольше?
Я это имя узнал-то случайно. Коллега1 отрываясь от моника выдает что-то типа «офигеть саша грей в политику собирается». Я и другой коллега хором «кто такой саша грей?». Коллега1 - не такой, а такая, этоже знаменитая порноактриса. Коллега2 - даа походу мы не те фильмы смотрим.

Видимо вам начальство ни разу не говорило: «Делай что хочешь, но что бы от них мне почта проходила! Надо и точка!»

Конечно :). Мое дело - добиться, чтобы от меня почта нормально доходила до адресатов. А криво сконфигурированные почтовики - проблема их владельцев.

😁😂👍

iptables придумали трусы )))

Дело тут не в трусости, а в уместности применения файрвола. Надо просто четко понимать, где от него есть польза, а где нет. А то у Вас по анекдоту получается:

- Как предохраниться от СПИДа?

- Наденьте презерватив, обмотайте ватой, дальше второй, и главное, никакого секса!

Вот он один и «первых», кто предоставил спамерам возможность работать.

Проблемы спама не было еще тогда ;). У меня и первые пароли повторяли имена пользователей (login: lena, password: lena) ;). И работало это не меньше года, никто не взламывал...

И работало это не меньше года, никто не взламывал...

Так openrelay это же не взлом. Это бесплатная услуга :) А сами ящики, да кому они в 90-х нужны были... это я про подбор паролей. Вот ftp,telnet,etc это да, было. PS Забыл диалап! Вот это наше все.

Проблемы спама не было еще тогда ;). У меня и первые пароли повторяли имена пользователей (login: lena, password: lena) ;). И работало это не меньше года, никто не взламывал...

Да были времена.. А сей пароли для узеров только я лично придумываю. В вебморде отключил возможность пользователю менять пароль.

Да хоть водку вместо газировки запивайте соком, потому что так полезнее ))

Какие задачи - такие и решения это понятно. Построить, что бы сломалось по окончании гарантии это тоже закономерно. Но перебздеть никогда лишним не было 😉

Работать в интернете без файрволла - это предохраняться от СПИДА путем секса без презерватива каждый день встречаясь с новой девушкой, товарищ!!!

Очень странно, что я говорю такую очевидную вещь человеку, у которого 2 звезды да еще и на Linux-форуме...

iptables придумали трусы )))

iptables придумали трусы, балбесы не знают, что такое firewall, а бывалые знают, что такое internet...

Но перебздеть никогда лишним не было

Присоединяюсь. Serge10 В части подбора паролей на почтаре. Соединились, запустился процесс, да логин/пасс не верный, и так сотнитысяч раз (без преувеличения). Ну не фэншуйнее ли сразу в drop?

Работать в интернете без файрволла...

Вполне возможно. Десктоп. Если у вас ни кто ничего не слушает. То почему нет? Главное в этой схеме, при установке чего-то нового/обновления не забывать проверить, что «ни кто ничего не слушает». Только вот геморройная схемка получаеться.

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

Где ты смотрел эти спам-базы?

Работать в интернете без файрволла - это предохраняться от СПИДА путем секса без презерватива каждый день встречаясь с новой девушкой, товарищ!

Ok, давайте подробнее разберем, от чего же защищает firewall. Напомню, что речь идет у нас не о сетке, не о рабочей станции, а об одиночном сервере. И так, на сервере запущены несколько служб — скажем, dns, почта, http-сервер и ssh. Соответственно, слушаются порты 25, 110, 22, 80, 143, 443, 993 и 995. На остальных портах ничего нет. Как Вы будете защищать сервер файрволом? Стандартный подход предполагает закрыть все порты кроме тех, что нужны.

А теперь давайте сравним, что получилось в итоге. На вероятность взломать наш с Вами сервер через уязвимости в используемых сервисах файрвол не влияет - мы оставили нужные нам порты открытыми. А что с остальными портами? В случае с файрволом попытка соединения с ними либо оборвется по тайм-ауту (если политика по умолчанию DROP), либо злоумышленник получит сообщение, что порт недоступен (если политика по умолчанию REJECT).

Казалось бы, все здорово, мы именно этого и хотели.

Но давайте теперь посмотрим, что будет в варианте сервера без файрвола. При попытке соединения с портом, который не используется, злоумышленник получи сообщение «connection refused».

А теперь вопрос, чем второй вариант опаснее первого?

Вы можете мне возразить, что функции файрвола не сводятся к перекрытию портов и вспомнить fail2ban, например. На что я Вам отвечу, что в 21 веке попытки подбора паролей методом последовательного перебора ничего кроме смеха не вызывают ;). Ну а от ddos защищаться надо по-другому...

Хотелось бы теперь услышать Ваши аргументы по поводу защитной роли файрвола в рассматриваемом случае (одиночный сервер)...

Если всё настроено (spf, ptr, dkim, dmarc, dane tlsa (с dnssec), mta-sts,smtp-tlsrpt), если tls на почтовом сервере настроен на соответствие hipaa, pci dss, nist, если на mail-tester 10/10

pci dss

А зачем тебе на почтовике данные платежных карточек обрабатывать? УПРЛС?

Ну только в плане tls же. А так да - врождённый перфекционизм можно и упрлс назвать:)

Ну а от ddos защищаться надо по-другому...

ЛПИП Мне вполне себе «повезло» при защите от ddos на 53/udp. Так что Вы в целом не правы.

Соединились, запустился процесс, да логин/пасс не верный, и так сотнитысяч раз (без преувеличения).

Хм, Вы сталкивались с ситуациями, когда подобные действия перегружали сервер? Лично я не сталкивался - не знаю, может, на каких-то магистральных каналах и можно организовать ddos таким способом, но на моих 10 Mb это совершенно нереально. А чем еще чреваты такие попытки? Лично мне они не мешают. А теперь представьте, что попытки подобрать пароль исходили из бота, который заразил какой-нибудь роутер. В результате все пользователи из сетки за этим роутером не смогут взаимодействовать с Вашим сервером - Вы его просто отправите в бан на неделю. Это явный минус подобного решения... Ну а плюсы для меня явно сомнительны...

Так что Вы в целом не правы.

Возможно. Я просто много раз примеривал с разных сторон fail2ban к своим ситуациям и ни разу не нашел его использование полезным...

Ну а в целом, конечно, кто-то его использует, с этим и спорить глупо...

Хотелось бы теперь услышать Ваши аргументы по поводу защитной роли файрвола в рассматриваемом случае (одиночный сервер)...

Мои аргументы будут в обмен на ваши 2 звезды плюс мне 500 баллов рейтинга этой моей учетки этого говносайта..

Вы сталкивались с ситуациями, когда подобные действия перегружали сервер?

Емнип мы с Вами уже обсуждали этот вопрос, в другой теме ранее.

на каких-то магистральных каналах и можно организовать ddos таким способом

Обращаю внимание. Не ddos и не dos. Только подбор пароля.

А чем еще чреваты такие попытки?

Да ничем, кроме варианта, что рано или поздно могут и подобрать простой пароль. Ну и лишняя нагрузка. А «в целом по больнице», с «сорок тысяч обезьян...» пока все еще подбирать долго. Только вот повторюсь, зачем лишняя нагрузка, если drop быстрее сработает?

А теперь представьте, что попытки подобрать пароль исходили из бота, который заразил какой-нибудь роутер. В результате все пользователи из сетки за этим роутером не смогут взаимодействовать с Вашим сервером

Минус. Мы же вроде про почтовые сервера, а не про «неизвестных» пользователей которые отправляют через наш почтарь, через неизвестно какой «зараженный роутер»

Вы его просто отправите в бан на неделю

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

Я просто много раз примеривал с разных сторон fail2ban к своим ситуациям

Я его тоже не пользую :) Хотя наверное надо будет попробовать. Давно сварганил самописный вариант fail2ban, и пока хватает.

Мои аргументы будут...

Руки меняй.

этого говносайта..

Будь мужиком, забанься как эдик.

1) Ну вот живой пример: недавно подобрали пароль от ящика (ну он совсем простой был), так вот отправить миллионы писем в одночасье взломщикам не удалось, одно соединение на одну отправку, но в час не более 30 соединений благодаря iptables. В результате оперативно сменён пароль от ящика и ни в один чёрный список сервер не попал.

2) Ещё пример: не перевелись боты просто бомбящие открытый порт 10^7 соединений в минуту просто так (в логе соединение открыто и закрыто), это безобразие прилично тормозит работу, нагружает слегка проц, грузит винты и устраивает помойку в логах. В результате работы iptables тормозов нет, а сервисы защищены от ботов. Не, ну может вам повезло и (пока что) боты не ломятся 10^7 пустых соединений 😁 Уж не говорю про регулярные битые и ломаные пакеты даже в малых кол-вах.

но в час не более 30 соединений благодаря iptables

Коллега. iptalbes инструмент незаменимый конечно. Но, постфикс и сам может это делать:

smtpd_client_message_rate_limit = 

а не про «неизвестных» пользователей которые отправляют через наш почтарь, через неизвестно какой «зараженный роутер»

Это могут быть наши пользователи. Находящиеся в командировке/на отдыхе и проверяющие почту из какого-то отеля.

Или я неправильно Вас понял, и Вы баните только 25 порт?

Давно сварганил самописный вариант fail2ban, и пока хватает.

Ну, я имел ввиду сам принцип, а не конкретную реализацию ;).

недавно подобрали пароль от ящика (ну он совсем простой был)

IMHO, совершенно недопустимая ситуация.

Не, ну может вам повезло и (пока что) боты не ломятся 10^7 пустых соединений

Видимо, у меня просто канал узкий (10 Mb). Боты ломятся постоянно, но серьезной, да и просто заметной нагрузки это не создает.

грузит винты

Вот это мне совсем непонятно. Ладно, процессоры, или там сетевая система. Но диски-то тут каким боком (речь вроде как идет про пустые соединения)? Или у Вас дефицит памяти на сервере и вовсю своп используется?

Кстати, да. Sendmail тоже позволяет задавать такие ограничения как на входящие, так и на исходящие соединения.

Это могут быть наши пользователи. Находящиеся в командировке/на отдыхе и проверяющие почту из какого-то отеля.

Согласен, вероятность выше нуля. Но пока везет :)

Видимо, у меня просто канал узкий (10 Mb). Боты ломятся постоянно, но серьезной, да и просто заметной нагрузки это не создает.

Как раз на узком канале быстрее просадка будет заметна. Если только ее (атаку) не отсекает пров ранее. Выше привел пример при ddos на dns, это было на узком канале. Так вообще «пошаговая стратегия» тогда была через ssh. Забито в ноль. При этом, этот же вариант был и на сотке, вообще не заметно.

Как раз на узком канале быстрее просадка будет заметна. Если только ее (атаку) не отсекает пров ранее.

Тогда, видимо, я каких-то принципиальных вещей не понимаю :(.

Если мы говорим о ширине канала как об ограничивающем факторе, то причиной «пошаговой стратегии» в сессии ssh очевидно является забитие канала, не так ли?

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

Получается, что причиной «пошаговой стратегии», все-таки, является не канал. Тогда тем более непонятно - чем канал шире, тем большую нагрузку на Вашу систему в состоянии создать атакующая сторона. А Вы утверждаете, что на широком канале проблем нет...

В чем я ошибаюсь?

Продублирую для вас тоже: «ограничение 30 соединений в час для 1 ip» - расскажите, как это умеет делать sendmail?

«30 соединений в час для 1 ip» - расскажите, коллега, как это умеет делать postfix?

расскажите, как это умеет делать sendmail?

У Sendmail'а есть очень мощная функциональность - поддержка милтеров. Где прикрутить можно любые проверки. Вот пример милтера для решения Вашей задачи.

Самое интересное, что входящая почта на сервер идёт, именно исходящую не хочет, т.е коннект только от меня не принимается.

да, blacklist именно так и работает

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

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

Процентов 20 кустарей

Откуда у вас, сударь, такая чудесная статистика?

Ошибаетесь. вариант1 демон слушает, и на запрос что-то отправляет в ответ. вариант2 дропаем пакет на входе. При массовом дропе, и отправляющая сторона «раком» может встать. Безусловно это не всегда сработает, и при ddos чаще нет чем да, но иногда помогает. Во всяком случае мне помогло.
Если интересно можете сами протестировать. Что будет при ответе и при дропе. Я когда-то прогонял такой тест.

PS Нашел свой же ответ Школьники ддосят (комментарий)

Ошибаетесь. вариант1 демон слушает, и на запрос что-то отправляет в ответ. вариант2 дропаем пакет на входе.

Ну т. е. я прав, по меньшей мере, наполовину - входящий трафик не меняется. Получается, что узким местом является исходящий канал.

Во всяком случае мне помогло.

Хм, а Вы уверены, что у Вас на тот момент был симметричный канал?

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

Тогда, конечно, все логично получается. А вот с симметричным каналом по-прежнему непонятно, как это работает :(.

Ну т. е. я прав, по меньшей мере, наполовину - входящий трафик не меняется. Получается, что узким местом является исходящий канал.

И да и нет. Про 53/udp. Вот сами подумайте. Берем бота который ждет ответа, при дроп, он будет какое-то время висеть и ждать этого ответа. А если этих запросов одновременно много, то дроп может и «подвесить» исходящую сторону.
При tcp и большего кол-ва пакетов (например почтарь) будет «веселее». При подборе пароля пролетит больше пакетов, хоть и с отлупом по причине «пароль не верный», но пакеты же пролетят, чем нагрузят канал больше чем если бы дропнуть первый syn.

Хм, а Вы уверены, что у Вас на тот момент был симметричный канал?

Да, уверен, на 146% :) Серьезно уверен.

ЗЫ 53/udp Например посмотрим на размер входящих и иcходящих пакетов при запросе dig google.com.

Так это умеет милтер, а не сендмейл.