Przystępując do diagnostyki problemu sieciowego czy aplikacyjnego musimy dokładnie zaplanować scenariusz, za którym będziemy podążali. W takim scenariuszu uwzględniamy to, w jaki sposób będziemy zbierali dane diagnostyczne i wykorzystywali dostępne nam narzędzia. Jednym z nich może być Wireshark, albo system z rodziny Unix czy BSD tcpdump, w przypadku, gdy jedno z urządzeń działa pod jego kontrolą. Niezależnie, jaki sposób zbierania i analizy danych wybierzemy, jeżeli odpowiednio nie zaplanujemy swojej pracy, zostaniemy przytłoczeni nadmiarem zebranych informacji, przez które będzie nam się bardzo ciężko przebić.  W jaki sposób zatem zabrać się do zbierania i analizy danych? Poniżej kilka moich rad.

Rozpocznij zbieranie pakietów od strony klienta

Jeżeli rozpoczniesz zbieranie danych od strony serwera natychmiast przytłoczy cię liczba zapisanych w zrzucie pakietów. Serwery aplikacyjne mają to do siebie, że jednocześnie obsługują dziesiątki, setki, a nawet tysiące klientów. Każdy z nich może otworzyć kilka lub kilkanaście sesji TCP z aplikacją uruchomioną na serwerze. Wolumen danych przesyłanych w ramach danej sesji zależy od charakteru aplikacji. W takim natłoku informacji odfiltrowanie sesji konkretnego klienta może być skomplikowane (musimy przecież znaleźć wszystkie połączenia, które zostały przez niego nawiązane) oraz czasochłonne.

Rozpoczynając zbieranie pakietów od strony klienta o wiele prościej będzie nam odfiltrować tylko te, które są dla nas interesujące. W tym celu posłużymy się prostymi filtrami ograniczającymi zbieranie pakietów jedynie do wskazanych kryteriów. Jeżeli o tym zapomnimy, ilość nadmiarowych zebranych pakietów będzie o wiele mniejsza niż w przypadku, gdybyśmy rozpoczęli zbieranie po stronie serwera. Bardzo często już na tym etapie będziemy w stanie określić co jest przyczyną naszych problemów albo zawęzić obszar poszukiwania.

Pamiętajmy też, że w wielu przypadkach nie mamy możliwości zbierania pakietów po stronie serwera, lub wymaga to od nas dodatkowego nakładu pracy czy uzyskania zgód. Nawet w przypadku, gdy serwer należy do naszej firmy, może znajdować się on w strefie bezpieczeństwa, w której niedozwolone jest instalowanie bez kontroli oprogramowania zbierającego ruch sieciowy. Innym razem, zgodę na taką diagnostykę musi wyrazić Departament Bezpieczeństwa naszej firmy. Do stacji roboczej zazwyczaj mamy łatwiejszy dostęp, jak i reguły pracy z nią są o wiele luźniejsze.

Jeżeli to możliwe, loguj pakiety po stronie serwera i klienta jednocześnie

Jeżeli jednak masz dostęp do serwera i możesz z niego także zbierać dane, to po wstępnej analizie komunikacji od strony klienta warto uruchomić logowanie pakietów jednocześnie po stronie klienta i serwera. Wszystko po to, aby mieć obraz tego, w jaki sposób przebiega komunikacja z punktu widzenia obu tych systemów. Dane wysłane przez klienta wcale nie muszą dotrzeć do serwera w dokładnie takiej samej formie. Po drodze znajduje się szereg urządzeń sieciowych, które w różny sposób mogą wpływać na komunikację pomiędzy tymi dwoma systemami. Przykładowo, jeżeli w ścieżce znajduje się load balancer, to sesja TCP rozpoczęta przez urządzenie klienckie może zostać zaterminowana na load balancerze, a nie bezpośrednio na serwerze. Load balancer może dokonać ingerencji w strukturę danych, na przykład przez podmianę certyfikatu SSL lub całkowite usunięcie szyfrowania. W takim przypadku mamy do czynienia z komunikacją, w której w rzeczywistości nawiązywane są dwie sesje TCP – jedna pomiędzy klientem a load balancerem, i druga pomiędzy load balancerem a serwerem. Te sesje mogą charakteryzować się innymi parametrami.

Innym przypadkiem, na który musimy zwrócić uwagę, są wszelkie urządzenia, które służą nam do monitorowania i filtrowania ruchu. Jeżeli w ścieżce znajduje się IPS lub NGIPS to może on zostać skonfigurowany w taki sposób, by po cichu odrzucać pakiety, które powodują wyzwolenie sygnatury wskazującej na atak lub infekcję systemu. W takiej sytuacji, obserwując pakiety zarówno po stronie nadawcy  jak i odbiorcy, jesteśmy w stanie zaobserwować, które pakiety są gdzieś blokowane.

Jeżeli mamy do czynienia z ruchem UDP, to rejestrowanie datagramów po stronie nadawcy i odbiorcy pozwoli nam określić czy poszczególne datagramy giną gdzieś po drodze, a także czy dochodzą w takiej samej kolejności w jakiej zostały wysłane. Przypomnijmy, że  protokół UDP nie ma wbudowanych żadnych mechanizmów retransmisji, ani kontroli kolejności dostarczania informacji od nadawcy do odbiorcy.

Pozbądź się nadmiarowych informacji

W ciągu minuty możesz zebrać miliony pakietów, które następnie chcesz poddać analizie, żeby znaleźć źródło diagnozowanego problemu. Większość z tych informacji może być jednak zupełnie nieprzydatna. Dlatego krok po kroku musisz eliminować informacje zbędne i usuwać je z pola widzenia. W tym celu wykorzystuj filtry pozwalające ukryć informacje spełniające konkretne kryteria.

Filtrowanie warto zacząć od najprostszych reguł. Przykładowo, jeżeli analizujesz połączenie pomiędzy klientem a serwerem, które realizowane jest za pośrednictwem sesji TCP, możesz od razu odfiltrować zebrane pakiety typu braodcast i multicast. W kolejnym kroku możesz zawęzić filtrami wyświetlanie pakietów jedynie do urządzeń o wskazanym adresie IP lub numerze portu, za pośrednictwem którego następuje komunikacja. Tworząc filtry postępuj metodą małych kroków,  stopniowo rozbudowując reguły filtrowania. Za każdym razem weryfikuj czy nie eliminujesz w ten sposób istotnych informacji.

Korzystaj z osi czasu

W czasie diagnostyki niezbędna jest korelacja ze sobą zaobserwowanych zdarzeń oraz wyciąganie z nich wniosków. Kluczowe jest zatem zestawienie ze sobą zebranych informacji korzystając z osi czasu. To ona pokaże nam, jaka była chronologia zdarzeń na danym urządzeniu oraz pozwoli porównać je ze zdarzeniami na zdalnym systemie.

Pomocne w ułożeniu chronologii zdarzeń jest narzędzie Flow Graph, które znajdziemy w menu Statistics. Narysuje ono nam graf komunikacji pomiędzy systemami. Grafy tego typu są czytelne i wykorzystywane od dziesiątków lat m.in. w publikacjach naukowych czy opisach standardów. Jasno i przejrzyście pokazują proces chronologiczny, a także proces wymiany danych pomiędzy systemami. Wireshark uzupełnia graf o dane dotyczące protokołów czy zawartości pakietów.