Juletip 1: Pakker, pakker og pakker

Hej Allesammen

Sidste år lykkedes det at lave 24 blogindlæg i december, og det vil jeg forsøge at gøre igen i år. Det bliver hårdt og jeg lover ikke noget :-)

Hvis du ikke så indlæggene fra sidste år kan du finde dem på følgende link: http://blog.kramse.org/blojsom/blog/default/2008/12/

I år vil jeg forsøge at holde et overordnet emne som er pakker! Pakker med bits og protokoller med masser af søde pakker, og måske et par bitre sure onde pakker. Disse pakker vil blive gennemgået i sammenhæng med diverse værktøjer og med links til websider med mere information. Niveauet bliver bestemt ikke højt, men jeg håber I synes det er interessant, indeholder et par gode tip og giver jer blod på tanden til at gøre mere selv :-)

Men skal vi ikke komme igang? Jo, lad os fortsætte hvor vi slap sidste år - med tcpdump. Dette første indlæg vil således dreje sig om brugen af tcpdump programmet i praksis, fra start til almindelig brug i servermiljøer - med vægt på remote opsamling.

Tcpdump

Tcpdump kender de fleste formentlig, det findes på alle vores Unix operativsystemer og Windump versionen til Windows. Dette program kan sniffe netværksdata. Idag er det formentlig også mange der kender og bruger Wireshark som er en grafisk pakkesniffer.

Fordelen ved tcpdump er at den kan gemme netværksdata i capture filer, som både tcpdump og andre programmer kan læse. Tcpdump er de facto standardformatet for netværkspakker i filer.

Første opsamling af pakker med tcpdump

Det mest basale man kan gøre med tcpdump er at starte den uden nogen parametre. Det giver noget i stil med følgende:

hlk@kris:hlk$ sudo tcpdump
tcpdump: listening on vr0, link-type EN10MB
09:03:26.109071 10.0.42.1.65001 > 10.0.42.95.50090: P 1353643570:1353643650(80) ack 3670719215 win 32942  (DF) [tos 0x10]
09:03:26.109439 10.0.42.1.65001 > 10.0.42.95.50090: P 80:128(48) ack 1 win 32942  (DF) [tos 0x10]
09:03:26.110008 10.0.42.95.50090 > 10.0.42.1.65001: . ack 80 win 65535  (DF) [tos 0x10]
09:03:26.110457 10.0.42.95.50090 > 10.0.42.1.65001: . ack 128 win 65535  (DF) [tos 0x10]
...

Bemærk her at jeg ikke angav noget netkort, og det pågældende operativsystem og tcpdump fandt selv ud af at vr0 var aktivt, og begyndte at sniffe pakkerne. Forsøger jeg det samme med min Mac OS X giver det ikke rigtigt noget, for den forsøger med netkortet en0 (Gigabit Ethernet) selvom jeg typisk bruger en1 (Airport Wireless kort).

Med Mac OS X skal jeg altså ofte angive netkortet, med -i option, og jeg tilføjer ofte også -n option der gør at portnumre og adresser ikke slåes op. Det giver altså:

hlk@bigfoot:hlk$ sudo tcpdump -ni en1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
09:05:41.359856 IP 10.0.42.36.53970 > 10.0.42.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:05:41.667137 IP 10.0.42.36.53970 > 10.0.42.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:05:41.974361 IP 10.0.42.36.53970 > 10.0.42.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
09:05:42.588721 IP 10.0.42.36.53971 > 10.0.42.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
...

Dejligt simpelt og så er vi igang, Windows folk må selv finde ud af Windump :-)

Bedre opsamling med tcpdump

Nu er ovenstående jo dejligt simpelt og giver god information, der er pakker i farvandet og tcpdump virker, yeah! Men ofte vil man gerne se indholdet af pakkerne - og tcpdump sniffer som standard ikke hele pakken. ... eller det vil sige, på nogle platforme tager den mere end på andre - så det er bedre at angive det med -s option. (Default på min OpenBSD hvor jeg lige checkede var 116 bytes, på min OSX lader det til at 64K er standarden. Samtidig kan man ofte med fordel smide lidt verbose på, så det bliver:

hlk@bigfoot:hlk$ sudo tcpdump -ni en1 -s 1500 -vvv 
tcpdump: listening on en1, link-type EN10MB (Ethernet), capture size 1500 bytes
12:57:26.893411 IP (tos 0x0, ttl 64, id 61810, offset 0, flags [none], proto UDP (17), length 78)
    10.0.42.12.50967 > 10.0.42.255.137: [udp sum ok] 
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
TrnID=0xC29
OpCode=0
NmFlags=0x11
Rcode=0
QueryCount=1
AnswerCount=0
AuthorityCount=0
AddressRecCount=0
QuestionRecords:
Name=MY-DECK         NameType=0x00 (Workstation)
QuestionType=0x20
QuestionClass=0x1

Hvis man benytter et netværk med større pakker end 1500 skal man selvfølgelig ændre til noget andet, eksempelvis hvis man med en monitorport på en switch får pakker med 802.1q VLAN :-)

Remote opsamling

Det næste problem med tcpdump er at man kun får pakkerne der kommer til ens interface! Det betyder at man for at kunne sniffe på et switchet netværk skal gøre noget mere. Enten skal ARP-spoofe, hvilket kun anbefales hvis man vil stjæle informationer fra andre :-), bruge en monitor port eller bruge en af parterne i kommunikationen man vil opsnappe.

Basalt set har man derfor et par muligheder:

• Opsamle via en switch der har en monitor port, kaldes også mirrorport eller SPAN port/remote SPAN port, afhængigt af leverandøren
• Opsamle på serveren, eller hos dig selv hvis du er part i kommunikationen
• Opsamle på netværksudstyr på netværksvejen

Specielt det sidste er efterhånden blevet mere og mere almindeligt. Eksempelvis har jeg set muligheder for at opsamle fra firewalls, routere, load balancere - og de giver typisk data i tcpdump format :-)

Opsamling via monitor port

Lad os starte med det simple opsamling via monitor port. Dette scenarie kræver at man har en switch der understøtter dette, det gør de fleste managed switche med command line og web interface. Basalt set definerer man at data fra en eller flere server porte skal kopieres over til en monitorport. Derefter kan man tilslutte en PC, laptop eller en anden server til setuppet som monitor og opsamle trafikken.

På den pågældende monitor kan man så via kommandolinien, eller via Remote Desktop til en Windows - opsamle trafikken. Denne model virker også godt med Intrusion Detection Systems (IDS), som Snort og Prelude.

Opsamling via remote server

Nu er det ikke altid at man skal opsamle al trafik på en switch, men kun data til en bestemt port. I dette tilfælde er det nemmere og hurtigere blot at køre tcpdump på systemet - men undgå at man opsamler sin egen trafik. Den nemmeste måde at undgå sin egen trafik på er ved at bruge et simpelt udtryk til tcpdump. Det simple udtryk kræver blot at man specificerer sin egen trafik, som kunne være IP-adressen som du selv er på.

hlk@bigfoot:hlk$ ssh laura 
Last login: Tue Dec  1 15:14:56 2009 from 10.0.42.123
OpenBSD 4.4-current (RAID.MP) #0: Fri Nov  7 09:20:30 CET 2008

Authorized access only

Use can be monitored and any abuse will be acted upon!
hlk@laura:hlk$ who | grep hlk
hlk      ttyp0    Dec  1 15:06   (10.0.42.123)
hlk@laura:hlk$ tcpdump -ni nfe0 -s 1500 -vvv ! host 10.0.42.123
tcpdump: need root privileges
hlk@laura:hlk$ sudo tcpdump -ni nfe0 -s 1500 -w server1.cap   ! host 10.0.42.123
tcpdump: listening on nfe0, link-type EN10MB
^C
52 packets received by filter
0 packets dropped by kernel
hlk@laura:hlk$ 

Bemærk at jeg ligeledes gemmer output med -w write option, hvorefter man kan overføre filen server1.cap til sin lokale arbejdsstation (husk at FTP er evil og SCP er gud) og åbne med Wireshark eller tilsvarende programmer.

Opsamling via netværksudstyr

Opsamling af datapakker er noget som professionelt eller halvprofessionelt udstyr kan udføre.

Eksempelvis finder man på JUNOS operativsystemet fra Juniper kommandoen tcpdump direkte:

root@CPH-01% tcpdump -h
Version 4.0-PRE-CVS
libpcap version 0.9.4
Usage: tcpdump [-abdeflnNOpqStUvxX] [-c count] [ -F file ]
                [ -i interface ] [ -r file ] [ -s snaplen ]
                [ -T type ] [ -w file ] [ expression ]
                [ -Jt resolve_tmo ]

På et andet, men dog udgået product, deres Loadbalancere DX med DXOS operativsystemet finder man ligeledes en tcpdump kommando:

Tilsvarende funktionalitet finder man på mange andre enheder fra andre producenter. Dette giver mulighed for at opsamle trafik både på vej ind i netværket, mellem enheder og mellem enheder og servere - og altsammen uden at skulle ændre på den fysiske kabelføring.

Da vi således har gennemgået hvordan man opsamler trafik vil jeg imorgen se på nogle specifikke netværkspakker. Vi ses :-)