If you have a SQL server on your network, you know how important it is to monitor transactions to identify suspicious activity.
<36> Jun 21 08:34:05 pvs: 149.X.X.X:0|149.X.X.X:0|7019|Database command logging|version: 1.19 PVS has observed the following command from a database client to the database server (206.X.X.X): SELECT COUNT(CASE WHEN e.EmailType = ‘User’ OR t.ProcessType = ‘Borrowing’ THEN 1 ELSE null end) as Borrowing,|INFO
This data is extremely useful for auditing SQL transactions between a web server and a database because it can help identify SQL injection and potential forms of data loss. The LCE can also identify statistical spikes in these SQL logs and generate an alert when new types of SQL events occur for the first time.
However, what about analyzing outbound SQL traffic?
Outbound SQL Traffic
Databases are typically configured and secured to prevent direct access from the Internet. Having a SQL server exposed to the internet, regardless if it is Oracle, MS SQL or MySQL, is generally considered a bad security practice. SQL servers often are not hardened and may not have auditing enabled or transaction logs. If the data is sensitive, there may also be compliance regulations mandating that these services may not be exposed directly to the Internet.
If your network carries such traffic, there are a few things we can assume or choose to investigate:
- Your network likely does not have a firewall or security enforcement policy on outbound traffic. SQL traffic for Oracle, MS SQL and MySQL all travel on common ports that can be easily blocked.
- You may have developers who are sending SQL queries directly to hosted SQL databases at a partner or in the Cloud. If this is the case, you should investigate if this is a risk to your organization. Performing these queries over SSL or through a VPN would likely be more secure.
- You may have an intruder. Although we’ve not yet seen a wide scale botnet that scans for open SQL services because they are not that common, it isn’t a bad idea to consider any outbound SQL traffic you aren’t familiar with as a potential compromise.
The following screen capture shows a sanitized view of SQL queries detected by the PVS that were obtained from one of the large networks Tenable monitors for research purposes:
Normally, SQL data is viewed as a high level list of events over time such as:
In this view, SecurityCenter launched a query to a LCE that had obtained SQL logs from the last 25 days through passive monitoring by the PVS. This particular data comes from passive monitoring of 15 different SQL databases in a university type of network environment.
SecurityCenter can let us view this data on the dashboard from a directional point of view:
The screen capture above is exactly what we want to see. There is no inbound or outbound SQL activity, only traffic on the inside of our network. SecurityCenter allows powerful queries to be created against all of the normalized events gathered by the LCE, including directionality such as inbound, outbound, internal or external.
SecurityCenter can also be used to create automated alerts such that if outbound SQL activity occurred, a user could be emailed or have a ticket opened automatically.
For More Information
Tenable has written several dozen other articles on Event Analysis Training that include analysis of IP reputation, botnet activity, network anomaly detection and much more. These articles are all listed in the Event Analysis Training section of our blog. If you would like more information about Tenable’s set of Unified Security Monitoring products, please feel free to watch any of our video demos or contact our sales team.