public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: "Peter Müller" <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH 0/3] Add ASN-based anomaly detections to IPFire's web proxy: Proactive Fast Flux detection and detection for selectively announced networks
Date: Mon, 05 Jul 2021 19:27:50 +0200	[thread overview]
Message-ID: <18ce6cea-a141-c91e-61ca-8fd1b9c4ab01@ipfire.org> (raw)
In-Reply-To: <B53EC20C-0AE3-40B7-BEE8-C5071164D7BD@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 3954 bytes --]

Hello Michael,

thank you for your reply.

> Hello Peter,
> 
> I love this feature. I think it is a one-of-a-kind thing and hopefully many more people will think the same.

Yes, I like the idea, too. Sometimes, security can be simple _and_ effective... :-)

> However, it will need a lot of documentation and explaining.

Indeed. I was thinking about a blog post for it; we probably need to explain Fast Flux in the
first place, and I am not sure if all of our users are aware of the existence of autonomous
systems.

> I have a couple of high-level questions:
> 
> * Does it make sense to give the user the choice for the threshold?
> 
> It seems to be a difficult question because it requires exact knowledge what this feature actually does. My fears are that people just set this to something like “9” and the feature would become ineffective. What use-case is there to change this?

One size never fits all, I guess.

Indeed, the range of useful threshold values is pretty small: Anything below 4 causes _way_ too
much false positives in productive environment, whereas even 7 appears to be too ineffective.

At the moment, the CGI catches values the ASNBL helper would treat itself as being invalid. Do
you think narrowing down this range to 4 to 7 makes sense? Or should we replace it by a dropdown
for adjusting sensitivity?

Either way, it is a good idea to tell users to leave the default where it is unless they truly
understand what they are doing.

> * Selective announcements: Should this necessarily live in the proxy? Why do we not generate a filter for the firewall?

We can do so as well, and I would love to see such a feature landing in IPFire.

Given our current state of libloc, I doubt this is possible: We would need a function that returns
all networks we do not have an AS for - to my knowledge, the libloc (bindings) do not support this
at the moment.

Apart from that: On a packet filter level, we lack the FQDN of a destination, which might be useful
to have for debugging or forensic reasons.

Also, the users will experience a timeout after n seconds. Having selective announcement detection
turned on, they'll get their error message straight away. I was told this improves UX... :-)

Thanks, and best regards,
Peter Müller

> 
> -Michael
> 
>> On 18 Jun 2021, at 18:24, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>>
>> This patchset adds two new features to IPFire's web proxy, taking advantage
>> of the Autonomous System information we have at hand by using libloc.
>>
>> The proactive Fast Flux detection is especially worth noticing, as even most
>> expensive (= advanced?) security suites do not provide similar protection,
>> especially not in a proactive manner.
>>
>> By simply enumerating the distinct amount of Autonomous System Numbers a FQDN
>> ultimately resolves to, we are able to deny access to malware distribution
>> sites, phishing sites, C&C servers, and other cybercrime stuff hosted on Fast
>> Flux setups abusing cracked machines around the world - even before the FQDN
>> or any IP address involved is flagged as malicious by any security vendor.
>>
>> Peter Müller (3):
>>  squid-asnbl: New package
>>  proxy.cgi: Implement proactive Fast Flux detection and detection for
>>    selectively announced destinations
>>  langs: Add English and German translations for newly added web proxy
>>    features
>>
>> config/rootfiles/common/squid-asnbl |  1 +
>> html/cgi-bin/proxy.cgi              | 89 +++++++++++++++++++++++++++++
>> langs/de/cgi-bin/de.pl              |  7 +++
>> langs/en/cgi-bin/en.pl              |  7 +++
>> lfs/squid-asnbl                     | 83 +++++++++++++++++++++++++++
>> make.sh                             |  1 +
>> 6 files changed, 188 insertions(+)
>> create mode 100644 config/rootfiles/common/squid-asnbl
>> create mode 100644 lfs/squid-asnbl
>>
>> -- 
>> 2.26.2
> 

  reply	other threads:[~2021-07-05 17:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-18 17:24 Peter Müller
2021-06-18 17:24 ` [PATCH 1/3] squid-asnbl: New package Peter Müller
2021-06-18 17:24   ` [PATCH 2/3] proxy.cgi: Implement proactive Fast Flux detection and detection for selectively announced destinations Peter Müller
2021-06-18 17:25     ` [PATCH 3/3] langs: Add English and German translations for newly added web proxy features Peter Müller
2021-07-05 16:59     ` [PATCH 2/3] proxy.cgi: Implement proactive Fast Flux detection and detection for selectively announced destinations Michael Tremer
2021-07-05 17:31       ` Peter Müller
2021-07-05 16:57 ` [PATCH 0/3] Add ASN-based anomaly detections to IPFire's web proxy: Proactive Fast Flux detection and detection for selectively announced networks Michael Tremer
2021-07-05 17:27   ` Peter Müller [this message]
2021-09-06 16:35     ` Peter Müller
2021-09-07 14:28       ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18ce6cea-a141-c91e-61ca-8fd1b9c4ab01@ipfire.org \
    --to=peter.mueller@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox