Вы здесь

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

что за зараза у меня завелась?

14 мая, 2008 - 12:16 — emark

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

May 12 19:38:49 gentux iptables: drop(3): IN= OUT=eth0 SRC=192.168.1.90 DST=87.224.249.252 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=21 DPT=6346 WINDOW=0 RES=0x00 ACK RST URGP=0

May 12 19:38:52 gentux iptables: drop(3): IN= OUT=eth0 SRC=192.168.1.90 DST=87.224.249.252 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=21 DPT=6346 WINDOW=0 RES=0x00 ACK RST URGP=0

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

Что бы это могло быть?

Форум: 
Системное администрирование
14 мая, 2008 - 12:41 — nwanomaly

адрес получателя - намесервер прова telenet.ru

14 мая, 2008 - 12:45 — hwline

А не с Вашим ли провайдером пытаеться соедениться?

—

discord: hwline#1904

constantly use: funtoo-linux, ubuntu

14 мая, 2008 - 17:34 — emark

hwline написал:
А не с Вашим ли провайдером пытаеться соедениться?

Вот и интересно, кто это делает? На машине в это время даже X не были запущены. И почему у него 21 порт в источнике?

Да и порт назначения в инете описывается как "часто атакуемые"

15 мая, 2008 - 09:44 — Storm

На флаги пакета хоть бы кто глянул. RST же блин. Сканировать походу тебя пытаются на предмет открытого фтп, соотв. твой компутер отвечает RST пакетом (флаг у TCP пакета, сигнализирующий о закрытии сокета, размер окна как и положено тут в 0 ставится), как и должно быть когда порт закрыт. Вообще обычно на INPUT у себя ставят DROP политику и не открывают то, что не нужно. Тогда и RST отвечать не будет.

15 мая, 2008 - 11:56 — emark

Storm написал:
На флаги пакета хоть бы кто глянул. RST же блин. Сканировать походу тебя пытаются на предмет открытого фтп, соотв. твой компутер отвечает RST пакетом (флаг у TCP пакета, сигнализирующий о закрытии сокета, размер окна как и положено тут в 0 ставится), как и должно быть когда порт закрыт. Вообще обычно на INPUT у себя ставят DROP политику и не открывают то, что не нужно. Тогда и RST отвечать не будет.

О... тогда несколько вопросов.
получается, что этот пакет инициализирует не приложение, а ядро?
У меня drop стоит и на INPUT и на OUTPUT для порта 6346...
А... понял, у меня в правилах для drop указан он как порт назначения.
Т.е. получается следующая последовательность действи: поскольку 21 порт у меня открыт, некто мне шлет пакет на него с 6346 порта, т.к. 21 порт в данный момент никем не используется, то ядро формирует ответ самостоятельно, который и перехватывается iptables по порту назначения (6346). Получается неочем беспокоится :)

16 мая, 2008 - 10:28 — Storm

Такс, попробую рассказать краткий курс "Как работает TCP/IP" :P
На твоем примере (но так работает любая TCP сессия) назовем тебя сервером, 87.224.249.252 - клиентом.
Клиент хочет подсоединиться к тебе на 21 порт (ftp). На клиенте создается сокет. ОС выбирается произвольный свободный порт с номером > 1024 (т.к. TCP сессии двунаправлены, нужен обратный адрес и порт, для программ этот процесс обычно прозрачен, все делает стек TCP/IP ОС). В данном случае порт был 6346, в следующий раз он может быть совершенно любой. Теперь стек формирует пакет TCP с флагами SYN (запрос на открытие соединения). В заголовках пакета он указывает порт назначения (21) и исходящий порт (тот самый произвольно открытый порт). Далее сервер получает пакет. Если порт, на который пришел пакет закрыт, стек сервера (который ес-но в ядре) автоматически по правилам TCP/IP формирует ответный пакет (который пойдет на исходящий порт, т.е. 6346) с флагами RST ACK, что означает что порт закрыт и сессию нужно прервать. Ну если бы порт был открыт, сервер должен был бы послать SYN ACK пакет и установить сессию. Все эти пакеты формируются драйвером TCP/IP (ядром). Вообще-то любой пакет впринципе формируется ядром, другое дело что ядро еще помнит какой процесс создал сокет, поэтому ты можешь видить какой процесс держит соединение когда оно работает. Порт закрыт - нет софта, соотв. нет и процесса.
Сканирование портов часто (ну техник много) эксплуатирует эти RST пакеты для проверки портов. Т.е. пришел RST - порт закрыт и его никто не слушает. Пришел ACK - порт открыт. Ничего не пришло - порт зафаерволлен и его возможно кто-то слушает, но не для нас =)
Теперь я надеюсь ты понял, что закрывать порт 6346 не нужно. Если не хочешь чтобы на закрытый порт от тебя уходили пакеты с RST, закрой входящий порт 21 правилом DROP. Пакет SYN к тебе будет отброшен ядром и соотв. ответный RST не будет сгенирирован.
iptables -A INPUT -p tcp --dport 21 -j DROP
Вообще обычно на всю цепочку INPUT ставят политику DROP, а затем открывают нужные порты.
iptables -P INPUT DROP
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
(это если у тебя веб-сервер например весит публичный).
Вот, надеюсь не зря катал и кому-то окажется познавательно :)

16 мая, 2008 - 12:17 — emark

Ну, я примерно это себе так и представлял. ;)

Что касается 6346 порта, то его (видел в инете) относят к "часто атакуемым" (уж не знаю почему) и поэтому рекомендуют прикрыть как на вход, так и на выход.

16 мая, 2008 - 13:37 — evadim

ну так,

grep 6346 /etc/services
gnutella-svc	6346/tcp
gnutella-svc	6346/udp

15 мая, 2008 - 09:53 — Casufi

У тебя SPT = 21, это значит, что конектится пытаются к тебе снаружи, похоже правда кто то пробует не открыт ли у тебя FTP

—

-----------------------------------------»
если хочешь послать в MAN, лучше промолчи.

Russian Gentoo Linux Community © 2005—2026
Gentoo — торговая марка Gentoo Foundation, Inc.
Сервер работает под управлением Gentoo Linux
Сайт работает под управлением CMS Drupal