Presentation about securing the environment that the Blackboard Learn application runs on. Includes: * IPS/IDS * Database Security Recommendations * Load Balancer etc.

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

14. IPTABLES
CONFIGURATION

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

18. TRAFFIC SHAPER
GRAPH

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

29. INSECURE SERVER
CODE

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

36. MOD_SECURITY
FLOW DIAGRAM

37. RENDERED
MOD_SECURITY LOG

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