399 lines
10 KiB
HTML
399 lines
10 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>What To Do During and After a Breakin</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="Linux Security HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Security Preparation (before you go on-line)"
|
|
HREF="secure-prep.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Security Sources"
|
|
HREF="sources.html"></HEAD
|
|
><BODY
|
|
CLASS="sect1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Linux Security HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="secure-prep.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="sources.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="sect1"
|
|
><H1
|
|
CLASS="sect1"
|
|
><A
|
|
NAME="after-breakin"
|
|
></A
|
|
>10. What To Do During and After a Breakin</H1
|
|
><P
|
|
> So you have followed some of the advice here (or elsewhere) and have
|
|
detected a break-in? The first thing to do is to remain calm. Hasty
|
|
actions can cause more harm than the attacker would have.
|
|
</P
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN1189"
|
|
></A
|
|
>10.1. Security Compromise Underway.</H2
|
|
><P
|
|
> Spotting a security compromise under way can be a tense
|
|
undertaking. How you react can have large consequences.
|
|
</P
|
|
><P
|
|
> If the compromise you are seeing is a physical one, odds are you have
|
|
spotted someone who has broken into your home, office or lab. You
|
|
should notify your local authorities. In a lab, you might have
|
|
spotted someone trying to open a case or reboot a machine. Depending
|
|
on your authority and procedures, you might ask them to stop, or
|
|
contact your local security people.
|
|
</P
|
|
><P
|
|
> If you have detected a local user trying to compromise your security,
|
|
the first thing to do is confirm they are in fact who you think they
|
|
are. Check the site they are logging in from. Is it the site they
|
|
normally log in from? No? Then use a non-electronic means of getting in
|
|
touch. For instance, call them on the phone or walk over to their
|
|
office/house and talk to them. If they agree that they are on, you can
|
|
ask them to explain what they were doing or tell them to cease doing
|
|
it. If they are not on, and have no idea what you are talking about,
|
|
odds are this incident requires further investigation. Look into such
|
|
incidents , and have lots of information before making any
|
|
accusations.
|
|
</P
|
|
><P
|
|
> If you have detected a network compromise, the first thing to do (if
|
|
you are able) is to disconnect your network. If they are connected via
|
|
modem, unplug the modem cable; if they are connected via Ethernet,
|
|
unplug the Ethernet cable. This will prevent them from doing any
|
|
further damage, and they will probably see it as a network problem
|
|
rather than detection.
|
|
</P
|
|
><P
|
|
> If you are unable to disconnect the network (if you have a busy site,
|
|
or you do not have physical control of your machines), the next best
|
|
step is to use something like <TT
|
|
CLASS="literal"
|
|
>tcp_wrappers</TT
|
|
> or <TT
|
|
CLASS="literal"
|
|
>ipfwadm</TT
|
|
>
|
|
to deny access from the intruder's site.
|
|
</P
|
|
><P
|
|
> If you can't deny all people from the same site as the intruder,
|
|
locking the user's account will have to do. Note that locking an
|
|
account is not an easy thing. You have to keep in mind <TT
|
|
CLASS="literal"
|
|
>.rhosts</TT
|
|
> files,
|
|
FTP access, and a host of possible backdoors.
|
|
</P
|
|
><P
|
|
> After you have done one of the above (disconnected the network, denied
|
|
access from their site, and/or disabled their account), you need to
|
|
kill all their user processes and log them off.
|
|
</P
|
|
><P
|
|
> You should monitor your site well for the next few minutes, as the
|
|
attacker will try to get back in. Perhaps using a different account,
|
|
and/or from a different network address.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect2"
|
|
><H2
|
|
CLASS="sect2"
|
|
><A
|
|
NAME="AEN1202"
|
|
></A
|
|
>10.2. Security Compromise has already happened</H2
|
|
><P
|
|
> So you have either detected a compromise that has already happened or
|
|
you have detected it and locked (hopefully) the offending attacker out
|
|
of your system. Now what?
|
|
</P
|
|
><DIV
|
|
CLASS="sect3"
|
|
><H3
|
|
CLASS="sect3"
|
|
><A
|
|
NAME="AEN1205"
|
|
></A
|
|
>10.2.1. Closing the Hole</H3
|
|
><P
|
|
> If you are able to determine what means the attacker used to get into
|
|
your system, you should try to close that hole. For instance, perhaps
|
|
you see several FTP entries just before the user logged in. Disable
|
|
the FTP service and check and see if there is an updated version, or
|
|
if any of the lists know of a fix.
|
|
</P
|
|
><P
|
|
> Check all your log files, and make a visit to your security lists and
|
|
pages and see if there are any new common exploits you can fix. You
|
|
can find Caldera security fixes at <A
|
|
HREF="http://www.caldera.com/tech-ref/security/"
|
|
TARGET="_top"
|
|
>http://www.caldera.com/tech-ref/security/</A
|
|
>. Red Hat has not
|
|
yet separated their security fixes from bug fixes, but their
|
|
distribution errata is available at <A
|
|
HREF="http://www.redhat.com/errata"
|
|
TARGET="_top"
|
|
>http://www.redhat.com/errata</A
|
|
>
|
|
</P
|
|
><P
|
|
> Debian now has a security mailing list and web page. See: <A
|
|
HREF="http://www.debian.org/security/"
|
|
TARGET="_top"
|
|
>http://www.debian.org/security/</A
|
|
> for more information.
|
|
</P
|
|
><P
|
|
> It is very likely that if one vendor has released a security update,
|
|
that most other Linux vendors will as well.
|
|
</P
|
|
><P
|
|
> There is now a Linux security auditing project. They are methodically
|
|
going through all the user-space utilities and looking for possible
|
|
security exploits and overflows. From their announcement:
|
|
</P
|
|
><P
|
|
> <SPAN
|
|
CLASS="QUOTE"
|
|
>""We are attempting a systematic audit of Linux sources with a view to
|
|
being as secure as OpenBSD. We have already uncovered (and fixed) some
|
|
problems, but more help is welcome. The list is unmoderated and also a
|
|
useful resource for general security discussions. The list address
|
|
is: security-audit@ferret.lmh.ox.ac.uk To subscribe, send a mail to:
|
|
security-audit-subscribe@ferret.lmh.ox.ac.uk""</SPAN
|
|
>
|
|
</P
|
|
><P
|
|
> If you don't lock the attacker out, they will likely be back. Not just
|
|
back on your machine, but back somewhere on your network. If they were
|
|
running a packet sniffer, odds are good they have access to other
|
|
local machines.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect3"
|
|
><H3
|
|
CLASS="sect3"
|
|
><A
|
|
NAME="AEN1218"
|
|
></A
|
|
>10.2.2. Assessing the Damage</H3
|
|
><P
|
|
> The first thing is to assess the damage. What has been compromised?
|
|
If you are running an integrity checker like <TT
|
|
CLASS="literal"
|
|
>Tripwire</TT
|
|
>, you
|
|
can use it to perform an integrity check; it should help to tell you
|
|
what has been compromised.
|
|
If not, you will have to look around at all your important data.
|
|
</P
|
|
><P
|
|
> Since Linux systems are getting easier and easier to install, you
|
|
might consider saving your config files, wiping your disk(s),
|
|
reinstalling, then restoring your user files and your
|
|
config files from backups. This will ensure that you have a new, clean system. If
|
|
you have to restore files from the compromised system, be especially
|
|
cautious of any binaries that you restore, as they may be Trojan horses
|
|
placed there by the intruder.
|
|
</P
|
|
><P
|
|
> Re-installation should be considered mandatory upon an intruder
|
|
obtaining root access. Additionally, you'd like to keep any evidence
|
|
there is, so having a spare disk in the safe may make sense.
|
|
</P
|
|
><P
|
|
> Then you have to worry about how long ago the compromise happened, and
|
|
whether the backups hold any damaged work. More on backups later.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect3"
|
|
><H3
|
|
CLASS="sect3"
|
|
><A
|
|
NAME="AEN1225"
|
|
></A
|
|
>10.2.3. Backups, Backups, Backups!</H3
|
|
><P
|
|
> Having regular backups is a godsend for security matters. If your
|
|
system is compromised, you can restore the data you need from
|
|
backups. Of course, some data is valuable to the attacker too, and they
|
|
will not only destroy it, they will steal it and have their own
|
|
copies; but at least you will still have the data.
|
|
</P
|
|
><P
|
|
> You should check several backups back into the past before restoring a
|
|
file that has been tampered with. The intruder could have compromised
|
|
your files long ago, and you could have made many successful backups
|
|
of the compromised file!
|
|
</P
|
|
><P
|
|
> Of course, there are also a raft of security concerns with
|
|
backups. Make sure you are storing them in a secure place. Know who
|
|
has access to them. (If an attacker can get your backups, they can
|
|
have access to all your data without you ever knowing it.)
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="sect3"
|
|
><H3
|
|
CLASS="sect3"
|
|
><A
|
|
NAME="AEN1230"
|
|
></A
|
|
>10.2.4. Tracking Down the Intruder.</H3
|
|
><P
|
|
> Ok, you have locked the intruder out, and recovered your system, but
|
|
you're not quite done yet. While it is unlikely that most intruders
|
|
will ever be caught, you should report the attack.
|
|
</P
|
|
><P
|
|
> You should report the attack to the admin contact at
|
|
the site from which the attacker attacked your system. You can look up this
|
|
contact with <TT
|
|
CLASS="literal"
|
|
>whois</TT
|
|
> or the Internic database. You might send them an
|
|
email with all applicable log entries and dates and times. If you
|
|
spotted anything else distinctive about your intruder, you might
|
|
mention that too. After sending the email, you should (if you are so
|
|
inclined) follow up with a phone call. If that admin in turn spots
|
|
your attacker, they might be able to talk to the admin of the site
|
|
where they are coming from and so on.
|
|
</P
|
|
><P
|
|
> Good crackers often use many intermediate systems, some (or many) of
|
|
which may not even know they have been compromised. Trying to track a
|
|
cracker back to their home system can be difficult. Being polite to
|
|
the admins you talk to can go a long way to getting help from them.
|
|
</P
|
|
><P
|
|
> You should also notify any security organizations you are a part of
|
|
(<A
|
|
HREF="http://www.cert.org/"
|
|
TARGET="_top"
|
|
>CERT</A
|
|
> or similar), as well as your Linux system vendor.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="secure-prep.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="sources.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Security Preparation (before you go on-line)</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Security Sources</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |