У меня проблемы с пониманием того, что означает эта уязвимость. Может ли кто-нибудь помочь мне понять это?
Меня особенно озадачивает раздел РЕЗУЛЬТАТЫ. Почему исходный порт 25 может отличаться от случайного исходного порта, если они оба происходят из внешнего мира?
Уязвимость:
Брандмауэр TCP Source Port PassУГРОЗА:
Кажется, ваша политика брандмауэра пропускает TCP-пакеты с определенным исходным портом.ВЛИЯНИЕ:
Некоторые типы запросов могут проходить через брандмауэр. Номер порта, указанный в разделе результатов этого отчета об уязвимости, является исходным портом, который неавторизованные пользователи могут использовать для обхода вашего брандмауэра.РЕШЕНИЕ:
Убедитесь, что все ваши правила фильтрации правильные и достаточно строгие. Если брандмауэр намеревается запретить TCP-соединения с определенным портом, его следует настроить так, чтобы блокировать все TCP SYN-пакеты, идущие на этот порт, независимо от исходного порта.СООТВЕТСТВИЕ:
НепригодныйПОЛУЧЕННЫЕ РЕЗУЛЬТАТЫ:
Хост ответил 4 раза на 4 зонда TCP SYN, отправленных на порт назначения 22 с использованием порта источника 25. Однако он вообще не ответил на 4 зонда TCP SYN, отправленных на тот же порт назначения с использованием случайного порта источника.
когда клиент подключается к серверу, клиент выбирает свободный TCP-порт, который у него есть между 1024 и 65535. В Linux / Unix пользователь без полномочий root не может выбрать порт <1024. Затем он подключается к хорошо известному порту, например 80 для http ...
В отчете утверждается, что он может достичь порта назначения, если исходный порт является конкретным (22 и 25 в вашем примере), но не может, если он использует случайный порт (например, между 1024 и 65535). Обычно клиент использует случайный порт, поэтому ваше правило не должно учитывать номер исходного порта.
Итак, одно из ваших правил плохое, потому что оно разрешает потоки, если исходный порт является конкретным, тогда как оно должно фильтровать только порт назначения, который является единственной статической частью между ними.
Я думаю, вы пропустили создание одного из своих правил, непреднамеренно обменяв исходное и конечное значение
Я обнаружил это и при сканировании уязвимостей, но для порта 53 UDP. В моем случае, я думаю, причина этого в том, что мы создаем правила политики брандмауэра, позволяющие определенному IP-адресу src через любой порт подключаться к IP-адресу dest и порт назначения. Перед нашим брандмауэром у нас есть интернет-маршрутизатор, на котором мы запускаем ACL. Мы разрешаем такие порты, как 80, 443, 21, 22 и т. Д., Для любого, поскольку наш брандмауэр обрабатывает правила для этих портов для наших серверов DMZ, и вы не можете фильтровать по IP, если разрешите всем доступ на свой сайт. Таким образом, ACL блокирует запросы большого количества, но разрешает такие порты, как 80, 443, 22 и т. Д., Поскольку ACL допускает их. Затем брандмауэр сбрасывает пакет, так что сканер видит это как закрытый порт.