Using dynamic IP lists to block forwarding

Using dynamic IP lists to block forwarding

[Dave Osbourne]

Hi,

Not totally sure this is an acceptable post... I'm trying to find a 
"firewalling principles" discussion group, but everything I find online 
is either old and not longer used or brand / package specific.

This question is specifically about services that MUST be exposed to the 
"big bad internet" (i.e. internal MS Exchange servers for OWA, POP / 
IMAP etc) and I'd like to exclude any discussion of whether this 
(exposure) is good plan, focusing rather on how to best handle 
forwarding (via iptales or deeper level inspection)

Our current Watchguard does a temporary IP block on "bad" activity (this 
could be from bad SYN/ACK/PSH or from a log watch), but I've noticed 
that co-ordinated probes are coming from many different IPs, so this 
sort of response doesn't help that at all.

One suggestion I've had from a security agency is to identify a list of 
"good" (in my case "UK" IPs) and block everything else.  I don't think 
this is good since there are 2 modes of failure.

 1. The list might be incorrect and legit requests will be blocked, the
    list will have to regularly derived (there might be a source who knows)
 2. "bad" IPs might be on that list and allowed


My response is to implement a dynamic block list (say) 
http://iplists.firehol.org/?ipset=blocklist_net_ua - using iptables on 
(say) Debian.  I've looked at an hour of probe data and it seems that 
that /*specific */list would have blocked 97+% of known bad probe 
attempts (and the list is updated regularly).

I hope someone might be able to provide argument for / against... or 
share an alternative...

Regards,
Dave

---
http://dave.osbourne.uk.eu.org/

Re: Using dynamic IP lists to block forwarding

[Joerg Dorchain]

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

On Tue, Jan 09, 2018 at 09:28:26AM +0000, Dave Osbourne wrote:
> 
> 1. The list might be incorrect and legit requests will be blocked, the
>    list will have to regularly derived (there might be a source who knows)
> 2. "bad" IPs might be on that list and allowed
> 
> 
> My response is to implement a dynamic block list (say)
> http://iplists.firehol.org/?ipset=blocklist_net_ua - using iptables on (say)
> Debian.  I've looked at an hour of probe data and it seems that that
> /*specific */list would have blocked 97+% of known bad probe attempts (and
> the list is updated regularly).
> 
> I hope someone might be able to provide argument for / against... or share
> an alternative...

I have been doing this for a while, but now have found that ipset
fit in very well here.
- Adding and removing ips from a set is easier than fiddling with
  iptables syntax.
- The timeout feature comes in very handy.
- Basically the iptables rules can be static.

Bye,

Joerg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 898 bytes --]

Re: Using dynamic IP lists to block forwarding

[Dave Osbourne]

On 2018-01-09 09:58, Joerg Dorchain wrote:
> On Tue, Jan 09, 2018 at 09:28:26AM +0000, Dave Osbourne wrote:
>> 1. The list might be incorrect and legit requests will be blocked, the
>>     list will have to regularly derived (there might be a source who knows)
>> 2. "bad" IPs might be on that list and allowed
>>
>>
>> My response is to implement a dynamic block list (say)
>> http://iplists.firehol.org/?ipset=blocklist_net_ua - using iptables on (say)
>> Debian.  I've looked at an hour of probe data and it seems that that
>> /*specific */list would have blocked 97+% of known bad probe attempts (and
>> the list is updated regularly).
>>
>> I hope someone might be able to provide argument for / against... or share
>> an alternative...
> I have been doing this for a while, but now have found that ipset
> fit in very well here.
> - Adding and removing ips from a set is easier than fiddling with
>    iptables syntax.
> - The timeout feature comes in very handy.
> - Basically the iptables rules can be static.
>
> Bye,
>
> Joerg

Ah - I looked at that (ipset) - didn't even know it existed...!!

I'm getting a lot of resistance from our outsourced IT supplier on 
this...  the excuses are variously:

* block based on SRCIP being in <insert unfriendly state here> or
* why don't you migrate to Office365 or
* don't worry if you patch regularly and have a good passwd policy then 
just let the traffic come

all completely pointless given the constrains and facts of the case.

Does *anyone* have some kind of a reference or best practice for this, 
or their own motivation even?

I feel the resistance I'm getting (not from the list) is through a lack 
of awareness by IT professionals...  this seems like such an obvious 
thing to do, yet 3 IT support companies I've spoken to don't seem keen....

Dave

Re: Using dynamic IP lists to block forwarding

[Mauro Santos]

On 09-01-2018 16:24, Dave Osbourne wrote:
> 
> 
> On 2018-01-09 09:58, Joerg Dorchain wrote:
>> On Tue, Jan 09, 2018 at 09:28:26AM +0000, Dave Osbourne wrote:
>>> 1. The list might be incorrect and legit requests will be blocked, the
>>>     list will have to regularly derived (there might be a source who
>>> knows)
>>> 2. "bad" IPs might be on that list and allowed
>>>
>>>
>>> My response is to implement a dynamic block list (say)
>>> http://iplists.firehol.org/?ipset=blocklist_net_ua - using iptables
>>> on (say)
>>> Debian.  I've looked at an hour of probe data and it seems that that
>>> /*specific */list would have blocked 97+% of known bad probe attempts
>>> (and
>>> the list is updated regularly).
>>>
>>> I hope someone might be able to provide argument for / against... or
>>> share
>>> an alternative...
>> I have been doing this for a while, but now have found that ipset
>> fit in very well here.
>> - Adding and removing ips from a set is easier than fiddling with
>>    iptables syntax.
>> - The timeout feature comes in very handy.
>> - Basically the iptables rules can be static.
>>
>> Bye,
>>
>> Joerg
> 
> Ah - I looked at that (ipset) - didn't even know it existed...!!
> 
> I'm getting a lot of resistance from our outsourced IT supplier on
> this...  the excuses are variously:
> 
> * block based on SRCIP being in <insert unfriendly state here> or
> * why don't you migrate to Office365 or
> * don't worry if you patch regularly and have a good passwd policy then
> just let the traffic come
> 
> all completely pointless given the constrains and facts of the case.
> 
> Does *anyone* have some kind of a reference or best practice for this,
> or their own motivation even?
> 
> I feel the resistance I'm getting (not from the list) is through a lack
> of awareness by IT professionals...  this seems like such an obvious
> thing to do, yet 3 IT support companies I've spoken to don't seem keen....
> 

The only experience with something simpler (trying to reduce the number
of ssh bruteforce attempts) is allowing only IPs from $MYCOUNTRY. Your
concern about the list of IPs not being correct is a valid one but I've
never had problems or complaints (machines have only a few users though)
when using the lists from here:

ftp://ftp.ripe.net/pub/stats/ripencc/

The files there are updated daily. You'll have to massage the file first
to get a range of IPs you can use.

That said your idea sounds good and if it could help catch the few
corner cases the static lists (firehol + ripe) don't catch I don't see
why not use it (maybe false positives concern?).

> Dave
> 
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Mauro Santos

Re: Using dynamic IP lists to block forwarding

[Joerg Dorchain]

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

On Tue, Jan 09, 2018 at 04:24:50PM +0000, Dave Osbourne wrote:
> 
> Ah - I looked at that (ipset) - didn't even know it existed...!!
> 
> I'm getting a lot of resistance from our outsourced IT supplier on this... 
> the excuses are variously:
> 
> * block based on SRCIP being in <insert unfriendly state here> or

Can do that, if you are sure to never get customer from there.
More complementatry, not a replacement measure.

> * why don't you migrate to Office365 or

Or use icloud. Blonde is actually a state of mind, and makes the
world a much easier place. Next round you'll be talking religous
arguments ("I belief this will..." completely lacking undermining
facts)

> * don't worry if you patch regularly and have a good passwd policy then just
> let the traffic come

Again, a complementatry thing.

Don't rely on a single measure alone; If you notice an IP banging
at you with a dozend failed logins a second, why not block it
automatically for some time? Helps a bit the noise in the logs,
and the length of that queue is a bit a a script kiddie fever
curve.
> 
> Does *anyone* have some kind of a reference or best practice for this, or
> their own motivation even?

Easy, cheap, helps. For more fundamental arguments, see relevant
literature (Schneier et al.)

> I feel the resistance I'm getting (not from the list) is through a lack of
> awareness by IT professionals...  this seems like such an obvious thing to
> do, yet 3 IT support companies I've spoken to don't seem keen....

Sometimes people just are not interested in things they can't
monetise within 3 month..

Bye,

Joerg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 898 bytes --]

Re: Using dynamic IP lists to block forwarding

[Neal P. Murphy]

On Tue, 9 Jan 2018 16:24:50 +0000
Dave Osbourne <dave@osbourne.uk.eu.org> wrote:

> Ah - I looked at that (ipset) - didn't even know it existed...!!
> 
> I'm getting a lot of resistance from our outsourced IT supplier on 
> this...  the excuses are variously:
> 
> * block based on SRCIP being in <insert unfriendly state here> or
> * why don't you migrate to Office365 or
> * don't worry if you patch regularly and have a good passwd policy then 
> just let the traffic come
> 
> all completely pointless given the constrains and facts of the case.

I would say lack of awareness is the main reason they resist. The same lack of awareness and the dearth of easy-to-admin firewalls is the main reason there are still so many bot nets, so much malware, and so many miscreants around the internet. Another reason is that far too many people believe that end-to-end encryption will solve most of the problems of the internet; but they are wrong. TLS-everywhere has one major drawback; it prevents owners of private internets (like you and me) from detecting and blocking malware and micreants from crossing our perimeter firewalls. The correct solution is host-to-gateway, gateway-to-gateway, and gateway-to-host encryption; OE would allow owners and operators of private networks to prevent malware and miscreants from entering--and leaving--their networks.

> Does *anyone* have some kind of a reference or best practice for this, 
> or their own motivation even?

Maybe more than you wanted, but a little knowledge can go a long way. Do these first thing in mangle:PREROUTING; in short, drop traffic you already know you don't want as early as possible in netfilter; waste not one extra CPU cycle processing such packets.
  - DROP all INVALID packets; netfilter doesn't know why they arrived nor where they should
    go, so just drop them.
  - Determine countries you *never* want to exchange traffic with and DROP packets to and from
    those IPs. But be aware. Sometimes apparently legitimate sites (like alibaba and linux-questions)
    will be blocked.
  - I made a simple mod for Smoothwall Express that automates block sets; it can probably be easily
    adapted for general netfilter use. It uses the Exploited Servers, Chinese, Nigerian, Russian
    and LACNIC lists from wizcrafts. The sets are auto-updated daily. I had also used the 90-day
    list from openbl for a while. The problem with some of these blocklists is that they
    occasionally get *too* zealous and block legitimate sites. So I added admin whitelisting
    capability. And then added admin blocklist capability for completeness. The set of blocklists
    to be used is configurable. It's fairly easy to add parsers for other list formats.
  - GAR is another Smoothwall Express mod, but is closely tied to Smoothwall; I mention it because
    I think it does almost exactly what you want. It watches snort/suricata alerts and drops
    packets for a period of time to and from any IP that causes an alert. Theory: if you see
    someone outside your home checking the locks on your windows, will you let him in your front
    door if he knocks? Of course not. So if a host (IP addr) probes your network for services that
    don't exist (such as SQL, ftpd, telnetd), or tries a known exploit, don't let any packets go
    to or from that IP for some specified period of time.
  - DROP all traffic to and from TEST NET addresses and other address blocks that should never
    be routed.
  - DROP all internet-side traffic to and from private addresses unless you know that there are some
    private LANs between you and the actual internet.

This should help you to significantly reduce traffic to and from scruffy-looking sites.

N

Re: Using dynamic IP lists to block forwarding

[Dave Osbourne]

Hi Everyone,

**not quoting the original message**

Joerg, Mauro and Neal - that you for your input.  This is invaluable to 
help me convince the rest of management about how we should move forward 
- with a solution centric rather than product centric approach.

It was really good to get some non product advice for a change.

I've amended my solution to include subnets from RIPE lists for 
"undesirables" since that does make some sense too.

Regards,
Dave

Re: Using dynamic IP lists to block forwarding

[zrm]

On 01/09/2018 01:40 PM, Neal P. Murphy wrote:
> I would say lack of awareness is the main reason they resist. The same lack of awareness and the dearth of easy-to-admin firewalls is the main reason there are still so many bot nets, so much malware, and so many miscreants around the internet. Another reason is that far too many people believe that end-to-end encryption will solve most of the problems of the internet; but they are wrong. TLS-everywhere has one major drawback; it prevents owners of private internets (like you and me) from detecting and blocking malware and micreants from crossing our perimeter firewalls. The correct solution is host-to-gateway, gateway-to-gateway, and gateway-to-host encryption; OE would allow owners and operators of private networks to prevent malware and miscreants from entering--and leaving--their net
 works.

It would be good to have that for certain metadata but not for content. 
It's clearly wrong for the gateway at some hotel where I'm checking my 
email to have access to the plaintext of the email. And it's not as if 
the gateway can do any magic content-based malware detection that 
couldn't be done on the endpoints.

But it would be useful for the gateway to at least know what services 
are being used. You know there shouldn't be any CIFS or NFS traffic 
across the public internet.

Sadly the people using outgoing default deny have screwed us all. All it 
takes is for a large enough minority to block everything but TLS/443 for 
everyone to respond by using TLS/443 for everything, and then you can't 
distinguish any of it. Which leaves everyone worse off than having 
outgoing default allow with specific exceptions for services known to be 
problematic.

>    - DROP all internet-side traffic to and from private addresses unless you know that there are some
>      private LANs between you and the actual internet.

A good way to do this is to add "unreachable" routes for all the private 
address ranges using the worst possible metric, and enable reverse path 
filtering. Then private addresses don't go to the default route 
(internet) but if a private network is directly connected or has a 
specific route it still works.

Re: Using dynamic IP lists to block forwarding

[Neal P. Murphy]

On Thu, 11 Jan 2018 16:28:26 -0500
zrm <zrm@trustiosity.com> wrote:

> On 01/09/2018 01:40 PM, Neal P. Murphy wrote:
> > I would say lack of awareness is the main reason they resist. The same lack of awareness and the dearth of easy-to-admin firewalls is the main reason there are still so many bot nets, so much malware, and so many miscreants around the internet. Another reason is that far too many people believe that end-to-end encryption will solve most of the problems of the internet; but they are wrong. TLS-everywhere has one major drawback; it prevents owners of private internets (like you and me) from detecting and blocking malware and micreants from crossing our perimeter firewalls. The correct solution is host-to-gateway, gateway-to-gateway, and gateway-to-host encryption; OE would allow owners and operators of private networks to prevent malware and miscreants from entering--and leaving--their n
 etworks.  
> 
> It would be good to have that for certain metadata but not for content. 
> It's clearly wrong for the gateway at some hotel where I'm checking my 
> email to have access to the plaintext of the email. And it's not as if 
> the gateway can do any magic content-based malware detection that 
> couldn't be done on the endpoints.

The hotel owns its network and has the duty to do what is reasonable to prevent the dissemination of malware (viruses, trojans, phishing, bot net controls, etc.), either inbound or outbound. End-to-end encryption precludes the hotel management from doing its duty. I'll even go so far as to say that end-to-end encryption fosters the spread of all manner of malware because it prevents all intermediate points from recognizing malware in the first place.

Endpoint detection is nice in theory. But, far too often, it doesn't exist, isn't up-to-date, or just cannot detect enough. That is, while you may be utterly diligent in keeping your endpoint detection systems up-to-date and operational, Joe Sixpack is almost certainly not going to be very diligent at all because that is not his area of expertise. Good security is multi-level: endpoints, firewalls, and other intermediate points. Having different detection methods in use and using different malware databases increases the probability that any given piece of malware will be detected and blocked.

> 
> But it would be useful for the gateway to at least know what services 
> are being used. You know there shouldn't be any CIFS or NFS traffic 
> across the public internet.

Port numbers no longer necessarily correspond to specific services. Other than proxies, what is to prevent a miscreant from using port 21, 22, 23, 53, 80, 123, 443, 587, 993, 995, or any number of other commonly accessible ports to distribute malware or control bot nets?

> 
> Sadly the people using outgoing default deny have screwed us all. All it 
> takes is for a large enough minority to block everything but TLS/443 for 
> everyone to respond by using TLS/443 for everything, and then you can't 
> distinguish any of it. Which leaves everyone worse off than having 
> outgoing default allow with specific exceptions for services known to be 
> problematic.

One could just as easily say that people using TLS everywhere have screwed us all by preventing intermediate points from recognizing and blocking malware. The owner of a network decides what may not enter or leave her network. Guests who disagree with said policies are free to find another net to use.

Like all freedoms, freedom of communication comes with duties and responsibilities. Utter freedom (that which is devoid of duties and responsibilities) is anarchic, and anarchy is the antithesis of society. For society to grow and flourish, it needs at least some rules and regulations that provide a level-ish playing field. The same applies to the internet. When the owners of private networks have their control wrested from them, then their property has been taken from them; I might even say their property has been stolen from them.

So at the risk of sounding crude, I's'll repeat myself. Owners of private networks must have the ability to examine data passing into and out of their networks so that they may recognize and block malware and miscreants.

And to bring this back on topic, netfilter must evolve and continue to help people to do their parts in controlling the spread of malware and shrinking the influence of internet miscreants.

N

Re: Using dynamic IP lists to block forwarding

[zrm]

> The hotel owns its network and has the duty to do what is reasonable to prevent the dissemination of malware (viruses, trojans, phishing, bot net controls, etc.), either inbound or outbound. End-to-end encryption precludes the hotel management from doing its duty. I'll even go so far as to say that end-to-end encryption fosters the spread of all manner of malware because it prevents all intermediate points from recognizing malware in the first place.

That has no bottom. Why have a hotel read all my email but not their 
ISP, or their ISP's transit provider, or the recipient's ISP, or the 
hardware vendors, or the software vendors, or the government of every 
jurisdiction the bits pass through, or all foreign governments?

In every case it would be true that if you gave them the plaintext they 
would have an opportunity to identify malware. That doesn't demand 
giving them all the plaintext.

> Endpoint detection is nice in theory. But, far too often, it doesn't exist, isn't up-to-date, or just cannot detect enough. That is, while you may be utterly diligent in keeping your endpoint detection systems up-to-date and operational, Joe Sixpack is almost certainly not going to be very diligent at all because that is not his area of expertise. Good security is multi-level: endpoints, firewalls, and other intermediate points. Having different detection methods in use and using different malware databases increases the probability that any given piece of malware will be detected and blocked.

It's possible to have multiple layers entirely within the endpoints. The 
operating system and browser can each have their own malware database. 
Each host is a layer of defense for the others, because each protected 
host doesn't get infected and spread the malware; herd immunity and all 
that.

It's also possible to add specifically trusted intermediaries. An 
enterprise may put its users on a proxy server that checks for malware. 
A home user could subscribe to a VPN service that does the same. Then 
the proxy can be trusted and cryptographically secured to the endpoints 
rather than making everyone trust every random wifi gateway they use 
that might well be operated by an attacker.

>> But it would be useful for the gateway to at least know what services
>> are being used. You know there shouldn't be any CIFS or NFS traffic
>> across the public internet.
> 
> Port numbers no longer necessarily correspond to specific services. Other than proxies, what is to prevent a miscreant from using port 21, 22, 23, 53, 80, 123, 443, 587, 993, 995, or any number of other commonly accessible ports to distribute malware or control bot nets?

Nothing, that's the point. That was never a thing it prevented. 
Information theory says you can't stop two colluding hosts from 
communicating arbitrary information unless you prevent them from 
communicating whatsoever. If one port is open between them then they 
might as well all be. They can even disguise their traffic as whatever 
protocol it's supposed to be.

The benefit of identifying traffic is when one of the endpoints is not 
malicious. For example, if you know you aren't operating any mail 
servers, block outgoing SMTP. A compromised host can't just use another 
port because the victim receiving mail server only accepts mail on the 
standard port.

>> Sadly the people using outgoing default deny have screwed us all. All it
>> takes is for a large enough minority to block everything but TLS/443 for
>> everyone to respond by using TLS/443 for everything, and then you can't
>> distinguish any of it. Which leaves everyone worse off than having
>> outgoing default allow with specific exceptions for services known to be
>> problematic.
> 
> One could just as easily say that people using TLS everywhere have screwed us all by preventing intermediate points from recognizing and blocking malware.

It's not a choice, it's selective pressure. If you create a new protocol 
using its own port and people are using default deny, you're default 
blocked even if you're innocent. Administrators won't create an 
exception for a protocol until it becomes popular and it won't become 
popular while it's blocked.

The application will either look like an existing allowed protocol or 
die, so all the new applications that didn't die look like an existing 
allowed protocol. Which is problematic.

> Like all freedoms, freedom of communication comes with duties and responsibilities. Utter freedom (that which is devoid of duties and responsibilities) is anarchic, and anarchy is the antithesis of society. For society to grow and flourish, it needs at least some rules and regulations that provide a level-ish playing field. The same applies to the internet. When the owners of private networks have their control wrested from them, then their property has been taken from them; I might even say their property has been stolen from them.
> 
> So at the risk of sounding crude, I's'll repeat myself. Owners of private networks must have the ability to examine data passing into and out of their networks so that they may recognize and block malware and miscreants.

I think you're making two separate arguments.

One is that you should have a _right_ to see the plaintext of anything 
on your network. Which is fine, block TLS on your private network if you 
like. Then most people won't want to use your network.

The other is that you should have a _duty_ to see the plaintext of 
everything on your network. This is where we disagree. I think it should 
be permissible to let someone use your wifi without requiring them to 
divulge their secrets to you.

> And to bring this back on topic, netfilter must evolve and continue to help people to do their parts in controlling the spread of malware and shrinking the influence of internet miscreants.

If you can't have a discussion about the consequences of particular 
networking filtering policies on a list for a network filtering 
framework, where are you supposed to have it? :)