[lxc-users] lxc-security: iptables audit with nflog not working with default settings (insecure)

[Fiedler Roman]

> Von: lxc-users [mailto:lxc-users-bounces at lists.linuxcontainers.org] Im 
> Auftrag
>
> On Wed, Mar 11, 2015 at 5:48 PM, Fiedler Roman <Roman.Fiedler at ait.ac.at>
> wrote:
> > Hello list,
> >
> > Has someone managed to get reliable network traffic auditing with LXC up
> and
> > running? That means, that it is possible to write a protocol of e.g. every
> > new connection from and to host.
> >
> > On my setup (Ubuntu Trusty), both host and guest may have different
> iptables
> > rulesets. But the guest NFLOG messages are lost completely, those from 
> > host
> > are sometimes sent to the ulogd in the guest (time-race), so the host log 
> > is
> > not trustworthy also.
> >
> > What could be the best solution to get trustworthy logs with LXC?
>
> Try something like this on the host:
>
> echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
> iptables -I FORWARD 1 -d 192.168.124.173 -j NFLOG --nflog-group 0
> --nflog-prefix lxc-v
> iptables -I FORWARD 1 -s 192.168.124.173 -j NFLOG --nflog-group 0
> --nflog-prefix lxc-v
>
> with the default ulogd2 setup on ubuntu 14.10 (which already includes
> rules for nflog-group 0 logging to a file)  you should then be able to
> get something like this when the container (192.168.124.173) pings
> another container (192.168.124.134)

This should be exactly the configuration I have tested  so far. But that did 
not yet solve my problem ...

* If some process in guest registers for the same NFLOG queue, he can "steal" 
the messages from the host queue, thus removing traces of his activity from 
host logging. SECURITY-ASPECT: apart from log corruption, the guest can get 
knowledge about any other connection to/from other containers and the host and 
as they include  sequence numbers, may be able to inject spoofed data into any 
other unencrypted TCP connection or at least interrupt the connection using 
another helper machine.

* If a guest should be protected with iptables also, e.g. to avoid Apache or 
Tomcat to connect to the local SSH port, those error logs - which are useful 
to detect ongoing guest intrusions - do not make it to any log-file.

[...snip...]

> You might only be missing the "bridge-nf-call-iptables" part. Note
> that you shouldn't need it IF you use a custom lxc network setup which
> doesn't use bridges:
> https://www.mail-archive.com/lxc-users@lists.linuxcontainers.org/msg02587.html

I've tried various network configurations also. I fear that effort here is 
quite futile since I do not yet understand the core kernel namespace concepts, 
e.g. how nflink and user namespaces work together. Hence everything I could do 
is (inefficient) trial and error instead of controlled engineering. And in the 
end I cannot be sure that there are not reliability/security-relevant holes 
left open with trial/error.

Without any other clues from the mailing list, I'll still try out this 
procedure also and see if it would change the nflog behavior.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6344 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20150311/5eff35d8/attachment.bin>