Block External to internal when not using FQDN

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Block External to internal when not using FQDN

L2 Linker

I have tried to create a Custom threat a number of times that blocks people from accessing our site via IP address as the url. I have tried setting it up as so

 

Operator: Pattern-Match

Context: http-req-host-header

Pattern: 111\.2\.3\.4

Qualifer: req-hdr-type

Value: HOST

 

Or

 

Operator: Pattern-Match

Context: http-req-host-header

Pattern: 111\.2\.3\.\d+[:](80|443)

Qualifer: req-hdr-type

Value: HOST

 

Or

 

Operator: Pattern-Match

Context: http-req-host-header

Pattern: 111\.2\.3\.4

Qualifer: rhttp-method

Value: HOST

 

I was going to try the following next:

 

Operator: Pattern-Match

Context: http-req-uri-path

Pattern: 111\.2\.3\.4

Qualifer: http-method

Value: Get

 

Any example or advice on this would be appreciated.

 

1 accepted solution

Accepted Solutions

L4 Transporter

Hello, murphyj!

 

I would expect your first example to satisfy this requirement.

 

Operator: Pattern-Match

Context: http-req-host-header

Pattern: 111\.2\.3\.4

Qualifer: req-hdr-type

Value: HOST

 

However, in testing in my lab, I see that my expectations are not met, and as you said, it does not function.

 

I've whittled the issue down to being something to do with the req-hdr-type qualifier you have specified. If you remove the qualifier, and simply do the below, it should function.

 

Operator: Pattern-Match

Context: http-req-host-header

Pattern: 111\.2\.3\.4

 

As to why the qualifier doesn't work, great question! I'll address that on our backend and see if I can find something. I do find it odd that you can add a qualifier for req-hdr-type as "HOST" even when the context is already set to "http-req-host-header," since the breadth of that entire context is simply just the Host value.

 

Thanks for participating! 🙂

 

View solution in original post

6 REPLIES 6

L4 Transporter

Hello, murphyj!

 

I would expect your first example to satisfy this requirement.

 

Operator: Pattern-Match

Context: http-req-host-header

Pattern: 111\.2\.3\.4

Qualifer: req-hdr-type

Value: HOST

 

However, in testing in my lab, I see that my expectations are not met, and as you said, it does not function.

 

I've whittled the issue down to being something to do with the req-hdr-type qualifier you have specified. If you remove the qualifier, and simply do the below, it should function.

 

Operator: Pattern-Match

Context: http-req-host-header

Pattern: 111\.2\.3\.4

 

As to why the qualifier doesn't work, great question! I'll address that on our backend and see if I can find something. I do find it odd that you can add a qualifier for req-hdr-type as "HOST" even when the context is already set to "http-req-host-header," since the breadth of that entire context is simply just the Host value.

 

Thanks for participating! 🙂

 

L4 Transporter

Here is a signature that works:

 

Operator: Pattern-Match

Context: http-req-host-header

Pattern: 111\.2\.3\.4

Qualifer: http-method

Value: GET

 

We have been using it for awhile.  We set the action as reset-both.  Can always use an exception response of block-IP if you are getting too many of them or if the originator has bad intentions.

 

Hope this helps,

 

Phil 

When I tried it with the Get it still did not work. There might be something with the version I'm running. I just test it on 6.1.3, when you have your setup is it for 1 ip address or a range? If its for a range how are you handling the last octet?

That did work for me. Thank you.

 

If you want the entire class C address space you could have a three patterns:

 

111\.2\.3\..   covers 0-9

and

111\.2\.3\...   covers 10-99

and 

111\.2\.3\....  covers 100-255

 

the trailing period is a wildcard

 

Alternatively you can have a pattern for each IP address.

 

 

Thank you. Before I got to try that someone I work with recommended 111\.2\.3\.[0-9]+ and that got it all in one statement. I does seem to cover everything, So I will be rolling with that for a bit but if I get false positives I will be using what you recommended.
  • 1 accepted solution
  • 7929 Views
  • 6 replies
  • 1 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!