Openly Secure   

Staying secure by using Open Source Mohamed Hussein Sayed mechanic@unixgarage.com h;p://www.unixgarage.com/

openlysecure.pdf 

Using OSS where security ma;ers 

•  Some corporaAons and government agencies forbid it. 

•  The source is available!: Easier for bad guys to find holes. 

•  The source is available!: Good guys can find holes and fix them. 

•  The source is available! You can fix it yourself or pay someone to fix it. 

The OS: Choosing a secure foundaAon 

•  The OS controls everything; if it is compromised the game is over. 

•  Linux kernel size and pace makes it harder to audit. 

•  SELinux was developed to cover the gaps and provide a more secure linux plaNorm. 

•  SELinux main features: Mandatory access controls, Security policies, implemented as LSM. 

The OS: Choosing a secure foundaAon 

•  SELinux is now enabled in many mainstream distribuAons. 

•  SELinux core idea is to protect the system in case of a parAal compromise. 

•  Many sysadmins are frustrated by the configuraAon and turn it off. 

The OS: Choosing a secure foundaAon. OpenSolaris 

•  Made serious efforts towards improving security infrastructure at the OS level. 

•  Common Criteria cerAfied EAL4+. •  Role based access control. •  Supports many popular firewalls.(PF, IPFilter). •  Policy management and roles definiAon requires some pracAce. 

•  Supports Pluggable AuthenAcaAon Modules , Kerberos, LDAP. 

The OS: Choosing a secure foundaAon OpenBSD 

•  Designed from the ground up with security in mind. 

•  Best security track record among OS OS’s. 

•  Gave birth to OpenSSH, the defacto secure shell. 

•  Gave birth to PF, solid and robust firewall engine. 

•  Great IPv6 and IPSec support. 

The OS: Choosing a secure foundaAon. OpenBSD 

•  May be late to implement features, especially if it affects security. 

•  May not support the latest and greatest hardware. 

•  Excellent choice for network services type work including Firewalls, VPNs, DNS , FTP, Mail and Web servers. 

The applicaAons: Email 

•  Crucial service in today’s world. •  Insecure email servers have been notoriously targeted in the past. 

•  Must be closely monitored. 

•  The grandfather of email servers had several major security issues. 

•  Newer alternaAves like sendmail had security as a core requirement.  

The applicaAon: FTP servers 

•  Older dp servers were commonly targeted. •  VulnerabiliAes usually required only a normal user which may be easily sniffed or socially engineered. 

•  Newer dp servers implement chroots, allow for stricter policies. 

•  VSFTPD puts a great effort into providing the service securely 

The applicaAon: Web Servers 

•  Crucial service for modern business. •  Industry standard has been apache. •  Apache has a great track record, but as the project adds features this record may come to test. 

•  Apache has support for various authenAcaAon backends. 

•  AlternaAves with less features are available and may be easily audited. 

Loose the fat: Less is be;er 

•  Many main stream distribuAons turn on services by default. 

•  It is important to disable any addiAonal services you may not use. 

•  Linux distribuAons can have a laxed service startup policy. 

•  OpenBSD service management is easy via /etc/rc.conf 

Secure the permiter 

Secure the perimeter: Firewalls 

•  OS firewall engines are plenty and excellent in features. 

•  IPTables has very large feature set, excellent modules repository and great library for developers. 

•  PF has a very clean syntax, excellent feature set. Excellent performance and have been ported to many OS’s 

Secure the perimeter: Firewalls Successful implementaAon 

•  Decide on a posture. •  Be Paranoid. •  Understand the business requirements. •  Create a policy. •  Review with your peers, ask the experts for Aps without leaking informaAon. 

•  Implement. •  Monitor. •  Adjust. 

Sample PF ruleset # macros ext_if="fxp0” int_if="xl0” tcp_services="{ 22, 113 }” icmp_types="echoreq” comp3="192.168.0.3” # opDonsset block‐policy return set loginterface $ext_if set skip on lo # scrub scrub in # nat/rdr nat on $ext_if from !($ext_if) ‐> ($ext_if:0) nat‐anchor "Rp‐proxy/*” rdr‐anchor "Rp‐proxy/*” rdr pass on $int_if proto tcp to port Rp ‐> 127.0.0.1 port 8021 rdr on $ext_if proto tcp from any to any port 80 ‐> $comp3 

Sample PF (CONT.) # filter rules block in pass out keep state anchor "Rp‐proxy/*” anDspoof quick for { lo $int_if } pass in on $ext_if inet proto tcp from any to ($ext_if) \   port $tcp_services flags S/SA keep state pass in on $ext_if inet proto tcp from any to $comp3 port 80 \    flags S/SA synproxy state pass in inet proto icmp all icmp‐type $icmp_types keep state pass in quick on $int_if 

Watch the acAon: IntrusAon detecAon 

•  Goal: Detect failed and successful a;empts to compromise your digital assets. 

•  Different types exist: Host intrusion detecAon, network intrusion detecAon. 

•  HIDS aim to detect a;acks at the machine level. It leverages filesystem monitoring, process monitoring,etc.Example: Tripwire. 

•  NIDS aim to detect a;acks by monitoring and compare against known a;acks signature. 

OS IDS: Snort 

•  Snort is a mature and well supported IDS. •  Sniffs traffic off the network and compare against signatures(Rules) 

•  Plenty of tools to analyze events or integrate with other systems 

•  ConfiguraAon system is straighNorward. 

•  Lately adopted a subscripAon model. 

OS IDS: Snort var HOME_NET any var EXTERNAL_NET any var DNS_SERVERS $HOME_NET var SMTP_SERVERS $HOME_NET var HTTP_SERVERS $HOME_NET var SQL_SERVERS $HOME_NET var TELNET_SERVERS $HOME_NET var SNMP_SERVERS $HOME_NET portvar SSH_PORTS 22 portvar HTTP_PORTS 80 portvar SHELLCODE_PORTS !80 portvar ORACLE_PORTS 1521 var RULE_PATH /etc/snort/rules var PREPROC_RULE_PATH /etc/snort/preproc_rules dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/dynamicengine /usr/local/lib/snort_dynamicengine/libsf_engine.so preprocessor frag3_global: max_frags 65536 preprocessor frag3_engine: policy first detect_anomalies 

OS IDS: BASE 

Analyze the logs 

•  Unexamined data is worthless. •  Tune your environment to record what you care about. 

•  Centralize your logs. •  Make it a habit to surf your logs. 

•  Create reports and graphs. A picture is worth a 1000 words. 

References 

•  www.openbsd.org/security.html •  opensolaris.org/os/community/security/ •  www.nsa.gov/research/selinux/ •  www.snort.org •  www.tripwire.org •  www.wireshark.org •  en.wikipedia.org/wiki/Syslog‐ng •  www.apache.org •  www.packetstormsecurity.org •  www.cert.org •  www.sans.org