Sebastian Lopienski CERN Computer Security Team Securing your servers and code (and how we can help you)

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 2 Outline ►How to secure your servers ►How to secure your code ►How the Computer Security Team can help you

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 3 Things to avoid Security measures that can be easily bypassed

How to secure your servers Part 1:

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 5 Checklist 1.Harden the OS and Applications 2.Keep the OS and Applications up-to-date 3.Use a local firewall 4.Take advantage of the logs 5.Ensure that all passwords are secure 6.Take extra precautions for privileged accesses 7.Use security products when relevant 8.Take into account physical security 9.Keep your security knowledge up-to-date.

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 6 1. Harden the OS & applications ► minimise the number of  packages installed  accounts enabled  network services offered  privileged processes running (this includes running with least privileges whenever possible) ► tighten the configuration of the major services (this includes limiting access to the minimum) Why? ► to limit exposure ► to limit number of components that you have to secure

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 7 2. Keep the OS & apps updated ► install all the security patches as soon as possible ► ideally, use a system that automates patching this applies to the OS and to all the software installed on the server, and especially to network services Why? ► to close known vulnerabilities in OS and software ► and to make sure that patching is not forgotten in the future

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 8 3. Use a local firewall ► install a local firewall configured to only allow what is expected (i.e. default policy is deny) ► ideally, also filter outgoing network traffic Why? ► to limit exposure (by restricting incoming traffic) ► to prevent criminals using backdoors and remote access (by restricting incoming and outgoing traffic)

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 9 4. Take advantage of the logs ► select appropriate logging levels for all sensitive components ► frequently review the logs to detect suspicious activity ► ideally, store the logs remotely to avoid tampering  e.g. to Central Security Logging service Why? ► to detect attacks and incidents ► to be able to investigate them (find reasons, and learn from them)

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 10 Things to avoid Security measures that get disabled with time, when new features are installed

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 11 ► make sure that  the passwords used are good enough (ideally, enforce this with the appropriate tools)  the passwords are not exposed (this includes using encrypted protocols such as https, or services like SINDES)  the passwords are changed regularly this applies also to other authentication methods, e.g. SSH keys Why? ► because weak and badly protected passwords are very common attack vectors 5. Ensure password security

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide Precautions for privileged access ► restrict privileged accesses to the bare minimum ► use delegation to minimise the number of operations requiring full privileges (for instance use sudo on Unix/Linux) ► log all actions executed with system privileges Why? ► because privileged access is what criminals are after

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide Use relevant security products ► anti-virus (ideally, with automatic signature update) ► Intrusion Detection Systems (both host-based and network-based) ► integrity checkers to detect system modifications e.g. rpm –V, Tripwire, rkhunter, chkrootkit; see also Why? ► because they help prevent and detect intrusions

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 14 Things to avoid Security solutions that do not cover the whole exposure area

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide Physical access ► take into account physical security (when relevant) Why? ► because malicious person with physical access can bypass most protections (e.g. directly log in as root)

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide Security knowledge ► keep your security knowledge up-to-date visit to read/watch:  monthly security reports for CERN  security reports from SWITCH CERT  various presentations etc. follow security training, or just contact Why? ► to learn about threats, attack vectors etc., and protect yourself - before they affect you

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 17 Be lazy, and delegate! If you manage a server for your experiment, consider making it a VOBOX ► many of the points discussed above will be done for you ! ► contact your VO Coordinator for details

How to secure your code Part 2:

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 19 Software is vulnerable Vulnerabilities reported yesterday From secunia.com

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 20 When to start? Security should be foreseen as part of the system from the very beginning, not added as a layer at the end ► the latter solution produces insecure code (tricky patches instead of neat solutions) ► it may limit functionality ► and will cost much more You can’t add security in version 2.0

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 21 Software life-cycle requirements design implementation testing deployment maintenance Security must be part of all these phases!

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 22 Architecture ►Modularity: divide program into semi-independent parts ► small, well-defined interfaces to each module/function ►Isolation: ► each part should work correctly even if others fail (return wrong results, send requests with invalid arguments) ►Defense in depth: build multiple layers of defense ►Simplicity (complex => insecure)

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 23 Multiple layers of defense XIII century XXI century

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 24 Complexity System calls in Apache

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 25 Complexity System calls in IIS

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 26 Design – (some) golden rules Make security-sensitive parts of your code small Least privilege principle ► program should run on the least privileged account possible ► same for accessing databases, files etc. ► revoke a privilege when it is not needed anymore Choose safe defaults; deny by default Fail gracefully and securely Question again your assumptions, decisions etc.

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 27 Things to avoid Procedures or docs that are impossible to follow; code impossible to maintain

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 28 Implementation rekcah xinU / lreP rehtona tsuJ";sub ";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f| ord($p{$_})&6];$p{$_}=/^$P/ix?$P:close $_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.] /&& close$_}%p;wait until$?; map{ /^r/&& }%p;$_=$d[$q];sleep rand(2) if/\S/;print ► What does this code do? ► Would you like to work on it? ► Is it secure? Write good quality, maintainable, self-documenting code!

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 29 Enemy number one: Input data ►Don’t trust input data – input data is the single most common reason of security-related incidents

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 30 Enemy #1: Input data (cont.) Example: your script sends s with the following shell command: cat confirmation | mail $ and someone provides the following address: cat /etc/passwd | mail cat confirmation | mail cat /etc/passwd | mail

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 31 Enemy #1: Input data (cont.) Example (SQL Injection): your webscript authenticates users against a database: select count(*) from users where name = ’$name’ and pwd = ’$password’; but an attacker provides one of these passwords: anything’ or ’x’ = ’x XXXXX’; drop table users; -- select count(*) from users where name = ’$name’ and pwd = ’anything’ or ’x’ = ’x’; select count(*) from users where name = ’$name’ and pwd = ’XXXXX’; drop table users; --’;

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 32 Input validation Input validation is crucial Consider all input dangerous until proven valid Default-deny rule ► allow only “good” characters and formulas and reject others (instead of looking for “bad” ones) ► use regular expressions Validation at different levels: ► at input data entry point ► right before taking security decisions based on that data

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 33 Coding – advice (cont.) Separate data from code: ►Careful with shell and eval function ► sample line from a Perl script: system(”rpm –qpi $filename”); but what if $filename contains illegal characters: | ; ` \ ► popen() also invokes the shell indirectly ► same for open(FILE, ”grep –r $needle |”); ► similar: eval() function (evaluates a string as code) ►Use parameterized SQL queries to avoid SQL injection: $query = ”select count(*) from users where name = $1 and pwd = $2”; pg_query_params($connection, $query, array($login, $password));

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 34 Temporary file – or is it? ► symbolic link attack: someone guesses the name of your temporary file, and creates a link from it to another file (i.e. /bin/bash) ► good temporary file has a name that is hard to guess ► use tmpfile() (C/C++), mktemp shell command or similar Coding – advice (cont.) /tmp/mytmpfile/bin/bash /root/myscript.sh writes data symbolic link

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 35 Source code static analysis tools Tools that analyse source code, and look for potential: ► security holes ► functionality bugs (including those not security related) Recommendations for C/C++, Java, Python, Perl, PHP available at ► RPMs provided, some available on LXPLUS ► trivial to use There is no magic: ► even the best tool will miss most non-trivial errors ► they will just report the findings, but won’t fix the bugs Still, using code analysis tools is highly recommended! These tools will help you develop better code

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 36 Code tools: FindBugs / Java

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 37 Code tools: pychecker / Python

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 38 Code tools: Pixy / PHP

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 39 Things to avoid Security tools that are disabled, or impossible to use

How the Computer Security Team can help you Part 3:

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 41 Things to avoid Incomplete protection measures that become “temporary” forever

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 42 How we ( * ) can help you (*) we = CERN Computer Security Team Web and machine scanning ► vulnerability assessment – black box testing ► automatic scans, but also on demand source code tools Central Logging Service training courses security audits and risk assessment (plus of course intrusion detection, incident investigation and response etc.)

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 43 Training Security courses available at CTA ( free free

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 44 Audits, risks assessments etc. The Computer Security Team can assist you with: ► Threat modelling and risk assessment  to ensure that risks are correctly managed, and no major threat is neglected ► Designing system security architecture  when starting a new system or software project ► Security code reviews  before deploying developed code ► Security audits of existing systems  when maintaining existing systems or software Don’t hesitate to contact

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 45 The new Web site Check out our new Web site

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 46 Thank you Any questions?

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 47 Training course available! “Developing secure software” technical training course ► ½ day, offered for free ► Register at CERN Training CatalogueCERN Training Catalogue

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 48 Web and server scanning ►Vulnerability scanning and assessment ► black box approach (we scan without having any inside knowledge) ► automatic scans, but also on demand ► in order to find weaknesses before attackers exploit them scanning machines ► looking for unpatched, misconfigured or vulnerable network services ► with Nmap and Nessus scanning Web applications ► looking for Cross-site scripting, SQL Injection, command injection and other vulnerabilities ► with Skipfish, W3AF and Wapiti

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar 2007 — “Computer Security Day” — slide 49 Central logging service ►Central storage of syslog messages ► Prevents log corruption during compromises or hardware failures ► Fast detection of anomalous behaviour ► Please, make your code interact with syslog ►Stores essential information for forensics ► legal requirements ► Grid community requirements ► And we can learn from our history ►You already see it ► “Logins from unusual locations" s ► And many more analyses in the background