Security practices with CFEngine as seen across big community and enterprise installations

1. Security Practices with CFEngine
as seen across big community and enterprise installations
Dimitrios Apostolou
jimis@cfengine.com
Nick Anderson
nick.anderson@cfengine.com

2. Host Security Checklist
●
host firewall, gateway firewall
●
Backup everything (including policy)
– regularly test restore
●
disable unwanted or unknown services
●
remove unnecessary packages
– remove dev packages
●
SSH: disallow root login, allow only specific users,
●
protocol version 2 only, display banner, etc
●
Use sudo and sudoers
●
keep system up to date
– while avoiding automatic breakage
●
enforce SELINUX and turn on iptables
– occasionally deal with the breakage
●
account management
− disallow users using same old
password
− enforce strong password
− password expiry
●
disable CTRL+ALT+DEL
●
remote syslog
●
mail important logs
− while keeping log noise minimal
●
run usbguard
●
physical security
●
[ … ]

3. Host Security Checklist
●
This was just a small one
●
Every sysadmin has his own checklist
– (usually gained through painful experience)
●
Official, regulated checklists do exist
– Thousands of very simple checks
– Example: STIG, CIS
– Automated policy feasible
– (see references and wait for demo!)
So, we got ourselves well covered, what can possibly go wrong now?

5. What happens when the 1st
line of defense is
breached?
●
Information Disclosure
●
Policy has the great advantage of being live documentation for
the whole infrastructure
– Disadvantage?
●
Configuration Management opens new horizons for the
attacker
– Study network topology
– Figure out company internal details
– Work his way in step-by-step
– Worst-case: directly configure other hosts
(case of misconfigured trust or access_rules)

6. Policy files, JSON files, CFEngine module files, CSV files usually
describe all of the infrastructure very concisely.
classes:
"compute_nodes" expression => iprange("1.2.3.1-4");
"storage_nodes" expression => iprange("1.2.3.5-8");
"db_nodes" expression => iprange("1.2.3.9-12");
"cluster_nodes" or => {
"compute_nodes","storage_nodes","db_nodes"
};
"firewall" expression => fileexists("/etc/blah");
"svn_server" expression => classmatch("123_123_123_123");
Additionally, a technical breach doesn't even have to occur
--> A person is usually the weakest link

7. So how can we deploy and manage our
infrastructure and policy,
in order to minimise information leakage,
while enjoying other benefits as well?

8. Infrastructure Split
●
GOLD – SILVER – BRONZE compartmentalisation
– GOLD: strictest security, e.g. policy hub
●
But not critical for product delivery – no panic if it's down for a while
– SILVER: medium security, critical services go here, possibility for
multiple silver zones
– BRONZE: everything else
●
Zone breach never compromises higher zone
– Policy is carefully structured and files/directories split and
protected appropriately
– Carefully isolated VLANs or DMZs
– Appropriate access_rules and CFEngine key distribution
– this will probably lead to some policy rewriting, but peace of mind
is worth it

9. Policy Hub(s)
●
Treat this as GOLD. It knows everything, having it hacked is fatal.
– But does it have to be that way?
In CFEngine the policy hub is just another autonomous agent so it
can be set up in a distributed way.
●
This can yield big improvements in both performance and security.
●
However it involves considerable administrative overhead which
might not be worth, depending on the number of configured
nodes.

10. Distributed Hub Configuration Examples
●
Many identical hubs (mirrors), custom =update.cf= to
download from an slist of IP addresses
●
Separate hubs, host groups bootstrapped to different hubs that
serve different sets of policies
– full compartmentalisation - double administrative overhead
●
Keep different hubs in many custom policy variables for all
hosts, each one serving different set of policy files
– =sys.policy_hub= is no longer valid - manual bootstrap needed -
manual trust establishment - manual update.cf
●
Cascaded hubs: Central hub(s) distributing generic policy;
autonomous departments have their own hubs pulling the
generic configuration, then merging in their own changes
before serving it to the department's machines.

11. Bowtie Process of Policy Management
●
Either many independent VCS repositories, or one with
appropriate ACL controls
●
Editing/Viewing right different to the different departments
●
fan-in to the Policy Dispatcher, who has full access to the Hub
●
fan-out to the hosts pulling the merged policy
“The burden of security is now localized entirely at the Policy
Dispatch Point. It becomes the responsibility of this role (policy
dispatcher) to ensure that the desired state is in fact the one
that is promised.”

13. Secrets in Policy
●
Rule no.1: You do not need secrets in your policy
●
But what if you do really want them? :-)
– Have them in seperate files, give access only to the relevant hosts
(bundle server access_rules)
– Secrets should be either hashes or encrypted
– cf-keycrypt – community tool for encrypting with the client's
public key, so that only that one client can decrypt
– Misc key vault tools

14. Secure CFEngine Bootstrap
●
Put Hub's key in client's ppkeys
●
Put client's key in Hub's ppkeys
●
Keep trustkeysfrom always empty
cf-agent --trust-server=no --bootstrap $HUB_IP

15. cf-runagent: allow only specific bundles
●
cf-serverd:
bundle server access_rules() {
access:
"bundle2"
admit_ips => { "127.0.0.1", "::1" },
resource_type => "bundle";
}
cf-runagent -H $CLIENT_IP --remote-bundles bundle2

16. File Change Monitoring
● cfe_internal/enterprise/file_change.cf
vars:
linux::
"watch_files_report_diffs"
slist => {"/etc/passwd","/etc/group"};
files:
linux::
"$(watch_files_report_diffs)" -> { "InfoSec" }
changes => diff;
2016-01-26T19:08:36+0000 notice:
/default/service_catalogue/methods/'security'/default/ch
ange_management/files/'/etc/passwd'[0]: Hash 'sha256'
for '/etc/passwd' changed!

17. Thanks
●
Bjørgeengen, Jarle (Cascaded hubs)
●
Bjørnstad, Jon Henrik (cf-keycrypt)
●
Burgess, Mark (Bowtie process etc special topics)
●
Georgatos, Fotis (Gold-Silver-Bronze compartmentalisation)
●
Marongiu, Marco (security checklist)
●
Phooripoom, Nakarin (security checklist)
●
Schulz, Tilman (much of the CIS policy)

18. References
●
file changes monitoring policy:
https://github.com/cfengine/masterfiles/blob/master/cfe_internal/enterprise/file_ch
ange.cf
●
distributed file monitoring:
https://auth.cfengine.com/manuals/st-security#Tamperproof-data-and-distributed-m
onitoring
●
bowtie process:
https://auth.cfengine.com/archive/manuals/st-rbac
https://auth.cfengine.com/archive/manuals/st-teams
●
Gold-Silver-Bronze infrastructure compartmentalisation:
http://www.sambaxp.org/archive_data/media/georgatos-XP2003.pdf
https://www.usenix.org/legacy/event/lisa98/full_papers/traugott/traugott.pdf
●
Cf-keycrypt: https://github.com/cfengineers-net/cf-keycrypt
●
STIG policies: https://auth.cfengine.com/stig
●
CIS policies: https://github.com/nickanderson/cfengine-cis