Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Search | Test
Home » Learning Curve

Safety Rules

The Internet's no good if it's dangerous but acting as if it isn't is stupid.


  • There is no such thing as too much paranoia.

    Paranoia is good. It keeps you on your toes. But your exercise in paranoia becomes self-defeating when you need too much time to nurture it.

  • The safety of your operating system is inversely proportional to the time you need to be paranoid about its use.

    With platforms like Windows you could devote all your time to being paranoid and still not be safe. Look at all the sites out there with long lists of suspect files and so forth.

    With Windows you have to continually check thousands of files to make sure you're not compromised. Obviously using Windows is self-defeating. And even if you had a team of security experts working on your kitchen table box day and night you wouldn't be safe.

    With OS X it's becoming like that too and already today the careful OS X user has to devote time to being paranoid. This is not a good sign.

  • If your OS vendor are out to get you, you're sunk anyway.

    Within reason you must accept and trust what you're sent or given by your operating system vendor. If what you have on disk with your new turnkey system is evil, you're really in trouble.

    But beyond that, trust no one.

  • If they're out to get you, they want your password.

    Few compromises work without a password. Full control of your box is what the bad guys are after. They want information. If they have your password they can get that information.

  • It's not a game - it's dirty business.

    Worms and trojans and viruses are not pranks: they're a concerted effort to compromise you and steal something from you. The innocent days when 'malicious' software didn't do any real damage are forever gone.

  • If you can build it yourself, do it.

    If you can inspect each and every line of code in every kernel module and program before building it then of course you're going to be a lot safer. But don't forget the co-father of Unix Ken Thompson was able to hide a trojan in the source code to the C compiler that no one ever found. You're safer but never 100% safe. You still have to be paranoid.

  • Track your software and web sessions.

    Use a tool like Tracker. Do this for all software and software installers. You don't have to do this every time you run a program, but you should do it the first time or times you do.

  • When running an installer or testing a program for the first time - disconnect from the Internet.

    You might trap a bad guy trying something devious if you're still connected, but don't take a chance. Check your logs for evidence the target program did in fact try to 'phone home'.

  • When running OS X be sure to check /Library regularly.

    /Library is an Achilles heel on OS X and there is no guarantee you've seen the end of the holes yet. The directory and its subdirectories have to be secure. If you're running Jaguar or Panther, use the scripts available elsewhere at this site to secure these directories. And even with Tiger you should check them regularly to be sure nothing has loosened them up.

    Rogue code that is able to penetrate /Library may very well compromise your machine.

  • Use an adequate file manager.

    On Windows use X-file and on OS X use Xfile or the equivalent. On Windows there is no alternative; on OS X there might be, but you have to be aware of what you need and what you don't need.

    On OS X you need full access to all Unix and HFS file information. Xfile is about the only file manager for the platform that gives you all this. You need to see all attributes and extended attributes, ownerships, resource forks, and 'Finder info' fields. Most alternative file managers for OS X do not even begin to offer you this information.

    Although you could in theory do most of this from the command line, it's hardly practical: your exercise in paranoia would become too time-consuming and therefore self-defeating.

  • Beware 'installers'.

    Ideally you want to be able to inspect a software package yourself and move everything into place on your own. If you're not capable of a couple of click and drag operations to get your software running, maybe you'd better go back to basket weaving or picking your nose.

  • Check 'linkage'.

    On OS X this is easy: drop to a command line in the executable's directory and run otool -L on the executable. Of course you need a file manager that lets you drill down inside bundles like that - and preferably pop open Terminal windows in the same directory - but you're not going to get that help from your OS X vendor. See above.

  • Check 'strings'.

    On OS X this is again easy: while you're still at that command line run Xstrings or strings on the executable.

  • Check the forums.

    You'll not only find info on products you'll want to use, you'll get evidence of security holes in your system. Don't rely on your OS vendor to protect you.

  • Run CLIX's 'leakd' script regularly.

    This script scours your system for a half dozen classic Unix file system holes and also looks for a few unique to HFS. If you have SUID root files - you should know why. If you have world writable files - consider yourself in trouble. And so forth.

  • Check /Library on startup.

    Automate this with a script. Even better a CLIX script. Do it again every time something significant happens to your box like a software install.

  • Check /Library on reboot and shutdown.

    A perfect way for malware to enter your OS X system is to sneak something in there right before you restart or shutdown. A logout hook will run as root and can compromise your entire machine and open Pandora's Box all over again.

  • Install third party software in your own home area.

    Unless you really know what you're doing, stay away from /Applications. Distance yourself from that directory as much as you would /System/Library. Look who owns those files.

  • Create a CD with static linked system tools.

    Note you will have to do this yourself: the tools you need will be supplied with dynamic links. You need the source code to these tools and you need to build them yourself.

    Following is a list of what you should have. You need these in the event you suspect you have a rootkit installed on your system.

    dd      df       du    file    finger
    grep    login    ls    lsof    netstat
    ps      sh       su    top     w
  • Archive your system time stamps.

    Again, this is important if ever you suspect you have a rootkit. But you have to do this now, before something bad happens.

    Run the following commands from at least your most important directories (such as /private) and save them on the same CD as above.

    ls -aciloR >> ctimes.rtx; ls -ailoR >> mtimes.rtx; ls -ailoRu >> atimes.rtx

  • Check who's logged in.

    Use commands like the following.

    finger      users
    who -TuH    who -TuH /var/run/utmp
  • Check where your logs are.

    Read the file /etc/syslog.conf to locate them.

    % cat /etc/syslog.conf
    *.err;kern.*;auth.notice;authpriv,remoteauth.none;mail.crit             /dev/console
    *.notice;*.info;authpriv,remoteauth,ftp.none;kern.debug;mail.crit       /var/log/system.log
    
    # Send messages normally sent to the console also to the serial port.
    # To stop messages from being sent out the serial port, comment out this line.
    #*.err;kern.*;auth.notice;authpriv,remoteauth.none;mail.crit            /dev/tty.serial
    
    # The authpriv log file should be restricted access; the
    # messages shouldn't go to terminals or publicly-readable
    # files.
    authpriv.*;remoteauth.crit                              /var/log/secure.log
    
    lpr.info                                                /var/log/lpr.log
    mail.*                                                  /var/log/mail.log
    ftp.*                                                   /var/log/ftp.log
    netinfo.err                                             /var/log/netinfo.log
    
    *.emerg                                                 *
  • Archive message digests on critical files offline.

    Use MD or md5 on at least the following files: df, du, find, ftp, halt, ifconfig, login, ls, netstat, passwd, ps, reboot, shutdown, ssh, su, sync, telnet.

  • Use strong passwords.

    Make sure your passwords stand up as long as possible to a dictionary attack.

  • Run that firewall.

    Don't have a single port open if you can help it.

  • Disable the root account.

    You can do this easily in NetInfo Manager. If the root password is not '*', make it so - do it now.

  • Never allow remote root login access.

    Don't spend time enumerating all the reasons you supposedly need this - just don't do it - not for any reason.

    If remote root login is enabled - and especially if the name of the root account is still 'root', you've effectively halved the time the bad guys will need to crack into your system. Permitting remote root login is one of the dumbest things a Unix user can ever do.

  • Don't listen to the fanboys.

    The fanboys aren't interested in protecting their systems - only in protecting their fearless leader. They're going to play down any news of potential security holes because the thought they may not be secure scares them shitless. They can't handle paranoia. They panic.

    Read what's written at sites other than the ones fanboys frequent to get your daily dose of paranoia. Sift through this information for what's essential to you. You're far more likely to avert catastrophe if you do.

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.