дамп tcp-з'єднання без tcpdump

Iptables має функцію налагодження, яка також може бути використана для аналізу трафіку.

Рішення описано на URL-адресі нижче.

Debugging rules in Iptables

Також варто прочитати наступну URL-адресу, щоб налаштувати запис виводу трасування у файл за вашим вибором.

http://backreference.org/2010/06/11/iptables-debugging/

Я б не вважав це рішення рівним tcpdump, але це можна зробити за допомогою мінімальної установки Centos. Необхідно бути обережним, щоб не заповнити диск журналами, оскільки tcpdump набагато ефективніший у використанні диска. Вимкніть реєстрацію, якщо вона не потрібна.

Ви можете скористатися наступним як основний шаблон у вашому сценарії.

# Logging
log(){
SOURCE=a.b.c.d (IP address)
$IPT -A INPUT   -s $SOURCE -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "In: "
$IPT -A OUTPUT  -s $SOURCE -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "Out: "
$IPT -A FORWARD -s $SOURCE -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "Fw: "
$IPT -t nat -A POSTROUTING -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "Nat: "
}
#log  (remove comment to enable)

trace(){
iptables -t raw -A PREROUTING -p tcp  -j TRACE
iptables -t raw -A OUTPUT     -p tcp  -j TRACE
}
#trace (remove comment to enable)

Я дійсно намагаюся отримати tcpdump. При цьому, деякі альтернативи, щоб побачити, чи існує певне з'єднання для IP-адреси:

strace:

[[email protected]: ~] strace -e trace=network nc 1.2.3.4 1234
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("1.2.3.4")}, 16) = -1 EINPROGRESS (Operation now in progress)

lsof:

[[email protected]: ~] nc 1.2.3.4 1234 &
[1] 11434
[[email protected]: ~] lsof -p 11434
....
nc      11434 kbrandt    3u  IPv4 4543149      0t0     TCP 10.7.0.78:58886->1.2.3.4:search-agent (SYN_SENT)

netstat:

[[email protected]: ~] nc 1.2.3.4 1234 &
[1] 11486
[[email protected]: ~] sudo netstat -a -p | grep 11486
tcp        0      1 10.7.0.78:58891             1.2.3.4:search-agent        SYN_SENT    11486/nc

Якщо вам потрібне спеціальне програмне забезпечення для виконання своєї роботи, і вам не дозволено, ви або не робите хороший бізнес-кейс , або продаєте свої ідеї потрібним користувачам ... або Ви не контролюєте цю систему ...

Якщо мені доручено щось зробити, і потрібна інформація про налагодження/усунення неполадок, яку вам потрібна в цьому випадку, я використовую правильний інструмент. Ймовірно, tcpdump або tshark . Так, це шматки програмного забезпечення, але я вважаю, що вони більше необхідних утиліт . Насправді, це утиліти, які можуть бути встановлені або завантажені в систему тимчасово і видалені без інциденту (чи є знімний носій опцією? ... підказка )

Але річ у тому, що обхідний шлях до політики компанії, ймовірно, потребує більше зусиль, ніж отримання схвалення для цього випадку використання.

Кайл запропонував кілька чудових варіантів. Ще одне - використовувати iptables :

[[email protected] ~]$ sudo iptables -I OUTPUT -d 1.2.3.4/32
...
[[email protected] ~]$ sudo iptables -L OUTPUT -n -v
Chain OUTPUT (policy ACCEPT 105 packets, 35602 bytes)
 pkts bytes target  prot opt in  out  source      destination
   87 33484 LOG     all  --  *   *    0.0.0.0/0   1.2.3.4     LOG flags 0 level 4

Це, по суті, правило бухгалтерського обліку. Він явно не дозволяє або забороняє трафік, тому застосовується політика за замовчуванням для ланцюжка OUTPUT (за замовчуванням ACCEPT). Однак будь-який відповідний пакет збільшить лічильники для правила.

Можна додатково записати деталі про пакет з параметром -j LOG :

[[email protected] ~]$ sudo iptables -I OUTPUT -d 1.2.3.4/32 -j LOG
...
[[email protected] ~]@ dmesg | grep 1.2.3.4 | tail -1
IN= OUT=eth0 SRC=192.168.1.1 DST=1.2.3.4 LEN=100 TOS=0x10 PREC=0x00 TTL=64 ...

Журнали перейдуть до засобу ведення журналу ядра, тому він повинен з'являтися в/var/log/messages на похідних Red Hat та /var/log/kern.log на похідні Debian. Він також буде видно у виводі dmesg , як показано на малюнку. Однак, на відміну від tcpdump , він не буде реєструвати повний вміст пакета, а лише вміст заголовка пакета.

Оскільки ваш сервер підключається до певного ІВ, я припускаю, що це буде до порту, який ви також маєте знати?

У будь-якому випадку, netstat або ss розроблені для того, щоб робити те, що вам потрібно. Ви можете зробити те ж саме з будь-якою командою:

netstat -n -t | awk '{print $5}' | grep A.B.C.D:n
ss      -n -t | awk '{print $5}' | grep A.B.C.D:n

де A.B.C.D представляє адресу IPv4, а n - номер порту, з яким ваш сервер підключається на віддаленій стороні. Наприклад:

ss      -n -t | awk '{print $5}' | grep 10.137.54.22:3389

Або, якщо потрібно знати, що підключення виконано:

ss      -n -t | awk '{print $5}' | grep -q 10.137.54.22:3389 && echo "CONNECTION MADE"

Якщо ви не знаєте номер порту, до якого ви намагаєтеся підключитися, то завдання буде складніше, оскільки TCP відкриє порт з обох сторін розмови для пакетів даних і ACK. У цьому випадку ви можете просто grep для IP-адреси, щоб показати, що будь-яке підключення було зроблено, чи то до чи від.

Нарешті, ви можете зробити це для вмісту вашого серця, щоб використовувати його як інструмент моніторингу:

while true; do
    ss -n -t | awk '{print $5}' | grep -q A.B.C.D:n && \
        echo "CONNECTION MADE" && \
        exit 0
    sleep 1
done