LINUX.ORG.RU
Форум — General  

nginx ddos http2

 ,


0

1

Сипится ддос на сайт 

88.99.114.116 - - [29/Jun/2023:10:21:24 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
37.79.216.162 - - [29/Jun/2023:10:21:24 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
пробовал geoip2 в nginx, пробовал отвести в nginx http2 на отдельный порт и блочить его в iptables, пробовал тесткуки, пробовал блочить по пустому рефереру, по пустому юзерагенту, пробовал даже банально в реквесте «PRI» блочить. Все мимо идёт. Подскажите что это за трафик такой и как с ним бороться

★
← У меня вопрос. Как узнать дату установки программы?
iRedMail сбрасывает соединение →

Судя по

пробовал отвести в nginx http2 на отдельный порт

никак не борись. А трафик самый обычный, что смущает?

Anoxemian ★★★★★
()
Ответ на: комментарий от timelf

та это понятно, но сам момент мне не ясен, почему nginx не отрезает по тому же пустому рефереру, при том что на http1 я вижу в логе что отрезает тоесть правило отрабатывает а вот на http2 оно буд-то мимо проходит

User01 ★
() автор топика
Ответ на: комментарий от julixs

if ($http_user_agent = "") { return 444; } вот так по юзерагенту пустому пробовал. Смысл в том что правило работает для http1 судя по логам, а вот на http2 не срабатывает

if ( $host = mysite.ru ) { set $flag «${flag}A»; } if ( $request ~* «PRI» ) { set $flag «${flag}C»; } if ( $flag = «AC» ) { return 444; }

вот так тоже не отрезает, при том что если вместо PRI указат GET, то оно порежет все гет запросы нормално

User01 ★
() автор топика
Последнее исправление: User01 (всего исправлений: 1)
Ответ на: комментарий от iron

благодарю, жду атаку уже натыкал всего подряд 

	http {
map $http2 $http1_ip {
		default 0;
		deny  all;
		return 444;
	}
...


##########http2#########
if ( $http1_ip = 1 ) {	return 441; }
if ( $server_protocol ~* "HTTP/2.0" ) { return 444; }
if ($request_method !~ (GET|POST|HEAD|OPTIONS)) {
    return 443;
}

посмотрю что отработает, если отработает конечно же

User01 ★
() автор топика
Ответ на: комментарий от iron

это одно и тоже ? 

http {
map $request_method $request_method_allow {
 default 0;
 ~*(GET|POST|HEAD|OPTIONS) 1;
}
...

if ( $request_method_allow = 0 ) {	return 441; }

User01 ★
() автор топика
Ответ на: комментарий от User01

это одно и тоже ?

Да, но лучше все методы перечистить (как в примере выше), чуток быстрее будет проверять.

iron ★★★★★
()
Ответ на: комментарий от User01

Каких еще ретюрнов?

В http пишешь map, в server проверяешь соответствие.

iron ★★★★★
()
Ответ на: комментарий от Dimez

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

User01 ★
() автор топика
Ответ на: комментарий от User01

жду атаку

могу ответить после 7 по москве. Но хотел бы все таки уточнить, сервер где?… под диваном, у хостера, вдс?

julixs ★★★
()
Ответ на: комментарий от User01

Можно просто в строчке listen аргумент http2 убрать, это проще и правильнее если хочешь порезать этот протокол.

firkax ★★★★★
()
Ответ на: комментарий от Dimez

Сходят и по http/1.1, ничего с ними от этого не случится. Такой дури чтобы ходить только через 2, вроде даже в гуглхроме ещё нету.

firkax ★★★★★
()
Ответ на: комментарий от User01

Такие сложные конструкции из if-ов официально не поддерживаются. Считай if как просто ещё одну локацию, это не скрипт а перечисление вариантов парсинга запроса.

firkax ★★★★★
()
Ответ на: комментарий от Dimez

if ($http_user_agent = "") { return 444; } ну как может быть не так, если я вижу что в логе тем что с http1 отдает ошибку 444 а те что http2 просто проходит мимо правила

User01 ★
() автор топика
Ответ на: комментарий от User01

А, наверно это фейковый http2 значит, обычный http только в поле протокола 2.0 указано зачем-то. Ну тогда фильтруй тем if-ом по названию протокола как хотел.

firkax ★★★★★
()

У тебя в логе в начале темы код 400 - это bad request. Битые запросы до разбора по конфигу не доходят вроде как, да и резать из смысла нет - они и так и так отброшены получаются. Если они грузят nginx, то правилами nginx с этим ничего не поделать - ведь он в любом случае будет парсить запрос перед тем, как что-то предпринимать. Блочь айпи-адреса файрволлом (только вручную это будет не очень удобно).

А вообще такое решается специальными системами защиты от атак, это отдельная тема.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Залез кое-куда на фронт, погрепал:

grep "HTTP/2.0" access.log | wc -l
4944107
grep "HTTP/1.1" access.log | wc -l
439981
grep "HTTP/1.0" access.log | wc -l
85704

Поздновато как-то уже HTTP/2.0 игнорировать, не находишь?

Dimez ★★★★★
()
Ответ на: комментарий от User01

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

Во-первых, айпишники спустя какое-то время хорошо бы оттуда удалять - они многие меняются, а где-то меняются даже владельцы целых /16 сетей, и на раньше атакующем адресек может оказаться чей-то честный домашний интернет. Думаю в среднем спустя сутки 50-90% забаненых адресов уже не актуально (всмысле, что они сменились), а спустя месяц наврено где-нить 1% плохих адресов продолжают оставаться у прежних «владельцев». Но бывают диапазоны, которые прям специализируются на всяких гадостях, их бы забанить на подольше, но их сначала надо выявить.

Во-вторых, парсер придётся обновлять регулярно.

firkax ★★★★★
()
Ответ на: комментарий от Dimez

Что значит «игнорировать»? Если ты на том фронте запретишь http2 то эти 4.94 миллиона http2 превратятся в 4.93 миллиона http/1.1. Ну, у них наверно будет чуть медленнее что-нить открываться, но в целом никакой трагедии не случится. Запрещать его просто так смысла разумеется нет, но если это способ заблокировать атаки то почему бы нет. Другое дело, что атаки от этого скорее всего не прекратятся, но автор хочет попробовать - пусть пробует. А ещё, как оказалось, у него http2 и так нету, а эти 2.0 - это фейковое поле протокола в http/1 запросе, такие точно надо запрещать (по-хорошему там nginx должен 400 отдавать сразу, если что-то кроме 1.0 или 1.1, но он хоть 5.5 примет).

firkax ★★★★★
()
Ответ на: комментарий от firkax

но если это способ заблокировать атаки то почему бы нет.

Это не способ заблокировать атаки :)

Dimez ★★★★★
()

ТС, и да, ты с регэкспами в конфиге nginx’а полегче, у тебя и так 100% нагрузка, а плохонаписанные регэкспы сильно ещё уронят производительность.

Dimez ★★★★★
()
Ответ на: комментарий от User01

как вариант отрезать диапазон TTL которые практически не используются, это частично должно снизить нагрузку

User01 ★
() автор топика
Ответ на: комментарий от User01

Посмотри в сторону fail2ban. Им можно отбиться от простого HTTP DDOS’а. Ну или да, руками парсить файл и добавлять в ipset, ipset это делает автоматически сам.

Dimez ★★★★★
()
Последнее исправление: Dimez (всего исправлений: 1)
Ответ на: комментарий от User01

Не сложит. Когда дудосили моих хороших знакомых, установленный fail2ban нащёлкал около 10.000 IP вообще без проблем.

Dimez ★★★★★
()
Последнее исправление: Dimez (всего исправлений: 1)
Ответ на: комментарий от Anoxemian

А трафик самый обычный, что смущает?

Ну хз. Например ip 88.99.114.116 принадлежит хетзнеру…

https://ipinfo.io/88.99.114.116

Вряд ли, кто то будет покупать сервак, чтобы через него сидеть в интернете(хотя может для VPN взяли)

romanlinux ★★★
()
Ответ на: комментарий от romanlinux

Хецнер это не только физический дедик, но и облачная vps-ка довольно давно.

Dimez ★★★★★
()
Ответ на: комментарий от romanlinux

там тысячи ip

189.90.33.12 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
5.8.12.23 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
178.18.243.28 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
47.242.170.80 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
172.107.170.86 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
141.164.39.243 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
183.181.26.70 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
170.0.208.38 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
201.27.119.81 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
8.218.204.110 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
34.219.64.140 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
27.133.92.79 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
45.11.3.151 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
198.200.51.172 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
159.223.59.111 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
15.220.82.166 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
164.90.225.1 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
8.218.234.60 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
163.47.158.62 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
45.32.35.8 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
109.166.36.31 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
211.55.148.123 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
15.220.82.166 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
103.155.197.179 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
18.181.83.163 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
43.131.240.44 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
3.39.9.232 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
35.199.90.225 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
121.162.19.88 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
187.35.251.122 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
47.243.41.51 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
121.162.19.88 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
118.38.92.25 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
109.166.37.5 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
109.166.36.31 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
177.128.193.37 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
109.166.36.31 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
177.128.193.37 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
47.90.82.199 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
45.32.35.8 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
212.80.215.69 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
176.32.35.22 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
3.39.9.232 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"
133.237.56.75 - - [28/Jun/2023:23:04:54 +0300] "PRI * HTTP/2.0" 400 157 "-" "-"

User01 ★
() автор топика
31 декабря 2023 г.
Ответ на: комментарий от User01

Удалось побороть?

Похоже на известную уязвимость в HTTP2. Только странно, т.к. он в конфигах не включен. Это точно? Для nginx есть простые решения с установкой keepalive_requests.

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

https://www.shodan.io/

stasmin
()

Купить новый IP, поставить его за CF или какой-нибудь DdosGuard, направить днс на новый IP, убедиться что http(s) на новый IP принимаются только с адресов ddos-фильтра, после этого можно отказаться от старого IP.

slowpony ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.
← У меня вопрос. Как узнать дату установки программы?
General
iRedMail сбрасывает соединение →