Как я могу определить, какой процесс делает трафик UDP на Linux?
У Вас должен быть корневой домен быть Вашим основным доменом и установить Ваш рекорд CNAME для WWW для указания на. Затем все запросы www.example.com решат на example.com.
Аудит Linux может помочь. Это, по крайней мере, определит местоположение пользователей и процессов, делающих датаграммные сетевые соединения. Пакеты UDP являются датаграммами.
Во-первых, установите auditd платформа на Вашей платформе и гарантирует это auditctl -l возвраты что-то, даже если это говорит, что никакие правила не определяются.
Затем добавьте правило наблюдать системный вызов socket() и отметьте его для легкого открытия позже (-k). Я должен предположить, что Вы находитесь на 64-разрядной архитектуре, но можно занять место b32 вместо b64 если Вы не.
auditctl -a exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
Необходимо выбрать через страницы справочника и заголовочные файлы для создания этого, но что это получает, по существу этот системный вызов: socket(PF_INET, SOCK_DGRAM|X, Y), где третий параметр является неуказанным, но часто обнуляйте. PF_INET 2 и SOCK_DGRAM 2. Соединения TCP использовали бы SOCK_STREAM который установил бы a1=1. (SOCK_DGRAM во втором параметре может быть ORed с SOCK_NONBLOCK или SOCK_CLOEXEC, следовательно &= сравнение.) -k SOCKET наше ключевое слово, которое мы хотим использовать при поиске журналов аудита позже. Это может быть что-либо, но мне нравится сохранять это простым.
Позвольте нескольким моментам пройти и рассмотреть журналы аудита. Дополнительно, Вы могли вызвать несколько пакетов путем проверки с помощью ping-запросов хоста в сети, которая заставит поиск DNS происходить, который использует UDP, который должен сместиться наше контрольное предупреждение.
ausearch -i -ts today -k SOCKET
И вывод, подобный разделу ниже, появится. Я сокращаю его для выделения важных частей
type=SYSCALL ... arch=x86_64 syscall=socket success=yes exit=1 a0=2 a1=2 ... pid=14510 ... auid=zlagtime uid=zlagtime ... euid=zlagtime ... comm=ping exe=/usr/bin/ping key=SOCKET
В вышеупомянутом выводе мы видим что ping команда заставила сокет быть открытым. Я мог затем работать strace -p 14510 на процессе, если это все еще работало. ppid (идентификатор родительского процесса), также перечислен в случае, если это - сценарий, который порождает трудного ребенка много.
Теперь, если у Вас есть большой трафик UDP, это не будет достаточно хорошим, и необходимо будет обратиться к OProfile или SystemTap, оба из которых в настоящее время вне моих экспертных знаний.
Это должно помочь отнести узкие вещи в общем случае.
Когда Вы сделаны, удаляете контрольное правило при помощи той же строки, Вы раньше создавали его, только занимали место -a с -d.
auditctl -d exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
Можно использовать netstat, но Вам нужны правильные флаги, и он только работает, если процесс, который отправляет данные, все еще жив. Это не найдет трассировки чего-то, что кратко пришло в себя, отправленное трафик UDP, затем ушло. Это также требует локальных полномочий пользователя root. Это сказало:
Вот я начинающий ncat на моем локальном хосте, отправляя трафик UDP для портирования 2345 на (несуществующей) машине 10.11.12.13:
[madhatta@risby]$ ncat -u 10.11.12.13 2345 < /dev/urandom
Вот некоторый вывод tcpdump, доказывающий, что трафик идет:
[root@risby ~]# tcpdump -n -n port 2345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:41:32.391750 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.399723 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.401817 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.407051 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.413492 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
12:41:32.417417 IP 192.168.3.11.57550 > 10.11.12.13.2345: UDP, length 8192
Вот полезный бит, с помощью netstat с флагом-a (для наблюдения деталей порта) и флаг-p для наблюдения идентификационных деталей процесса. Это - флаг-p, который требует полномочий пользователя root:
[root@risby ~]# netstat -apn|grep -w 2345
udp 0 0 192.168.3.11:57550 10.11.12.13:2345 ESTABLISHED 9152/ncat
Как Вы видите, pid 9152 перебирается как наличие соединения, открытого для портирования 2345 на указанном удаленном хосте. Netstat услужливо также выполняет это через PS и говорит мне, что имя процесса ncat.
Надо надеяться, это несколько полезно.
Я использовал бы сетевого сниффера как tcpdump или wireshark для просмотра запросов DNS. Содержание запроса может дать общее представление о том, какая программа выпускает их.
У меня была точно такая же проблема, и, к сожалению, провел аудит мало что сделал для меня.
У меня был трафик с некоторых моих серверов на DNS-адреса Google, 8.8.8.8 и 8.8.4.4 . Теперь у моего сетевого администратора умеренное ОКР, и он хотел очистить весь ненужный трафик, поскольку у нас есть внутренние кеши DNS. Он хотел отключить исходящий порт 53 для всех, кроме этих кеш-серверов.
Итак, после неудачной попытки с auditctl , я копался в systemtap . Я придумываю следующий сценарий:
# cat >> udp_detect_domain.stp <<EOF
probe udp.sendmsg {
if ( dport == 53 && daddr == "8.8.8.8" ) {
printf ("PID %5d (%s) sent UDP to %15s 53\n", pid(), execname(), daddr)
}
}
EOF
Затем просто запустите:
stap -v udp_detect_domain.stp
Это результат, который я получил:
PID 3501 (python) sent UDP to 8.8.8.8 53
PID 3501 (python) sent UDP to 8.8.8.8 53
PID 3506 (python) sent UDP to 8.8.8.8 53
Вот и все! После изменения resolv.conf эти PID не приняли изменений.
Надеюсь, это поможет :)
Вот опция systemtap, использующая зонды netfilter, доступные в stap версии 1.8 и новее. См. Также man probe :: netfilter.ip.local_out .
# stap -e 'probe netfilter.ip.local_out {
if (dport == 53) # or parametrize
printf("%s[%d] %s:%d\n", execname(), pid(), daddr, dport)
}'
ping[24738] 192.168.1.10:53
ping[24738] 192.168.1.10:53
^C
Имейте в виду, что при использовании autitctl, nscd, например, использует немного другой параметр в системном вызове сокета при выполнении запроса DNS:
socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP)
Итак чтобы убедиться, что вы перехватываете эти запросы в дополнение к тем, которые были упомянуты выше, вы можете добавить дополнительный фильтр с тем же именем, если хотите:
auditctl -a exit,always -F arch=b64 -F a0=2 -F a1=2050 -S socket -k SOCKET
Здесь 2050 - побитовое ИЛИ SOCK_DGRAM ( 2) и SOCK_NONBLOCK (2048).
Затем поиск найдет оба этих фильтра с одним и тем же ключом, SOCKET :
ausearch -i -ts today -k SOCKET
Шестнадцатеричные значения для констант сокета, которые я нашел здесь: https://golang.org/pkg/syscall/#pkg-constants
Поскольку у меня нет очков репутации для комментариев, я добавил это.