Может кто-нибудь объяснить, что означает эта уязвимость?

Вопрос или проблема

У меня возникла небольшая проблема с пониманием того, что означает эта уязвимость, может кто-то помочь мне это понять?

Меня особенно смущает раздел РЕЗУЛЬТАТЫ. Почему исходный порт 25 должен отличаться от случайного исходного порта, ведь оба порта исходят из внешнего мира?

Уязвимость:
TCP Исходный Порт Пропускает Брандмауэр

УГРОЗА:
Ваша политика брандмауэра, похоже, позволяет TCP-пакетам с определённым исходным портом проходить.

ВЛИЯНИЕ:
Некоторые типы запросов могут проходить через брандмауэр. Номер порта, указанный в разделе результатов этого отчета об уязвимости, является исходным портом, который неавторизованные пользователи могут использовать для обхода вашего брандмауэра.

РЕШЕНИЕ:
Убедитесь, что все ваши правила фильтрации корректны и достаточно строги. Если брандмауэр намерен запрещать TCP-соединения к определённому порту, он должен быть настроен на блокировку всех TCP SYN-пакетов, идущих к этому порту, независимо от исходного порта.

СОБЛЮДЕНИЕ:
Не применимо

РЕЗУЛЬТАТЫ:
Хост ответил 4 раза на 4 TCP SYN-запроса, отправленных на порт назначения 22 с использованием исходного порта 25. Однако он совершенно не ответил на 4 TCP SYN-запроса, отправленных на тот же порт назначения с использованием случайного исходного порта.

Когда клиент подключается к серверу, клиент выбирает свободный TCP порт в диапазоне от 1024 до 65535. В Linux/Unix не привилегированный пользователь не может выбрать порт < 1024. Затем он подключается к хорошо известному порту, например, 80 для http...

Отчет утверждает, что он может достичь порта назначения, если исходный порт специфичен (22 и 25 в вашем примере), но не может, если используется случайный порт (например, в диапазоне от 1024 до 65535). Клиент обычно использует случайный порт, поэтому ваше правило не должно учитывать номер исходного порта.

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

Я думаю, вы случайно создали одно из своих правил, обменяв местами значения исходного и назначенного портов.

У меня также возникла такая проблема при сканировании уязвимостей, но для UDP порта 53. В моем случае, я думаю, что причина, по которой это возникло, заключается в том, что мы создаем наши правила политики брандмауэра, позволяя конкретному IP-адресу источника подключаться к IP-адресу назначения и порту назначения через любой порт. Перед нашим брандмауэром находится наш интернет-роутер, на котором мы запускаем ACL. Мы позволяем порты, такие как 80, 443, 21, 22 и т.д., любому, так как наш брандмауэр обрабатывает правила для этих портов для наших серверов DMZ, и вы не можете фильтровать по IP, если разрешаете всем доступ к вашему сайту. Поэтому ACL блокирует запросы с высоким числом, но разрешает порты, такие как 80, 443, 22 и т.д., поскольку ACL разрешает их. Затем брандмауэр сбрасывает пакет, поэтому сканер видит это как закрытый порт.

Как я решил эту проблему… нажмите здесь

Ответ или решение

Понимание уязвимости "TCP Source Port Pass Firewall"

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

Описание уязвимости

Уязвимость: Проход пакетов TCP через файрвол с определенным исходным портом
Угроза: Политика вашего файрвола позволяет прохождение TCP-пакетов с определенным исходным портом, что может привести к несанкционированному доступу.

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

Секция "Результаты"

В представленном вами отчете указано, что хост ответил на 4 TCP SYN запроса, отправленных на порт 22 с исходным портом 25, тогда как он не дал ответа на аналогичные запросы с произвольными исходными портами. Это прямо указывает на то, что ваша конфигурация файрвола неправильно обрабатывает правила фильтрации.

Вопрос: Почему исходный порт 25 отличается от произвольного порта?
Ответ: В нормальных условиях, TCP-клиент использует произвольный порт (обычно от 1024 до 65535) для установления соединения, и файрвол должен блокировать все входящие соединения на определенные целевые порты, независимо от исходного порта. Если ваш файрвол разрешает соединения на порт 22 только для пакетов с исходным портом 25, это создает уязвимость. Злоумышленник может легко отправить запросы с этого порта и обойти вашу защиту.

Решение проблемы

Рекомендации: Для устранения данной уязвимости, убедитесь, что ваши правила фильтрации настроены корректно и строго. Если файрвол должен блокировать TCP-соединения на определенный порт (например, порт 22), он должен быть настроен на блокировку всех TCP SYN пакетов, направляющихся на этот порт, независимо от исходного порта.

Дополнительные аспекты

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

Заключение

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

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

Оцените материал
Добавить комментарий

Капча загружается...