topic Threats from internal hosts in Network Security

Threats from internal hosts

Christopher Liesfield — Fri, 21 Feb 2020 15:44:59 GMT

We have an in-depth internal penetration testing under way at the moment and it is becoming clear that our Firepower for ASA sensors are not blocking traffic sourced from IPs within the $HOME_NET range.

We have a Trend Micro DDI probe at each of our sites and it is raising alarms like crazy, whilst our FMC remains silent and none of the intrusive traffic is being blocked.

Is this normal behaviour? Are all hosts within the $HOME_NET range trusted without question?

In an act of desperation, I edited the whitelist to only include our server subnets - this has had no effect.

How should we configure our sensors to distrust PCs, phones and printers on our internal networks, so if we have a compromised host, it won't wreak havoc?

I thought I knew a lot about Firepower stuff and now I'm questioning my knowledge.

Thanks in advance for your assistance.

Re: Threats from internal hosts

yogdhanu — Thu, 10 May 2018 06:04:51 GMT

Hi Christopher,

Try creating additional rule with intrusion policy and variable set where Home_net is 0.0.0.0 as well as external_net or add the internal network in external_net as well for that specific policy. Most of firepower snort rules are defined with external_net to home_net or vice-versa

And if the home_net is defined with internal network, traffic between host on that network would not match the rules.

rule

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"BROWSER-CHROME Google Chrome and Apple Safari Ruby before and after memory corruption"; flow:to_client,established; file_data:; content:"<ruby>"; fast_pattern:only; content:"ruby|3A|"; pcre:"/ruby\s*{\s*float\x3a.*?ruby\x3a(before|after).*?(display\x3atable|counter-reset\x3a)/si"; metadata:service http; reference:cve,2011-1440; classtype:attempted-user; sid:29755; rev:1; gid:1; )

Hope it helps,

yogesh

Re: Threats from internal hosts

Christopher Liesfield — Thu, 10 May 2018 06:17:56 GMT

Thanks, I'll give that a try and endeavour to respond with the results.