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

Ви можете використовувати 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. Якщо підрахувати з'єднання на самому сервері, завжди потрібно використовувати зворотне.

Рішення 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] - це віддалена адреса.

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

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

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

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

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

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

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

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

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

Подивіться

• darkstat,

• iplog,

• iptraf,

• bwm-ng

• ntop

• vnstat

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

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

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

Досі рішення, яке працювало краще для мене, було просто захопити вміст/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 .