[SSHd] Limiting access from authorized IP's

[Kurt Buff]

On Fri, Apr 18, 2008 at 8:59 AM, Matthew Seaman
<m.seaman at infracaninophile.co.uk> wrote:
> Paul Schmehl wrote:
>
>
> > I have maintained publicly available servers for a small hobby domain for
> almost ten years now.  Initially, I bought in to this logic and ran a
> firewall. (At that time we only had one server.)  What it cost me was CPU
> and memory. What it gained me was nothing.  I turned it off.  I have never
> run a firewall on a publicly available host since.
> >
> > Firewalls are for preventing access to running services.  By definition,
> if you are running a service, you want it to be accessed.  So firewalls are
> self-defeating or completely useless at the host level **unless** you don't
> know what you're doing.  For an enterprise they make a great deal of sense.
> No matter what a user inside your network might do, you can prevent access
> by simply not allowing traffic on that port.
> >
>
>  On the whole I agree with you -- you should be able to view a firewall as
>  a luxury rather than a necessity on a well configured server.  However
> there
>  is one rather nasty loophole that you can block with a firewall which
> otherwise
>  is pretty impossible to deal with, at least on FreeBSD machines.
>
>  It's all to do with the weak routing model -- that is, a network packet to
>  an IP on one of a host's interfaces will be accepted on *any* interface on
>  that host[*].  So even though you protect services that are not meant to be
>  for public consumption by binding them to the loopback address, some one
>  can still send you a spoofed packet to 127.0.0.1 that arrives on your
> external
>  network i/f /and it will let you connect to the service bound to the
> loopback/
>  The attacker has to have access to the same layer 2 network as your host,
>  but sending the spoofed packet is as simple as tweaking the routing table.
>  See eg:
>    http://seclists.org/bugtraq/2001/Mar/0042.html
>
>  Blocking this sort of attack against the loopback address can be done with
>  the following 3 line PF firewall config.  Extending this to back-end
> networks
>  etc. is left as an exercise for the student:
>
>   scrub in all
>   pass all
>   antispoof log quick for lo0
>
>         Cheers,
>
>         Matthew
>
>  [*] Which is not without its legitimate uses, as anyone who as ever
> configured
>  a load balancer using DSR mode will attest.
>
>  --
>  Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
>                                                  Flat 3
>  PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
>                                                  Kent, CT11 9PW

Not to detour this conversation too much, I hope, but I'm in a
different situation, and this is going to be an issue for me. I'm
putting together a box that's going to be a router for our company,
using BGP to give access to our T1 and frac DS3. That's all it should
be doing, it will have no other services. It'll be in our server room,
though, so I won't have to get at it from anywhere, except perhaps
home, and even that could be avoided by simply traveling the 10 miles
to work.

So, I'm wondering how to lock it down - I'm even contemplating
eliminating any MTA and sshd, and just running the routing daemon, but
sshd is just so useful that it's hard to do without, and eliminating
the MTA denies me the goodness of the periodic reports. 'Casting
syslog to my internal syslog host is also problematic, but possible, I
suppose. Then there's the problem of managing and monitoring the thing
once it's installed. Being able to use mrtg/cacti/something to query
SNMP would be extraordinarily useful, as we will be paying extra for
bandwidth above our fractional rate on the DS3, and also to monitor
the health of the box.

I haven't found any good guides for this, but I do have "Security
Power Tools", "Mastering FreeBSD and OpenBSD Security", and a couple
of other books, including one on OpenBSD and PF, but haven't teased
out all that I need from them regarding doing this in a sane/secure
manner.

At any rate, locking down ssh access is one of my concerns, for sure,
so this discussion is helpful.

Kurt