Hogyan nem találtam hibát a TSharkban

Miután két napon keresztül bohóckodtam egy AWK szkripttel, ami TShark által lesniffelt, majd a TShark prokoll dekóderén áthajtott adatokat dolgoz fel, és capture file-ból már hibátlanul működött mind a TShark-os dekódolós rész, mint az AWK szkript, gondoltam ideje kipróbálni valódi környezetben is dolgot. Felkerült egy tesztrendszerre, pár módosítás a capture-t végző szkriptben, hogy valódi sniffelés legyen, ne capture fájlból olvasson, aztán mindenkit odacsődítettem, hogy na, ezt nézzétek, elkészült, és... kopp. Nem megy. Á... igen, rövid hegesztgetés a capture filteren, apróbb állítgatás a protokoll dekóderen, na, majd most... kopp. Még egy kis mókolgatás, és... kopp, kopp, kopp.

Egy jó másfél órás túrás után kiderült, hogy a szkript lelkének számító "tshark ... | magic.awk > /dev/tcp/1.1.1.1/1111" szerkezetű sorban (a /dev/tcp/IP/port Bash specifikus) már a legelején elkerülik a pipe-ot az adatok. Persze én a másik végéről visszafelé haladva ellenőriztem mindent, ez nem is kérdés. A probléma egyébként roppant egyszerű: capture filter használata esetén az STDOUT-ra nem ad semmit a TShark, ami nem valami szép dolog tőle. Az alábbi egyszerű példák megvilágítják, hogy mi is a gond. Tegyük fel, hogy folyamatos ICMP forgalmunk van a 192.168.0.1 és a 192.168.0.2 között.

Capture filter és pipe nélkül minden rendben:

betazed:~# tshark -i eth2
Running as user "root" and group "root". This could be dangerous.
Capturing on eth2
  0.000000 192.168.0.1 -> 192.168.0.2  ICMP Echo (ping) request
  0.000118  192.168.0.2 -> 192.168.0.1 ICMP Echo (ping) reply
  ...

Capture filterrel, de pipe nélkül is OK:

betazed:~# tshark -i eth2 icmp
Running as user "root" and group "root". This could be dangerous.
Capturing on eth2
  0.000000 192.168.0.1 -> 192.168.0.2  ICMP Echo (ping) request
  0.000103  192.168.0.2 -> 192.168.0.1 ICMP Echo (ping) reply
  ...

Capture filter nékül, pipe-pal:

betazed:~# tshark -i eth2 | grep .
Running as user "root" and group "root". This could be dangerous.
Capturing on eth2
  0.541318 192.168.0.1 -> 192.168.0.2  ICMP Echo (ping) request
  0.541418  192.168.0.2 -> 192.168.0.1 ICMP Echo (ping) reply
  ...

Capture filterrel és pipe-pal:

betazed:~# tshark -i eth2 icmp | grep .
Running as user "root" and group "root". This could be dangerous.
Capturing on eth2
^C26 packets captured

Az STDERR-re kikerül a CTRL+C megnyomása után, hogy 26 csomagot fogott a TShark. Szép, szép, de hová tette azt a 26 csomagot? A grep tutira nem nyeli le őket, hiszen ebben a formában mindent átenged, ergo meg sem kapja az STDIN-jén az adatokat. Akkor vajon mi lehet gond? Rövid töprengés után (vö. Gyalog galopp boszorkányégetős jelenet) megvan az itélet: biztosan a TShark vacak, máglyára vele. Nincs is szebb annál, mint amikor a hülyeség szorgalommal párosul, lejelentettem hibára a bugs.wireshark.org-on. Nem tudom, hogy a véletlenül kapott mágikus erejű bug ID (7777) hatására, vagy azért, mert egyébként is jól felépített szervezetet tolt a Riverbed a Wireshark alá, de húsz perc múlva volt megoldás: user error. Khm... nos, igen, körülbelül iyen "Operációs rendszerek" szeminárium első évfolyam, első félév, második alkalom szintű dologról van szó, nem tudtam, hogy az STDOUT pufferelt, és ha nincs elég sok adat a TShark kimeneten, akkor bizony sokáig a pufferben ragadnak a dolgok. Ezért abban az esetben, ha TShark van a pipe elején, "-l" kapcsolóval érdemes elindítani, akkor azonnal ürül a puffer minden egyes csomag feldolgozása után. Innen persze már működött a csoda szkriptem is, az más kérdés, hogy a végső változatban mégsem TShark-kal sniffeltem, hanem ngrep-pel, és a TShark parancssori protokoll dekódere helyett mindent AWK-val oldottam meg, nem is ez a fontos, hanem az, hogy a szakmában töltött évek száma semmilyen kapcsolatban nincs az ember valós vagy inkább vélt tévedhetetlenségével.

RIverbed offtopic érdekességek

Egy kis érdekesség egy Riverbed Steelhead 550-es WAN optimizer CLI-jéből. A legmenőbb networkös cégeknél mindig vannak magyarok:

amnesiac > show ver

Product name:      rbt_sh

Product release:   7.0.1

Build ID:          #202_11

Build date:        2012-02-09 17:16:08

Build arch:        i386

Built by:          root@miskolc

Uptime:            2m 29s

Product model:     550

System memory:     1549 MB used / 475 MB free / 2024 MB total

Number of CPUs:    2

CPU load averages: 1.85 / 0.76 / 0.28

amnesiac >

Ha már Riverbed, akkor még egy dolog, amiről érdemes tudni: kb. két éve megvették kilóra a Wireshark mögött álló céget, persze maga a kód GPL-es, de a tudás, a kulcsemberek, mind-mind Riverbed alkalmazottak. A legszebb az egészben, hogy itt nem történtek olyan baklövések, mint amelyek például az OpenOffice és az Oracle esetében a LibreOffice forkhoz vezettek -- szintén ugye két éve. Nem tépték szét a fejlesztői közösséget, nem akarták kisajátítani a Wiresharknak a protokoll analizátorok közötti páratlan népszerűségét, építettek rá egy üzleti modellt, tök jó termékek kaphatók, egy Cascade Shark appliance-t például egyszer szívesen meghajtanék.

Szóval riszpekt, köszi, hogy nem kúrtátok el, és persze üdv a magyar kollégá(k)nak.

Egymásba ágyazott ismétlődések kezelése TShark field print opciókkal

Tegyük fel, hogy szkriptet kell írnunk, ami valamiféle statisztikát készít mondjuk IPIP vagy GRE tunnelezett forgalomról. Mintának egyből használhatjuk a packetlife.net-ről a GRE.cap-ot. A tunnel ebben az esetben a 10.0.0.1 és a 10.0.0.2 közt van kihúzva, a tunnelen belül pedig az 1.1.1.1 és a 2.2.2.2 kommunikál egymással:

Ha mindezt CLI-ben szeretnénk feldolgozni, akkor persze TSharkra lesz szükség, és egy kicsit állítgatni kell az alapértelmezett outputon. Egyszerűsítsük le a végletekig a dolgot, csak a forrás, illetve a cél IP-ket jelenítsük meg:

karsair@betazed:~$ tshark -r GRE.cap -T fields -e ip.src -e ip.dst -E separator=\;
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1

Nos, ez nem egészen az, amire szükség van, hiszen itt csak a GRE payload IP-k látszanak, azaz az ip.src és az ip.dst mezők utolsó előfordulásai minden egyes keretben. Ettől többet sajnos nem is várhatunk egészen a Wireshark 1.6-os verziójáig. Az új stabil Wireshark ágban azonban már gondoltak a rekurzivitás barátaira, új opciók vannak ugyanis a hasonló esetek kezelésére. Egyrészt megváltozott az alapértelmezett viselkedés a TShark-ban, -e után megadott mező összes előfordulását kilistázza a program vesszővel elválasztva:

karsair@betazed:~$ /opt/wireshark-1.6.5/bin/tshark -r GRE.cap -T fields -e ip.src \
-e ip.dst -E separator=\;
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1

Másrészt vadonatúj field print opcióként itt az "occurrence". Az eddigi field print opciókkal be lehetett állítani, hogy legyen-e az outputban fejléc (-E header=y), a fenti példákban már bemutatott separator opcióval megadhattunk mezőelválasztó karaktert (-E separator=\;), illetve kérhettünk idézőjeleket a mező tartalma köré (pl. -E quote=d). Most viszont azt is megadhatjuk az occurrence opcióval, hogy az adott nevű mező első (f), utolsó (l) vagy összes (a) előfordulását szeretnénk látni, így akár imitálhatjuk az 1.6-os verziók előtti viselkedést (-E occurrence=l):

karsair@betazed:~$ /opt/wireshark-1.6.5/bin/tshark -r GRE.cap -T fields -e ip.src \
-e ip.dst -E separator=\; -E header=y -E quote=d -E occurrence=l
ip.src;ip.dst
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"

Ami még ide tartozik, mégis kimaradt az eddigi példákból, az az aggregator field print opció, ami az -e után megadott nevű mező(k)nek az adott keretben való előfordulásait elválasztó karaktert definiálja, az alábbi példában ez a kettőspont:

karsair@betazed:~$ /opt/wireshark-1.6.5/bin/tshark -r GRE.cap -T fields -e ip.src \
-e ip.dst -E separator=\; -E quote=d -E occurrence=a -E aggregator=:
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"

Eljutottunk tehát odáig, hogy a TShark egy jól konfigurálható kimentet ad a poszt elején vázolt szkript számára, az IP-ket pakolgathatjuk tömbökbe, ide-oda, számolgathatjuk, hogy melyik hányszor fordult elő ilyen külső IP, amolyan belső IP mellett, de az már egy másik történet.

GRE/IPSec tunnel Cisco és Vyatta eszközök közt

Korábban volt már egy hasonló című poszt (GRE tunnel IPSec-ben Cisco és Vyatta eszközök közt), gyanús lehet, hogy most ugyanazt elsütöm mégegyszer, pedig nem, a mostani pár sorban különbözik :). Akkor Adrian F. Dimcev ötletére épülve egy loopback interfészes trükk közbeiktatásával készült kézzel összedrótozgatott GRE/IPSec-hez hasonló megoldás, azonban a Vyatta 6.3 új IPSec VPN lehetőségeinek hála egyszerűbben is megoldható a probléma. A mostani teszt során az alábbi topológia készült el:

A környezet felépítéséhez egy Cisco 3725-ös routert, illetve Vyatta oldalon egy Vyatta Core 6.3-assal telepített mezei PC-t használtam. A Cisco oldali konfiguráció a következőképp alakul:

interface FastEthernet0/0
  ip address 172.17.136.254 255.255.248.0
  no shutdown
  exit

interface FastEthernet0/1
  ip address 10.10.20.1 255.255.255.0
  no shutdown
  exit

crypto isakmp policy 10
  encr aes 256
  hash sha
  authentication pre-share
  lifetime 28800
  group 5
  exit
 
crypto isakmp key TITOK address 172.17.136.255
 
crypto ipsec transform-set TESZTSET esp-aes 128 esp-md5-hmac
exit                                                 
 
crypto ipsec security-association lifetime seconds 3600
 
crypto ipsec profile TESZTPROFIL
  set transform-set TESZTSET
exit
 
interface Tunnel 0
  ip address 10.0.0.2 255.255.255.252
  tunnel source 172.17.136.254
  tunnel destination 172.17.136.255
  tunnel protection ipsec profile TESZTPROFIL
exit

ip route 10.10.10.0 255.255.255.0 10.0.0.1

GRE/IPSec esetén crypto map-et, crypto ACL-t, nem kell megadnunk (milyen subnetből milyen subnetbe megy az IPSec-kel védett forgalom), hiszen az a GRE tunnelben fog utazni, az IPSec-nek pedig itt csak annyit kell tudnia, hogy mi a két IP a GRE tunnel két végén, és hogy e két IP között a GRE forgalom legyen titkosítva. A minimalista tesztkonfigot a GRE szomszédra mutató, a túloldali védett subnethez tartozó route zárja. A Vyatta konfiguráció sem bonyolultabb, sőt szerintem áttekinthetőbb, jobban csoportosított, pirossal emeltem ki a Vyatta 6.3-ban bemutatkozó új lehetőséget (az IPSec processz által lekezelendő forgalom megadása protokollal):

set interfaces ethernet eth0 address 172.17.136.255/21
set interfaces ethernet eth1 address 10.10.10.1/24
 
set interfaces tunnel tun1 address 10.0.0.1/30
set interfaces tunnel tun1 encapsulation gre
set interfaces tunnel tun1 local-ip 172.17.136.255
set interfaces tunnel tun1 remote-ip 172.17.136.254

set vpn ipsec ike-group TESZT-IKE-GROUP
set vpn ipsec ike-group TESZT-IKE-GROUP lifetime 28800
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 dh-group 5
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 encryption aes256
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 hash sha1

set vpn ipsec esp-group TESZT-ESP-GROUP
set vpn ipsec esp-group TESZT-ESP-GROUP proposal 10 encryption aes128
set vpn ipsec esp-group TESZT-ESP-GROUP proposal 10 hash md5
set vpn ipsec esp-group TESZT-ESP-GROUP lifetime 3600

set vpn ipsec ipsec-interfaces interface eth0

set vpn ipsec site-to-site peer 172.17.136.254
set vpn ipsec site-to-site peer 172.17.136.254 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 172.17.136.254 authentication pre-shared-secret TITOK
set vpn ipsec site-to-site peer 172.17.136.254 ike-group TESZT-IKE-GROUP
set vpn ipsec site-to-site peer 172.17.136.254 local-ip 172.17.136.255
set vpn ipsec site-to-site peer 172.17.136.254 tunnel 1
set vpn ipsec site-to-site peer 172.17.136.254 tunnel 1 esp-group TESZT-ESP-GROUP
set vpn ipsec site-to-site peer 172.17.136.254 tunnel 1 protocol gre

set protocols static route 10.10.20.0/24 next-hop 10.0.0.2

A végeredmény a korábban bemutatott megoldáshoz képest egyszerűbb, a két eszköz mögötti védett hálózatok forgalma azonban a korábbiakhoz hasonlóan IPSec tunnelben, azon belül GRE tunnelben utazik az egyik routertől a másikig. A megoldás tesztelését könnyen megejthetjük mondjuk egy telnet sessionnel pl. a 10.10.10.2-es hostról a 10.10.20.2-es hostra, nyilvánvalóan ezeket a hostokat is fel kell konfigurálni (IP cím, default route, telnet szolgáltatás). Ha a már működő telnet sessionbe belehallgatunk a megfelelő Vyatta interfészen tsharkkal, akkor viszont csak az ESP payloadot láthatjuk, várakozásainknak megfelelően:

vyatta@vyatta:~$ sudo tshark -i eth0 
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
  0.000000 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.018434 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  0.018748 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.179962 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.198421 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  0.198757 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.319907 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.338476 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  0.338800 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.459966 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.478455 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  0.478774 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.879923 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.898456 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  0.898779 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.027966 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.048497 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  1.048816 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.067968 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.088483 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  1.126881 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.239920 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.258538 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  1.258873 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.379974 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.398574 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  1.398900 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.759984 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.778730 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  1.779053 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)

Netflow dekódolás Wiresharkban

Ki gondolta volna, hogy a Wiresharkban remek Netflow támogatás van? Egy pár napja szaladtam bele egy kis hülyeségbe és jól jött volna a ManageEngine Netflow Analyzert futtató szerverünkön egy másik Netflow szabványt értő program. Hát persze, hogy a Wiresharkhoz nyúltam először, és persze, hogy nem olvastam el előtte semmit, készítettem egy pár perces capture-t a vizsgálandó router forrás IP-jéről érkező csomagokról, utána meg lestem, hogy miért csak layer4-ig tudja dekódolni a Wireshark, micsoda disznóság már, hogy épp az engem érdeklő Netflow adatokat csak úgy, kódolatlanul jeleníti meg? Lehetséges, hogy nem ismeri a Netflow-t? Neeem, ilyesmit lazán tudnia kellene. Már néztem is a Help > Supported Protocols-ban, hm... nincs Netflow, nincs Nflow, bezzeg sFlow az van, de végül megtaláltam, CFLOW a protokoll dekóder neve (Cisco NetFlow/IPFIX).

Innen már csak egy lépés beállítani a megfelelő UDP portra: Analyze > Decode as... > Decode UDP source X port(s) as > CFLOW. Annyi csavar van még a dologban, hogy Netflow v9 esetén már template alapú a dekódolás, nálunk pedig történetesen épp a v9 van használatban, így nem feltétlenül elegendő csupán egy-két UDP datagram, érdmes kicsit tovább várni, amíg megjön a Netflow template-ünk is a forrástól. Ha már megjött a template, a Wireshark ügyesen kibontja a datagramokat, és böngészgethetünk is a router által küldött forgalmi adatokban kedvünkre.

Szűrés is állítható bármelyik Netflow mezőre, nálam például a "cflow.direction" volt az érdekes (0=ingress, 1=egress), van ugyanis egy szolgáltatói routerünk, amelyik egyszerűen nem hajlandó egyik interfészéről sem OUT adatokat szolgáltatni Netflow-n keresztül, következetesen csak IN adatokról küld információt bármiféle beállítás, rábeszélés, rugdosás ellenére, de erről majd később, ha már lezárult az ügy, jelenleg még mindig vizsgálják a szolgáltatónál a hiba okát.