search

openziti / ziti

The parent project for OpenZiti. Here you will find the executables for a fully zero trust, application embedded, programmable network @OpenZiti
https://openziti.io
Apache License 2.0
2.68k stars 153 forks source link

Service dial success messages should include the IP:Port of the hosting device's connection #565

Closed mikegorman-nf closed 2 years ago

mikegorman-nf commented 2 years ago

THe IP:Port combination is the last piece of a complete forensic review of application logs from a non ziti embedded endpoint. For example, a web application is attacked or probed. The htaccess files or other logs indicate the IP:Port address of the attacker, but the IP is the Edge Router hosting the service. There are multiple service sessions attributable to multiple users in the same time frame. What device was it?

qrkourier commented 2 years ago

Have I got it? I think you want edge tunnelers that are hosting a service to log their own IP:port used by the server egress traffic. If so, isn't that tricky? A process sending traffic to egress from a device normally delegates to the OS and so there's no tight coupling of process ID and egress IP or port.

mikegorman-nf commented 2 years ago

The system is aware of the socket assigned on the local host. Today, I don't think the information leaves the host, only being logged locally when necessary. Sent back tot he controller in some message, it could become a part of the recorded events, and available for troubleshooting or forensic use cases.

mikegorman-nf commented 2 years ago

Additional probably related request. If the connection is TCP and fails due to a SYN timeout or RST packet, this should be reported as well. This will allow a better separation and understanding of user experienced failures. Currently, if the service is not responding on the terminating side, the Ziti network shows successful termination (of the circuit), but the user still experiences a problem, and the troubleshooting requires logs or packet traces from the hosting endpoint, taking significant time.

mikegorman-nf commented 2 years ago

Fantastic that this is now available and working. One additional request. Can we move the socket information to it's own field, rather than as part of the path field? There are some useful analyses looking at and counting paths, and the socket info makes each one unique, adding noise to the analysis.

plorenz commented 2 years ago

Functionality has been released