• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Snort and SQL Injection (Microsoft SQL Server + IIS): SOLVED!

Scheduled Pinned Locked Moved pfSense Packages
8 Posts 2 Posters 8.6k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M
    mdima
    last edited by Aug 2, 2012, 6:08 PM Aug 2, 2012, 5:24 PM

    Hi,
     I'd like to share with you a solution to a problem I was solving for a customer.

    The goal is to make SNORT able to catch a Microsoft SQL Server injection made by querystring. Honestly, I was searching and searching in the Snort and EmergingThreats rules, but I didn't find anything similar, so I had to make a couple of rules by myself.

    First of all, we have to create a "local.rules" file and to store it in a place that will not be rewritten by the normal rules update.

    So just create a "local.rules" text file withe the following content:

    # ------------
    # LOCAL RULES
    
    alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NT2-SQL Injection-Varchar"; flow:to_server,established;uricontent: "?";http_uri;content:"varchar";nocase; resp: rst_all; classtype:web-application-attack; sid:9990001; rev:1;)
    alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NT2-SQL Injection-Declare"; flow:to_server,established;uricontent: "?";http_uri;content:"declare";nocase; resp: rst_all; classtype:web-application-attack; sid:9990002; rev:1;)
    alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NT2-SQL Injection-Exec"; flow:to_server,established;uricontent: "?";http_uri;content:"exec"; nocase; resp: rst_all; classtype:web-application-attack; sid:9990003; rev:1;)
    
    

    Then upload the file in the directory:
    /usr/local/etc

    and step 1 is done.

    Finally, we just have to open the Snort interface, in the "Advanced configuration pass through" just add:

    
    include /usr/local/etc/local.rules
    
    

    and that's it, just save, restart Snort and you'll be able to catch (and ban) the SQL injections.

    Just a couple of things:

    1. If you have a "global threshold" rule in your suppress list, just remember to add an exception for the events 9990001, 9990002 and 9990003
    2. Unfortunately the 1st malicious request reach the web server. So just install or update URLScan to version 3.1 and you'll be able to add the strings to exclude the same sequences from your QueryString ([DenyQueryStringSequences] section of the UrlScan.ini file).

    I hope what I wrote will be useful to someone else…

    Ciao,
    Michele

    1 Reply Last reply Reply Quote 0
    • M
      mdima
      last edited by Aug 2, 2012, 6:09 PM

      I just updated the rules, those are more precise…

      1 Reply Last reply Reply Quote 0
      • C
        Cino
        last edited by Aug 2, 2012, 7:17 PM

        nice! good job!!

        question, have to tried to add them to custom.rules? Not sure if that gets deleted or not but it was added into the code for custom rules.

        1 Reply Last reply Reply Quote 0
        • M
          mdima
          last edited by Aug 2, 2012, 7:22 PM

          @Cino:

          nice! good job!!

          Thanks a lot!

          @Cino:

          question, have to tried to add them to custom.rules? Not sure if that gets deleted or not but it was added into the code for custom rules.

          well… I was searching for "snort_local.rules", but this gets overwritten on each rule update...
          Where is the "custom.rules" file? Or, where should I create/post it?

          Thanks,
          Michele

          1 Reply Last reply Reply Quote 0
          • C
            Cino
            last edited by Aug 2, 2012, 7:33 PM

            Click on the rules tab under the interface

            1 Reply Last reply Reply Quote 0
            • M
              mdima
              last edited by Aug 2, 2012, 7:42 PM

              @Cino:

              Click on the rules tab under the interface

              OPS, I really didn't see or know about that… if it's what I think (that rules are saved in the box config and the file "custom rules" under "/usr/local/etc/snort/snort_XXXXXX/rules" is recreated on each update/change of the config than it's awesome.
              There's no need to create a rule file, upload it manually and include it manually in the config! Also, that rules will be backed-up on each backup of the configuration...

              It all this is true, just skip the "create file" part and insert the rules in the custom.rules...

              Thank you for this info!!

              Michele

              1 Reply Last reply Reply Quote 0
              • C
                Cino
                last edited by Aug 3, 2012, 12:02 AM

                your welcome. I haven't had a chance to test this new feature but i'll try it out with the custom rules you provided :-)

                1 Reply Last reply Reply Quote 0
                • M
                  mdima
                  last edited by Aug 3, 2012, 5:56 AM

                  Well, I tried the "custom.rules" feature.

                  It really does what it's supposed to do, changes on that rules are saved in the config.xml file and are recreated during the rule update.
                  Just, it's quite slow when you save the rules, I don't know what actions are made on that post, but anyway to apply the changes I need to restart-snort manually.

                  Ciao,
                  Michele

                  1 Reply Last reply Reply Quote 0
                  8 out of 8
                  • First post
                    8/8
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                    This community forum collects and processes your personal information.
                    consent.not_received