Source Port Korrelation

Olivier
Olivier

Der Source Port von TCP Verbindungen kann nützlich zum Debuggen sein. Er erlaubt einen Rückschluss auf die exakte Prozess ID auf dem Source System.

Nach dem Upgrade auf die neuste Fortigate Version hatten wir neulich das Problem, dass die CPU permanent auf 100% ausgelastet war. Der Schuldige lies sich über ein get system performance top einfach finden. sshd verursacht mit mehreren Prozessen, dass alle Cores permanent ausgelastet waren. Diese Prozesse liessen sich zwar mit diagnose system kill 9 <PIDNR> abschiessen, allerdings kamen auch schnell wieder neue 'CPU-Fresser' dazu. Ein etwas umfangreicheres Debugging war also gefordert.

In der Ausgabe von get system session list | grep ":22" war schnell ersichtlich, dass es sich um SSH Sessions vom Monitoring Server handeln musste. Die entsprechenden Sessions waren länger offen und verschwanden auch nach mehreren Minuten nicht. Eine normale Monitoring Session dauert sonst max. 10 Sekunden.

Beispieloutput von get system session list:

PROTO     EXPIRE  SOURCE         SOURCE-NAT   DESTINATION    DESTINATION-NAT
...
tcp 1600 192.168.0.10:12345 -          192.168.1.1:22 -
...

Da der Monitoring Server viele SSH Sessions zu dem betroffenen System öffnet, und zudem noch verschiedene Skripte ausgeführt werden, lässt sich nicht einfach bestimmen welcher Monitoring Check Amok lief, resp. für die hohe CPU Last verantwortlich war. An dieser Stelle kam der Source Port ins Spiel. Mit ihm lässt sich der Problemprozess auf dem Quellsystem ausfindig machen. Dies kann man z.B. mit einem netstat. Dabei helfen die Optionen: --tcp|-t für TCP Verbindungen, --numeric|-n für die numerische Ausgabe von Ports und --programs|-p welches noch das Programm angibt:

$ netstat -tnp | grep <sourceport>
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp       12     48 192.168.0.10:12345          192.168.1.1:22      ESTABLISHED 9590/ssh: username

In der Spalte PID/Programm Name steht die Prozess ID. Nun muss man diese nur noch über pstree oder ps axfu suchen und hat den Schuldigen gefunden.

$ ps axfu
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
...
monitoringuser      12344  0.0  0.7   9128  3784 pts/8    Ss   20:28   0:00  |       \_ -bash
monitoringuser      12345  0.0  0.1   3532   836 pts/8    S+   20:46   0:00  |           \_ monitoringcmd 
...

In diesem fiktiven Output war nun der Befehl monitoringcmd für die Hohe CPU Last verantwortlich.