Safety LAMP: data security & agile languages

Safety LAMP

data securityin the age of

agile languages

Josh BerkusPostgreSQL Experts, Inc.Enterprise LAMP 2009

LAMP 1.0 (1998)

Linux

Apache

MySQL

Perl,PHP,Python

LAMP 1.1 (2002)

Linux

Apache

Middleware

PostgreSQL

LAMP 2.0 (2008)

Linux,Solaris, BSD

Apache,Lighttpd, appservers

MySQL,PostgreSQL, SQLite,CouchDB, Memcached,etc.

Python,Ruby,PHP,Perl, Javascript

Why shouldyoucareabout

data security?

“I don't need to know”

“Our network security will take care of it.”

“I applied all the web server and PHP patches.”

“Security belongs in the application layer.”

“Database security slows development.”

“Nobody will hack my website. We run Linux.”

microsoft

government agencies

the U.N.

political parties

The cost of unsafe data

Contacting 19,000 customers: $380,000

Paying for credit reports for 19,000 customers: $931,000

Shipping stolen merchandise:$4,600,000

Lost customer goodwill and reputation as an insecure & careless company:Priceless!

Why is LAMP special?

1. AgilityLAMP platforms are designed for rapid development and deployment

2. Constant UpgradesLAMP components are rapidly advancing

3. LightweightLAMP stacks are simple and have few layers

Why is LAMP special?

1. Agilityrapidly deploy security holes

2. Constant Upgradesnew versions � new exploits

3. Lightweightfew layers � fast to hack

How do you make your data safe?

securityprinciples

one:security != control

control systems

control systems correctly employed

improved security

control systemsincorrectly employed

reduced security

two:security

is a process

two:security

is a process

not a result

security process

1.plan

2.design

3.develop

4.test

5.deploy

6.monitor

7.repeat

perimeter-only security

webserver load-balancer

databaseserver

firewall

anti-DOS

openopen

secureinsecure

multilayer security

webserverdatabaseserver

firewall

anti-DOS

restricted

secure

updates

tripwireabstraction

permissions

restrictedauditload-balancer

three:every component

in yourLAMP stack

must be secure

four:how much security

do you need?

Data Security

Cost

Deployment Speed

Performance

five:have a threat model

What is your vulnerable data? (assets)

Who wants this data? (threats) How will they get it? (attack vectors)

What are the consequences of lost data? (costs)

How do you make your data safe?

your database engine can help

webserver routerdatabaseserver

firewall

anti-DOS

restricted

secure

updates

tripwireabstraction

permissions

restrictedaudit

attack vectors

Primary attack vectors for data theft in LAMP:

1.SQL injection

2.direct connection

3.application server compromise

4.staff malfeasance/mistake

5.physical access

database tools

1.access control

2.authentication

3.drivers

4.privileges

5.data abstraction

6.encryption

7.data auditing

8.advanced security frameworks

access control

Goal: Use database access control lists to prevent connections from anywhere but specified networks.

webserverdatabaseserver

access control

Network Isolation:

isolated network segment

only appservers & admins can connect

use firewall tools to restrict ports & networks

access control

Database Access Control

restrict which users can connect to which databases from which networks

PostgreSQL

pg_hba.conf, listen_addresses, pgbouncer

MySQL

users table, MySQL Proxy

authentication

Goal: prevent privilege escalation through direct connections to the database.

psql -U postgres -h masterserver -c 'update users set password = \'haxx0r\'where login = \'administrator\'

authentication methods

ident: host OS responsible for security

good for: administrative tasks

bad for: external users


hashed user/password

good for: most things bad for: application server / network compromise


krb5 / sspi / ldap: identity checked against authentication servers

good for: network/application server compromises

bad for: performance, troubleshooting, uptime

driver tools

Goal: prevent SQL injection

prepared queries:

$q = prepare(“SELECT * FROM profile WHERE user = ?”);

execute($q, db_escape($this_user));

driver tools

Goal: prevent SQL injection

switches

no multi-statement

read-only connection

database privileges

Goal: prevent authenticated low-level users from modifying or accessing restricted data.

SELECT FROM users;

UPDATE users;

database privileges

Privileges Rule #1: your app should not be connecting as the database owner or superuser

ROLEs

create some ROLEs (users and groups)

public

application_user

application_admin

admins

claudio felipe

users

dataentry readonly

guestwei-chenleo

db_admin superuser

privileges best way to restrict access to specific data

SQL standard

Both MySQL & PostgreSQL support:

database/schema, table, column

privileges

PostgreSQL privileges:

tables: SELECT, INSERT, UPDATE, DELETE, ALTER

schema: USAGE, CREATE, ALTER

function: EXECUTE, ALTER

database: CONNECT, TEMP, CREATE, OWNER

database abstraction

Goal: prevent theft of sensitive data by not allowing direct access to base tables

memberschema admin

rightssettings

schema membersprofilesmessagesviewuser_names

login()change_pw()

users

database abstraction

views

a VIEW is a “stored query” with its own permissions

limit access to specific rows or columns

stored procedures

SECURITY DEFINER procedures allow controlled privilege escalation

make sure to lock them down, though!

encryption

Goal: prevent misuse of sensitive data by anyone who has managed to capture it

the only protection against physical possesion

encrypt your backups!

encryption

1. encrypted authentication

2. encrypted connections

3. encryption of specific data

4. whole database encryption

the biggest problem with encryption

??

What do you do if they get in anyway?

sometimes your other measures fail

exploits

loopholes

misconfiguration

sometimes the bad guys have legitimate access

users

staff

sysadmins

database auditing

Goal: know what happened after it happened, and be able to restore your data without searching backup tapes.

auditing: logs

dozens of log options

users

connections

queries run

errors

the log can help you analyze a break-in

maybe even tell you what was stolen

secure your logs

best way to find “DBA corruption”

make sure that not even the admins can erase/alter all copies

make sure few people can change postgresql.conf

use a secured log server

“syslog” is good for this

make a plan for secure log archiving

data auditing

Goal: figure out exactly which data changed, when and how, and be able to reverse it.

Methods

Triggers

Replication

Snapshots

xtreme security:multilevel

xtreme security:SE Postgres

contact Josh Berkus

[email protected]

it.toolbox.com/blogs/database-soup

PostgreSQL

www.postgresql.org

SEPostgres: http://code.google.com/p/sepgsql

PostgreSQL Experts, Inc.

www.pgexperts.com

Copyright 2009 Josh Berkus, distributable under the creative commons attribution license

Thanks to KaiGai Kohei for SEPostgres diagrams, and to Harrison Fisk for MySQL examples.Thanks to Google Images for the various images, which belong to their original owners.

Safety LAMP: data security & agile languages

Technology

Transcript of Safety LAMP: data security & agile languages