RST & ACK?
Не знаю, что ты подразумеваешь под нормальной ситуацией, но:
linux/net/ipv4/tcp_output:tcp_send_active_reset
FreeBSD нет сейчас перед глазами, извини.
linux/net/ipv4/tcp_output:tcp_send_active_reset
FreeBSD нет сейчас перед глазами, извини.
Вообще-то меня интересует ответ на вопрос не с точки зрения какой-то ОС, а с точки зрения протокола TCP/IP. Может ли возникать такой пакет и в каких случаях?
там комментарий:
/* We get here when a process closes a file descriptor (either due to
* an explicit close or as a byproduct of exit'ing) and there
* was unread data in the receive queue. This behavior is recommended
* by draft-ietf-tcpimpl-prob-03.txt section 3.10. -DaveM
*/
Ну ладно. Пока это draft то я это зафильтрую.
уебаном решил заделаться?
Какой-то новый вирус рассылает такие пакеты по случайным адресам на бооольшой скорости. Таким образом переполняются счетчики ip accounting.
ух ты, покажи!
на самом деле против такого дела (равно как против flow cache DoS для cisco, переполнения таблицы соединений на NAT-роутере и stateful-файрволе) надо бороться исходя из природы проблемы
дело ведь в большом количестве новых соединений за единицу времени, а вовсе не в каких-то флагах пакета
поэтому надо ограничить число новых соединений (или всех соединений в случае NAT) от каждого клиента
на самом деле против такого дела (равно как против flow cache DoS для cisco, переполнения таблицы соединений на NAT-роутере и stateful-файрволе) надо бороться исходя из природы проблемы
дело ведь в большом количестве новых соединений за единицу времени, а вовсе не в каких-то флагах пакета
поэтому надо ограничить число новых соединений (или всех соединений в случае NAT) от каждого клиента
Не всё так просто, на мой взгляд.
Комментарий говорит о секции 3.10, которая стала секцией 2.17 в RFC2525 (ftp://ftp.isi.edu/in-notes/rfc2525.txt).
Если я правильно её понял, то она не требует посылки такого пакета, просто в линуксе так делается почти всегда.
А вот секция 2.10 в упомянутом RFC указывает случай, когда действительно нужно посылать RST + ACK. И линукс так делает в tcp_keepalive_timer.
Комментарий говорит о секции 3.10, которая стала секцией 2.17 в RFC2525 (ftp://ftp.isi.edu/in-notes/rfc2525.txt).
Если я правильно её понял, то она не требует посылки такого пакета, просто в линуксе так делается почти всегда.
А вот секция 2.10 в упомянутом RFC указывает случай, когда действительно нужно посылать RST + ACK. И линукс так делает в tcp_keepalive_timer.
13:27:46.900932 X.X.X.159.1025 > 217.72.45.105.1054: R 0:0(0) ack 272302081 win 0
Вот такой вот мусор валит со скоростью несколько сот пакетов в секунду с нескольких хостов.
Верно. Когда появится другой вирус, то такой фильтр не поможет.
Я уже связывался с автором ng_ipacct, он говорит что сталкивался с такой бедой и думает о её решении.
Я пока ограничился tresholdом в 10^6 записей в полчаса.
Вот такой вот мусор валит со скоростью несколько сот пакетов в секунду с нескольких хостов.
на самом деле против такого дела (равно как против flow cache DoS для cisco, переполнения таблицы соединений на NAT-роутере и stateful-файрволе) надо бороться исходя из природы проблемы
дело ведь в большом количестве новых соединений за единицу времени, а вовсе не в каких-то флагах пакета
поэтому надо ограничить число новых соединений (или всех соединений в случае NAT) от каждого клиента
Верно. Когда появится другой вирус, то такой фильтр не поможет.
Я уже связывался с автором ng_ipacct, он говорит что сталкивался с такой бедой и думает о её решении.
Я пока ограничился tresholdом в 10^6 записей в полчаса.
Тк в большинстве случаев получатель этого пакета и так его не получит, то фильтрование не создаст проблем.
Оставить комментарий
sergey_m
Может ли в нормальной ситуации возникать пакет одновременно с флагами RST и ACK?