Главная » Форум » Gentoo Linux » Системное администрирование

ARP flood

KiberGus 20 октября, 2008 - 12:50

Есть система: 4 компьютера во внутренней сети (2х - gentoo, 2x - windows) и роутер (gentoo), который стоит между ними и сетью провайдера. Переключился на нового провайдера (корбина) и через день меня забанили, сказали мол флужу. Проверил на вирусы, ужесточил правила iptables. Снова забанили. В логах ядра остались сообщения "neighbour table owerflow", то бишь ARP таблица переполняется. Сказали, что флуд идет dhcp запросами, широковещательными пакетами.
Сейчас бан сняли и я очень аккуратно сижу в интернете со включенным tcpdump'ом. Вчера увидел следующее:
В какой-то момент роутер клинит и он решает, что пакеты надо слать не через маршрутизатор провайдера, а прямо в ethernet. А раз так, то надо бы узнать MAC адреса этих компьютеров и он шлет ARP запросы. Шлются они для любых IP адресов (по крайней мере tcpdump видел только arp запросы и IP в них были из совсем разных подсетей, разнились старшие биты адреса). Ну а с учетом того, что братец сидит в торентах, что дает около 20 обращений к разным IP адресам в секунду. Получается флуд широковещательными ARP пакетами, действительно есть за что банить.
Посмотреть ifconfig в момент сбоя я не догадался - поторопился сразу же вырубить соединение. Но есть у меня подозрение, что маска подсети оказалась 0.0.0.0, иначе зачем слать ARP пакеты всем. DHCP запроса в момент запроса не происходило и DHCP ответов мой роутер не получал. Есть ли у кого-нибудь идеи, что происходит?

‹ [SOLVED] При подключении ноутбука к корпоративной сети меняется hostname Не создает отчет sarg [soloved] ›
»

идея пока только

Автор Гость (не зарегистрирован), дата создания 20 октября, 2008 - 23:28.

идея пока только одна:
проверь дефолт маршрутов на роутере сколько? и как они поднимаются...

»

Похоже никто ничего не знает.

Автор KiberGus, дата создания 21 октября, 2008 - 20:12.

Похоже никто ничего не знает. Тема в гугле на 2ом месте. Сегодня удалось наловить логов о проишествии. Вот так выглядит tcpdump для интерфейса, который смотри в интернет:

16:19:15.402711 IP 85.21.0.16 > 10.53.43.238: GREv1, call 0, seq 5705824, ack 5632891, length 520: IP [|ip]
16:19:15.403123 IP 10.53.43.238 > 85.21.0.16: GREv1, call 35280, seq 5632892, ack 5705824, length 60: IP [|ip]
16:19:15.403188 IP 85.21.0.16 > 10.53.43.238: GREv1, call 0, seq 5705825, ack 5632891, length 72: IP [|ip]
16:19:15.403369 IP 10.53.43.238 > 85.21.0.16: GREv1, call 35280, seq 5632893, ack 5705825, length 80: IP [|ip]
16:19:15.403634 IP 85.21.0.16.1723 > 10.53.43.238.47017: P 3248:3396(148) ack 4061 win 4036: pptp CTRL_MSGTYPE=CDN CALL_ID(35280) [|pptp]
16:19:15.404269 IP 85.21.0.16 > 10.53.43.238: GREv1, call 0, seq 5705826, ack 5632893, length 72: IP [|ip]
16:19:15.404320 IP 85.21.0.16.1723 > 10.53.43.238.47017: P 3396:3412(16) ack 4061 win 4036: pptp CTRL_MSGTYPE=StopCCRQ REASON(0) [|pptp]
16:19:15.404345 IP 10.53.43.238.47017 > 85.21.0.16.1723: . ack 3412 win 7504
16:19:15.404394 IP 10.53.43.238.47017 > 85.21.0.16.1723: P 4061:4077(16) ack 3412 win 7504: pptp CTRL_MSGTYPE=StopCCRP RESULT_CODE(1) ERR_CODE(0) [|pptp]
16:19:15.404532 IP 10.53.43.238.47017 > 85.21.0.16.1723: FP 4077:4093(16) ack 3412 win 7504: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0) [|pptp]
16:19:15.405014 IP 85.21.0.16 > 10.53.43.238: GREv1, call 0, seq 5705827, ack 5632893, length 960: IP [|ip]
16:19:15.405061 IP 10.53.43.238 > 85.21.0.16: ICMP 10.53.43.238 protocol 47 unreachable, length 556
16:19:15.417560 IP 85.21.0.16.1723 > 10.53.43.238.47017: . ack 4094 win 4020
16:19:15.420901 IP 85.21.0.16.1723 > 10.53.43.238.47017: FP 3412:3412(0) ack 4094 win 4004
16:19:15.420916 IP 10.53.43.238.47017 > 85.21.0.16.1723: . ack 3413 win 7504
16:19:16.263385 STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.00:15:e9:bb:a7:bc.8018, length 43
16:19:16.358802 unknown STP version, length 43
16:19:16.530095 unknown STP version, length 43
16:19:16.669554 arp who-has 68.80.176.106 tell 10.53.43.238
16:19:16.677545 arp who-has 210.160.54.17 tell 10.53.43.238
16:19:16.717514 
16:19:16.733544 arp who-has 70.178.147.66 tell 10.53.43.238
16:19:16.737546 arp who-has 218.110.14.231 tell 10.53.43.238
16:19:16.753546 arp who-has 221.30.168.11 tell 10.53.43.238
16:19:16.781544 arp who-has 84.248.246.156 tell 10.53.43.238
16:19:16.797545 arp who-has 118.3.192.21 tell 10.53.43.238

То есть в 16:19:16 его клинит и начинается котовасия. При этом ifconfig нормальный:

eth1      Link encap:Ethernet  HWaddr 00:0C:6E:DE:44:71
          inet addr:10.53.43.238  Bcast:10.53.47.255  Mask:255.255.248.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:29611821 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36769748 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2011588381 (1918.4 Mb)  TX bytes:4183267339 (3989.4 Mb)
          Interrupt:22 Base address:0x2000

Но что любопытно, за секунду до этого потерялась связь с ppp сервером:

Oct 21 16:19:15 [pptp] anon log[ctrlp_disp:pptp_ctrl.c:928]: Call disconnect notification received (call id 35280)
Oct 21 16:19:15 [pptp] anon log[ctrlp_disp:pptp_ctrl.c:787]: Received Stop Control Connection Request.
Oct 21 16:19:15 [pptp] anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 4 'Stop-Control-Connection-Reply'_
Oct 21 16:19:15 [pptp] anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown)
Oct 21 16:19:15 [pptp] anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'_
Oct 21 16:19:15 [pptp] anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)
Oct 21 16:20:01 [cron] (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Oct 21 16:20:40 [dhcpcd] eth1: received SIGTERM, stopping

Вот только что ситуация повторилась:

20:00:21.761557 arp who-has 72.14.235.9 tell 10.53.43.238
20:00:22.457554 arp who-has 66.249.93.9 tell 10.53.43.238
...

И системный лог:

Oct 21 20:00:21 [pptp] anon log[ctrlp_disp:pptp_ctrl.c:928]: Call disconnect notification received (call id 34709)
Oct 21 20:00:21 [pptp] anon log[ctrlp_disp:pptp_ctrl.c:787]: Received Stop Control Connection Request.
Oct 21 20:00:21 [pptp] anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 4 'Stop-Control-Connection-Reply'_
Oct 21 20:00:21 [pptp] anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown)
Oct 21 20:00:21 [pptp] anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'_
Oct 21 20:00:21 [pptp] anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)
Oct 21 20:00:31 [pptp] anon log[main:pptp.c:272]: The synchronous pptp option is NOT activated_
Oct 21 20:00:31 [pptp] anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'_
Oct 21 20:00:31 [pptp] anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply
Oct 21 20:00:31 [pptp] anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.
Oct 21 20:00:32 [pptp] anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'_
Oct 21 20:00:32 [pptp] anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.
Oct 21 20:00:32 [pptp] anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 11923)._
Oct 21 20:00:38 [pptp] anon log[callmgr_main:pptp_callmgr.c:255]: Closing connection (shutdown)
Oct 21 20:00:38 [pptp] anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'_
Oct 21 20:00:38 [pptp] anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)
Oct 21 20:00:39 [dhcpcd] eth1: received SIGTERM, stopping

Тут нельзя сказать, что упало первым, но я думаю, что ppp снова был первым. Может теперь у кого-нибудь появятся идеи, что настроено неправильно. В следующий раз посмотрю, какие маршруты получаются на машине при падении.
P.S. Сейчас используется pptp, до этого использовался xl2tp. Глюк с arp возникал и там и там, но xl2tp еще флудил в логи ошибкой вида "ааа, все плохо" и тем грузил процессор на 100%.

»

Сейчас повнимательнее

Автор KiberGus, дата создания 22 октября, 2008 - 00:44.

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

 route add default dev eth1

а она и говорит, незнаешь, куда слать пакеты - попробуй eth1, ну система и пробовала. Мораль: не копируйте скрипты с форумов, пока не поймете, что делает КАЖДАЯ строчка.

»

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".