ELFms discussion: iptables

Tuesday 2 Mar 2010, 14:15 → 15:00 Europe/Zurich

513-1-27 (CERN)

Veronique Lefebure

discuss use of the "ncm-iptables" component at CERN: Configuring iptables with Quattor is not trivial. Documentation could be improved, as well as the CDB templates to be used.

ELFms discussion: iptables (02 Mar 2010)

Chaired by: Ms. Lefebure, Veronique

Participants: Ricardo, Ulrich, Gavin, Giacomo, Igancio, Veronique, JanI [and others, hopefully on Veronique's list]

Issues

• Problem 1: there is no really useable "default" ncm-iptables configuration in CDB, this implies using the RH default - while this at least opens up SSH, it prevents Quattor from managing the machine.
• Problem 2: service managers should be able to easily add a port for a new service, without having to rewrite the whole iptables config from scratch.
• Problem 3: Y.Calas templates are old and rather convoluted (need review), but are in use and the names sound like "defaults". VOC instruction mention them.
• Problem 4: ncm-iptables auto-dispatch is bad (recently changed?), can e.g. kill some ORACLE connections on loaded machines - need explicitly-scheduled intervention.
• Feature request 1: would like to be able to open up access for a LanDB set (DB Group does this via LandDB+SOAP. but does not use ncm-iptables)

Discussion:

1. ncm-iptables should already allow to insert things, but have to set ordered_rules=no. (some settings don't really work with this, but these are special cases)
2. a lot of pain comes from the explicit "deny any SSH except lxadm" rules. Agreement - the explcit "deny" should go away, and instead a suitable "reject by default" needs to be implemented.
3. Agreement: ncm-iptables should have a minimal and restrictive set of rules that allows service managers to add new ports easily, e.g. via "service" templates. Removing ports again should normally not be neccessary. Quattor ports should only get opened for machines using Quattor, i.e. at the same time the respective RPMs or services get added (notd, cdb-listend)
4. Agreement: auto-dispatch should be off by default. iptables restart behaviour should be looked at, need perhaps to file a bug.

When could these changes be implemented? After the current (and last) "scheduled software update", via the then-free  /test namespace.

Short discussion on risk/merits - messing with all firewalls is inherently risky, but current situation is bad (example was that everybody is fully open to the security scanners - but nobody knew), and we are under pressure from security team to use iptables everywhere. Any changes would need careful phase-in, ideally would need explicit action from service owner.

Feature request 1: in principle accepted by Veronique but would like real use case (DB as requester isn't using ncm-iptables at all). Could work via a regular extraction of LanDB sets into CDB variables (that then can be used for loops).

Action on Gavin+Jan: write documentation for what new default will be used (i.e. via new component/iptables/config) - might include "emergency" lxadm access to cover up mistakes, and how to add a single rule (i.e. open a port).

Action on Veronique: reshuffle existing users of component/iptables/config to make clear that a legacy setup is in use (rename Y.Calas rules to _deprecated?).