LINUX.ORG.RU
ФорумAdmin

Забивает таблицу маршрутизации

 ,


0

1

Доброго времени форумчане. Извиняюсь дико пред вами ибо я ламер в linux. Попробую объяснить проблемку.

Есть сервер на OpenSuse, который включает в себя организацию работы всего предприятия. Стоят 4е сетевые карты (LAN+VPN+PPPoE+выделенный канал). Пользователей в сети порядка 100.

Беда в том, что на выделенном канале (на нем крутится FTP-сервер) стоит статический IP-адрес, и на него судя по всему валятся запросы из солнечного Китая. Погуглив значение ошибки «nf_conntrack: table full, dropping packet» докопался, что NAT-таблицу забивает под завязку и потом идет дроп пакетов именно на выделенный канал.

Гугл сказал, что надо посмотреть саму таблицу (xxx.xxx.xxx.xxx - наш внешний статический IP-адрес):

cat /proc/net/nf_conntrack | less

ipv4 2 tcp 6 115 SYN_SENT src=xxx.xxx.xxx.xxx dst=115.238.241.15 sport=33836 dport=8523 [UNREPLIED] src=115.238.241.15 dst=xxx.xxx.xxx.xxx sport=8523 dport=33836 mark=0 zone=0 use=2
ipv4 2 tcp 6 114 SYN_SENT src=xxx.xxx.xxx.xxx dst=115.238.241.15 sport=31589 dport=8523 [UNREPLIED] src=115.238.241.15 dst=xxx.xxx.xxx.xxx sport=8523 dport=31589 mark=0 zone=0 use=2
ipv4 2 tcp 6 114 SYN_SENT src=xxx.xxx.xxx.xxx dst=115.238.241.15 sport=16437 dport=8523 [UNREPLIED] src=115.238.241.15 dst=xxx.xxx.xxx.xxx sport=8523 dport=16437 mark=0 zone=0 use=2
ipv4 2 tcp 6 112 SYN_SENT src=xxx.xxx.xxx.xxx dst=124.228.91.80 sport=61983 dport=8523 [UNREPLIED] src=124.228.91.80 dst=xxx.xxx.xxx.xxx sport=8523 dport=61983 mark=0 zone=0 use=2
ipv4 2 tcp 6 114 SYN_SENT src=xxx.xxx.xxx.xxx dst=115.238.241.15 sport=14559 dport=8523 [UNREPLIED] src=115.238.241.15 dst=xxx.xxx.xxx.xxx sport=8523 dport=14559 mark=0 zone=0 use=2
ipv4 2 tcp 6 115 SYN_SENT src=xxx.xxx.xxx.xxx dst=115.238.241.15 sport=19289 dport=8523 [UNREPLIED] src=115.238.241.15 dst=xxx.xxx.xxx.xxx sport=8523 dport=19289 mark=0 zone=0 use=2
ipv4 2 tcp 6 114 SYN_SENT src=xxx.xxx.xxx.xxx dst=115.238.241.15 sport=50028 dport=8523 [UNREPLIED] src=115.238.241.15 dst=xxx.xxx.xxx.xxx sport=8523 dport=50028 mark=0 zone=0 use=2
ipv4 2 tcp 6 113 SYN_SENT src=xxx.xxx.xxx.xxx dst=124.228.91.80 sport=2626 dport=8523 [UNREPLIED] src=124.228.91.80 dst=xxx.xxx.xxx.xxx sport=8523 dport=2626 mark=0 zone=0 use=2
ipv4 2 tcp 6 119 SYN_SENT src=xxx.xxx.xxx.xxx dst=43.241.50.3 sport=45804 dport=7391 [UNREPLIED] src=43.241.50.3 dst=xxx.xxx.xxx.xxx sport=7391 dport=45804 mark=0 zone=0 use=2

Далее почитал о том, как забанить эти IP-адреса. Банил сразу по подсетям

iptables -I INPUT -s ***.0.0.0/8 -j DROP

Результата нет. Все равно забивает таблицу этими запросами от Китая. Может я чего-то упустил или не в курсе каких-то тонкостей?

Самое простое увеличить размер таблицы conntrack

например: sysctl net.netfilter.nf_conntrack_max=524288

tugrik ★★ ()

Вас досят, не вы первый, не вы последний с кем это происходит. Скорее всего вам нужна таблица FORWARD, а не INPUT. По портам что-то не похоже на стандартный ftp, возможно надо более продумано отнестись к организации файрвола и запретить трафик на неоткрытые порты.

gvtlor ()
Ответ на: комментарий от gvtlor

Про INPUT vs FORWARD, xxx.xxx.xxx.xxx - это же локальный интерфейс сервера??? тогда да, INPUT... просмотрел смотрите все правила

gvtlor ()
Ответ на: комментарий от gvtlor

xxx.xxx.xxx.xxx - это внешний IP-адрес, который дает нам провайдер. Он жестко вбивается в сетевуху.

Увеличивать таблицу пробовал - забивает таблицу все равно.

shkodni4ek ()

какое отношение ddos имеет к SNAT?
разве это не 100500 исходящих соединений, которые не устанавливаются до конца, и потому забивают таблицу трансляций? зверье?

anonymous ()
Ответ на: комментарий от anonymous

[qoute] разве это не 100500 исходящих соединений [/qoute] Исходящих? То есть «точкой отправления» кучи исходящих соединений являемся мы сами?

shkodni4ek ()
Ответ на: комментарий от shkodni4ek

Походу аноним прав, ддос идет с твоей машины.

Deleted ()
Ответ на: комментарий от Deleted

Однако... А как бы «самого себя» теперь вычислить? Что за сервис/служба ддосит?

shkodni4ek ()
Ответ на: комментарий от shkodni4ek

Посмотри запущенные процессы. Судя по nf_conntrack, источник - сам шлюз.

Deleted ()
Ответ на: комментарий от anonymous

«netstat -npt» показывает только локальные IP-адреса (192.168.xxx.xxx) + VPN-адреса (10.10.xxx.xxx).
Есть только подозрительная одна запись: «tcp 0 0 xxx.xxx.xxx.xxx:58479 107.xxx.xxx.xxx:3007 ESTABLISHED 771/echo „find“»

shkodni4ek ()
Ответ на: комментарий от shkodni4ek

странно, должна быть куча записей со статусом SYN_SENT, каждая из которых соответствует записи в nf_conntrack
может что-то не то делаешь? или волна прошла, и уже трафика нет? nf_conntrack не очистился?

anonymous ()
Ответ на: комментарий от anonymous

Кучи записей не будет, если через пакеты генерируют через SOCK_RAW. В netfilter они есть, потому что это отдельная подсистема. В этом случае либо у процесса есть права CAP_NET_RAW, либо он запущен из-под рута.

Deleted ()
Ответ на: комментарий от Deleted

если через пакеты генерируют через SOCK_RAW

то пожалуй, но зачем так делать в эксплоите? :)

2ТС:

# netstat -nlpt | grep 58479

anonymous ()
Ответ на: комментарий от anonymous

Потому что так быстрее за счет того, что каждый не регистрируется новое соединение.

Deleted ()
Ответ на: комментарий от Deleted

ну, если цель — исходящий веером син-флуд, то понятно; просто я не понимаю, зачем оно нужно само по себе? думал, что это лишь побочный эффект какого-то более понятного взлома

anonymous ()
Ответ на: комментарий от anonymous

Ни одной записи нет со статусом SYN_SENT. Волна не прошла. Постоянна забита таблица. Меняются только IP.

Нашел еще одну собаку. Сделал «tcpdump -i inet», увидал интересную вещь. VIP.by - это выдуманное название.

17:31:27.490428 IP vpi.by.salient-dtasrv > 123.206.30.150.http: Flags, seq 354543393:354543401, win 62934, length 8
17:31:27.490441 IP vpi.by.46219 > 123.206.30.150.http: Flags, seq 3029039723:3029039731, win 62554, length 8
17:31:27.490456 IP vpi.by.63438 > 123.206.30.150.http: Flags, seq 4157487623:4157487631, win 63168, length 8
17:31:27.490468 IP vpi.by.17020 > 123.206.30.150.http: Flags, seq 1115446608:1115446616, win 64135, length 8
17:31:27.490481 IP vpi.by.31348 > 123.206.30.150.http: Flags, seq 2054425178:2054425186, win 62143, length 8

#cat /etc/resolv.conf

nameserver 192.168.16.5

192.168.16.5 - это наш AD+DNS локальный домен.

shkodni4ek ()
Ответ на: комментарий от anonymous

зачем оно нужно само по себе?

Для пинга, например. Ну и вообще, если ты хочешь отправлять в сеть что-то кастомное.

2ТС: лучший вариант - выключить машину, загрузиться с livecd, проверить места, откуда могут загружаться программы после старта системы (/etc/rc.local, /etc/init.d/, крон и пр.), проверить файлы установленных програм через rpm -Va, также проверить наличие левых модулей ядра (лучше его просто переустановить). После этого сменить пароль руту и обновиться.

Ну или сразу переустановка ОС.

Deleted ()
Ответ на: комментарий от Deleted

Может быть совпадение, а может быть и не совпадение. Прогнал сервер AD+DNS «drweb cureit» - ничего не нашел, кроме «AMMYY ADMIN» (аналог Teamviewer). Удалил на всякий случай. Забанил подозрительный IP Американский

iptables -I INPUT -s 107.0.0.0/8 -j DROP

И все...теперь таблица содержит всего лишь 500 записей. А может быть просто кто-то выключил рабочий комп)
Завтра отпишусь. Сегодня еще понаблюдаю.

shkodni4ek ()
Ответ на: комментарий от shkodni4ek

tcp 0 0 xxx.xxx.xxx.xxx:58479 107.xxx.xxx.xxx:3007 ESTABLISHED 771/echo „find“

Вон у тебя процесс малварный висит. Завтра с другого адреса придут и все по новой. Лучше почистить машину.

Deleted ()

в таком случае банить нужнов raw а не в filter

«iptables -t raw -I OUTPUT -s .... -j DROP» - дропнутое в raw не попадет в conntrack

vel ★★★★★ ()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от shkodni4ek

У тебя бэкдор на машине, предположительно на 58479 порту tcp. Собственно, что ты хочешь дальше? Если изучить эксплоит (что делает, как проник), то тебе показывали путь, но ты вместо этого стал играть доктором, tcpdump'ом и фильтрами срубил управляющий коннект. Если просто избавиться, ни в чем не разбираясь, то совет тоже есть.

anonymous ()
Ответ на: комментарий от Deleted

Для пинга, например. Ну и вообще, если ты хочешь отправлять в сеть что-то кастомное.

Что такое RAW_SOCKET, я знаю. Я не понимаю, зачем организовывать исхоящий веерный син-флуд на рандомные адреса и порты, которые даже никто не слушает. Неужели только для того, чтобы оставить сетку ТС без инета на пару часов? Как-то это мелко. Хотя и указывает на кого-то из своих, возможно, бывших.

anonymous ()
Ответ на: комментарий от anonymous

ТСу тут никто специально навредить не хочет. Его машину используют для ддоса кого-то другого, попутно ложа и его самого, но не умышленно :)

Deleted ()

Вот никто не обратил внимание на:

ибо я ламер в linux.
Есть сервер на OpenSuse, который включает в себя организацию работы всего предприятия
который включает в себя организацию работы всего предприятия

организацию работы всего предприятия

ТС Тут есть другой раздел Job

anc ★★★★★ ()
Ответ на: комментарий от Deleted

А dst-адресов почему несколько? Атака на распределенный сервис? Так там и dst-портов как минимум два, а в полном выхлопе, наверно, и еще больше. Или там сразу несколько атак с одного ботнета?

anonymous ()
Ответ на: комментарий от anonymous

Атака на распределенный сервис?

Скорее всего. А может и несколько атак.

Deleted ()
Ответ на: комментарий от anonymous

Спасибо больше всем. Реально помогли. В общем таблицу больше не забивает. Но вредитель по прежнему долбиться на свой адрес.

tcp 0 1 xxx.xxx.xxx.xxx:43085 107.xxx.xxx.xxx:3007 SYN_SENT 771/echo «find»

Мало того, что он висит, так он еще и проц подгружает

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
771 root 20 0 59844 1372 412 S 40.20 0.034 2586:12 hquuepdxgh

Как мне изгнать эту пакость?

shkodni4ek ()
Ответ на: комментарий от shkodni4ek

для оформления кода или выхлопа юзай 'code', а не 'quote'

покажи:

# netstat -napt | grep 771
# netstat -napt | grep 43085

anonymous ()
Ответ на: комментарий от anonymous

Первая команда нашла вот это:

tcp        0      1 xxx.xxx.xxx.xxx:46191    107.160.40.139:3007     SYN_SENT    771/echo "find"
Вторая команда ничего не нашла

shkodni4ek ()
Ответ на: комментарий от shkodni4ek

вот так найдешь, где лежит бинарь зверя:

# ll /proc/771/exe
а дальше полученное имя файла поищи внутри всех файлов в /etc — так найдешь, как он загружается после ребута (если он так вообще делает)

anonymous ()
Ответ на: комментарий от anonymous

Ага...спасибо. Вот что получил на выходе.

lrwxrwxrwx 1 root root 0 Jan 16 08:10 /proc/771/exe -> /usr/bin/hquuepdxgh

Сейчас посижу покапаюсь. Может и найду откуда у него растут ноги.

shkodni4ek ()
Ответ на: комментарий от shkodni4ek

погляди этот файл внутри, возможно это не бинарь, а скрипт; если так, то залей его, пожалуйста, куда-нибудь на пастебин, например

по команде:

# stat /usr/bin/hquuepdxgh
можно выяснить, когда этот файл появился на твоем сервере, и вокруг этого времени смотреть системные логи на предмет подозрительной активности, чтобы попытаться предположить, как он проник на машину

PS: имя файла не гуглится, возможно оно случайное и потому разное на каждой взломанной машине

anonymous ()
Ответ на: комментарий от shkodni4ek

если еще не прибил этот процесс, то вот так:

# ps auxwwf | less
можно посмотреть цепочку его родительских процессов (если есть), что возможно поможет понять, кто его запустил

anonymous ()
Ответ на: комментарий от anonymous

Начал я его искать в «/usr/bin/hquuepdxgh»...а его там уже и нету. И след простыл. Однако в «/etc/init.r/rc1.d» нашелся старый «hquuepdxgh» и еще один, но они пустые.
Посмотрел netstat и top. Теперь он носит совершенно другое имя.

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
23383 root      20   0   25888    864    412 S 40.86 0.021   3:42.52 ehwrvngtlz

Родительских процессов нет. Раз поменялся процесс и имя файла, то смотреть дату создания файла нет смысла.

Вот что содержит файл. Это лишь его малая часть. Там огромная куча строк.

080ad950 t .L108
080ad990 t .L113
080ad9f8 t .L114
080ada30 t .L115
...
08098d80 T _IO_vfscanf

shkodni4ek ()
Ответ на: комментарий от shkodni4ek

это какой файл? ты же сказал, что файла уже нет

anonymous ()
Ответ на: комментарий от shkodni4ek

и почему процесс поменял имя? ты руками прибил предыдущий? или ребут сделал?

anonymous ()
Ответ на: комментарий от anonymous

Процесс не прибивал. Единственное, это смотрел содержимое файла. Файла нет с прошлым названием. Появился новый файл «ehwrvngtlz». И «/etc/init.d» так же появились новые файлы «ehwrvngtlz».

shkodni4ek ()
Ответ на: комментарий от shkodni4ek

И «/etc/init.d» так же появились новые файлы «ehwrvngtlz».

покажи их

anonymous ()
Ответ на: комментарий от anonymous

«cat /etc/init.d/ehwrvngtlz»

#!/bin/sh
# chkconfig: 12345 90 90
# description: ehwrvngtlz
### BEGIN INIT INFO
# Provides:             ehwrvngtlz
# Required-Start:
# Required-Stop:
# Default-Start:        1 2 3 4 5
# Default-Stop:
# Short-Description:    ehwrvngtlz
### END INIT INFO
case $1 in
start)
        /usr/bin/ehwrvngtlz
        ;;
stop)
        ;;
*)
        /usr/bin/ehwrvngtlz
        ;;
esac

Ну вот...5 минут назад процесс снова поменял свой PID и появились новые файлы с новым именем.

shkodni4ek ()
Ответ на: комментарий от shkodni4ek

ну, похоже, вся логика в бинаре
нужно удалить этот файл /etc/init.d/ehwrvngtlz, и потом прибить процесс:

# killall -9 ehwrvngtlz
но способ проникновения неизвестен, и может повториться
система свежая? апдейты накатываются?

anonymous ()
Ответ на: комментарий от anonymous

еще вот так можно посмотреть все строки, которые встречаются в бинаре, и если там окажется что-то похожее на подпись или название, то гуглить в инете:

# strings /usr/bin/hquuepdxgh

anonymous ()
Ответ на: комментарий от anonymous

Прибивать пока не буду, т.к. не вредит сейчас кроме нагрузки на проц.
Система стоит порядка 6 лет. Апдейт ставился около года назад, если не ошибаюсь.

А на что похожа подпись в бинаре?

shkodni4ek ()
Ответ на: комментарий от shkodni4ek

на «developed by SuperHacker»

а вообще, вам в контору настоящий админ нужен, хотя бы приходящий; тебе еще рано

anonymous ()
Ответ на: комментарий от anonymous

Да был у нас админ, который конкретно этим сервером занимался, но он уехал на ПМЖ в США. Да прибудет со мной сила.
Спасибо за помощью. Я могу сюда еще писать в случае еще чего? или закрывать тему?

shkodni4ek ()
Ответ на: комментарий от shkodni4ek

Раз пожар потушили, я за темой следить прекращаю. Хотя если напишешь, кто-нибудь прочитает и ответит.

anonymous ()
Ответ на: комментарий от shkodni4ek

Прибивать пока не буду, т.к. не вредит сейчас кроме нагрузки на проц.

Перечитал все. Вы больны? Только разворачивать из бэкапа. Или если у вас его нет настраивать заново.
Ваш же ответ это: «я год сплю с портовыми шлюхами без презерватива, и не хожу к венерологу»

anc ★★★★★ ()
Ответ на: комментарий от anc

Да ясно же, что никакого бекапа нет, переустановить ос и все настроить он не сможет, да даже обновления там делают раз в год. Он, наверно, и о взломе то начальству не доложил. А если и доложил, то не сказал же он, что это лор его руками решил проблему, и что в контору им настоящий админ нужен вместо него. Сидит тихо, и делает вид что админит. Видишь, даже такой факап выше среднего смог пережить.

Но оставлять вирусный процесс работать - это уже, конечно, перебор.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.