Перейти к содержимому


Фото
- - - - -

Взлом почты...


  • Please log in to reply
94 ответов в этой теме

#41 Borka

Borka

    Забанен за флуд

  • Moderators
  • 19 512 Сообщений:

Отправлено 19 Октябрь 2011 - 16:31

Это с чего бы это?

У вас есть список публичных почтовых релаев?

А мне он зачем?

Несколько лет назад было засилье сусликов (ntos.exe, если кто помнит), которые детектились как Trojan.Proxy, задачей которых было поднять на клиентской машине почтовый сервер опен релей. С одной стороны - рассылает сам, с другой пересылает от других.

Только человек с альтернативными умственными способностями будет принимать с такого компа почту.

А он этого не знает. ;)
С уважением,
Борис А. Чертенко aka Borka.

#42 Полимер

Полимер

    Бетатестёр

  • Posters
  • 2 924 Сообщений:

Отправлено 19 Октябрь 2011 - 16:34

Borka, Борис, посмотри личку.

#43 Borka

Borka

    Забанен за флуд

  • Moderators
  • 19 512 Сообщений:

Отправлено 19 Октябрь 2011 - 17:05

Угу, только что увидел уведомление. -_- Так удобно...

ЗЫЖ Так? ;)
С уважением,
Борис А. Чертенко aka Borka.

#44 Полимер

Полимер

    Бетатестёр

  • Posters
  • 2 924 Сообщений:

Отправлено 19 Октябрь 2011 - 17:09

ЗЫЖ Так?

Лучше текстом из лички и в code, спасибо.

#45 basid

basid

    Guru

  • Posters
  • 4 140 Сообщений:

Отправлено 19 Октябрь 2011 - 17:12

Оптимизм это, конечно, хорошо. "Но есть ньюанс".
Две (независимые) сети 192.168.0/24, 192.168.10/24, почтовый сервер 192.168.10.1, концентратор, обслуживающий 192.168/16.
На концентраторе, в пакете с адреса 192.168.0.2 меняем source-IP на 192.168.10.33 и пересчитываем контрольные суммы. В ответном пакете проделываем обратную замену и снова пересчитываем контрольные суммы.
"Внимание, вопрос!" Что будет записано в логах почтового сервера и служебном заголовке Recieved?

P.S. "Упрощено до безобразия" - не значит "Невозможно".

#46 Полимер

Полимер

    Бетатестёр

  • Posters
  • 2 924 Сообщений:

Отправлено 19 Октябрь 2011 - 17:18

Василий А. Сидоров,
В логе принимающего сервера будет внешний IP отправляемого сервера, все остальное не волнует.

#47 basid

basid

    Guru

  • Posters
  • 4 140 Сообщений:

Отправлено 19 Октябрь 2011 - 17:24

Василий А. Сидоров,
В логе принимающего сервера будет внешний IP отправляемого сервера, все остальное не волнует.

Угу. Поддельный IP.

P.S. Не, SMTP-Auth, конечно, рулит и всё такое, но опираться на IP-адрес при вынесение приговора - я бы поостерёгся.

#48 Полимер

Полимер

    Бетатестёр

  • Posters
  • 2 924 Сообщений:

Отправлено 19 Октябрь 2011 - 17:29

Василий А. Сидоров,
В логе принимающего сервера будет внешний IP отправляемого сервера, все остальное не волнует.

Угу. Поддельный IP.

P.S. Не, SMTP-Auth, конечно, рулит и всё такое, но опираться на IP-адрес при вынесение приговора - я бы поостерёгся.

Вы не понимаете о чем пишете. Если бы можно было менять IP отправителя, то инет встал.

#49 basid

basid

    Guru

  • Posters
  • 4 140 Сообщений:

Отправлено 19 Октябрь 2011 - 17:32

Это вы не понимаете. Или никогда не видели сетку за NAT-ом.

P.S. Думаю, что люди профессионально занимающиеся маршрутизацией и прочими DPI могут и не так огорошить.

#50 pig

pig

    Бредогенератор

  • Helpers
  • 10 703 Сообщений:

Отправлено 19 Октябрь 2011 - 19:08

Ну, NAT-то снаружи видится СВОИМ публичным адресом. А если он IP отправителя поставит 87.242.72.150 вместо своего 212.114.19.21 - кто получит ответный пакет?
Почтовый сервер Eserv тоже работает с Dr.Web

#51 Полимер

Полимер

    Бетатестёр

  • Posters
  • 2 924 Сообщений:

Отправлено 19 Октябрь 2011 - 20:07

Это вы не понимаете. Или никогда не видели сетку за NAT-ом.

P.S. Думаю, что люди профессионально занимающиеся маршрутизацией и прочими DPI могут и не так огорошить.


Чтобы знать основы инета, не нужно быть профессионалом.

#52 HHH

HHH

    Massive Poster

  • Posters
  • 2 714 Сообщений:

Отправлено 19 Октябрь 2011 - 20:29

А я об чем? Поздно пить боржоми, письмо принято провайдером. Хороший отсеет махровый спам, спорный положит в подозрительные. А определять спам доктором на основании только содержания письма не имеет смысла.
ЗЫ. Хоститесь у нормальных провайдеров и проблем со спамом не будет или пользуйтесь вебмордой.

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

По RFC почтовик *обязан* принять письмо, если оно адресовано его пользователю. Даже если я с GPRS его телнетом отправлять буду. Не?

Сообщение было изменено HHH: 19 Октябрь 2011 - 20:30


#53 --VovanGrup--

--VovanGrup--

    Newbie

  • Posters
  • 49 Сообщений:

Отправлено 19 Октябрь 2011 - 20:39

RFC пора переписывать)

#54 Полимер

Полимер

    Бетатестёр

  • Posters
  • 2 924 Сообщений:

Отправлено 19 Октябрь 2011 - 20:53

По RFC почтовик *обязан* принять письмо, если оно адресовано его пользователю. Даже если я с GPRS его телнетом отправлять буду. Не?

Смотря от кого:
1. Если вы c MUA авторизовались на нем, т.е. это ваш сервер, то да и не важно кому письмо.
2. Если это MTA и он не нарушает правил и письмо для вашего сервера, то да.
3. В других случаях нет.

#55 Borka

Borka

    Забанен за флуд

  • Moderators
  • 19 512 Сообщений:

Отправлено 19 Октябрь 2011 - 22:22

Тут, наверное, вопрос про обязан попытаться принять. То есть минимум соединение будет установлено. А потом уже можно (и нужно) смотреть.
С уважением,
Борис А. Чертенко aka Borka.

#56 HHH

HHH

    Massive Poster

  • Posters
  • 2 714 Сообщений:

Отправлено 19 Октябрь 2011 - 23:48

Смотря от кого:

Я, признаться, RFC читал давненько, но что-то мне подсказывает - вы не правы ;) На отправителя там ограничений не накладывается

#57 Полимер

Полимер

    Бетатестёр

  • Posters
  • 2 924 Сообщений:

Отправлено 20 Октябрь 2011 - 08:20

Смотря от кого:

Я, признаться, RFC читал давненько, но что-то мне подсказывает - вы не правы ;) На отправителя там ограничений не накладывается

RFC прописан для взаимодействия между MTA, взаимодействие MUA и MTA, говорят в RFC не определен.
Ну, если рассуждать логически, с какого бодуна мой сервер будет принимать почту с неизвестного компа?
PS. У меня прием почты снаружи не отличается, будь то MTA или MUA, т.е. для ВСЕХ MUA вход закрыт(они не пройдут проверку по правилам RFC). К сожалению, так устроен мой MTA - проверка reverse lookup проходит до авторизации. Для своих юзеров, которые хотят работать с почтой снаружи, настраиваю вебклиент.

#58 a1822

a1822

    Member

  • Posters
  • 116 Сообщений:

Отправлено 20 Октябрь 2011 - 09:19

А в чём дао неприёма подозрительной почты? Стопроцентной уверенности, что это спам, не бывает. Более того, зная обычаи больших начальников и закон подлости в целом, скажу: самое судьбоносное письмо ВСЕНЕПРЕМЕННО придёт на ваш почтовый сервер с динамического небекресолвящегося айпишника из блеклистнутого диапазона.

Я лично принимаю всю почту, идущую на валидные адреса. То, что распознаётся как спам, складываю в папочку "спам" и автоматически удаляю через две недели. Юзеры знают: если что-то должно прийти, но долго не приходит, надо поискать в спаме. Четыре года, полёт нормальный.

#59 HHH

HHH

    Massive Poster

  • Posters
  • 2 714 Сообщений:

Отправлено 20 Октябрь 2011 - 09:25

RFC прописан для взаимодействия между MTA, взаимодействие MUA и MTA, говорят в RFC не определен.
Ну, если рассуждать логически, с какого бодуна мой сервер будет принимать почту с неизвестного компа?

Если бы еще был способ отличить MUA от MTA, было бы совсем хорошо.

Когда я говорил про частичную подделку тех. информации, я имел в виду именно вставку нескольких фейковых received для маскировки истинного отправителя.

В общем, предлагаю завязывать, т.к. всё равно каждый при своём останется ;)

a1822, +1 поступаю аналогично.

Сообщение было изменено HHH: 20 Октябрь 2011 - 09:27


#60 Полимер

Полимер

    Бетатестёр

  • Posters
  • 2 924 Сообщений:

Отправлено 20 Октябрь 2011 - 09:51

Я лично принимаю всю почту, идущую на валидные адреса.

Я берегу своих пользователей. ;) Несколько недоразумений, которые были за 10 лет, быстро устранялись.


Читают тему: 0

0 пользователей, 0 гостей, 0 скрытых