[svlug] Configuring Server - SSH Trouble + Security Considerations

Rick Moen rick at linuxmafia.com
Mon Oct 23 11:57:16 PDT 2006


Quoting Lord Sauron (lordsauronthegreat at gmail.com):

> You're right.

{shrug}  It happens.  Even a stopped clock is right twice a day, and all
that.


> So while I'm here, is there any software-based firewall for linux
> that's free that's better than/works well beside iptables that I
> should know about?

You're probably well aware of this, but just to make sure everyone is:
iptables / netfilter is a _toolset_ for making port/address filtering
and packet-mangling rules.  There are a large number of front-end gizmos
that aim to guide you through the process of using that toolset, and 
sometimes for managing and monitoring the results.  

There are also regimes to do application-level proxy gatewaying, which
is a more-sophisticated approach, and much more complex to set up.  You
should ideally read up on the taxonony of such things, before digging
in.  That would also help you decide if you're trying to solve the right
problem:

> I'm asking because I'm about to place the server on the network at a
> point *before* the hardware firewall.  This will be a server on the
> net with NO hardware firewall protection.  

So, here's my house network, using the BayLISA tradition of pathetic
ASCII art:

          Raw Bandwidth Communications DSLAM
                 |
                 | aDSL link
                 |
            aDSL bridge box, chez Moen
                 |
                 |
       cheap, unmanaged Ethernet switch
       |               |             |
 Deirdre's server  Rick's server   wireless base station
 (deirdre.org)   (linuxmafia.com)  & NAT box ("airport")
                                     |
                                     |
                         cheap, unmanaged Ethernet switch
                         |         |           |        |
                      other     people's    laptops    & such


For reasons that should be obvious from the above, deirdre.org,
linuxmafia.com, and airport are fully exposed to the Internet.  That is,
without some major (and troublesome) rearchitecting, there's no choke
point where such a magic dingus could reasonably be placed.  (The aDSL 
bridge is a Westel black-box thing.)  Oh, I could junk up the
linuxmafia.com box's ethernet interface with a bunch of ingress and
egress rules, but I don't -- or, at least, I doubt I have much beyond 
something to block broadcast ICMP.  (I'd have to go check.)

Why?  Well, it comes down to threat-model philosophy, and reasonable
people differ about this.  Some folks believe in the magic protective
barrier thing; for this network, at least, I don't.  My model is:  Just
_don't run_ any network-facing process that isn't robust against public
attack.  Don't trust the network.  Don't trust other hosts.  

So, it follows that, on my house LAN, each host is responsible for its
own security, and each host's "security perimeter" is the edge of its
PC case -- as opposed to the magic barrier thing at the network's edge
that most people put their faith in.

How do you know that a host is robust against public attack?  1) nmap is
your friend.  Security-scan it from nearby on the same LAN.  (You can
use a Knoppix or similar live CD for this.)  2) Know your system, and
know in detail what it's running.  

Don't expose cruddy PHP Web apps, AWstats, or other badly written
software to the outside world.  Use common sense.  Follow your distro's
security-alerts mailing list.  Understand what threats against your
system are worth worrying about, and have a plan for dealing with those.
Run Prelude-IDS or a similar file-based Intrusion Detection System.
Have current off-system (and preferably off-premises) backups and a
tested recovery plan, in case something goes wrong.

Do port/IP filtering/munging/etc. rulesets have a place in that?  Many
people think so -- but make _very_ sure you understand all of your
security systems well.  As I've mentioned before, Linux geeks tend to be
gadget freaks; their reflexive response to a possible system problem is
to throw more software (or other mechanism) at it, which is most often
the wrong thing to do.  Added complexity makes security more difficult
(and, often, less likely).

I had a boss once at $FIRM, a software company in the 1980s, who wrote
an elaborate set of port/IP filters for the company's Ascend IDSN router
facing the Internet.  He put them in place, and never revisited or
tested them.  Months later, we spotted customers making comments about
things they were finding on the sensitive, 100% internal Engineering
Dept. ftp/NFS server.   Mr. Boss hastily checked the Ascend router's
rulesets:  They were all missing. 

Upon examination, he found that he'd laboriously created all those rules
in the router's RAM, and then walked away when everything seemed to be
working right.  His mistake:  He'd failed to also save the ruleset to
the router's non-volatile RAM.  At the first power reset, poof!

If he'd so much as put in place a weekly cronjob to attempt a
non-permitted connection from outside, he'd have caught his error and
saved himself much crow-eating.





More information about the svlug mailing list