Re: [Snort-devel] Final Year Project Custom MySQL Database Server Rules and Classifications Review

[Mkultra via Snort-users <snort-users () lists snort org>]

I'm no snort pro, I grew up on PIX/ASA, but i have been doing netsec stuff for a few decades now. I can answer a few of 
these.

1. if internet can hit mysql through an edge device (snort at the perimeter), you are doing it wrong 99.999% of the 
time. Of course snort could be used in other configurations such as zoning your server farms into groups with different 
security levels, segmenting your internal network segments, etc. MySQL is pretty solid in this regard but be extremely 
wary of using a Microsoft product in this manner. I once had a sql server get owned and wiped clean so somebody could 
store german porn and video games on it. This was back in the slammer worm days when it took 18 hours to restore from 
tape backup.

when you do flow:to_server,established; and flags:PA; -- flow:to_server:est & PA means there is a TCP session 
established already.

Here is a quick rundown of a TCP session
---------------------------------------------------------------------------------------
SYN -->
<--- SYN-ACK
ACK --->
(session is now in the ESTABLISHED state.)
[send data to and fro]
[ok done working, time to close the channel to free up resources]
FIN --->
<--- ACK
(session is now closed)
----------------------------------------------------------------------------------------

2. Is this possible?
---- yes any packet can be created with any combination of flags, ttl, headers, payload, or whatever. search xmas tree 
attack, etc. see
 https://www.professormesser.com/security-plus/sy0-401/christmas-tree-attack-2/
and
http://sectools.org/tag/packet-crafters/

3. Do we look for all sessions that start with a push-ack?
---- no TCP session will ever start with PSH-ACK. The first packet in any tcp conversation is always SYN. See RFC 793. 
Its always SYN, SYN-ACK, ACK. http://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml any session that 
starts in any other way is automatically bad mojo.

4. Fourth, about your dos attacks, you probably want to track_by_src, if not you're just tracking high usage of your 
application.
---- DOS attacks almost always use spoofed source addresses or use botnets where each individual host may make only 50 
or 100 connections but 100,000 separate outside hosts hitting the same inside server causes the DOS/DDOS condition. 
Tracking the source IP for DOS attacks is kind of a waste of time since its either faked, or it is just a tiny part of 
a massive group of coordinated zombies attacking you. Back when I was a noob I kept a logfile of all those bad people 
vowing to pillage their village, take their women as my own, murder their cattle and salt their fields, but in the end, 
the log file never stops filling up and all the addresses are fake anyway so whats the point.

5. it looks from the rule that the only real positive identifier is the sql query itself. The flags and ttl are 
probably included to ensure the highest probability of a true positive and lowest probability of a false positive. You 
could remove these and achieve the same result.

6. it seems from the OP email below yours that the attacker would be hitting a web application and using a SQL 
injection atack to compromise the database server to get a toehold. This makes me think two things.
a.) you should write a rule that analyzes the web (http/https) requests hitting your "damn vulnerable web application" 
(ha, arent they all) instead of focusing on traffic from the web server to the mysql server. Most firewall setups sniff 
either just outside the perimeter or just inside, so a snort rule to analyze mysql queries would never hit because when 
it hits the sniffer it will probably be in the form of an HTTP request.

b.) this rule will only work if the sniffer is located between the web server and the database server AND the mysql 
traffic is not encrypted (protip: it should be).  A web application won't be (or shouldnt be) sending sql queries in 
the clear (select * from webusers where userid = 'admin' and password = '31337HeeHee'). So your question either implies 
horrendous security or horrendous security both of which add up to pain and heartbreak.

7. Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10
---lol get rid of this, you are advertiusing to your enemy that a.) you use windows 10, and b.) you use the built in 
mail app. Thats an attack vector. Don't do your adversaries work for them.

Hope this helps.

Cheers,

Mkultra

Sent from email program on nondescript PC or Mobile type device.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On April 10, 2018 5:02 PM, DFIRob via Snort-users <snort-users () lists snort org> wrote:

> Hi Jack,
> First I think you should loop in snort-users on this, since snort-devel is really not the place for rule writing. 
> Then Joel will jump on you saying https://www.snort.org/faq/can-i-have-help-with-my-homework, and will be totally 
> right in this case.
> Nonetheless ignoring this...
>
> Second, if $EXTERNAL_NET can talk to $SQL_SERVERS, you have a problem snort won't be able to fix. What you probably 
> want is $HTTP_SERVERS
> Third, and I'd love to have some feedback on this one, when you do flow:to_server,established; and flags:PA; in the 
> same rule, what does this mean exactly? Is this possible? Do we look for all sessions that start with a push-ack? 
> What about the sessions that don't? And what about your TTL flag? Do this apply to all the packets in the session?
> Fourth, about your dos attacks, you probably want to track_by_src, if not you're just tracking high usage of your 
> application. But then again if your $SQL_SERVERS are reachable from $EXTERNAL_NET...
> Fifth, regarding sid:1000101, how is your false positive rate going? Have you tested this on any real application?
> ---
> # Tautology SQL injection rule, searches for SELECT statement in a tcp packet and pcre parameter matches any 'n' = 
> 'n' attempt on mysql with a packet that has time to live of 128 (usual) with push and acknowlege flags set in a mysql 
> tcp packet request established to the mysql server with push and ack flags set, main aim of this rule is to detect 
> 'n' = 'n' queries, works! #
> # alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 3306 (msg:"MYSQL-EXPLOIT Potential SQL Injection detected using 
> tautology on the MySQL server"; flow:to_server,established; pcre:"/\'[0-99]{1,}\'\s\=\s\'[0-99]{1,}\'/i"; 
> fast_pattern:only; ttl:128; flags:PA; reference:url, https://arxiv.org/ftp/arxiv/papers/1203/1203.3324.pdf; 
> reference:url, https://www.debuggex.com/cheatsheet/regex/pcre; metadata:policy security-ips drop, service mysql; 
> classtype:sql-injection; sid:1000101; rev:11;)
> ---
> Best regards,
> Rob'
>
> On Sun, Apr 8, 2018 at 7:50 PM, Jack Eastwood via Snort-devel <snort-devel () lists snort org> wrote:
>
> > Good Afternoon,
> >
> > I’m a final year Computer Forensics and Security student representing Leeds Beckett University in the UK and 
> > finalizing my final year project based on using Snort as an IDS to monitor an active MySQL server.
> >
> > For the basis of my project I have installed and configured Snort as an IDS to monitor an array of activity against 
> > a MySQL community server with a vulnerable application called “damn vulnerable web application” (DVWA) that is 
> > connected the MySQL database. I have uploaded three files in this email: a general MySQL rules file, a MySQL exploit 
> > rules file -where I have written custom made snort rules to detect an array of activity - and a classification 
> > configuration file which I have also written custom made classifications in context to my project. For each rule I 
> > have inserted comments explaining the function of each rule and the requirements on how each rule gets triggered.
> >
> > I would be thankful if anyone could review these files and provide any form of feedback that could enhance these 
> > rules for future research or even potentially be published as official Snort rules.
> >
> > If you would like any more information regarding my project, Snort or MySQL configuration settings or anything else 
> > that could benefit the reviewing process then don’t hesitate to contact me.
> >
> > Thanks you and regards
> >
> > Jack Eastwood
> >
> > Sent from [Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10
> >
> > _______________________________________________
> > Snort-devel mailing list
> > Snort-devel () lists snort org
> > https://lists.snort.org/mailman/listinfo/snort-devel
> >
> > Please visit http://blog.snort.org for the latest news about Snort!
_______________________________________________
Snort-users mailing list
Snort-users () lists snort org
Go to this URL to change user options or unsubscribe:
https://lists.snort.org/mailman/listinfo/snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!

Please follow these rules: https://snort.org/faq/what-is-the-mailing-list-etiquette