[svlug] Configuring Server - SSH Trouble + Security Considerations

Rick Moen rick at linuxmafia.com
Mon Oct 23 14:57:20 PDT 2006

Quoting Lord Sauron (lordsauronthegreat at gmail.com):

> Yah, I should have looked at wikipedia first.

On a good day, I like Wikipedia.  On bad days, you run across entries
like this:  http://en.wikipedia.org/wiki/Epimenides_paradox   (Feh!)

> Apache (beta portions of sites protected by username/password)
> MySQL (listening to localhost ONLY)

Please note that MySQL may still be open to network-based attack via Web
apps.  That is, Prof. Moriarty send devilishly clever malformed URLs
that get through swiss-cheese PHP-app input validation routines and 
execute dangerous SQL queries.  These are called SQL-injection attacks.


Well, the real question is:  PHP configured how?  PHP used with what
apps?  "PHP" on http://linuxmafia.com/kb/Security has some thoughts on
that.   And, to add to that:

o  Many distros default to installing a php.ini that's explicitly
   intended for development-use only.  Some of those prototype php.ini
   files have prominent comment lines saying "For Ghu's sake, don't
   even _think_ of deploying this on public networks.  It's not safe."
   But that doesn't do a lot of good if you, the admin, blithely 
   go with the default and never look at the config files.

o  Terrible, unsafe coding habits became so ingrained in the PHP 
   community for such a long time that many developed PHP Web apps 
   are themselves Typhoid Marys of security problems.  Read the 
   development history of some of the bigger ones, attentively, and it 
   comes accross like this: 
     Feb. 3:  Oops!  Input validation bug.  Upgrade to 3.51b.
     Feb. 21:  Oops!  Another input validation bug.  3.51c.
     Mar. 18:  Dammit, real input validation this time for sure!
   It gets pretty ignominious, after a while.  I mean, c'mon, guys,
   even Perl eventually got serious and started using "taint" mode.

o  Accordingly, don't be surprised if some/many developed PHP Web apps
   break after you tighten PHP security.


   Unless you're running pserver, this isn't a separate risk; access
   is either local or ssh-mediated.

> NO FTP (all site-uploads and stuff handled over CVS)

I have a stubborn liking for ftp daemons -- appropriately selected and
used for anonymous-only service.  I do that with vs-ftpd, myself.
See: "FTP Daemons" and "FTP Justification" on

> SSH (trying to find a way to restrict it to my machines only, so if
> you're not my laptop or desktop, it should just categorically deny
> you.)

A lot of people do that; I don't.  I simply don't think the "Eek!  OMG,
I've been portscanned.  Eek!  OMG, someone's dictionary-attacking my 
sshd" stuff is even significant at all (given precautions to keep local
users from doing dumb things with password-selection).

If you want something to worry about, here:
"Break-in without Remote Exploit" on http://linuxmafia.com/kb/Security 
(Any resemblance to screw-ups involving shells.sourceforge.net and VA
$WHATEVER is strictly intentional^Wcoincidental.)

> My home network has some networked printers, tons of windows machines,
> and other insecure things that would be very easily hacked.

Sure, good point.

> I have nmap on my laptop.  I've basically tried installing everything
> networking on it so I can plug in and diagnose any network (or rape
> it, if I want to, but I'm horrible at that...)  Any other good network
> apps I should know about?

Off the top of my head, gee, dunno.  Nessus?  Tiger?  Maybe you should
start out with just one or two basic tools and learn to use those
_well_.  (Beware the Gadget Freak Side, Luke.)

> So know what ports are open, what services use them, and how those
> services are configured.  Using Gentoo's rc-update tool, I have a
> pretty good idea of what's starting and when, though there could be
> other daemonized things that I'm not seeing.

Again, don't _just_ study the host from within itself.  Study it from
the outside using nmap.  For one thing, that's what the bad guys would
do.  Sort of like this:  "Attacking Linux" on

More information about the svlug mailing list