Estou usando esse script que, na verdade, verifica a taxa de pacotes de entrada e é acionado se a taxa atingir 5mbps ou mais. Os pacotes são então registrados em um arquivo tcpdump.
interface=eth0
dumpdir=/tmp/
while /bin/true; do
pkt_old='grep $interface: /proc/net/dev | cut -d : -f2 | awk '{ print $2 }''
sleep 1
pkt_new='grep $interface: /proc/net/dev | cut -d : -f2 | awk '{ print $2 }''
pkt=$(( $pkt_new - $pkt_old ))
echo -ne "\r$pkt packets/s3[0K"
if [ $pkt -gt 5000 ]; then
echo -e "\n'date' Under attack, dumping packets."
tcpdump -n -s0 -c 2000 -w $dumpdir/dump.'date +"%Y%m%d-%H%M%S"'.cap
echo "'date' Packets dumped, sleeping now."
sleep 300
fi
done
A saída é algo como 2000 pacotes capturados. XXX pacotes recebidos pelo Filter e XXX- (menos) 2000 descartados pelo Kernel.
Agora, o que eu quero saber aqui é que o arquivo de saída não me contaria a taxa do ataque como se fosse 300mbps ou o que? Então, os pacotes XXX são recebidos por filtro por segundo? Se não, como faço para verificar isso porque minha porta às vezes fica saturada.
ATUALIZAÇÃO:
Eu usei um programa para capturar estatísticas do arquivo capturado através do script acima. Aqui está o que eu tenho:
root@$:/tmp/dumps# capinfos dump.20130621-174506.cap
File name: dump.20130621-174506.cap
File type: Wireshark/tcpdump/... - libpcap
File encapsulation: Linux cooked-mode capture
Number of packets: 2000
File size: 2065933 bytes
Data size: 2033909 bytes
Capture duration: 43 seconds
Start time: Fri Jun 21 17:45:06 2013
End time: Fri Jun 21 17:45:49 2013
Data byte rate: 46968.49 bytes/sec
Data bit rate: 375747.94 bits/sec
Average packet size: 1016.95 bytes
Average packet rate: 46.19 packets/sec
Acredito que o ataque tenha durado apenas 15-20 segundos enquanto a informação capturada foi de 43 segundos, então a taxa de bits de dados aqui pode ter sido calculada a partir desse tempo total. O que pode ajudar aqui é se alguém pudesse editar o script original acima em vez de capturar 2000 pacotes e descartar o restante, para capturar todos os pacotes por uma duração de digamos 5 segundos quando o limite for atingido.
ATUALIZAÇÃO:
Depois de alterar o script como mencionado, parecia que o arquivo estava danificado ao lê-lo no Wireshark, que dizia: "O arquivo de captura parece ter sido interrompido no meio de um pacote." Aqui está a saída de capinfos:
capinfos: An error occurred after reading 3085 packets from '"dump.20130710-215413.cap": Less data was read than was expected.
Em uma segunda tentativa, consegui ler esse arquivo apenas quando pressionei Ctrl + C no console do script:
capinfos dump.20130710-215413.cap
File name: dump.20130710-215413.cap
File type: Wireshark/tcpdump/... - libpcap
File encapsulation: Linux cooked-mode capture
Number of packets: 18136
File size: 2600821 bytes
Data size: 2310621 bytes
Capture duration: 591 seconds
Start time: Wed Jul 10 21:54:13 2013
End time: Wed Jul 10 22:04:04 2013
Data byte rate: 3909.73 bytes/sec
Data bit rate: 31277.83 bits/sec
Average packet size: 127.41 bytes
Average packet rate: 30.69 packets/sec
Observe a duração da captura em 591 segundos. Eu acredito que o 'sono 300' tem algo a ver aqui, porque eu vejo a saída do console. Esta saída é com a opção '-c 2000':
./Log.sh
10275 packets/s
Wed Jul 10 12:41:31 MSD 2013 Under attack, dumping packets.
tcpdump: listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
2000 packets captured
100012 packets received by filter
98003 packets dropped by kernel
Wed Jul 10 12:42:34 MSD 2013 Packets dumped, sleeping now.
Agora, esta é a saída depois que você modificou o script com 'sleep 5':
./Log.sh
24103 packets/s
Wed Jul 10 21:54:13 MSD 2013 Under attack, dumping packets.
tcpdump: listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
Wed Jul 10 21:54:18 MSD 2013 Packets dumped, sleeping now.
1620 packets/sroot@nl:~# 18136 packets captured
1850288 packets received by filter
1832106 packets dropped by kernel
^C
Repare que pressionei Ctrl + C para interromper a função de suspensão, o que supostamente possibilitou a leitura do arquivo.