Rozwiązywanie problemów sieciowych za pomocą sniffera Czyli: Co? Jak? I gdzie sniffować...

1. Rozwiązywanie
problemów
sieciowych
za
pomocą
sniffera
Czyli:
Co?
Jak?
I
gdzie
sniffować….
Ósme spotkanie PLNOG
Warszawa, 6 marzec 2012
Paweł Białasiewicz, Polbank EFG S.A.

2. Narzędzia
• Istnieje
różnica
pomiędzy
oprogramowaniem
do
łapania
pakietów
a
analizy
pakietów.
Przykładowe
narzędzia
do
łapania
pakietów:
• Tcpdump
–
jest
typowym
narzędziem
do
łapania
pakietów,
posiada
kilka
przełączników
ułatwiających
analizę
lecz
większość
pracy
musimy
wykonać
sami.
• Rawcap
–
czyste
rozwiązanie
do
łapania
pakietów,
pozbawione
funkcji
analitycznych.

3. Narzędzia
do
analizy
pakietów
Możemy
podzielić
na:
NFAT
Network
Forsenic
Analysis
Tool:
-­‐ Network
Miner
-­‐ Xplico
-­‐ Clarified
Analyzer
Protocol
Analyzers:
-­‐ Wireshark
-­‐ Cascade
Pilot
Personal
EdiVon
-­‐ ColasoW
Capsa
Network
Analyzer

4. Co
wybrać?
• Chcemy
zająć
się
analizą
pakietów
• Nie
chcemy
wydawać
dużych
sum
pieniędzy
• Chcemy
mieć
możliwość
zajęcia
się
Forsenic
• Ma
działać
na
większości
plaXorm
Windows/
Linux/Mac

5. Typowe
problemy
sieciowca
„Aplikacja
działa
poprawnie,
to
na
pewno
problem
z
siecią…
„Baza
działa
bez
zarzutów
ale
sieciowcy
chyba
coś
wczoraj
robili…
Czyli: Jak nie dać z siebie zrobić wielbłąda

6. Praca
w
środowisku
rozproszonym

7. Praca
w
środowisku
rozproszonym
• Kilka
DC
• Bycie
typowym
tranzytem
• Klienci
zewnętrzni:
– Nie
zawsze
chcący/mogący
współpracować
– Nie
zawsze
potrafiący
współpracować
• Bycie
tranzytem
pomiędzy
dwoma
klientami
zewnętrznymi


8. Jak
sobie
poradzić
podczas
wystąpienia
problemu?
Przeprowadzić
poprawnie
analizę
pakietów

Na
co
musimy
zwrócić
szczególną
uwagę:
Sam
pcap
nic
nam
nie
daje!!!
Trzeba
umieć
tą
informację
odpowiednio
“ubrać”.
Uszycie
takiego
ubrania
składa
się
z
następujących
elementów:

9. 1.
Złapanie
pakietów
 Musimy
znać
topologię
na
której
będziemy
dokonywać
analizy.
Potrzebna
jest
znajomość
zarówno
fizycznej
topologii
jak
i
logicznej.
Dobra
znajomość.
 Musimy
wiedzieć
w
którym
miejscu
należy
dokonać
analizy
ruchu.
Czasem
trzeba
to
zrobić
w
kilku
miejscach!
 Należy
pamiętać
o
wstępnym
odfiltrowaniu
potencjalnie
interesującego
nas
ruchu.
 Musimy
uwarzać
aby
nie
“zabić”
infrastruktury
pordukcyjnej


10. 2.
Użycie
odpowiednich
narzędzi
 Sam
wireshark
nie
pokazuje
nam
szerszego
obrazu
– Powinniśmy
się
wspomoagać
takimi
systemami
jak
NeXlow,
RRDTool
itd.
 Wiedza
z
obsługi
funkcji
analitycznych
i
statystycznych
wiresharka
jest
niezbędna
 Doświadczenie
w
analizie
pakietów
znacznie
przyśpiesza
ten
proces


11. 3.
Stworzenie
stosownego
raportu
z
incydentu
 Pokazać
ogólny
problem
za
pomocą
neXlow,
RDDTool
 Wskazać
dokładniej
problem
za
pomocą
narzędzi
analitycznych
programu
wireshark
(np.
TCP
Graphs)
 Wskazać
bardzo
dokładnie
problem
na
przykładzie
kilku
wybranych
pakietów
 Dodać
stosowny
komentarz
jasno
wskazujący
przyczynę
problemu
Cała
czynność
zaczyna
się
robić
czasochłonna?
 Można
utworzyć
szablon
i
procedurę
tworzenia
takiego
raportu
 Można
zautomatyzować
całą
procedurę


12. Dodatkowe
korzyści
z
analizy
pakietów
 Jest
to
ciekawa
furtka
dla
DevOps
 Tutaj
musimy
już
współpracować
mocno
z
innymi
działami
 Możemy
się
dowiedzieć
sporo
nowych
rzeczy
o
naszej
sieci
 A
w
szczególności
o
aplikacjach
“biegających”
po
naszej
infrastrukturze
 Każda
analiza
zwiększa
nasze
doświadczenie
co
powoduje
iż
każda
kolejna
analiza
zajmuje
nam
mniej
czasu.

13. Początkowa
wiedza
potrzebna
do
analizy
pakietów
Brzmi
groźnie
ale
tak
naprawdę
nie
jest
tego
aż
tak
dużo

1.
Musimy
wiedzieć
jak
i
gdzie
sniffować?
2.
Musimy
zapoznać
się
z
kilkoma
podstawowymi
funkcjami
wiresharka.

14. Jak
i
gdzie
sniffować
Skorzystać
z
HUB a
+
Jest
bardzo
łatwe
+
Otrzymujemy
dokładną
kopię
ruchu
-­‐
Wymaga
chwilowego
rozpięcia
infrastruktury
-­‐
Niska
wydajność
100
Mbps
half
duplex

15. Jak
i
gdzie
sniffować
Skorzystać
z
trybu
port
monitor/SPAN
na
switchu
+
Jest
to
łatwa
metoda
+
Nie
wymaga
rozłączania
infrastruktury
-­‐
Zmienia
sygnatury
czasowe
pakietów!
-­‐
Span
jest
jednym
z
ostatnich
procesów
na
liście
priorytetów
switcha
-­‐
SPAN
odrzuca
wszystkie
pakiety
które
są
uszkodzone
(runt,
corrupt
itd.)
-­‐
Problem
duplexu
-­‐
Robienie
SPAN
na
łączach
WAN
jest
nie
wskazane

16. Jak
i
gdzie
sniffować
Skorzystać
z
TAP
interface
+
Inteligentne
TAPy
pozwalają
na
wstępne
filtrowanie
ruchu
+
Są
najlepszą
i
najpewniejszą
opcją
jeśli
chodzi
o
łąpanie
ruchu
w
szególności
jeśli
chodzi
o
linki
o
prędkości
większej
niż
1
GB/s
-­‐
Trzeba
na
chwilę
rozpiąć
infrastrukturę
-­‐
Interfejsy
TAP
są
dość
drogie

17. Jak
i
gdzie
sniffować
Na
samych
urządzeniach
sieciowych
+
Nie
wymaga
rozpinania
infrastruktury
+
Możliwość
filtrowania
ruchu
+
Możliwość
łapania
ruchu
na
interfejsach
FC
-­‐
Małe
bufory
-­‐
Niski
priorytet
-­‐
Nie
wszystkie
urządzenia
wspierają
tą
funkcję

18. Jak
i
gdzie
sniffować
Wersje
hardcore
raczej
nie
przeznaczona
dla
środowisk
produkcyjnych

MAC
Address
flooding,
doprowadzamy
do
przepełnienia
tablicy
MAC
switcha
i
redukujemy
go
do
roli
HUB a,
lub
tak
zwanego
„Fail
open
ARP
Poisoning,
czyli
Man
In
The
Middle

19. Kilka
przydatnych
funkcji
1.
MergeCap
 Służy
do
łączenia
kilku
pcapów
w
jeden
 Przydatny
jeśli
ruch
przechodzi
przez
kilka
urządzeń
i
jest
NATowany
 Nasz
kolektor
może
zbierać
pliki
w
małym
rozmiarze
a
za
pomocą
tego
narzędzia
możemy
je
poźniej
scalić.

20. Kilka
przydatnych
funkcji
2.
Flow
Graph
 Jest
niezastąpiony
przy
analizie
konwersacji
w
środowiskach
w
których
ruch
“biega”
między
wieloma
serwerami
lub
urządzeniami
sieciowymi.
Przy
LB
jest
również
bardzo
przydatny
 Pozwala
ustalić
wzorzec
ruchu
na
przyszłość

21. Kilka
przydatnych
funkcji
3.
Kolumna
Delta
Time
 Standartowo
nie
ma
jej
w
wiresharku.
 Podaje
nam
ona
czas
pomiędzy
czasem
złapania
poszczególnych
pakietów.
 Jest
niezastąpiona
przy
analizie
opóźnień.
 Jest
przydatna
przy
każdej
analizie


22. Kilka
przydatnych
funkcji
3.
Capture
Filter
 Pozwala
nam
wstępnie
odfiltorwać
ruch
który
nas
nie
interesuje.
 Pomoga
nam
odciążyć
kolektor
i
zmniejszyć
wielkość
naszych
plików
pcap
 Jest
przydatny
jedynie
do
pierwszego
odfiltrowania
nieporzadanego
ruchu.
 Należy
uwarzać
gdyż
bardzo
łatwo
jest
wyciąć
zbyt
dużą
ilość
ruchu.

23. Kilka
przydatnych
funkcji
4.
Display
Filter
 Podstawa
pracy
z
wireshariem
 Pomaga
nam
odnaleźć
dokładnie
to
czego
potrzebujemy
 Posiada
złożoną
składnię
dzięki
której
możemy
szybko
odfiltrować
intersujący
nas
ruch.
 Możemy
filtrować
po
dowolnym
parametrze
pakietu!

24. Przykłady
z
życia
wzięte
„Problem
z
niektórymi
połączeniami”
 Czas
części
połączeń
jest
dłuższy
o
ponad
500%
 Nie
mamy
informacji
o
tym
czym
wyróżniają
się
„długie
połączenia
 Bardzo
ograniczony
debug
po
stronie
klienta
aplikacji
 Brak
dostępu
do
logów
z
serwera

25. Przykłady
z
życia
wzięte
„Problem
z
niektórymi
połączeniami”
Uproszczona
topologia:

26. Przykłady
z
życia
wzięte
„Problem
z
niektórymi
połączeniami”
Gdzie
łapaliśmy
pakiety:

27. Przykłady
z
życia
wzięte
„Problem
z
niektórymi
połączeniami”
Co
uzyskaliśmy?
 Pcap
z
poprawnym
czasem
połączenia.
 Pcap
z
wadliwym
czasem
połączenia.
Po
ich
porównaniu
mieliśmy
winnego

Jak
tego
dokonaliśmy…

28. Przykłady
z
życia
wzięte
„Problem
z
niektórymi
połączeniami”
1. Zebraliśmy
odpowiednio
przefiltrowane
PCAPy
z
odpowiednich
miejsc.
2. Użyliśmy
narzędzia
mergecap
w
celu
scalenia
wyników
capture
do
jednego
pliku.
3. Użyliśmy
funkcji
Flow
Graph
w
celu
uzyskania
lepszego
punku
widzenia
na
całą
ścieżkę
połączenia
i
…

32. Przykłady
z
życia
wzięte
 Za
pomocą
Vmestampów
z
plików
PCAP
udało
się
wyśledzić
w
logach
serwera
wadliwe
połączenie.
 Za
pomocą
logów
i
zawartości
pola
data
konkretnych
pakietów
developerom
aplikacji
udało
się
ustalić
gdzie
tkwił
błąd
i
go
naprawić.
Pracochłonne?
„Problem
z
niektórymi
połączeniami”
Całość zajęła około 30 minut…
Okazało
się
iż
problem
znajdował
się
na
serwerze
aplikacyjnym.

33. Przykłady
z
życia
wzięte
W
jednej
z
aplikacji
znacznie
wydłużyły
się
czasy
ładownia
paczek
z
danymi.
Administratorzy
DB
dostarczyli
wykres
pokazujący
iż
faktycznie
coś
jest
nie
tak:
„Wolno
działająca
aplikacja
i
podejrzana
baza
danych”

34. „Wolno
działająca
aplikacja
i
podejrzana
baza
danych”
Jednym
z
podejrzanych
był
proces
importu
paczki
danych.
Za
pomocą
funkcji
I/O
Graphs
dokonaliśmy
wstępnej
analizy:

35. Za
pomocą
tego
wykresu
określiliśmy
jak
wygląda
proces
pobierania
jednej
paczki
danych.
„Wolno
działająca
aplikacja
i
podejrzana
baza
danych”

36.
W
celu
określenia
kierunku
konwersacji
użyliśmy
narzędzia
StaRsRcs
ConversaRons.
Dla
pliku
pcap
pierwszego
peaku:
Oraz
dla
pliku
pcap
drugiego
peaku:
„Wolno
działająca
aplikacja
i
podejrzana
baza
danych”

37.
 Wiedzieliśmy
o
tym
że
w
trakcie
jednej
takiej
transakcji
przesyłane
jest
około
500
zapytań
a
następnie
otrzymywane
jest
około
500
odpowiedzi.
 Musieliśmy
znaleść
paczkę
500
zapytań.
 Na
podstawie
analizy
I/O
Graphs
wyizolowaliśmy
jedną
transakcję
zapytanie
-­‐>
odpowiedź.
 Następnie
rodzieliliśmy
zapytania
i
odpowiedzi
na
dwa
oddzielne
pliki
pcap.
 Skorzystaliśmy
z
funkcji
StaRsRcs-­‐>
Packet
Lengts.
„Wolno
działająca
aplikacja
i
podejrzana
baza
danych”

38. Dla
pierwszego
peaku,
wysyłanie
z
B
do
A:
Dla
drugiego
peaku,
wysłanie
z
A
do
B:
„Wolno
działająca
aplikacja
i
podejrzana
baza
danych”

39. Jak
zauwarzyliśmy
druga
część
transackji
(wysłanie
z
A
do
B)
zajmowało
znacznie
więcej
czasu
(B-­‐>A
-­‐
4s,
A-­‐>B
-­‐
40s).
Za
pomocą
fucnkji
StaRsRcs
TCP
Stream
Graph
Time
Sequence
Graph
(Stevens),
przyjrzeliśmy
się
wysyłanemu
strumieniowi
danych.
„Wolno
działająca
aplikacja
i
podejrzana
baza
danych”

40. Okazało
się
iż
aplikacja
wysyła
po
13
rekordów
po
czym
następuje
1s
przerwa.
Przy
około
500
rekordach
daje
to
nam
około
40s
przestoju
przy
wysyłaniu
jednej
paczki.
A
tych
paczek
jest
ponad
50
w
każdej
sesji.
„Wolno
działająca
aplikacja
i
podejrzana
baza
danych”

41.  Dalsza
analiza
wykazała
iż
dla
porównania
przy
przesyłaniu
informacji
w
pierwszym
peaku
aplikacja
przesyła
po
80
rekordów
i
dopiero
po
tym
czasie
następuje
1s
przerwa.
 Problem
został
zdiagnozowany.
Po
przekazaniu
wszystkich
informacji
do
administratorów
DB
i
analizie
tego
problemu,
Vcket
został
przekazany
do
develeoperów
aplikacji.
 Tym
razem
analiza
była
znacznie
bardziej
czasochłonna.
Zajęło
to
kilka
godzin.
Lecz
znów
problem
udało
się
zlokalizować
za
pomocą
analizy
pakietów.
 Jako
ciekawostkę
dodam
iż
z
bazami
danych
mam
bardzo
mało
wspólnego
Przykłady
z
życia
wzięte
„Wolno
działająca
aplikacja
i
podejrzana
baza
danych”

42. Podsumowanie
 Nie
należy
się
bać
analizy
pakietów.
Mając
odpowiednią
wiedzę
z
działania
protokołu
IP
można
osiągnąć
naprawdę
świetne
wyniki.
 Należy
przestać
myśleć
o
analizie
pakietów
jak
o
ostaniej
desce
ratunku.
Często
zamiast
spędzać
pół
nocy
nad
konsolą
wystarczy
po
pojawieniu
się
problemu
złapać
i
przenalizować
kilka
pakietów,
aby
szybko
wskazać
problem.
 Analiza
pakietów
jest
czasochłonna,
lecz
moim
zdaniem
jedynie
na
początku.
Już
po
pierwszych
kilku
analizach
jej
czas
skraca
się
wielokrotnie.
 Aby
szybko
odnajdywać
nieprawidłowości
należy
poświęcić
odrobinę
czasu
na
naukę
obsługi
narzędzia
do
analizy
pakietów.
Dużo
osób
o
tym
zapomina,
przez
co
marnują
czas.
 Analiza
pakietów
doskonale
sprawdza
się
w
diagnozowaniu
wszelkich
problemów
nie
tylko
sieciowych
dzięki
czemu
jest
świętną
furtką
dla
DevOps,
i
polepszania
współpracy
między
działami.
Dziękuję za uwagę!