Почему люди постоянно подключаются к моему MTA, ничего не делают и уходят?

У меня есть сервер sendmail. Периодически (т.е. несколько раз в час) я получаю такие записи в журнале:

Sep  3 10:06:49 lory sendmail[30561]: v8396nsQ030561: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Sep  3 10:06:49 lory sendmail[30564]: v8396nmv030564: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
[29 very similar lines deleted]
Sep  3 10:06:50 lory sendmail[30654]: v8396or0030654: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6
Sep  3 10:06:50 lory sendmail[30657]: v8396ou3030657: [37.49.226.159] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v6

Этот конкретный сервер какое-то время работал с такой скоростью, а затем стал прерывистым, установив в общей сложности около 600 соединений за 110 секунд; другие менее многословны. Они не вызывают проблем у моего сервера; fail2ban немного поупражняется, наблюдая за файлом журнала электронной почты на предмет сбоев SMTP AUTH, и игнорируя все эти новые записи, но это ничто, чтобы заставить сервер потеть.

Что мне интересно и что я спрашиваю, так это Зачем кто угодно мог бы такое сделать. Они надеются, что у моего движка ретрансляции / серых списков / SPF очень маленький мозг, и после 500 подключений он говорит сам себе Боже, они действительно хотят поговорить со мной, я лучше приму все, что они отправят сейчас? Они надеются, что на моем сервере нет запасной виртуальной машины, а sendmail раздувается и вызовет убийцу OOM, таким образом DoSing меня? Я предполагаю, что кто-то делает такие вещи по какой-то причине, но есть ли у кого-нибудь хоть малейшее представление о том, что это за причина?

security sendmail

Sendmail "не выдавал MAIL / EXPN / VRFY / ETRN при подключении к MTA" предупреждения не являются неожиданными, они вызваны попытками аутентификации, которые были отклонены, но не только тогда, когда указана комбинация неправильного имени пользователя и пароля, но вы видите та же ошибка, даже если аутентификация не поддерживается (или, по крайней мере, не допускается без TLS):

telnet localhost 25
   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
   220 hbruijn ESMTP Sendmail 8.14.4/8.14.4; Fri, 8 Sep 2017 13:06:31 +0200
AUTH LOGIN
   504 5.3.3 AUTH mechanism LOGIN not available
QUIT

Это генерирует тип журнала событий, который вы видите:

8 сентября 13:06:39 hbruijn sendmail [11333]: v88B6VYg011333: localhost [127.0.0.1] не выдавал MAIL / EXPN / VRFY / ETRN во время подключения к MTA

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

Когда я подключаюсь к STARTTLS и указываю (неправильное) имя пользователя и пароль, sendmail регистрирует точно такую же ошибку.

openssl s_client -starttls smtp -connect localhost:25
   250 HELP
AUTH LOGIN
   334 VXNlcm5hbWU6
bXl1c2VybmFtZUBkb21haW4uY29t
   334 UGFzc3dvcmQ6
d2Vha3Bhc3M=
   535 5.7.0 authentication failed
QUIT
   DONE

Это создает дополнительную строку журнала, но потом точно такое же событие.

8 сентября 13:24:22 hbruijn sendmail [11648]: STARTTLS = сервер, relay = localhost [127.0.0.1], версия = TLSv1 / SSLv3, verify = NO, cipher = DHE-RSA-AES256-GCM-SHA384, биты = 256/256
8 сентября 13:24:32 hbruijn sendmail [11648]: v88BOMvW011648: localhost [127.0.0.1] не выдал MAIL / EXPN / VRFY / ETRN во время подключения к MTA

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

Мой собственный домен не получает много почты, но достаточный фоновый интернет-шум в отношении сканирования портов и попыток перебора. Я захватил весь SMTP-трафик за последние пару дней, и, в дополнение к довольно большому количеству уникальных IP-адресов, запускающих такие события журнала, у моего сервера было два IP-адреса, которые не отступили, когда мой sendmail ответил, что AUTH не поддерживается (без TLS), что приводит к появлению большого количества предупреждений с этих IP-адресов.

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

и связанный журнал:

10 сентября 04:04:34 hbruijn sendmail [7558]: v8A24YLM007558: [196.196.27.126] не выдавал MAIL / EXPN / VRFY / ETRN во время подключения к MTA
10 сентября 04:04:34 hbruijn sendmail [7561]: v8A24Yi1007561: [196.196.27.126] не выдавал MAIL / EXPN / VRFY / ETRN во время подключения к MTA
10 сентября 04:04:34 hbruijn sendmail [7564]: v8A24YHM007564: [196.196.27.126] не выдавал MAIL / EXPN / VRFY / ETRN во время подключения к MTA
10 сентября, 04:04:35 hbruijn sendmail [7567]: v8A24YSY007567: [196.196.27.126] не выдавал MAIL / EXPN / VRFY / ETRN во время подключения к MTA
10 сентября 04:04:35 hbruijn sendmail [7570]: v8A24ZC2007570: [196.196.27.126] не выдавал MAIL / EXPN / VRFY / ETRN во время подключения к MTA
10 сентября 04:04:35 hbruijn sendmail [7573]: v8A24ZYo007573: [196.196.27.126] не выдавал MAIL / EXPN / VRFY / ETRN во время подключения к MTA
10 сентября 04:04:35 hbruijn sendmail [7576]: v8A24ZLt007576: [196.196.27.126] не выдавал MAIL / EXPN / VRFY / ETRN во время подключения к MTA
10 сентября 04:04:35 hbruijn sendmail [7579]: v8A24Zva007579: [196.196.27.126] не выдавал MAIL / EXPN / VRFY / ETRN во время подключения к MTA