[clug] Secure your Internet facing stuff (was Re: googlebot doing funny things in logs, now proposed pen testing)
bob at cs.anu.edu.au
Sat Jun 18 05:17:08 MDT 2011
On 18/06/11 19:21, Scott Ferguson wrote:
> 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"? :-)
>> 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.
>> 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
> 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.
All good advice, thanks Scott.
Also, might be worth advising your ISP that you will be doing hardening
testing on your site on the night so that they don't detect foul play
and cut your connection outright.
Also, anyone got a lazy botnet or two lying around we could harness?
(yep, thought so, not going to let on if you do, eh?)
And, in case it isn't implicit, I'm proposing Linux only Internet-facing
servers (oh, alright, and Free/Open/Net-BSD etc.). If you want
your Windoze server audited, take it somewhere else, please.
More information about the linux