The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: [OT] - HELP PLEASE we've been hacked.


  • Subject: Re: [OT] - HELP PLEASE we've been hacked.
  • From: "David Buckley" <db@xxxxxxxxxxx>
  • Date: Tue, 13 Apr 2004 21:49:13 -0000

--- In ukha_d@xxxxxxx, "Dean Barrett" <dean@w...> wrote:
> I would be grateful for someone to explain HOW they did it ?
>

The uncomfortable answer is "because you let them"

Fairly recently I opined that NAT is an excellent first step to
protecting a connection to the internet, but, and its a big but, it
adds nothing in terms of protection if you allow incoming
connections.  If you allow incoming connections you need to be
altogether more careful.

So the first question is what ports do you have open?  You must be
able to account for every port you have exposed.  The easiest error
to make is to fill in the box on the router that says "direct all
incoming connections to what IP address".  Just dont do it.

An  easy way to check "from the outside" is the shields up tool
at
http://www.grc.com.  Please ignore the
politics about the
individual  who runs this site and company, just use the tool.

When you have a server that is exposed in any way, you need to
ensure its secure.  Obvious really.  That means minimisation
(removing or inactivating anything you dont need) and hardening
(making sure all the correct security options are configured).  The
trouble is, this is hard, and thats what folks get paid a lot of
money to do.  Especially with MS based product.  If you were running
a Sun server, you could go to the sun website and download some
great blueprints that tell you exactly what to do.

You need to take some steps.

You are wedded to a MS server, and dont want to invest heavily in
making (more accurately, trying to make) it secure.  I can
understand that reluctance, as keeping a MS server secure is hard.
So the next least bad approach is to "ringfence" the thing.  You
need to put it in a DMZ.  A proper DMZ, not a different subnet on a
common physical network.  The often used answer to this is a "three
legged firewall", but best advice is that you dont use these boxes,
but use two separate firewalls.

You actually need a router to terminate your internet connection,
and a "dirty" hub in the middle of the (what will be) three
routers.  If your internet connection is no more than 4mbit/sec, I
really reccomend a 10mbit hub, like the NetGear EN104.  If you ever
need to attach a network sniffer, its much easier with a hub!  If
its faster, get a 100mbit/sec hub.

You need a NAT box for your ordinary ("clean" or
"office") LAN with
no incoming connections, and another box to the ringfenced DMZ
network.  This last box should be quite good, as its what will
protect you and the world.

Given you can buy a half-decent firewall like the ZyWall 1 for not
much money, its a cost effective solution for your incoming
connection network.  You then need to set up the routing so that the
office lan can connect to the DMZ machine.  Your router / firewall
things need to support Access Control Lists (ACLs), and NAT.  If you
are using "normal" protocols (eg HTTP or FTP) then one that
supports "stateful inspection" is a plus.  It would have made
your
attack pointless, as it looks like the web server has been replaced
by a FTP server, which would be blocked by stateful inspection as
the protocol doesnt look like valid HTTP.

The DMZ machine should have no dependency on anything in the office
LAN, and especially shouldnt be part of a domain.  And in a
different workgroup.

That just leaves maintenance activities on the DMZ box.  The best
product for this used to be Reachout!, which did remote control and
file transfer in one product, and its easy to set the ACLs to permit
it where required only.  Sadly, no longer available in single
quantities.  So for file transfer, I'd recommend SecureFX and
Vshell, as these use SSH and thus require a simple port ACL, unlike
FTP.  And for remote control, use RDP.  Only allow this from the
clean lan to the DMZ, not vice versa.

But just because the dodgy server is on the DMZ, dont ignore it!  It
still needs to be kept secure.

Note 1.  You keep saying "...I run Geovision server on a specific
port, CBus Homegate server on another port", presumably 'cos you
dont want to tell the world what the ports are.  This is an example
at "security through obscurity", and this doesnt actually work. 
One
of the first steps to penetrating a network is a port scan to find
open (and thus possibly vulnerable) ports.  There are numerous
tools to scan ports.  Anyone who want to find out what ports you are
using can do so trivially.

Note 2.  The worst bit about a compromised server on the office LAN
is that it is a full member of your network, and could have been
used to download, delete or modify other stuff on other machines on
the office LAN.  Have a look around, run full virus scans and ad-
aware on all your machines.

Note 3.  Even being careful, your box may be hit again.  Have great
backups so you can rebuild it if necessary with less hassle.

Good luck.  Its a bad, bad world out there...








UKHA_D Main Index | UKHA_D Thread Index | UKHA_D Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.