All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Neal P. Murphy" <neal.p.murphy@alum.wpi.edu>
To: Dave Osbourne <dave@osbourne.uk.eu.org>
Cc: netfilter@vger.kernel.org
Subject: Re: Using dynamic IP lists to block forwarding
Date: Tue, 9 Jan 2018 13:40:54 -0500	[thread overview]
Message-ID: <20180109134054.47146cc3@playground> (raw)
In-Reply-To: <a2194be6-ac9a-5631-7e55-def8cb240b45@osbourne.uk.eu.org>

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

  parent reply	other threads:[~2018-01-09 18:40 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09  9:28 Using dynamic IP lists to block forwarding Dave Osbourne
2018-01-09  9:58 ` Joerg Dorchain
2018-01-09 16:24   ` Dave Osbourne
2018-01-09 16:59     ` Mauro Santos
2018-01-09 17:33     ` Joerg Dorchain
2018-01-09 18:40     ` Neal P. Murphy [this message]
2018-01-10 15:55       ` Dave Osbourne
2018-01-11 21:28       ` zrm
2018-01-11 22:17         ` Neal P. Murphy
2018-01-12  1:43           ` zrm

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=20180109134054.47146cc3@playground \
    --to=neal.p.murphy@alum.wpi.edu \
    --cc=dave@osbourne.uk.eu.org \
    --cc=netfilter@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.