RE: should i bother??

From: Scot L. Harris (webid_at_cfl.rr.com)
Date: 01/13/05

  • Next message: Kevin Fries: "Re: totem in FC3"
    To: For users of Fedora Core releases <fedora-list@redhat.com>
    Date: Thu, 13 Jan 2005 11:46:37 -0500
    
    

    On Thu, 2005-01-13 at 11:02, James Mckenzie wrote:
    > Scot Harris said about shout i bother??
    > >
    > >Don't rely on a hard candy coating to keep all the hackers at bay.
    > >Harden the inside of your system whenever possible. Layered defense is
    > >always better.
    >
    > You said this so well. I always look at a patch to see if it addresses security or just to give additional capabilities or if it is a bug fix. If it is a security patch, it gets installed. Of course, this may introduce other security problems or possible problems. If it gives additional capabilities, I look to see if I can exploit those capabilities. If it is a bug fix, I look (again) to see if I use the capability that the bug fixes.
    > >

    Thanks. I did not want to spend to much time writing an entire security
    white paper so I just hit the main items.
    > >dedicated firewall--->
    > (network address translation from a public IP to a private network is always advised here)
    > You also forgot to add a network sniffer such as SNORT to keep track of who is trying to do what to your firewall

    Snort can be a little much for most people to setup. If you have the
    ability and resources it is a very good NID system to have in place.

    > >(limited ports passed through (if any)
    > Mostly on the inbound leg is where folks block. You should also block known outbound troublemakers just in case someone gets through to your private network

    You are correct. Blocking outbound ports is as important if not more
    important than blocking inbound ports. I once had a request to open
    certain outgoing ports on the firewall at work. Did some quick research
    and found that they were most likely trying to play counterstrike. The
    only other reference was the port being used for a worm. Request was
    denied. :)

    > --->firewall on server (limited services allowed through)---->
    > This is not as important as keeping up the network firewall. Also, only known outbound services should be able to talk on the network

    Which is why I recommend running a firewall on the sever also. If some
    how a program gets started that has a trojan in it it or a local user
    tries to use cheops or sniff the network the local firewall should make
    that difficult if not impossible.

    Threats on the inside of the network are actually more likely than
    threats outside your local network.

    > >disable all unneeded services------>
    > This is definately a must. If you don't have Windows file shares on your network you don't and should not have SAMBA enabled for instance. If you are not sharing Network assets between UNIX/LINUX boxes you should not be running NFS. It is quite interesting that CUPS is open to the world upon installation and I use a firewall to block its ports and restricted it to localhost only.
    > >keep system patches up to date ------>
    > This is a must. First line of defense is having a system with all know vulnerabilities closed/patched. This is how the MS Blast worm got through. The patch was released for over six months before the worm was released.
    > >run tripwire------>
    > A good idea.

    I have yet to find a better IDS package. AIDE did not seem to be mature
    enough the last time I looked at it.

    > >run chkrootkit ------->
    > Or any other root kit program. I run root kit hunter as a daily cron job.

    rkhunter is another but I have not used that one.

    > >monitor log files ---->
    > FC3 mails them to you on a daily basis. Read your root mail...

    Amazing how many people don't do this.

    > >use screen savers to lock terminal session ----->
    > Yep.
    > >use good passwords ----->
    > Strong passwords of random letters, with at least two numbers and two special characters for all accounts, definately root.

    Again it is amazing how many passwords are purely dictionary based or
    names of pets or family members. A long time ago on a Vax 11/780 I ran
    a scan against the password file and was able to come up with 75% of the
    passwords being used. My bosses included. I had told him I was doing
    the scan so it was no big surprise.

    > >change passwords ----->
    > Change them at least every three months, monthly if it is an active system. Change all passwords if a user password is 'lost'. If a user comes to you to change a password, think real hard about asking all user's to change. Definately change root's.
    > >don't use the same password on multiple systems---->
    > Never use the same password for root on several systems. Do not use an old root password for root on another system.

    Again it is amazing how many people use the same password not only on
    their servers but for web forms and what not.

    > >disable root login on ssh ----->
    > This is easy and is the default for FC3.
    > >don't use telnet or ftp
    > Never use a protocol that sends a user's password as cleartext. Use ssh/scp/sftp.
    >
    > You missed a real good security tip. Only allow those who need physical access to the server. Keep your server in a secure area behind a locked door. You would be surprized what happens. If you can, disable console logon to your server and allow only ssh logins. This is what saved a company's reputation.
    >

    That's what the shotgun and dogs are for. :)

    Yes physical security is a must. If someone has physical access to a
    system it can be broken into and root passwords changed. Or worse disk
    drives stolen or entire systems stolen. In a business setting access to
    the computer room/network rooms should be limited to very few people
    and if possible use a card access system and cameras to track who goes
    in and out.

    > >Keep shotgun handy along with several watch dogs......
    > Hmmm. This seems to be a little overboard, but both system and physical security is a must for any server system.
    >

    Paranoid is not a state of mind, it is a lifestyle. :)

    -- 
    Scot L. Harris
    webid@cfl.rr.com
    BEWARE!  People acting under the influence of human nature. 
    -- 
    fedora-list mailing list
    fedora-list@redhat.com
    To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
    

  • Next message: Kevin Fries: "Re: totem in FC3"

    Relevant Pages

    • Re: Access is denied ( to remote shared PC folder)
      ... Here are general network troubleshooting steps. ... by 1) a misconfigured firewall or overlooked firewall (including a stateful ... Create matching user accounts and passwords on all machines. ... Select a user account to automatically log on by clicking on the ...
      (microsoft.public.windows.vista.networking_sharing)
    • Re: How to remove users "only" on NIS database?
      ... In the beginning hashed passwords were in the /etc/passwd file. ... that information over the network. ... Therefore with NIS the shadow file is made available. ... won't have local root. ...
      (Debian-User)
    • Re: How secure is our server?
      ... We are currently using just Standard SBS. ... If not, you need a good, business-quality external firewall device. ... does not qualify as a network firewall. ... And, don't forget passwords. ...
      (microsoft.public.windows.server.sbs)
    • Re: Viewability of shared folders ?
      ... network that takes the most basic security precautions. ... firewall will keep attackers from the internet from accessing your ... regular password changes which should require that passwords or pass phrases ... be at least 15 characters in an environment that would need high security. ...
      (microsoft.public.win2000.security)
    • Re: Securing root?
      ... Disabling remote root logins ... I can't really see any advantage to requiring two passwords - better just to ... Remember, that since this is an attack over the network, ... "Linux Network Security", the ultimate book on protecting your network from ...
      (comp.os.linux.networking)