Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1
RSS
Treason в логах - что это?
 
В логе (уровень логирования DEBUG: в /etc/syslog.conf добавлена сторчка: kern.=debug /var/log/iptdrop) постоянно (уже год - все время, как у меня шлюз под линукс)  появляюся записи:

Aug 31 18:02:52 gateway kernel: TCP: Treason uncloaked! Peer 212.26.128.40:8080/59856 shrinks window 879856291:879856296. Repaired.

То их много, то на несколько недель  - затишье. Причем айпишник 212.26.128.40 всегда один и тот же - относится к сетке какого-то Киевского провайдера.
Для справки:
Treason - предательство, измена, в т.ч. и супружеская.
Uncloced  - обнаружена

Последствий никаких. Просто интересно, что происходит?  

ЗЫ. Гугл показал, что это происходти, когда мне шлют пакеты с окном, равным нулю - один из видов DOS атак. Только почему я єтих атак даже не замечаю?
 
shrink:
1. сущ.
усадка, усушка, уменьшение
2. гл.
уменьшать, сокращать

Видимо, Гугл прав.
879856291:879856296 - только 6 пакетов с "shrinks window".
Не знаю, какого характера такая DoS атака.

Я бы на твоём место просто обрубил этот адрес(или отправить письмо этому провайдеру, чтоб у себя покапались).
 
Цитата
Jul_i пишет:
Aug 31 18:02:52 gateway kernel: TCP: Treason uncloaked! Peer 212.26.128.40:8080/59856 shrinks window 879856291:879856296. Repaired.
Этот хост является получателем пакетов на порт 8080(о чем можно судить по коду ядра с комментариями), предположительно на нем поднят TARPIT, который принимает соединение и сразу же переводит TCP-окно в 0, игнорируя попытки закрыть соединения, с целью завесить сканеры портов.
Кто-то с вашего хоста или за ним(routing/NAT) балует сканированием проксей, что и отражается в логе в виде сообщений "Treason uncloaked!".
 
Цитата
R пишет:
игнорируя попытки закрыть соединения, с целью завесить сканеры портов.
Хм ... У меня порт 8080 прозрачно проксируется сквидом. Так что зависнуть должен был сквид! Явно выраженных тормозов инета в последний раз не было, хотя могли и не заметить - предпраздничная суета ...

Насколько сильно эти незакрытые соединения жрут ресурсы? Кто-нибудь сталкивался? И сколько надо их открыть чтобы хоть что-то почувствовать? У меня интервал между записями в логах - две минуты, а дилтся все безобразие порциями примерно по 20 имнут.  

И что значит в конце записи слово repaired? Что исправлено? На чьей стороне?
 
Цитата
Jul_i пишет:
Так что зависнуть должен был сквид!
Скорее временно подвиснут один или несколько чайлдов сквида пока соединение не завершится по таймауту.

Цитата
Jul_i пишет:
И что значит в конце записи слово repaired? Что исправлено? На чьей стороне?
На стороне вашего прокси. Уменьшение окна принимающей стороной нарушает RFC-1122(но было допустимо в  первоначальном стандарте TCP/IP, RFC-793).  Linux реализует алгоритм, согласно которому в такой ситуации, когда приемник уменьшает размер окна до нуля, тем самым делая TCP-соединение неактивным если приложение закрывает сокет, то сокет убивается форсированно в течение 2 минут не смотря на то, что тарпит игнорирует закрытие соединения.

Цитата
Jul_i пишет:
Насколько сильно эти незакрытые соединения жрут ресурсы?
Из рассчета, что один TCP-сокет это память под структуру ядра(несколько сот байт) + память выделенная ядром под буферы приема(задается в tcp_rmem) и передачи(net.ipv4.tcp_wmem), при чем память эта несвопируемая.  
Стратегия выделения памяти под сокеты адаптивна и зависит от объема ОЗУ. Например, с 512 МБайт RAM значения по умолчанию(мин/дефолт/максимум) таковы:
net.ipv4.tcp_rmem = 4096        87380   524288
net.ipv4.tcp_wmem = 4096        16384   524288
net.core.wmem_max = 107520
net.core.rmem_max = 107520
Конкретный объем выделяемой под буферы памяти зависит от ситуации, от того, сколько памяти уже было выделено под буферы. Поведение системы определяется параметром net.ipv4.tcp_mem(границы заданы в страницах памяти, 4К).
Если net.ipv4.tcp_mem = 12288        16384   24576
То при объеме памяти, выделенной под буферы до 48МБ под каждый сокет выделяется до 105 КБ памяти(net.core.rmem_max, net.core.wmem_max) на буфер чтения и записи, при объеме выделенной памяти от 48МБ до 64МБ - 87380(буф. чтения) + 16384(буф.записи) байт и при объеме выделенной памяти свыше 64МБайт - по 4КБ на буфер чтения и записи.
48МБайт уходит под ~ 230 сокетов, еще 16 МБ ~ 160 сокет, а далее на каждый сокет уходит порядка 8КБ, т.е. каждая сотня мегабайт ~12800 сокетов. У хоста же с TARPIT никакие локальные ресурсы под сокеты не выделяются, поэтому такой хост может подвесить неограниченное число соединений.
 
2R, спасибо. TARPIT  - прикольная штука, но , если верить http://gazette.lrn.ru/rus/articles/iptables-treasures.html , не совсем безобидная для себя:
Цитата
Едва ли стоит использовать conntrack и TARPIT на одной и той же системе, особенно если ожидается большое число соединений, попавших в ловушку. Каждое такое соединение будет расходовать ресурсы conntrack.

ЗЫ. На 212.26.128.40:8080 оказался аудио-видео архив, разрешены только 2 соединения одновременно. Долблюсь туда в 3 потока уже час - никаких Treason в логах. Врядли у них это умышленно - скорее всего кривоватость.
 
Цитата
Jul_i пишет:
Едва ли стоит использовать conntrack и TARPIT на одной и той же системе, особенно если ожидается большое число соединений, попавших в ловушку. Каждое такое соединение будет расходовать ресурсы conntrack.

man iptables
...
      NOTE:  If  you use the conntrack module while you are using TARPIT, you
             should also use the NOTRACK target, or the kernel will  unneces-
             sarily  allocate  resources  for  each  TARPITted connection. To
             TARPIT incoming connections to the standard IRC port while using
             conntrack, you could:

             iptables -t raw -A PREROUTING -p tcp --dport 6667 -j NOTRACK

             iptables -A INPUT -p tcp --dport 6667 -j TARPIT

 
Цитата
Jul_i пишет:
TARPIT - прикольная штука
Да штука веселая, но, к сожалению, Linux из ловушки вырывается по таймауту достаточно быстро, закрытый приложением сокет в состоянии FIN_WAIT1 убивается за пару минут:

$ netstat -nto|grep 1337
tcp        0      1 192.168.0.3:1037        192.168.0.1:1337        FIN_WAIT1  unkn-4 (4,31/0/2)
$ netstat -nto|grep 1337
tcp        0      1 192.168.0.3:1037        192.168.0.1:1337        FIN_WAIT1  unkn-4 (1,10/0/2)
$ netstat -nto|grep 1337
tcp        0      1 192.168.0.3:1037        192.168.0.1:1337        FIN_WAIT1  unkn-4 (94,39/0/5)
$ netstat -nto|grep 1337
tcp        0      1 192.168.0.3:1037        192.168.0.1:1337        FIN_WAIT1  unkn-4 (38,85/0/5)
$ netstat -nto|grep 1337
$

А вот винде жестко не повезло - она попадает в ловушку накрепко, соединения продолжают оставаться в FIN_WAIT1 и система продолжает постоянно слать ACK и получать в ответ ACK и WIN=0 в течение уже часа - похоже это до перезагрузки. ;) Душераздирающее зрелище :)

C:\>netstat -n

Active Connections

Proto Local Address Foreign Address State
TCP 192.168.100.50:3007 192.168.0.1:1337 FIN_WAIT_1
TCP 192.168.100.50:3008 192.168.0.1:1337 FIN_WAIT_1
TCP 192.168.100.50:3009 192.168.0.1:1337 FIN_WAIT_1

$ tcpdump -n port 1337
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:08:20.049528 IP 192.168.100.50.3008 > 192.168.0.1.1337: .333106748:33310674                                           9(1) ack 3495052863 win 64240
09:08:20.049558 IP 192.168.0.1.1337 > 192.168.100.50.3008: . ack 0 win 0
09:09:19.645889 IP 192.168.100.50.3007 > 192.168.0.1.1337: .318202741:31820274                                           2(1) ack 3426996937 win 64240
09:09:19.645927 IP 192.168.0.1.1337 > 192.168.100.50.3007: . ack 0 win 0
09:09:35.745556 IP 192.168.100.50.3009 > 192.168.0.1.1337: P 382144047:382144048(1) ack 3683448127 win 64240
09:09:35.745584 IP 192.168.0.1.1337 > 192.168.100.50.3009: . ack 0 win 0
09:10:19.496244 IP 192.168.100.50.3008 > 192.168.0.1.1337: . 0:1(1) ack 1 win 64240
09:10:19.496275 IP 192.168.0.1.1337 > 192.168.100.50.3008: . ack 0 win 0
...
10:05:19.423193 IP 192.168.100.50.3009 > 192.168.0.1.1337: P 0:1(1) ack 1 win 64240
10:05:19.423221 IP 192.168.0.1.1337 > 192.168.100.50.3009: . ack 0 win 0
10:06:00.283359 IP 192.168.100.50.3010 > 192.168.0.1.1337: P 1:2(1) ack 1 win 64240
10:06:00.283388 IP 192.168.0.1.1337 > 192.168.100.50.3010: . ack 1 win 0
10:06:03.272869 IP 192.168.100.50.3008 > 192.168.0.1.1337: . 0:1(1) ack 1 win 64240
10:06:03.272900 IP 192.168.0.1.1337 > 192.168.100.50.3008: . ack 0 win 0
10:07:02.869289 IP 192.168.100.50.3007 > 192.168.0.1.1337: . 0:1(1) ack 1 win 64240
10:07:02.869339 IP 192.168.0.1.1337 > 192.168.100.50.3007: . ack 0 win 0
10:07:18.815925 IP 192.168.100.50.3009 > 192.168.0.1.1337: P 0:1(1) ack 1 win 64240
10:07:18.815954 IP 192.168.0.1.1337 > 192.168.100.50.3009: . ack 0 win 0
 
2 R
Я как-то никогда не баловался с TARPIT. Не подскажите, а то чего-то сходу не соображу?
Из приведенного Вами куска мана следует, что если я ставлю в TARPIT спамерское соединение на мой 25 порт, то я должен сделать "-p tcp --dport 25 -j NOTRACK". Но будет ли после этого работать отслеживание состояний соединений на 25 порту, т.е. "-p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT"?
 
Цитата
LIDS пишет:
Но будет ли после этого работать отслеживание состояний соединений на 25 порту, т.е. "-p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT"?
NOTRACK позволяет выборочно отключить отслеживание состояния соединений в conntrack. Правило "-p tcp --dport 25 -j NOTRACK" отключает отслеживание состояния соединений в conntrack для соединений на порт tcp/25, а поскольку модуль state классифицирует соединения по ифнормации из contrack, то правило "-p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT" с соединениями на 25-й TCP-порт работать не будет. Правило нужно будет заменить на stateless правило проверяющее флаги, порты или адреса, а не состояние соединения.
Учитывая, что правила с  -j TARPIT обычно ставят только на незадействонванные TCP-порты, то никаких лишних телодвижений быть не должно: одно правило отключает отслеживание состояния для соединений,попадающих в ловушку , второе правило указывает -j TAPRIT в качестве цели и непосредственно защелкивает несанкционированные соединения в ловушке, а весь остальной трафик можно зазруливать с помощью -m state и conntrack.
Правило с целью  NOTRACK при включенном conntrack рекомендуется использовать для того, чтобы не расходовать ресурсы contrack на каждое соединение, захваченное TARPIT-ом, чтобы проблемы с исчерпанием ресурсов затрагивали только попавших в ловушку червей, спамеров и сканерщиков.
 
2 R
Спасибо за исчерпывающий ответ.

ЗЫ: Хороше когда праздники! Вот у root-а, например, много свободного времени на исчерпывающие ответы ;) Надо срочно придумать еще какой-нибудь вопрос :)
Страницы: 1
Читают тему (гостей: 1)