Fast Flux Detection with a new Feature

Security
1

Dear @pmueller ,

thanks for the feature-information: blog.ipfire.org - Feature Spotlight: Weaponising IPFire Location to proactively detect Fast Flux setups

As you described, the best way to use the new “Weapon” against Fast Flux Networks is to use it with the integrated web proxy.
But the web proxy only works for TCP 80.

How to avoid Fast Flux Access using other ports and protocols?
For example https 443 TCP too.

Thanks and regards,

Jan

1 Like
2

This is not correct. If the browsers on the clients are configured to use the proxy for https (manual configured or wpad/proxy.pac) it works also of TCP 443.

2 Likes
3

Hi,

am I blind or are there no such checkboxes as depicted in the blog post? Shouldn’t they be located at the web proxy configuration page? Or where else? Running core update 160 here.

Cheers

Gremlin

4

OK. But because the transparent usage of the web-proxy isn’t possible, it only works for tcp 80 and, if configured via wpad/proxy.pac, for tcp 443. But not for any other connection from internal to external, right?

5

The blog post indicates it is being added into Core Update 161.

2 Likes
6

Hi all,

first, thanks for your comments. :slight_smile:

As @arne_f already pointed out, the web proxy works for other destination ports than 80 as well, if clients use it explicitly. Technically, it works for any destination port, if the configuration of permitted destination ports allows it.

In short: The tricky part is to get the proxy configuration to the clients, and make them use it. As soon as this works, the web proxy itself is not a limit.

Oh, perhaps I should have been more clear here. In the very last paragraph, the announcement says:

Both this and the Fast Flux detection will be part of the upcoming Core Update 161.

As soon as there is a testing version of Core Update 161 available (personal ETA: next 10 days), you will see these two checkboxes. Please stay patient a little longer. :slight_smile:

Thanks, and best regards,
Peter Müller

3 Likes
7

Hi @pmueller & @arne_f ,

because it’s not possible to give the proxy-info reliable to every device in the network, is there a possibility to block ALL outgoing connections to bad destinations (like this):
image
Would be happy to be sure, all possible bad destinations would be blocked, independent of the browser-config or anything else.

Thanks and regards,

Jan

8

Hi,

yes, this is possible:

  1. Core Update 162, which I expect to be released within the next days, introduces a new pseudo country code, XD, for hostile networks safe to drop entirely. It contains networks listed at Spamhaus DROP, and a few additions of our own.
    Once Core Update 162 is released and you upgraded to it, you can create firewall rules for dropping all inbound and outbound traffic to country XD, so you will have the “baddest of the bad” covered. We plan to do so by default on new installations for basic user protection; existing systems will always remain unchanged.

  2. In addition, these IPS rulesets contain known hostile destinations (C&C servers, etc.), so enabling them is always a good idea:

    • botcc.rules
    • ciarmy.rules
    • compromised.rules (does not seem to filter out Tor exit nodes :expressionless: )
    • drop.rules (Spamhaus DROP is already covered by XD)
    • dshield.rules
    • threatview_CS_c2.rules

As described here, a good IPS policy in conjunction with a proper monitoring should be sufficient to shield most dirt from your network.

Hope to have helped. :slight_smile:

Thanks, and best regards,
Peter Müller

3 Likes
9

@pmueller -

Thank you for the ruleset recommendations and the forthcoming country code info. BTW, any ETA for Core 162? I have an outage scheduled this weekend for my machine, and would like to include the upgrade, if it is available.

Thanks again!

10

Hi,

well, Core Update 162 should have been released a while ago.

Unfortunately, we are currently facing connectivity issues in a facility where the ARM builders are located. :frowning: As soon as we got these resolved, Core Update 162 is ready to go.

Sorry to disappoint, and best regards,
Peter Müller

1 Like
11

Hi @pmueller
I would love to add those rules to my IPS config but I’m currently running Snort subscribed ruleset using policy security-ips. I will most gladly add those ET known hostile destinations blocking rules once able to use rulesets from multiple providers (per Stefan’s fine handywork). Is there a chance the multi-provider feature makes it into Core Update 163?

Thanks to you and the team for the great work you do,
Charles Brown

3 Likes
12

Hi,

well, after some delay, Core Update 162 has been finally released, so you can now use the XD country code to drop all traffic from and to known hostile networks.

Unfortunately, I am unaware of the current state of Stefan’s work here. He did a lot of work here, but I haven’t seen a message on the mailing list saying this is good to go. I will ask at the next telco in early January.

Aside from all this, I’d like to close this topic now, or split the posts after October 14 into a new one. It is good to discuss security considerations, and I love doing this, but it went a bit off-topic by now. :slight_smile:

Merry Christmas if you celebrate. Enjoy holidays if not.

Thanks, and best regards,
Peter Müller

1 Like