[Fedora] Seeing input on Securing the Linux system from intrusions and attacks.

Tod Merley todbot88 at gmail.com
Mon Dec 31 02:55:08 UTC 2007


On Dec 29, 2007 11:08 PM, John Summerfield
<debian at herakles.homelinux.org> wrote:
> Tod Merley wrote:
> > On Dec 29, 2007 2:43 PM, John Summerfield <debian at herakles.homelinux.org> wrote:
> >> Tod Merley wrote:
> >>> On Dec 27, 2007 11:10 AM, Daniel B. Thurman <dant at cdkkt.com> wrote:
> >>>> I have finally got my F8 setup and running so now I am reviewing the
> >>>> security issues that needs to be taken into account.
> >
> >>>> I would like to focus on securing Fedora ..against intrusions and attacks..
> >>>>
> >>>> Thanks!
> >>> Hi  Daniel B. Thurman!
> >>>
> >>> It is late so topics only for tonight:
> >>>
> >>> 1. Turn off services you do not use.
> >>> 2. Make your computer "silent" to all but those who use it - e.g. turn
> >>> off ping - e.g. use a door knock protocol on a non-standard port for
> >>> ssh to access ssh (give no reply to those who knock on the normal port
> >>> and respond to only your special "knock" on your non-standard port),
> >> imv turning off ping is highly overrated, and introduces management
> >> problems.
> >>
> >> My technique that I've already posted all-but prevents password scans.
> >>
> >
> > But why let them know where you are in the first place???
>
> I run a mail server, finding me is no great difficulty.
>
> >
> >>> 3. Have a constant background scan done for virus, root kit, e-mail,
> >>> changes in critical files, port scan, log  files (logwatch), and
> >>> audits for suspicious activity.  This can and should be "niced" to not
> >>> interfere with normal operations.
> >> One can't really trust a computer to diagnose itself.
> >>
> > I do agree!
> >
> > Yet why not use those "brains" on the machine that are uncompromised
> > to see that we are compromised so we can start to do something about
> > it?
> >
> > Thanks for the pointer though.  I have considered containing all of
> > the on box security in a virtual machine (well, most of it anyway).
> > As well, why not have a separate box do the file scans, log checking,
> > etc...?
> >>> 4. Google "pen testing".  C/o osstmm.
> >>> 5. Honey pots!
> >> Really! They may be useful for detecting the ungodly, but they do
> >> nothing to add to one's security. Quite the reverse, you must assume
> >> that the ungodly have a nest in your midst.
> >>
> > Do not soldiers train with live ammo?  Do you find out if something is
> > waterproof by exposing it to sunlight?
>
> They don't generally invite the opposition into the camp, and that's
> what you propose.
>
I think you respond here to a comment that I meant to support
penetration testing.  I regret that I was misunderstanding your last
post.

Your guidance concerning honey pots is welcome.  What I am becoming
aware of is that indeed our networks are filled with them.  Every
computer on your network contains "honey" someone wants to get to.  I
suppose what I really want are better tools to prevent and detect and
respond to infection.

I did come up with one possibly useful idea while thinking about this.
 I think I would like to see our computers report suspicious activity
(attempts to access ports for services we do not use - port scans -
etc,,) to a central clearing house.  Perhaps each state could have a
site with a server farm dedicated to obtaining and processing data of
this nature which would then forward the processed results to a
national server.  Perhaps the national server could coordinate a trace
process designed to find the actual source which coordinates the
suspicious activity.  I would like to find "bot" controllers.  Maybe
this could become part of how.

I suppose the response of the enemy to this would be to DOS it with
false reports and other attacks.  This could be mitigated and used to
enhance the process by spreading the server IPs across several ranges,
coordinating the times which messages are to be sent by specific
computers to those IPs and detecting the bots by either that they send
at a wrong time or do not use the secret protocol as they were
instructed by the server at a previous time.
> >
> > I have noted with interest that Penetration Testing has become an
> > expected part of any good security audit.  I believe it is not only
> > expected, it is practically required.
>
> The trouble one needs to take to implement security depends on what one
> has to protect.
>
> the first step is to choose software that is and will be properly
> supported into the future, and that means _not_ Fedora. There are
> hardened Linux disros around, and there are NetBSD and OpenBSD:
> ---
> NetBSD is a free, secure, and highly portable Unix-like Open Source
> operating system available for many platforms, from large-scale server
> systems to powerful desktop systems to handheld and embedded devices.
> ---
> Only two remote holes in the default install, in more than 10 years!
>
>   The OpenBSD project produces a FREE, multi-platform 4.4BSD-based
> UNIX-like operating system. Our efforts emphasize portability,
> standardization, correctness, proactive security and integrated
> cryptography. OpenBSD supports binary emulation of most programs from
> SVR4 (Solaris), FreeBSD, Linux, BSD/OS, SunOS and HP-UX.
> ---
>
> In contrast:
> Fedora is a Linux-based operating system that showcases the latest in
> free and open source software.
>
> and I note that RH doesn't highlight security at all, that's I could
> find in three clicks.
>
In fairness Windows gets hit most because it is most popular.
Similarly RH gets hit most because it is most popular.  Same with
Ubuntu.
>
> >
> > I would rather find out that my car leaks in my driveway with a water
> > hose than tragically on the highway!  Any day!  That way I find the
> > leak in a way I can clean it up.
> >
> > Honey pots are more of a risk I would agree.  Containment is a real
> > issue since the goal of many exploiters is to use your machine to
> > spread their wares.  I guess I am hoping that the containment issues
> > can be resolved so we can have them as a tool to see what got in -
> > what it was and how it grows - hopefully to be able to go and deal
> > with it's progenitor.
>
> You will never find out who got into anything but the honeypot, by
> looking at the honeypot. Nor is one likely to highlight the viruses and
> trojans your users download in their web content and email.
>
> If there's a place for a honeypot in aiding security (and having
> considered it for some years I doubt it), it's in an organisation with a
> well-trained security team with the resources to set one up, isolate it
> from the rest of the organisation, and monitor it.
>
> It's not for a relative beginner who's just installed his first Linux
> box and us confused about all the attacks he sees.
>
I suppose what I would really like to see is an intelligent "action
watcher" which would notice  malicious activity and start yelling
about it.  I guess I should not call it a "honey pot" in the classic
sense meaning a computer designed to be hacked (no security).  I am
thinking of one whose security is set up as the computers in it's area
are set up.  The fact that no one should be accessing it is the first
and very telling clue.  It would have e-mail accounts which are
mentioned in the address lists on several other computers.  If it ever
gets any mail we know where it's address is mentioned and so know
where to look next.
>
> >>> 6. Backup your "used" areas often and in a number of different ways.
> >>> I use flash drives, CDs, and other portions of the local or remote
> >>> hard drives.  I also tend to put an occasional file in an obscure
> >>> e-mail account.  Be ready to "wipe and re-load" efficiently.  I have
> >>> played with the idea of using "ghosted" "snapshots" for this purpose
> >>> but have only taken that to the idea level. Tar is becoming a friend.
> >> flash drives are too easy to corrupt. I'm fairly careful with such
> >> things, but one of mine lost its partition table. In my case recovery
> >> was easy because I knew that copying the first sector from an identical
> >> other drive would repair it.
> >>
> > What I like about them is that they are convenient, espically for a
> > laptop.  Since they are fairly cheap what I do is always have and use
> > more than two.  Loose one, not happy with that but little loss.
>
> bank account details? SS number for Americans. Information about you
> that could lead to someone else knowing enough about you to present
> himself as you?
>
I hate in a way to admit it, but I do not use online transactions.  I
gladly receive your point if I ever do.
>
>
> >>> 7. Do planned "wipe and re-loads" several times a year.  For that
> >>> matter, if you simply save your used areas and then wipe and load the
> >>> new version of your distro when it comes out that is probably enough.
> >>> Be ready to restore to where you were if you need to.
> >> That will cause more grief than it is ever likely to save. If you're
> >> running a serious server, you're off the air for some time. A server
> >> that's down isn't earning you money.
> >>
> > You yourself said:
> >
> > "What you need to do depends on what you're trying to protect. If you're
> > not running any servers, then things are pretty cheesy - you only need
> > to worry about invited data (websites you visit, email you receive and
> > such)...."
> >
> > I certainly agree with the first part, but somewhere in the
> > neighborhood of some six million compromised machines out there now
> > doing the bidding of organized crime make me down right angry at the
> > second part of the statement.
>
> and reinstalling them all the time would be of limited benefit. However,
> keeping up to date with vendor fixes, using firefox and thunderbird
> instead of Internet Exploder and Lookout Express (these are mostly
> Windows boxes) _would_ help.
>
Several in this thread have testimonies to what they were forced to do
when infected with no way to cure it.  I believe we are often infected
with no way to even find it!!

Yes, we now have scanners that will detect some polymorphic viruses.
So what else will they come up with that we do not yet know about?

Certainly wipe and re-load is hard.  However, I have noted myself that
you get much better at it with practice.  Since you may have to do it
anyway, it would be good to be practiced!  It is not just about
frustrating system infection it is also about what you will eventually
need to be ready to do.

Perhaps we can agree that vendor fixes and other security upgrades
should be soon placed into a test environment and when found to be
good the configuration implemented on similar boxes in the system
quickly and in a way that can be easily and quickly replicated when
necessary.  Also, that snapshots of the data areas be taken often.

If a box is often exposed to an infectious environment,  I believe it
should be re-loaded with such approved configurations often.
> --
>
> Cheers
> John
>
>
Thanks for the discussion John, always a pleasure.  I learned much here!

Thanks again,

Tod




More information about the users mailing list