Запросы HTTP CONNECT к Apache - что это и как бороться?

Это вот оно:

https://httpd.apache.org/docs/2.2/mod/mod_proxy_connect.html

найди где оно включено и выключи. Или сделай

<Proxy *>
  Deny from all
</Proxy>

И лучше установи nginx вместо апача, там шансов нарваться на какое-то неотключённое легаси намного меньше.

<Limit CONNECT>
    Require all denied
</Limit>

вы хотя бы версию apache писали

мучил нейросеть

первым промптом получил ответ

какие-то китайцы могут невозбранно ходить на китайские сайты видосов через мой сервер

По дефолту не могут. Он виснет методом CONNECT на порт и молчит, скорее всего. Поэтому таких коннектов море. Если бы они продолжали попытку куда-то сходить, то их бы обрубило, а ты бы увидел в логах отлуп по 403.

А так они просто вешают открытое соединение, ну и получается такой DoS.

Раз в логах метод CONNECT с кодом 200, то значит они успешно сходили туда куда запросили.

Это не конкретно это. mod_proxy у меня не загружен. Подозреваю что оно через mod_ssl идет.

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

Там дальше в логах, они куда-то успешно ходят с кодом 200 на запросы GET к левым доменам.

Торможу(

Просто странно, открытый CONNECT-прокси - это точно не дефолтная конфигурация, это надо специально разрешать.

Впрочем, может в каких-то дистрах…

Да, мне уже разули глазки.

Ну вот видимо авторы debian 11 успешно это разрешили, потому что я точно этого не настраивал, я понятия не имею вообще что это.

Собственно, вопрос тогда - как конкретно это можно разрешить и куда мне лезть.

А чем они могут так ходить? Какой-то софт есть для этого?

Расширение для браузера

Посмотри выхлоп apache2ctl -t -D DUMP_MODULES на наличие mod_proxy_connect.

Нет такого

oaded Modules:
 core_module (static)
 so_module (static)
 watchdog_module (static)
 http_module (static)
 log_config_module (static)
 logio_module (static)
 version_module (static)
 unixd_module (static)
 access_compat_module (shared)
 alias_module (shared)
 auth_basic_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)
 autoindex_module (shared)
 deflate_module (shared)
 dir_module (shared)
 env_module (shared)
 filter_module (shared)
 mime_module (shared)
 mpm_prefork_module (shared)
 negotiation_module (shared)
 php7_module (shared)
 reqtimeout_module (shared)
 rewrite_module (shared)
 setenvif_module (shared)
 socache_shmcb_module (shared)
 ssl_module (shared)
 status_module (shared)

Это не конкретно это. mod_proxy у меня не загружен.

Значит загружен. За CONNECT отвечает mod_proxy_connect+mod_proxy.

Подозреваю что оно через mod_ssl идет.

Каким образом?

Попробуй сам сделать CONNECT такой и посмотри что тебе сервер ответит.

CONNECT addr:port HTTP/1.1
Host: addr:port
(тут пустая строка)

А вообще, повторю - ставь nginx - там всё понятнее.

Значит загружен

Смотри пост выше, там перечень всех загруженных модулей. Не загружен.

Каким образом?

Вот и я бы хотел спросить у товарищей айтишников, каким к черту образом??

Попробуй сам сделать CONNECT такой и посмотри что тебе сервер ответит

Пытаюсь, но не могу вкурить - чем именно, конкретно, можно это сделать? Куда что вводить?

Пробую так

curl -x https://my.site:443 -L www.google.com

Вижу в логах запрос GET с хостом www.google.com, мой сервер отвечает на него код 200 и высылает глагну моего сайтика. Запросов CONNECT при этом не происходит. А как породить именно CONNECT?

Попробуй указать свой сайт в качестве HTTP Proxy

Что-то начало получаться, только я не понимаю как это ввести.

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

CONNECT www.google.com:443 HTTP/1.1

Нажимаю ВВОД. оно пишет RECONNECTING (при этом в лог падает запрос CONNECT, ура)

после него опять что-то вываливает и останавливается с пустой строкой. Ввожу Host: www.google.com:443, ввод

Пишет bad request

Что именно в логе появляется? И в консоли вывод пришли нормально в конце.

И попробуй заранее обе строки в буфер обмена засунуть чтобы быстро их отправить - может там таймаут короткий.

Вот так получилось, именно то что у них.

НО!

Какого-то рожна, после каких-то моих манипуляций сейчас, оно перестало отрабатывать этот CONNECT и дает теперь всем ошибку 405 на запрос CONNECT (и мне самому тоже). Попытался откатить конфиг к состоянию когда проблема была - все равно ошибка 405. Ну блина почему всегда так, как только начнешь отлаживать - проблема испраяется???

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

Посмотри старые логи, где там 200 началось и было ли 405 до него? Ну и какие запросы между были?

И даты файлов конфигов.

Короче, что-то выходит, CONNECT прилетает. Но на него теперь идет отлуп 405. А вчера на чужие запросы шло 200. Что за бред, уже начинаю подозревать что этот mod_proxy как-то был загружен, и перестал быть после того как я перезапустил apache. Хотя это очень очень странно. Ничего вообще не могу понять, что происходит.

Вот тебе поудобнее команда

curl -k --proxy-insecure --proxytunnel -x https://proxy.site https://kudanado.site

Кажется нашел такое, но не могу сюда скопировать - тупой вопрос - как мне из архива логов в gz открыть файл в nano, например, чтобы я мог это скопировать в браузер? Или как из просмотрщика mc скопировать, если у меня Konsole? Система для людей блеат

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

zgrep же, и копируй себе прям из konsole.

И что zgrep, что с этим делать то? ввел zgrep имя файла, ничего не происходит.

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

Ну zgrep CONNECT /var/log/apache2/logfile.gz

Короче вот оно похоже

167.172.79.58 - - [22/Mar/2025:22:19:49 +0300] "CONNECT speedrivermoving.com:443:443 HTTP/1.1" 400 493 "-" "-"
152.42.240.140 - - [22/Mar/2025:22:19:49 +0300] "CONNECT speedrivermoving.com:443:443 HTTP/1.1" 400 493 "-" "-"
143.198.80.101 - - [22/Mar/2025:22:19:49 +0300] "CONNECT speedrivermoving.com:443:443 HTTP/1.1" 400 493 "-" "-"
206.189.36.211 - - [22/Mar/2025:22:19:49 +0300] "CONNECT speedrivermoving.com:443:443 HTTP/1.1" 400 493 "-" "-"
167.172.79.58 - - [22/Mar/2025:22:19:49 +0300] "CONNECT speedrivermoving.com:443:443 HTTP/1.1" 400 493 "-" "-"
::1 - - [22/Mar/2025:22:19:50 +0300] "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.54 (Debian) OpenSSL/1.1.1n (internal dummy connection)"
::1 - - [22/Mar/2025:22:19:51 +0300] "OPTIONS * HTTP/1.0" 200 126 "-" "Apache/2.4.54 (Debian) OpenSSL/1.1.1n (internal dummy connection)"
82.157.18.3 - - [22/Mar/2025:22:20:00 +0300] "CONNECT movie.douban.com:443 HTTP/1.1" 200 79072 "-" "okhttp/3.14.9"
82.157.18.3 - - [22/Mar/2025:22:20:04 +0300] "CONNECT m.douban.com:443 HTTP/1.1" 200 79072 "-" "okhttp/3.14.9"
82.157.18.3 - - [22/Mar/2025:22:20:16 +0300] "CONNECT movie.douban.com:443 HTTP/1.1" 200 79072 "-" "okhttp/3.14.9"
82.157.18.3 - - [22/Mar/2025:22:20:38 +0300] "CONNECT m.douban.com:443 HTTP/1.1" 200 79072 "-" "okhttp/3.14.9"

Сначала валило код 400, потом какая-то шняга которую я не понимаю, после нее сразу стало с кодом 200 все идти.

На 98%, это отвалилось у них когда я перезапустил Apache, после этого код 405 идет.

Посмотри логи

Запросы HTTP CONNECT к Apache - что это и как бороться? (комментарий)

как это трактовать?

Сначала валило код 400

Так это оно валило на ошибку в адресе, speedrivermoving.com:443:443.

Да. Не понятно ни хрена. Вот этот internal dummy connection все пишут что нормально и не обращать внимание. Но именно после него, магически, стали CONNECT запросы проходить

именно после него

Покажи до него нормальный отлуп, а не 400 на невалидный адрес.

Или вообще найди точное время перезапуска в error.log и сравни ответы на CONNECT до и после.

Это заморочки конкретно mcview, они зачем-то на кнопки мыши повесили пролистывание файла. В mcedit этой фигни нет и там все работает.

По error логу, рестарта не было рядом с этим временем, да и в течение всего дня.

С каким ЭТИМ? Еще раз: если ты про этот OPTIONS, то ты не туда смотришь. Отлуп с кодом 400 из цитируемого лога возникал не потому, что до тех пор сервер не был открытой проксёй, а потому, что на него прилетал кривой запрос с продублированным номером порта.

zgrep CONNECT /gde/tam/logi/*.gz | grep 200 | head

К сожалению, больше ничего там нету, все архивы логов до самого конца засраны этим кодом 400. С кодом 200 первая запись которую я вообще могу увидеть - та, которую я запостил.

Весь mc перехватывает мышь по умолчанию. Чтобы не перехватывал - можно shift нажимать в большинстве терминалов - они тогда не отдают клики программе а обрабатывают сами.

Код 400 и запросы с :443:443 в конце все?

Да, и правда shift помогает.

Да. Вся концовка архива логов этим залита, ничего больше не увидеть.

Я не знаю, каким образом это интерпретировать. Меня это беспокоит потому что у меня тоже живой апач остался. Могу предполодижить только что internal connection это признак того, что апач внутри себя что-то сделал. Возможно, в заголовках запроса что-то было, что не попало а лог, и оно заставило апач возбудиться.

Скорее всего, это просто совпадение. Либо, корректный запрос CONNECT заставил Apache разбудить второй свой процесс этой бородой, для обработки. То есть это вряд ли связано с вопросом, откуда разрешение на проксирование взялось.

Ну что ж. А вокруг времени рестарта, когда ты сам его перезапустил, видно что 200 сменилось на 405, правильно?

Ну вообще апач такой OPTIONS делает как раз при ребуте вроде как. То что его нету в error_log при этом - странно. Можно ещё /var/log/auth.log и прочие в /var/log посмотреть вблизи этого времени.