Snort mailing list archives

Re: Assistance w rule that detects traffic to *IP only* URL


From: Dave Killion via Snort-sigs <snort-sigs () lists snort org>
Date: Tue, 4 Jun 2019 18:32:15 -0700

A minor adjustment:

alert tcp any any -> any 80 (content:"| 0d 0a|Host:"; nocase;
pcre:"[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}| 0d 0a|"; within:20;
http_header;)

The signature as-written could FP on "1.2.3.4.com" or whatever.  I added
looking for the header line ending \r\n.

I also added the http_header option which I believe should further limit
the inspection depth to just the header.

Play around with that to see if it still works.

-Dave

On Tue, Jun 4, 2019 at 6:26 PM Dave Killion <dave.killion () gmail com> wrote:

Hey John,

So when the HTTP request is actually made by the browser, the "host"
portion of the URL is broken out and put in a separate header from the rest
of the URL in the packet - aptly, the "Host: " header.

To write a signature that looks for IP's and not FQDN's when a there's an
IP-based URL, you'll need to look for numbers and periods only after this
header.

Something like this:

alert tcp any any -> any 80 (content:"| 0d 0a|Host:"; nocase;
pcre:"[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"; within:20;)

This is just off the top of my head - I've not tested this - I may have
some errors in syntax there.

It uses a content match to lock on to the Host header, nocase just to make
sure there's no tomfoolery with the header characters, a regex for the IP
address-style host value (a bit of brute-force, an IP starting with zero is
wrong, but... whatever), and then limits the depth of the pcre check for
performance.  I swagged the within 20 - it could probably be as short as 15.

Hope this helps,

Dave

On Tue, Jun 4, 2019 at 5:24 PM John Davis via Snort-sigs <
snort-sigs () lists snort org> wrote:

Ive had some exposure to creating snort rules from a previous course. Im
a bit of a novice, so apologies ahead of time for any mistakes or errors in
assumption. Im interested in a snort rule that can provide an alert when it
detects any outbound traffic to an external URL that is referenced by IP
address only.
Example:
Internal host x browsing to http://www.cnn.com - no match to rule,  no
alert
Internal host x browsing to http://71.29.x.x.  matches rule, alert
generated

That example is probably most common, http traffic over port 80. However,
my assumption is, any internal source that generates unencrypted requests
to reach an external site URL, should most likely require a DNS query and
figured that’s where the rule should perform it’s detection. Ive been
searching to see if this type of rule already exists and so far, haven’t
had any luck. Im also not quite sure if this is achievable or the best
approach for detection, but it would appear the rule needs to be capable of
making the distinction between an alphanumeric URL w a DNS record vs a URL
that is identified by IP address only. Anyone that may be able to provide
some perspective on this creation or point me in the right direction would
be appreciated. Thanks!
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists snort org
https://lists.snort.org/mailman/listinfo/snort-sigs

Please visit http://blog.snort.org for the latest news about Snort!

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

Visit the Snort.org to subscribe to the official Snort ruleset, make sure
to stay up to date to catch the most <a href="
https://snort.org/downloads/#rule-downloads";>emerging threats</a>!



--
Dave Killion



-- 
Dave Killion
_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists snort org
https://lists.snort.org/mailman/listinfo/snort-sigs

Please visit http://blog.snort.org for the latest news about Snort!

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

Visit the Snort.org to subscribe to the official Snort ruleset, make sure to stay up to date to catch the most <a 
href=" https://snort.org/downloads/#rule-downloads";>emerging threats</a>!

Current thread: