[clug] Secure your Internet facing stuff (was Re: googlebot doing funny things in logs, now proposed pen testing)

[Scott Ferguson]

On Sat Jun 18 01:33:07 MDT 2011 Bob Edwards wrote:
> So, way back 2 and a bit days ago, Ian requested that someone give
> a presentation at a CLUG meeting about how to "secure" (that's for
> your enjoyment, Sam) an Internet-facing Linux machine.
> 
> In the spirit of the CLUG list, there have been some helpful responses
> and some that are not so helpful (don't do it, you are not qualified,
> pay someone else to do it for you, you may end up killing someone etc.)
> which are not so much in the DIY spirit of CLUG, where we normally help
> and support each other in a free and open world.
> 
> However, no one has actually put their hand up to do the requested
> presentation. Why is this? 

Because a year wouldn't be long enough to cover something as vague as
"an Internet-facing Linux machine"? :-)

<snipped>
> 
> I'm happy to give a presentation of how I have my Internet-facing Linux
> machine set up at home (and even the one I have at a hosting company).
> 
> However, I thought it might be more helpful, in the spirit of CLUG,
> to hold some sort of "audit-off" night (possibly also known as a
> "crackfest"). My idea would be that during the evening, if you can
> demonstrate beyond a reasonable doubt that you own or administer a
> particular web site, then you can invite those attending to probe and
> otherwise audit your sites security. If and when we discover weaknesses
> we'll provide advice on how to fix them up etc.
> 
> I propose we only do this at a live event and not over e-mail etc.
> in case we uncover serious issues which we don't want to advertise to
> the world until they can be sorted out.

Sounds sensible.

> 
> I reckon such an event could be both educational and helpful in the
> spirit of CLUG. What do others think?

An excellent idea. Perhaps you could make it a regular event.

> 
> Cheers,
> 
> Bob Edwards.
> 
> 

I wouldn't attend (as usual) but I'd consider allowing access to some
examples of common webserver configuration mistakes, limited by
time/work commitments and my puny wireless broadband connection. If I
could free up some time I could possibly do some remote fuzz testing.

A couple of points/suggestions though:-

1. It might be useful to propose a few (half a dozen ?) generic
instances - and list the basic steps/approaches for securing them, as
well as the most common mistakes, for each example. eg. Myth tv server,
Wordpress/Joomla blog, small apache web server, home automation
controller, ftp server.

2. Also cover some basic concepts so that self-described n00bs aren't
lost by terms such umask, sub-nets, etc. (handouts or links)

3. People post a basic description of the externally accessible services
they'd like to test/get advice on before the meeting - that help testers
and "advisors" to prepare and also to ask for any other necessary
information before the event.

4. Having decided what is to be covered by 1. provide a list of standard
resources for additional information eg. howto search for known exploits
for Myth, Apache, Joomla and Wordpress extension and modules.

5. Someone generate some unique alpha-numeric strings. Anyone wanting
their server/s tested put the strings somewhere externally visible eg.
part of a web page. You could use that to verify ownership. (It's how
Google does it).

Many people run a number of externally accessible services on their home
network - how the services are combined is often part of a
vulnerability. So the more those attending with intention of testing and
advising know about the services and the intentions of the service - the
more useful the outcomes. It's easy to point a finger and say "x is a
stupid practise" but without knowing why x was put in place the proposed
solution may be useless. eg. trivial password is the flaw, non-trivial
password or smartcard is the proposed solution, person does not know and
easy method of remembering non-trivial passwords or is forever losing
things.

Pen testing takes time. And time spent testing is usually less than the
time spent researching/fingerprinting and blueprinting first. The
tighter the terms of reference the more productive the time will be.

Cheers