что за зараза у меня завелась?
emark 14 мая, 2008 - 12:16
Настоил 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
Напрягает то, что ничего фтпэшного запущено не было. Насколько я понимаю,
процесс (который это сгенерил) имеет рутовые права.
Что бы это могло быть?
»
- Для комментирования войдите или зарегистрируйтесь
адрес
адрес получателя - намесервер прова telenet.ru
А не с Вашим ли
А не с Вашим ли провайдером пытаеться соедениться?
Вот и интересно,
Вот и интересно, кто это делает? На машине в это время даже X не были запущены. И почему у него 21 порт в источнике?
Да и порт назначения в инете описывается как "часто атакуемые"
Попробуй когда
Попробуй когда будет коннект netstat --inet -p, авось че и найдешь.
читайте маны, они - рулезз.
Дык событие
Дык событие редкое (я же писал)
была недавно
была недавно тема, где человек так же ловил какой то процесс, там есть готовое решение.
Поиск в руки и вперед ))
Так и быть, за вас нашел http://www.gentoo.ru/node/10166 )))
А теперь
А теперь посмотри кто автор этой темы ;)
Нет там решения, процесс-то не известен.
Есть кое-какие идеи по поводу отлова... но вот уже
два дня эта зараза сидит и не ввысовывается.
На флаги пакета
На флаги пакета хоть бы кто глянул. RST же блин. Сканировать походу тебя пытаются на предмет открытого фтп, соотв. твой компутер отвечает RST пакетом (флаг у TCP пакета, сигнализирующий о закрытии сокета, размер окна как и положено тут в 0 ставится), как и должно быть когда порт закрыт. Вообще обычно на INPUT у себя ставят DROP политику и не открывают то, что не нужно. Тогда и RST отвечать не будет.
На флаги пакета
О... тогда несколько вопросов.
получается, что этот пакет инициализирует не приложение, а ядро?
У меня drop стоит и на INPUT и на OUTPUT для порта 6346...
А... понял, у меня в правилах для drop указан он как порт назначения.
Т.е. получается следующая последовательность действи: поскольку 21 порт у меня открыт, некто мне шлет пакет на него с 6346 порта, т.к. 21 порт в данный момент никем не используется, то ядро формирует ответ самостоятельно, который и перехватывается iptables по порту назначения (6346). Получается неочем беспокоится :)
Такс, попробую
Такс, попробую рассказать краткий курс "Как работает 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
(это если у тебя веб-сервер например весит публичный).
Вот, надеюсь не зря катал и кому-то окажется познавательно :)
Ну, я примерно
Ну, я примерно это себе так и представлял. ;)
Что касается 6346 порта, то его (видел в инете) относят к "часто атакуемым" (уж не знаю почему) и поэтому рекомендуют прикрыть как на вход, так и на выход.
ну так, grep 6346
ну так,
У тебя SPT = 21, это
У тебя SPT = 21, это значит, что конектится пытаются к тебе снаружи, похоже правда кто то пробует не открыт ли у тебя FTP