Going outside the application
- 1. Going Outside the Application Securing the Environment for Blackboard Learn Matthew Saltzman, Security Engineer Blackboard Inc.
- 2. ABOUT ME Matthew Saltzman Security Engineer Blackboard Inc. matthew.saltzman@blackboard.com I have been at Blackboard for over 5 years, 4 of those in Blackboard Support
- 3. 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
- 4. COMPONENTS TO SECURE • Application • Network • Operating System • Database • 3rd Party components external to Blackboard • Institution Policies
- 6. 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
- 7. 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
- 8. 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
- 9. CHANGES DUE TO ALTERNATE DOMAIN Without Alternate Domain for serving content: With Alternate Domain for serving content:
- 10. 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
- 12. 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
- 13. DEMO • How Firewalls help prevent network penetration • Demonstration of how port scanning works
- 15. 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
- 16. NETWORK DIAGRAM
- 17. 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
- 19. 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
- 20. 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)
- 21. SNORT
- 22. OSSEC
- 23. SURICATA
- 24. 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
- 25. PORT SCANNER
- 27. 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
- 28. DEMO • Why dedicating servers to specific tasks is a good idea • Insecure tool running on same server as Blackboard
- 30. AUDITING OS ACTIVITY • OS should be configured for auditing • Account with activity • Action this account took • Time the action was taken
- 31. 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
- 32. BAD AUDIT LOG
- 33. 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
- 34. PUBLIC KEY SSH AUTHENTICATION
- 35. 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
- 38. 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
- 40. 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
- 41. 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
- 42. 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
- 44. 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
- 45. 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
- 46. 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
- 48. 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
- 49. 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
- 50. 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
- 51. THANK YOU! Matthew Saltzman Security Engineer Blackboard Inc. matthew.saltzman@blackboard.com
Editor's Notes
- #13: Begin by blocking all ports Open Loopback, and remote connection ports Each AppServer Open Port 443 (and 80 without SSL System Wide) to all traffic in and out Open Ports 8009, 8005 to the local server and all other appservers only Open Port 8016 Collab Server Open the Collab Ports (8010, 8011, 8443, 8005) Database Server Open DB Port (1521 for Oracle, 1433 for SqlServer) to all appservers
- #31: Windows: Group Policy Manager: gpedit.msc Linux: /etc/audit/auditd.conf and /etc/audit/audit.rules.