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: usernameIn 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.