Проблема с отправкой почты на SMTP сервер за PIXом

Материал из Xgu.ru

Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной. Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

Короткий URL: sendmail/pix

[править] Текст письма

Если вы столкнулись с описанной проблемой, лучше всего убедить владельца сбойного устройства PIX обновить операционную систему на этом устройстве.

В обновлении заинтересован именно он, поскольку:

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

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

Здравствуйте.

У нас возникла проблема с отправкой писем
на адрес:

    XXXXXXX.XXXXXXX@XXXXXXX.XXXXX.XX

и рядом других адресов, которые
обрабатываются почтовым сервером
XXX.XXXXX.XX.

Проблема выражается в следующем:

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

Мы заметили похожую проблему c несколькими другими почтовиками.
Но их доля в общем количестве получателей почты мала
и составляет не более 5% от общего количества.

После детального анализа SMTP-соединения с сервером

    XXX.XXXXX.XX

выяснилось, что проблема возникает с SACK сегментами,
которые имеют некорректный SN (sequence number, номер последовательности
в TCP).

Брандмауэр на нашей стороне не пропускает TCP-сегменты с такими номерами
и до нашего SMTP-клиента они не доходят.
Таким образом, соединение не работает и разрывается через некоторое
время по тайм-ауту.

Если отключить брандмауэр на нашей стороне,-
и разрешить приход всех пакетов без исключения,-
то соединение работает.

Выяснилось, что проблема может быть связана с ошибкой программного обеспечения
Cisco, известно как «ISN randomization bug».

Проблема может возникнуть в том случае,-
если SMTP-соединение защищено с помощью
устройства Cisco (ASA или PIX), которое выполняет рандомизацию
SN в TCP-соединении.
Если программное обеспечение Cisco имеет указанный баг
рандомизация SN в SACK-сегментах выполняется неверно,-
что полностью соответствует нашей проблеме.

Описание бага доступно здесь:
http://www.cisco.com/cgi-bin/bugtool/onebug.pl?bugid=CSCse14419

=============================================================================

CSCse14419 Bug Details

        Headline     ASA 7.0(4) : not randomizing TCP SACK sequence numbers
        Product      pix-asa
        Feature      Statefull Firewall    Components   Duplicate of-----
        Severity     3  Severity help   Status   Verified  Status help
        First Found-in Version   7.0(4)     First Fixed-in Version   7.2(2.2), 7.0(6.14), 7.1(2.34), 8.0(0.141)  Version help
        Release Notes


         Symptom:
         PIX randomizing main TCP sequence number but not TCP SACK sequence numbers


         Conditions:
         7.0(4)


         Workaround:
         Disable randomization of TCP sequence numbers


         Further Problem Description:
         None.

=============================================================================

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

Если это невозможно, можно отключить TCP randomization
вообще (чего не стоит делать), или только на некоторые адреса.

Отключение можно сделать так:
(это просто пример, код может отличаться в зависимости от версии прошивки)

=============================================================================
access-list NOTCPRAND extended permit tcp any any

class-map NOTCPRAND
 match access-list NOTCPRAND

policy-map global_policy
 class NOTCPRAND
  set connection random-sequence-number disable
=============================================================================



Проблема не является критической, и можно оставить всё как есть.

Но если она действительно существует,
то

1) Некоторые отправители электронной почты в вашу сеть будут сталкиваться-
   с проблемой при отправке писем. И не все письма в итоге могут дойти получателям.

2) Квалифицированные специалисты могут определить, что SMTP-соединение
   защищено с помощью PIX/ASA и под какой версией программного обеспечения
   оно работает.


Если у вас есть время и возможность заниматься сейчас этой проблемой,
мы бы хотели попросить у вас помощь в выяснении этого вопроса и устранении
проблемы.

В качестве элементарной меры, которая расставила бы все точки над i,
можно было бы выполнить временное отключение рандомизации.


Спасибо!


PS. 
С более детальной информацией об этой проблеме вы можете ознакомиться на странице:
    http://xgu.ru/wiki/sendmail/pix

=====================================================================================================================