> Von: lxc-users [mailto:[email protected]] Im > Auftrag > > On Wed, Mar 11, 2015 at 5:48 PM, Fiedler Roman <[email protected]> > 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/[email protected]/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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
