Re: [PATCH 0/5] ipblacklist: IP Address Blacklists

["Peter Müller" <peter.mueller@ipfire.org>]

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

Hello Tim, hello Michael,

please see my responses inline...
>>>
>>> We could periodically update the blacklists on our main mirror (and
>>> wait for the network to sync it), make sure it is signed and write
>>> a small downloader that fetches, validates and installs them.
>>>
>>> @All: Thoughts on this?
>>
>> I think there are a number of points here.
>>
>> Firstly, from the point of a third party using IPFire, is this really
>> solving the privacy disclosure problem?  There's no way round disclosing
>> your public IP address to someone you're downloading from; all this does
>> is change who that information is being disclosed to.  For the  user
>> there's no way of knowing whether the source is more or less protective
>> of the user's privacy than the blacklist provider.  Indeed it won't be
>> possible to know who the lists are being downloaded from until the
>> download starts.
> 
> There is a way: Tor. But that is a totally different story.
Well, I see a third option on this: Use the mirror infrastructure we already
have. Every IPFire installation discloses its public IP address to one of these
servers sooner or later, so we do not disclose additional data if the blacklists
were fetched from these.

Needless to say, Tor (hidden services) would be better, but that is a different
story indeed. :-)
> 
> The point is rather that a forget list can be sent instead of the “real” one.
I did not get this. Forget? Forged?? ???
> 
>> Secondly, latency; some of the lists are updated every 5 minutes.  While
>> I've limited the maximum check rate to hourly, will the updates
>> propagate quickly enough.  For reference on my main system the 24
>> updates on the CIARMY list made 143 498 changes (additions or
>> deletions).  I've seem it do over 200 000.
Yes, I observe that behaviour for CINS/CIArmy too. Unfortunately, they do not
document a recommended update interval anywhere, so we can only guess.

Personally, more static lists seem to be preferable for packet filtering. Highly
dynamic ones such as CIArmy should be done via DNSBL queries or something similar
- do we really want to have that list here?
> 
> How did you come up with the hour? Will it be retried more often if the download was not successful?
One hour is the most common interval indeed, but adding some random time might
be useful in order to reduce load on the servers providing a blacklist.
> 
>> Third, bandwidth; while the downloads are fairly small (ALIENVAULT is
>> the largest at a few MB), there are going to be a lot of them.  How will
>> this affect the willingness of people to mirror IPFire?
I do not consider this being a problem as we do not generate that much traffic
to them. Of course, that depends on the update interval again.
>>
>>>
>>> Talking about the preference of packet filter and IPS, I prefer to
>>> use the latter as well as it gains more insight in what kind of malicious
>>> traffic tried to pass a firewall machine. On systems with low resources,
>>> this might be problematic and removing load from the IPS can be preferred
>>> (make this configurable?!), on others, people might want to have both
>>> results.
>>>
>> You're only going to get one result for a packet whichever way round the
>> IP blacklist and IPS are since whichever comes first will drop the
>> packet before it reaches the second (well it would be possible to put
>> the IP blacklist first and get it to log and mark packets which are then
>> dropped after the IPS, but I think that's getting a little complicated.
>> In addition I've seen the messages about the trouble marking was
>> causing in the QoS).
>>
>> I think it's a 50/50 choice as to which is more valuable first; it's
>> probably going to differ from packet to packet.  For me the possibility
>> of reducing the IPS load means I prefer putting the IP blacklist first
>>
>> It should be fairly easy to add the choice of where to put the IP
>> blacklist.  I think it'll have to be in the main firewall script, so
>> it'll require a firewall restart, but it's not something that'll be
>> changed often.
> 
> I do not think that the user should choose this. If we cannot easily make a decision, how can our users do this? Not saying they are stupid here, we are just giving them something so that they do not have to put the thought and research into things themselves and make their jobs easier.
Agreed.

> 
> I think performance matters. And if the IPS comes first, the most likely case would be that we are seeing a SYN packet that is being scanned and after that being dropped by the blacklist. It was pointless to even scan the empty packet (TCP fast open aside). This is only different for other packets with payloads.
> 
> We would protect the IPS from a SYN flooding attack here at least and from scanning more packets unnecessarily.
So dropping packets from blacklisted IP addresses/networks before IPS is it, then.
> 
> I do not even think it makes sense to swap the order in the outgoing direction.
Me too.

> 
> What IPFire is lacking is a statistical analysis for those logs. Collecting more and more data isn’t helpful from my point of view. Only if you are looking at a very specific thing.This is true, but I am not sure if it makes sense to spend too much work on this.
Based on my personal experience, firewall hits observed on a single machine exposed
to the internet are interesting, but the overall situation across multiple machines
is even more interesting. Very quickly, you'll end on something like a centralised
logging server and custom statistical analysis here...
> 
>>>
>>> Personally, I consider Spamhaus DROP/EDROP can be safely enabled by default.
>>> I would love to see the bogon ruleset here, too (think about 8chan successor
>>> hosted at unallocated RIPE space in Saint Petersburg), but that will likely cause
>>> interference if RED does not have a public IP address assigned.
>>
>> I can add a field to the options file that controls whether a list is
>> enabled by default.
Thank you. :-)
> 
> To stress the point from above again: We would then share all public IP addresses of all IPFire systems in the world with Spamhaus and who is hosting their infrastructure. That can be considered a threat.
This is my only objection against this patchset. Now, what can we do about it?
One possibility is to apply the patchset now and implement a custom download
source thing later on, or do that before releasing Core Update 139 (or which version
the patchset will be to) after we agreed on something.

If we do, I will have a look at the licensing stuff (DShield and Spamhaus do not
seem to be problematic, as they are hosted on 3rd party servers, too).

Thanks, and best regards,
Peter Müller