safety lamp: data security & agile languages
DESCRIPTION
TRANSCRIPT
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
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
nokia
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
perimeter-only security
webserver load-balancer
databaseserver
firewall
anti-DOS
openopen
secureinsecure
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
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
authentication methods
hashed user/password
good for: most things bad for: application server / network compromise
authentication methods
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
data auditing
table members.profiles
member | interests
josh | pottery, cooking
table audit_members.profiles
member | interests | changed | change_by
josh | gaming | 5/23/01 | claudio
josh | pottery | 3/24/08 | felipe
xtreme security:multilevel
xtreme security:SE Postgres
contact Josh Berkus
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.