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.