Як я можу знайти загальну кількість з'єднань TCP для даного порту та періоду часу за допомогою IP?

On a Linux system there are plenty of methods for listing the current TCP connections for a given port by connecting IP but: how can I count the total number of connections to a port per source IP for period of time?

5
Це те, що я хотів би спостерігати протягом певного періоду часу під час тестування підключень під час виконання програми.
додано Автор peacetype, джерело
Про який період часу ви говорите? Останні 5 хвилин або довгий термін (місяці/роки)?
додано Автор tapananand, джерело

6 Відповіді

Увімкніть iptables і встановіть його на LOG для вхідних з'єднань. Приклад правила:

 -A INPUT --state NEW -p tcp --dport 4711 -j LOG

(де 4711 - це порт, який потрібно відстежувати).

Потім запустіть результуючий журнал через будь-який скрипт, який вам подобається, який може зробити резюме для вас.

13
додано
-m state , мабуть, потрібно використовувати при використанні iptables-1.4.7-4.el6.i686.
додано Автор Tim Howland, джерело
Ця відповідь працює і є найпростішою для мене в цій ситуації. Якщо б я не зміг змінити iptables, метод tcpdump також працював би.
додано Автор peacetype, джерело
@quadruplebucky Іноді трапляється, що люди роблять помилку, коли вводять команду. У цьому випадку, запитуючи, що вони означають, це добре, хоча краще, якщо це зроблено ввічливо.
додано Автор Jenny D, джерело
Не намагаючись бути грубим, прошу вибачення. Я просто не розумів, що ви мали на увазі, як я сказав вище, iptables рідко мій інструмент вибору.
додано Автор rightfold, джерело
Якщо я збираюся використовувати iptables для цього, я точно не буду використовувати "tcp" як модуль для прапора -m. Навіть якщо б воно існувало, що б це означало?
додано Автор rightfold, джерело

Ви можете використовувати tcpdump для реєстрації всіх SYN (без ACK) пакетів:

tcpdump "dst port 4711 and tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn"

або реєструвати всі пакети SYN + ACK (встановлені з'єднання):

tcpdump "src port 4711 and tcp[tcpflags] & (tcp-syn|tcp-ack) == (tcp-syn|tcp-ack)"

А потім об'єднайте його з wc -l для підрахунку всіх рядків

Вам також знадобиться спосіб вимірювання фіксованих періодів часу (можна було б, щоб cron просто надсилав йому SIGINT через регулярні проміжки часу, tcpdump буде рахувати байти і пакети, але тільки час журналу)

Оновлення: не потрібно говорити, зверніться до сторінки man tcpdump і розгляньте можливість використання деяких параметрів, таких як: -i (слухати лише один інтерфейс), -p ( вимкнути безладний режим, менш інвазивний), або деякі параметри виводу. Tcpdump потребує дозволів на кореневу систему, і вам не сподобається ваш бос, тому що це свого роду хакерський інструмент. З іншого боку, вам не потрібно нічого чіпати у вашій системі, щоб запустити її (на відміну від рішення iptables LOG )

Зауважте також невелику різницю у файлі src/dsk у фільтрі. Якщо ви ловите пакети SYN + ACK і хочете підрахувати підключення до сервера з порту 4711, вам знадобиться src. Якщо ви ловите пакети SYN +! ACK за той же результат, вам знадобиться dst. Якщо підрахувати з'єднання на самому сервері, завжди потрібно використовувати зворотне.

7
додано
Ви маєте рацію, я хочу змінити подвійні лапки на одинарні лапки. введіть "tcpdump single quotes" у ваш улюблений движок, щоб краще зрозуміти. Це не банально, і ви абсолютно перебуваєте в оболонці. Ні sol8, ні windows приходять з bash або tcpdump, для чого він коштує.
додано Автор rightfold, джерело
додано Автор rightfold, джерело
@DanielAdler Ваш другий приклад є синтаксично неправильним. Він відкидає все, що є син або ack, тому що він відповідає будь-якій стороні == і вважає, що ця умова є булевою правдою. І доцільно уникати подвійних лапок, тому що ви дійсно можете просто працювати на коробці sol8. І коробки посилають мені syns весь час, які не ростуть, щоб бути зв'язками.
додано Автор rightfold, джерело
@DanielAdler Я серйозно п'яний на босів, які називають tcpdump і nmap "хакерські інструменти", тому у мене їх більше немає (боси, а не інструменти). Ваша думка добре прийнята, але ви можете йти вперед і реєструвати плавники теж, і ви все одно будете отримувати невелике ціле число, щоб розділити його на ваш рол-ваш-власний; але насправді не витрачав надто багато часу, думаючи про це. Я до сих пір є свого роду хлопцем.
додано Автор rightfold, джерело
@quadruplebucky знову помиляється: логічний синтаксис правильний, але щось змінити в src/dst частині фільтра
додано Автор Daniel Alder, джерело
@quadruplebucky ви дійсно хочете змінити подвійні лапки на одинарні лапки. Але врахуйте: ми не говоримо про оболонки. Ви можете використовувати іншу оболонку на вашій машині Solaris, але також Solaris має оболонку bash. Якщо я зміню цю річ, користувач Windows прийде і скаже, що окремі лапки не підтримуються його системою. А потім, я повинен повернутися назад? Отже, що є справжньою причиною наполягати на цій банальності? Було б краще для вас, щоб обережно підготувати моє ім'я і не писати його в друкарському помилку наступного разу ...
додано Автор Daniel Alder, джерело
@quadruplebucky Тільки чотири символи, які я знаю, можуть бути проблематичними: ",", $,!. Будьте більш конкретними, якщо ви дійсно хочете допомогти спільноті (і мені). Google знаходить workrobot.com/sysadmin/security/tcpdump_expressions.html , у якому сказано:" У командному рядку TCPDUMP рекомендується розмістити їх всередині окремих лапок (UNIX) або подвійних лапок (Windows), щоб уникнути плутанини і можливих помилок розбору. "
додано Автор Daniel Alder, джерело
@quadruplebucky Якщо підрахувати як пакети SYN, так і SYN + ACK, і розділити їх на 2, то замість 1 або 2 ви отримаєте 1,5 замість одного, але один не працюватиме (тільки приклад)
додано Автор Daniel Alder, джерело
@quadruplebucky: ви мали рацію: мій опис не відповідав команді. але з вашим редагуванням встановлені з'єднання підраховуються двічі, це не те, що ми хочемо.
додано Автор Daniel Alder, джерело

Рішення SystemTap

Сценарій наткнувся на приклад tcp_connections.stp :

#!/usr/bin/env stap
# To monitor another TCP port run:
#     stap -G port=80 tcp_connections.stp
# or
#     ./tcp_connections.stp -G port=80
global port = 22
global connections

function report() {
  foreach (addr in connections) {
    printf("%s: %d\n", addr, @count(connections[addr]))
  }
}

probe end {
  printf("\n=== Summary ===\n")
  report()
}

probe kernel.function("tcp_accept").return?,
      kernel.function("inet_csk_accept").return? {
  sock = $return
  if (sock != 0) {
    local_port = inet_get_local_port(sock)
    if (local_port == port) {
      remote_addr = inet_get_ip_source(sock)
      connections[remote_addr] <<< 1
      printf("%s New connection from %s\n", ctime(gettimeofday_s()), remote_addr)
    }
  }
}

Вихід:

[[email protected] ~]# ./tcp_connections.stp -G port=80
Mon Mar 17 04:13:03 2014 New connection from 192.168.122.1
Mon Mar 17 04:13:04 2014 New connection from 192.168.122.1
Mon Mar 17 04:13:08 2014 New connection from 192.168.122.4
^C
=== Summary ===
192.168.122.1: 2
192.168.122.4: 1

рішення

Або запустіть програму під strace:

strace -r -f -e trace=accept -o /tmp/strace ${PROGRAM} ${ARGS}

або відстежувати вже запущену програму:

strace -r -f -e trace=accept -o /tmp/strace -p ${PID_OF_PROGRAM}

-r prints a relative timestamp upon entry to each system call in case it's needed later for extra performance analysis. -f traces child processes and it might not be needed.

Вихід виглядає приблизно так:

999        0.000000 accept(3, {sa_family=AF_INET, sin_port=htons(34702), sin_addr=inet_addr("192.168.122.4")}, [16]) = 5
999        0.008079 --- SIGCHLD (Child exited) @ 0 (0) ---
999        1.029846 accept(3, {sa_family=AF_INET, sin_port=htons(34703), sin_addr=inet_addr("192.168.122.4")}, [16]) = 5
999        0.008276 --- SIGCHLD (Child exited) @ 0 (0) ---
999        3.580122 accept(3, {sa_family=AF_INET, sin_port=htons(50114), sin_addr=inet_addr("192.168.122.1")}, [16]) = 5

і може бути відфільтровано за допомогою:

# gawk 'match($0, /^([0-9]+)[[:space:]]+([0-9.]+)[[:space:]]+accept\(.*htons\(([^)]+)\),.*inet_addr\("([^"]+)"\).*[[:space:]]+=[[:space:]]+([1-9][0-9]*)/, m) {connections[m[4]]++} END {for (addr in connections) printf("%s: %d\n", addr, connections[addr]); }' /tmp/strace
192.168.122.4: 3
192.168.122.1: 2

Коротке пояснення одного лайнера AKW: m [1] - PID, m [2] - це мітка часу, m [3] є віддалений порт і m [4] - це віддалена адреса.

Перевага цього рішення полягає в тому, що корінь не потрібний, якщо сервер працює під одним користувачем. Недолік полягає в тому, що всі підключення підраховуються, фільтрація відсутня, тому вона не працюватиме, якщо програма слухає кілька портів.

3
додано
@fche, чи маєте ви посилання на probe :: netfilter .ip.local_in ?
додано Автор Tim Howland, джерело
FWIW, використання netfilter зондів в systemtap було б більш ефективним.
додано Автор fche, джерело
Так. Так. Так. Так.
додано Автор fche, джерело

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

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

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

Існує ще один загальний клас рішення, який є netflow. Це більше пов'язано з налаштуванням, але якщо це зроблено правильно, то це особливо ефективно, і якщо ви робите великомасштабний або постійний моніторинг, я дивлюся в цьому напрямку. Захоплення необроблених даних можна зробити у брандмауері (наприклад, fprobe-ulo) або за допомогою libpcap, який є більш повільним (наприклад, fprobeg). Система захоплення посилає дані потоку через мережу до колектора (наприклад, nfdump), і тоді у вас є безліч інструментів для аналізу цих даних (наприклад, nfsen).

Деякі маршрутизатори (зокрема, cisco gear) постачаються з мережевим захопленням, а також можуть бути налаштовані на інші маршрутизатори через програмне забезпечення третіх сторін, або, звичайно, ви можете запустити його на вашій системі linux. Якщо бажаєте, багато точок збору можуть пересилати свої дані про потік до одного колектора. Ви можете знайти опції вільного програмного забезпечення, наприклад, http://www.networkuptime.com/tools/netflow/ , а також є багато комерційних пропозицій.

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

Будьте обережні в будь-який час, коли ви заплутуєте правила брандмауера на віддаленому сервері, і взагалі я рекомендую знайти хороший інтерфейс для налаштування брандмауера, а не безпосередньо видавати команди iptables. (Мені подобається ферма, але є багато хороших).

Ще одна річ, про яку потрібно думати - іноді ви взагалі не хочете робити це на мережевому рівні. Іноді доречно стежити за системними викликами процесу демона з strace або подібним. Це інтенсивний процесор, і будьте обережні, щоб уповільнити процес Демона, але за деяких обставин, це може бути доречним, залежно в основному від того, яку іншу інформацію потрібно зібрати одночасно, або, можливо, якщо потрібно ізолювати одну роздвоєну дитину демона.

2
додано

Подивіться

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

Існує також цілий набір інструментів для реалізації безкоштовного стека, сумісного з Netflow, на linux. І ціла купа людей намагається продати підтримку навколо цього. (Я не збираюся рекомендувати комерційний продукт ...) Те, про що ви просите, є набагато простішим, ніж те, на що деякі з них здатні.

ІМХО (Free | Net | Open) BSD були далеко попереду свого роду аналізу протягом багатьох років. Брандмауер pFsense надасть вам принаймні 7 варіантів з коробки.

2
додано
Всі вони працюють на Linux і доступні як пакети в більшості дистрибутивів. Оскільки на запитання не вказується, як довго перебуває період, або скільки з'єднань є, я знайшов iptables + ви розбираєте його, щоб бути незадовільною реалізацією колеса. Ви більш ніж ласкаво просимо не погодитися і принизити мене.
додано Автор rightfold, джерело
Всі ці інструменти відповідатимуть на питання про з'єднання протягом певного періоду часу. Я повинен був зробити це більш чітким, ніж "подивитися на"
додано Автор rightfold, джерело
Де ви даєте відповідь на запитання?
додано Автор Paul Hennessy, джерело
Прочитайте знову питання. Це Linux, а не BSD. Мова йде не про криміналістику, про графіки, про реєстрацію db. Це не про "який інструмент?" але "як я можу?", це не "з'єднання протягом певного періоду часу", а "загальна кількість підключень до порту на IP джерела за період часу". Дивіться перші 2 відповіді: вони насправді відповіли на це питання.
додано Автор Paul Hennessy, джерело

Досі рішення, яке працювало краще для мене, було просто захопити вміст/proc/net/ip_conntrack кожні 20 секунд, записати його у файл з ім'ям файлу, що містить відповідну мітку часу і використовувати їх як вхідні дані для будь-яких сценаріїв фільтрації, або навіть при необхідності. Щоб заощадити час, ви можете використовувати мій сценарій. Я використовую записи crontab, щоб переконатися, що сценарій запускається кожну хвилину (він триває 60 секунд у поточній конфігурації, змінюйте його :-)

 cat conn_minute.sh
#!/bin/bash

function save_log {
LOG_DIR=/mnt/logs/ip_conntrack/`date +%Y%m%d`
TEMP_FILE=$LOG_DIR/`date +%Y%m%d_%H%M%s`.gz
LOG_FILE=$LOG_DIR/`date +%Y%m%d_%H`.tar
if [ ! -d $LOG_DIR ]
then
    mkdir $LOG_DIR
fi
gzip -c /proc/net/ip_conntrack > $TEMP_FILE
if [ -f $LOG_FILE ]; then
    tar -rf $LOG_FILE $TEMP_FILE 2> /dev/null
else
    tar -cf $LOG_FILE $TEMP_FILE 2> /dev/null
fi
rm $TEMP_FILE
}
function log_minute {
i=1;
LOOP_COUNTER=3
LOOP_TIME=20
while [ $i -le $LOOP_COUNTER ]; do
    save_log
    i=$[i+1]
    sleep $LOOP_TIME
done
}

log_minute

Ви можете налаштувати, як часто потрібно скидати вміст ip_conntrack, змінюючи відповідно LOOP_COUNTER і LOOP_TIME. Таким чином, щоб отримати його кожні 5 секунд, було б: LOOP_COUNTER = 12, LOOP_TIME = 5. LOG_DIR має на увазі, де будуть збережені журнали.

Після цього ви можете використовувати zcat для файлів cat, які ви зацікавили, і використовувати grep для фільтрації IP-адрес/портів, що цікавлять вас (або просто використовуйте zgrep). grep -c буде враховувати все, що ви шукаєте. Ви також можете використовувати grep src = 1.2.3.4 | grep dport = 63793 | сортувати uniq | wc -l .

1
додано
Конфігурація ядра # CONFIG_NF_CONNTRACK_PROC_COMPAT не встановлена ​​. Вставлення модуля ядра nf_conntrack_ipv4 не допомогло.
додано Автор Tim Howland, джерело
Які правила iptables потрібні для того, щоб мати /proc/net/ip_conntrack ? У мене немає правила з відповіді Дженні Д. Я використовую Scientific Linux 6.
додано Автор Tim Howland, джерело
Наявність/proc/net/ip_conntrack у вашій системі не є питанням використаних правил iptables. Справа в тому, які функції/модулі ядра ви ввімкнули у вашому ядрі. Я міг подумати: CONFIG_NF_CONNTRACK_PROC_COMPAT = y, CONFIG_NF_CONNTRACK_IPV4 = y та CONFIG_NF_CONNTRACK = y. Альтернативно через модулі: # lsmod | grep -i conn nf_conntrack_ipv4 9833 3 iptable_nat, nf_nat nf_conntrack 46391 3 iptable_nat, nf_nat, nf_conntrack_ipv4 nf_defrag_ipv4 1139 1 nf_conntrack_ipv4
додано Автор Marwan, джерело