going outside the application
TRANSCRIPT
Going Outside the ApplicationMatthew Saltzman, Security EngineerBlackboard Inc.
Securing the Environment for Blackboard Learn
ABOUT ME
Matthew SaltzmanSecurity EngineerBlackboard [email protected]
I have been at Blackboard for over 5 years, 4 of those in Blackboard Support
INTRODUCTION
• Blackboard contains Sensitive Information• Names• Addresses• Social Security Numbers
• Should be removed if present• Grade Information for Courses
• This data must be protected• Securing the application can only be one
component in securing this information• Also need to secure the environment it runs on
COMPONENTS TO SECURE
• Application• Network • Operating System• Database• 3rd Party components external to Blackboard• Institution Policies
SSL
• Protection against network monitoring tools• Traffic Sniffing
• Protection against Man in the Middle Attacks• Easy to configure Blackboard to use SSL
• Requires an SSL certificate from a signing authority (SA)
• Configure webserver to use SSL certificate• Turn on SSL
• Through the Application• Via SSL offloading
TYPES OF CERTIFICATES
Regular SSL Certificate • single site• up to 256-bit encryption
EV Certificate • single site• up to 256-bit encryption• Much stricter issuing criteria
Wildcard Certificate • multiple sites in the same domain
• up to 256-bit encryption
Intermediary Certificate • single site• Used in conjunction with a
Wildcard Certificate to validate the identity of the individual site
ALTERNATE CONTENT DOMAIN
• Purpose: XSS Prevention from files• Creates a single-use session for downloading
the file• Prevents session stealing from main Blackboard
session• Expires as soon as the file is downloaded
• Requires separate SSL certificate for alternate domain• Otherwise SSL errors will appear
CHANGES DUE TO ALTERNATE DOMAIN
Without Alternate Domain for serving content:
With Alternate Domain for serving content:
PATCHES AND UPGRADE SCHEDULE
• Application Vulnerabilities often fixed via patches• Released via bbpatch• Publish a Security Advisory to Behind the
Blackboard• Not all vulnerabilities fixed this way
• Too complex a fix• Fixed by a new security feature
• Capturing Security Events (SP12)• Secure User Password Storage (SP12)
• Keep Blackboard version up to date as well
FIREWALL
• Helps prevent unauthorized access to the server• Limits access to allowed ports• Blocks access from devices that should not
have access• Required Ports (Defaults):
80 - HTTP port 8011 - Collab HTTP Port
443 - SSL port 8443 - Collab SSL Port
8009 - Tomcat Port number 8006 - Collab Shutdown Port
8005 - Tomcat Shutdown Port 1521 - (Oracle DB) 1433 - (SQLServer)
8010 - Collab TCP Port 8016 - BBExec Service Port
61616 – ActiveMQ Port
DEMO
• How Firewalls help prevent network penetration• Demonstration of how port scanning works
IPTABLES CONFIGURATION
NETWORK SEGMENTING
• Different types of servers should be in different network zones• DMZ – perimeter network containing external
facing servers• Most vulnerable
• Any other network zone – Should not contain external servers
• Firewall present between DMZ and rest of network
• Application servers should be in the DMZ• Database should not
NETWORK DIAGRAM
TRAFFIC SHAPER
• Device that does “Rate Limiting” on network traffic to specific devices
• Packet Shaping• Helps prevent DoS attacks
• Slows rate of traffic hitting server• Requires statistics
• Expected Incoming Traffic • Acceptable incoming traffic Rates• Traffic rate too low causes performance issues for
end users• Traffic rate too high could allow DoS attack to
succeed• Could be done through Load Balancer
TRAFFIC SHAPER GRAPH
SSL OFFLOADING
• Can use either Load Balancer or specific offloading tool (SSL Accelerator)• Cuts down cost of encryption
• Tool (Load Balancer or otherwise) much faster at encryption then Application Server
• Allows Longer SSL encryption key• Thus, helps prevent DoS due to SSL
INTRUSION DETECTION/ PREVENTION SYSTEM
• Monitors network for malicious traffic• Can take various actions when discovered:
• Send an Alert• Log malicious traffic for review• Drop malicious traffic (Prevention only)
• Can be configured using custom rules• Different types
• Network Based – prevents network attacks• Host based – prevents OS level attacks
• Some examples (Open Source):• Snort (Network IPS)• OSSEC (Host IPS)• Suricata (Network IPS)
SNORT
OSSEC
SURICATA
ALTER PORTS, REMOVE BANNERS
• Port Scans• Tells scanner which ports are open• Reports any banners associated with open ports
• Default ports describe which application is running• Therefore, do not use default ports
• Exceptions: ports 80 and 443 • Banners on ports explain what non-default
ports do• Therefore, remove any descriptions of the ports
as well
PORT SCANNER
PROTECT ANY OPERATING SYSTEM
• Keep Operating System up to Date• OS Patches• Application/Service Packs
• Dedicate Servers to specific tasks• Prevents vulnerabilities in one application or
task from affecting others• Use domain accounts for users
• Allows for simpler auditing of user activity• Require strong passwords for all accounts
• Helps prevent unwanted access to servers
DEMO
• Why dedicating servers to specific tasks is a good idea• Insecure tool running on same server as
Blackboard
INSECURE SERVER CODE
AUDITING OS ACTIVITY
• OS should be configured for auditing• Account with activity• Action this account took• Time the action was taken
AUDIT LOG RECOMMENDATIONS
• Archive and Clear audit log daily• Prevents performance issues• Easier to read and locate problems• Easier to notice tampering with the audit log
• Alerts on suspicious activity• Authentication Problems• Altering system settings• Accessing Sensitive Data
BAD AUDIT LOG
SECURING LINUX SERVERS
• Require SSH instead of Telnet• Telnet is insecure• Traffic sniffing Telnet session is possible
• Use public/private key authentication • Private Key file never leaves the client machine• Private key cannot be computed from public key
• Add a strong passphrase to the private key file• Prevents a user from using a stolen private key
PUBLIC KEY SSH AUTHENTICATION
APACHE2
• All Linux application servers should run Apache2• Added security, as is current version• Can keep up-to-date with patches and new
versions• Does not require Blackboard intervention
• Can add MOD_SECURITY • Application firewall
• Can prevent some application vulnerabilities • Not easy in Blackboard Apache, if even possible• Allows for audit logging of HTTP
• Information about potential malicious activity within the application
MOD_SECURITY FLOW DIAGRAM
RENDERED MOD_SECURITY LOG
SECURING WINDOWS SERVERS
• Group Policy• Strong password Requirements• Require password changes often• Audit log (covered earlier)
• IIS Settings• IIS User with minimal permissions to everything
except application• MOD_SECURITY for IIS possible
• SCW (Security Configuration Wizard)• Wizard for setting security configuration
UNIQUE DATABASE CONCERNS
• Contains all data from the application• Need to configure OS Security
• Access to the OS means access to the DB, usually
• Also need database specific security• DB is meant to be accessed remotely
DATABASE USER SECURITY
• Strong Database Passwords• Should not match OS
Passwords• Each Password
should be Unique• Users should not use
system accounts• sa, root, master, etc. • Allows for auditing of
individual users’ activity
DATABASE SECURITY MEASURES
• Limit DB permissions to bare minimum• Helps prevent database privilege escalation
• Limit login by IP Address• Prohibits access to Database by unauthorized
machines• Potential Solution:
• Encrypt traffic to and from Database• Please performance test this first, may not
perform well
REDIS
• 3rd Party Caching Database• Blackboard Developed
B2 to replace server caches
• See Nori’s presentation on performance impact: • 8:30 – 9:15 AM
Tuesday in Murano 3301B
REDIS SECURITY FEATURES
• Should never manually log into Redis cache• Password should be far more complex than
normal• Stored in a properties file
• Block Unused Redis commands• Prevent users who gain access from affecting
Redis in unauthorized ways• Keep Redis Application up to date
OTHER 3RD PARTY APPLICATIONS
• Understand scope of server• What needs to access it• Expected network traffic• Expected paths to and from
server• Size the application properly• Utilize all security features of
the application• Secure the server itself
INSTITUTION POLICIES
• Policies meant to encourage secure behavior by all personnel
• Help to prevent privileged user mistakes• Such as sharing security information at a bar
PASSWORD POLICIES
• Strong passwords should be encouraged• Require minimum password strength• Require users to change passwords often• Do not re-use passwords• Do not share passwords
• Can prevent malicious user from accessing privileged account• Privileged accounts can bypass most security• Renders all previous actions essentially moot
DOMAIN USER POLICIES
• Each user has a domain account• Each account has a set of associated roles
• Defines level of access• Administration• IIS/Apache• Etc.
• Limit Access to servers or admin features by role• Prevents unauthorized or unexpected access
