Hi Stuart,
On 2023-08-11 11:39:24, Stuart Henderson wrote:
On 2023/08/11 08:47, Harald Dunkel wrote:
For forensic measures in case of an incident it is crucial to
have the peers public key. This string is constant over time
(unless it is not rotated for security). The first 16 or 10
chars should do., e.g.
% grep 3QUz9EgDY4 /var/log/messages
:
Aug 9 15:22:02 mygate /bsd: wg0: Sending handshake initiation to peer 17
(3QUz9EgDY4)
Aug 9 15:22:07 mygate /bsd: wg0: Handshake for peer 17 (3QUz9EgDY4) did not
complete after 5 seconds, retrying (try 19)
Is that just meant as an example, or do you have a diff? If you have a
diff, please send it, because from a quick read it seems doing that is
non-trivial (logging the peer description would be simpler, but whether
it's pubkey or descr, I'm pretty sure it requires taking a lock to
access this information, and that makes it a fairly complex change to
review).
This was just a mock, of course. I don't want to request complex changes,
just something better suitable than "peer 17". I have seen the public key
as some kind of not modifiable identifier for a VPN connection. Adding
the description to the log file wouldn't help, since there is just a
single description for a wireguard connection with multiple peers (if
I understood ifconfig(8) correctly).
I am talking about the setup for a road-warrior VPN gateway. The road-
warriors are supposed to have their own IP address, but they use the
same subnet and routing.
It would be much easier to log the public key and peer number when the
peer is created, but then you'll need to keep more logs.
Some peers are connected 24/7 for weeks.
If you're doing analysis of wg debug logs, you'll also have a problem
with how the messages get split up in syslog sometimes, and making the
lines longer isn't going to help that
/bsd: wg0: Receiving handshake re
/bsd: sponse from peer 0
/bsd: wg0: Send
/bsd: ing kee
/bsd: pali
/bsd: ve p
/bsd: ack
/bsd: et to
/bsd: pee
/bsd: r 0
This is OK, I can live with that.
Regards
Harri
