Bug 1566132

Summary:	ipsec.conf logip=no config setup option doesn't seem to work
Product:	Red Hat Enterprise Linux 7	Reporter:	Martin Zelený <mzeleny>
Component:	libreswan	Assignee:	Paul Wouters <pwouters>
Status:	CLOSED NOTABUG	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.5
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-04-17 15:19:24 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Martin Zelený 2018-04-11 15:17:01 UTC

Description of problem:
When trying to hide peers IP address, the address is still visible in logs.

Version-Release number of selected component (if applicable):
libreswan-3.23-3.el7

How reproducible:
On both CLIENT and SERVER there is the same /etc/ipsec.conf:

version 2.0

config setup
 plutodebug="none"
 logappend=no
 plutostderrlog="/var/log/pluto/pluto.log"
 protostack=netkey
 virtual_private=
 oe=off
 logip=no

conn test-logip
 authby=secret
 left=<CLIENT>
 right=<SERVER>
 keyingtries=1


Steps to Reproduce:

SERVER:
1. service ipsec start && sleep 5
2. ipsec auto --add test-logip

CLIENT:
1. service ipsec start && sleep 5
2. ipsec auto --add test-logip
3. ipsec auto --up test-logip


Actual results:

Both SERVER and CLIENT IP addresses are visible in /var/log/pluto/pluto.log:
"test-logip" #1: Peer ID is ID_IPV4_ADDR: '<SERVER>'

output of CLIENT's command "ipsec auto --up test-logip"
002 "test-logip" #1: Peer ID is ID_IPV4_ADDR: '<SERVER>'

output of "ipsec auto --status":
000 "test-logip": <ip address><CLIENT>...<ip address><SERVER>; erouted; eroute owner: #

- CLIENT and SERVER are real IP addresses


Expected results:
Opposite peer's IP address will be hidden.

Additional info:
If behavior is correct, please tell how the "logip=no" option is meant to be used.

Comment 2 Paul Wouters 2018-04-12 14:30:15 UTC

The ipsec status command is not further protected. Only the logging is censored, and only when not enabling any kind of debugging.

It does seem that you found one issue where the peer uses its IP as ID, and since we don't filter ID's, the IP leaks there.

The usual deployment for this option is where the administrator uses either a groupid and preshared key, or certificate based ID's. These would not reveal the IP address.

Comment 3 Martin Zelený 2018-04-16 12:59:27 UTC

(In reply to Paul Wouters from comment #2)
> The ipsec status command is not further protected. Only the logging is
> censored, and only when not enabling any kind of debugging.

Ok, I will not test output of the status command.

> It does seem that you found one issue where the peer uses its IP as ID, and
> since we don't filter ID's, the IP leaks there.

Can we consider this issue as a bug? Do we want to track it in this BZ or another one?

> The usual deployment for this option is where the administrator uses either
> a groupid and preshared key, or certificate based ID's. These would not
> reveal the IP address.

Should I enrich testing for this type of use or is the presumption correct that "logip=no" means no IP in the log even not in the ID value?

Thanks

Comment 4 Paul Wouters 2018-04-17 14:16:05 UTC

logip= is really to prevent simple IP logs for large deployments that need to keep privacy. It is meant to ensure there are no log entries binding the (pseudo anonymous) ID with an IP address. So this prevents user344324324 leaving traces of their IPs in the logs.

This is mutually exclusive with using ID type IP. There you are always on the same static IP and there is no privacy issue here of tracking a single user through a cloud of VPN servers.

So speaking with my upstream hat on, I believe the option is working properly.

I added the following sentence to the man page for logip=

    When using ID of type IP address, this option will not hide 
    the actual IP address as part of the ID.

Comment 5 Martin Zelený 2018-04-17 15:19:24 UTC

Thanks for explanation. Closing this as NOT A BUG.

Comment 6 Paul Wouters 2018-04-17 16:43:37 UTC

Thanks for the testing and reporting! If you find other things you are unsure about, please keep reporting them!