[plug] [Fwd: Re: David Conran's talk]

Raven ian.kent at pobox.com
Sun Jun 11 15:38:02 WST 2000


Hi all,

Can everbody review this and send any comments to Daniel as he has
asked.

-------- Original Message --------
Subject: Re: David Conran's talk
Date: Fri, 09 Jun 2000 01:35:50 +0800
From: Daniel Baldoni <dbaldoni at iinet.net.au>
Organization: LcdS Pty. Ltd.
To: Ian Kent <ian.kent at pobox.com>
References: <39379AB5.CFAB7A66 at iinet.net.au>
<393A1186.8884F3F1 at pobox.com>

G'day again,

>> I don't know if you're the right person to contact on this, but here goes.
>>
>> You may have heard about the seminar given by David Conran to a group
>> meeting of PLUG and the WA chapters of AUUG and SAGE-AU (about 2 weeks
>> ago).  I have written up a brief report on his talk and I'm going to submit
>> it to the AUUGN journal and the SAGE Advice newsletter.  But, I thought the
>> PLUG members might like to have a read.
> 
> Yes and Yes!

Okay, the attachment is a straight (7 bit) text version of the file I'm
about
to submit to AUUGN and SAGE Advice.  Feel free to publish it on PLUG's
mailing
list but note that PLUG must not claim copyright (as the document will
also be
appearing in two journals and on-line).  This same stipulation will be
made to
the editors of the journals.  FYI, the HTML version will (eventually) be
at
"http://www.lcds.com.au/waug/2000may.shtml" (after some slight site
re-organisation).

>> I can make available a text copy if you wish (for distribution on PLUG's
>> mailing lists)...there will also be a HTML version on my company's web-site
>> shortly.
> 
> I will forward it to the mailing list and direct comments to you.
> 
> Thanks for thinking of us.

Not a problem - this type of information sharing can only benefit
everybody
and I'm glad to help.

Ciao.

-- 
-------------------------------------------------------+---------------------
Daniel Baldoni BAppSc, PGradDipCompSci                 |  Technical
Director
require 'std/disclaimer.pl'                            |  LcdS Pty. Ltd.
-------------------------------------------------------+  856B Canning
Hwy
Phone/FAX:  +61-8-9364-8171                            |  Applecross
Mobile:     041-888-9794                               |  WA 6153
URL:        http://www.lcds.com.au/                    |  Australia
-------------------------------------------------------+---------------------
"Any time there's something so ridiculous that no rational systems
programmer
 would even consider trying it, they send for me."; paraphrased from
"King Of
 The Murgos" by David Eddings.  (I'm not good, just crazy)
-------------- next part --------------
This month the WA chapters of AUUG and SAGE-AU got together with PLUG (the Perth
Linux Users' Group) to hold a special meeting.  We were fortunate enough to have
David Conran from AusCERT (the Australian Computer Emergency Response Team) give
us a talk entitled "Probes, Logs and Things That Go Bump in the Night".

The first question David covered was "What is a probe?".  He described it as:
    - a "knock on the door" or "rattling of the windows" of your firewall;
    - a precursor to being hacked;
    - a good indication that the source site (of the probe) has been compromised
      and
    - costing you bandwidth.

How often do they happen?  Apparently, this can depend on:
    - how big your site is;
    - how large your DNS is (check who you allow zone transfers to);
    - how visible your site is; and
    - whether or not you're unlucky enough to be the default settings in some
      program.

David then told us that only about 1 in 1,000,000 IPs scanned are ever reported.

[Author's note]
Having a particular interest in computer and network security, I've seen this
type of behaviour before but I was still surprised at the scale of the failure
to report.

How often are the probes successful?  David said that if you're checking your
logs, then you're probably okay.  Back to statistics ... about 8% of of
compromises are reported.

At this point, David was asked how they (AusCERT) "knew" these numbers were
accurate.  His response was "from the logs of compromised sites".  When other
(either "upstream" or "downstream") sites were contacted, note is taken of who
had been compromised and whether or not they had reported the fact.  He then
went on to emphasise that these statistics are only for Australia and that
AusCERT considers them to be very optimistic.

Okay, so who's doing the probing?  David listed a number of groups:
    - "script kiddies"
      Children (as young as pre-teens) who have a point-and-click program and
      they get a '#' prompt at the end of the process.  They have no idea what
      it is they've done or what they now have access to.
    - "chat room groupies" 
      People who use ICQ or IRC (or whatever) and like to wage war over
      something said in a chat-room.
    - "suits"
      Those who are deliberately (and professionally) engaged in this type of
      action (can you say "corporate espionage"?).
    - Broken devices and programs, or devices and programs with bad default
      settings.
      As David indicated, we've all seen print servers or SNMP agents which
      like to "discover" the entire Internet address space.
    - Governments attacking other governments.
      All that was said on this point was, "yes, we've seen it happen".

So, why don't people report these probes when they happen?  The reasons given
were:
    - too much effort
    - so many
    - don't know what to do about them
    - we don't look at the logs
    - what's the point?
    - somebody else will

Okay, given all those "perfectly valid" reasons, why should network probes be
reported?
    - It lets other sites know; they may have been compromised as nobody is
      going to try breaking into a site from their own.  This may be how you
      discover you've been compromised!
    - No-one else will (just read the previous list!).
    - Was it just your site?  You don't know if it was part of a larger scan.
      If the source site gets 20 reports from 20 different sites, they're far
      more likely to take it seriously than if they only get one.
    - It may be something new, meaning you may be the first to  have detected
      it.
    - Tracing back allows cleanup of other affected sites.
    - It may help in a legal case.  A large number of reports destroys the "I
      did it by accident" defence.
    - It may help agencies get funding or other resources to deal with this type
      of crime.

How can these probes be detected?  Obviously, through firewall and system logs.
Also, check logs for things like "TCP wrappers" (e.g. tcpd, tcp_wrapper).  David
then stressed the need to keep your logs synchronised and your various sytems'
times accurate.  Then, combining some of your logs when analysing them may
highlight attacks you weren't aware of.  The example David gave was combining
your firewall logs with your sendmail logs ... if you suddenly see mail failures
one minute after noting a probe in your firewall logs, some kind of attack was
made.  He also pointed out that automated checking can be very useful,
particularly if you have large logs.

So you've decided to report a probe; how do you go about?
The first thing David stressed was to contact the right person.  Also, be polite
when dealing with them.  Remember that they may be madly running around trying
to clean up a compromised system (consider how you'd be feeling if you were in
their situation).  Provide them with clear and concise data, complete with your
time zone and the date of the probe (as they may not get around to handling your
query for a couple of days).  Also, provide them with contact information so
that they can check this isn't just a hoax "call".  Finally, you could partially
automate the process by using a pre-generated form letter.  Or, you could go
for a fully automated system which examines your logs, and automatically fires
off an appropriate message to the site(s) concerned.

As mentioned above, it's important to contact the right person at the source
site.  But, who is that?  You could try the "standard" addresses of root,
postmaster (required by RFC 822) or abuse (required for ISPs) at the appropriate
domain.  You could also scan the relevant organisation's website as they may
have a designated security contact.  The whois database contains Technical and
Administrative Contacts for every domain.  These may be out of date but the
indicated people should know who the currently relevant person is (and how to
contact them).  Next, check the SOA field in the site's DNS as it should provide
a contact email address for network-related issues.  Finally, report it to the
CERT team in the area of the source site; they may even be able to translate for
you if necessary.

Why report it to CERT?
    - People take notice if an external organisation is making an investigation.
    - CERT sees other reports and can let a site know that this is not an
      isolated incident (again, this is more likely to induce action).
    - They have experience in this and know how to take it further.
    - They can provide more evidence and "clout" in follow-up action.
    - CERT have a larger scope of activities; they can see the "overall picture"
      and allows them the benefit of strategic planning.
    - They produce alerts and advisories to the "general populace".
    - It reduces your workload as they do the work of investigating (or "chasing
      down") the incident - but only if you're a member.
    - It makes you feel good as you're helping out.

At this point, one of the attendees asked why the advisories were so late (in
comparison to information avenues like "bugtraq").  David then described
AusCERT's need to thoroughly verify any reports made to them.  As they're a
trusted source of information, they must be seen to produce accurate synopses of
and, where possible, "cures" for the problems reported to them.  This often
requires them to deal with hardware or software vendors (for patches, upgrade
information, etc.) and this can lead to delays.

Fine, so you've decided to report a probe; how do you report it to AusCERT?
The e-mail address you should use is "probe at auscert.org.au".  When reporting
probes, David requested that you:
    - use the source's IP address rather than FQDN as it avoids the "it
      wasn't us - it's probably a spoof" response;
    - provide a separate report for each source IP address;
    - don't send your entire firewall logs in a single message, but break them
      up based on source IP address;
    - CC: the message to the offending site;
    - use a good Subject: line (e.g. avoid things like "FYI");
    - send logs in plain text (screen dumps of logs aren't too useful) and in
      English;
    - keep messages short and the most useful information at the start of each
      message (so readers don't have to wade through logs to find a synopsis of
      the situation); and
    - provide updated information if and when it becomes available.

He also asked that you indicate whether or not any of the information you have
provided can be passed on or must be kept confidential.  By default, everything
sent to AusCERT is considered confidential and won't be passed on.  However, it
may prove helpful if some parts of the information (e.g. logs with IP addresses
masked out). can be passed along to other authorities.

Now that AusCERT has your reports, what do they do with them?  The reports are
tracked and correlated (which helps in locating patterns of attack and in the
development of that strategic planning mentioned earlier).  They can then take
it further with police and other organisations both in Australia and overseas.

If you have a situation which is more serious than "just a probe", you can
e-mail the details to "auscert at auscert.org.au".  If the problem is "really
serious", you should PGP encrypt the message (AusCERT's key is available from
their website).

Now, back to the statistics.  In March 2000, almost 700 incidents were reported.
580 of these were network probes and about 50% of those indicated that sites had
been compromised.  Approximately 337 sites in Australia were compromised during
that month (or, about 11 were compromised each day).  Extrapolating from our
earlier statistics (these are only reported numbers), 580,000,000 sites were
probed during the month of March.  David pointed out that this equates to every
IP address being scanned every 4 days.

Finally, how can you protect yourself from these probes?  David gave a list of
AusCERT's "top 10" targets for March.  These were, in order:
    - portmapper
    - WWW - php, phf, etc.
    - telnet
    - NetBIOS
    - 8080 and other proxies
    - IMAP
    - POP3
    - POP2
    - TCP 3128 (Squid)
    - DNS

You should also follow these general rules:
    1.  Keep your systems and filters up-to-date.
    2.  Install a firewall and use egress filtering (to keep information inside
        your own network and to prevent you from becoming a "default-based
	prober").
    3.  Implement host-based security to provide an additional layer of
	protection between you and the attacker.
    4.  Monitor your logs and report on them.
    5.  Keep yourself up-to-date with security related issues.
    6.  Don't become complacent.

Lastly, David introduced his "rule of 9s".  If you have a firewall, you're
probably 90% secure.  If you also have host-based security, you're probably 99%
secure.  If you have also been applying system and software patches, then you're
probably 99.9% secure.  At 99.9% secure, and approximately 600 incidents per
month, you will probably have a security incident every two months.

This evening was the first in what the various WA chapter committees hope will
be a series of such seminars.  To those of you who couldn't make it to this one,
we hope to see you at a future event.



More information about the plug mailing list