Lately I was reading a fair amount of articles/web reports on various security issues. As it appears, there really is no web site at this point that could claim to be 100% hacker proof. On the one hand, you see all those unfortunate web masters using at least a few of the Mattís Perl scripts that are known to be somewhat buggy and hence insecure as also proven by the authors of the NMS project here. On the other hand, you get a handful of hardware associated security holes. Of course, there are various means to avoid those by installing proper firewall servers, disabling application features known to contain a number of easily exploitable bugs and etc. The task of safeguarding oneís server that is directly accessible by the Internet public seems to me a much harder undertaking.

Although one could never remain assured that his/her web site/server is completely impenetrable, Iím wondering what are the steps undertaken to make this monastery secure, for example? Sure we all are aware of the common techniques to shield our Perl cgi scripts from random hacker pranks, by making use of the taint feature, filtering user input for any embedded scripts that could run havoc on an unsuspecting clientís machine (especially crucial for sites such as this), and probably controlling who runs your cgi scripts (via the HTTP_REFERER string) amongst a number of other measures. You can read more on CGI security here or here.

Aside from CGI, thereís a great chance of having one of your server side scripts/daemons jeopardized or exploited. Iíve used a number of security scanners on a couple of servers of mine and was amazed at the results. On one occasion I was pointed in the direction of an FTP daemon/server that allowed anonymous access. At my previous company (a small start up), I recall seeing our main server hacked and exploited by a rookie (nearly inapt script kiddie) simply by playing with either our ftp server or telnet! Also, at my current job (a fairly large company), we had a number of intrusions. Some of the things to watch out for are listed here:

  • Anonymous FTP access.
    It is generally recommended to disable anonymous FTP access if it is not needed badly. Anonymous FTP access can allow an intruder to gain crucial information about your system that can possibly help him/her gain access/control of your system.

  • Running a version of FTP server application that has a number of known bugs.
    For example, running NcFTPd version < 2.6.2 opens you to a possibility of this attack.

  • Running Telnet. I always go for just SSH and dump Telnet altogether. The problem with Telnet is that it sends all user names, passwords, and data unencrypted. So, even after successful login (meaning no one noticed how you got into the system) a malicious hacker can eaves drop on any communication taking place between the client (your box) and the server (telnet).

  • Automatic remote process execution.

This list is by far not complete. I would be interested to learn about your experiences as related to server/CGI security. Have you ever had any of your Perl CGI scripts compromised? What about any of your server side scripts? What steps are you taking and would suggest to me/other monks to safeguard your/their system?

Thanks for your participation in this discussion! ;)

Update: oops, I forgot to use the &lt; in place of raw <, which 'deleted' a couple words from my original text. Sorry about that ;).

# Under Construction

Replies are listed 'Best First'.
Re: Security matters: keep thy doors closed!
by cjf (Parson) on Jun 14, 2002 at 14:40 UTC
      Oops, I actually realized that my use of 'hacker' in place of the proper term 'cracker' would be subject to ridicule ;-). I recall now that I too had a significant fight (friendly) with a friend of mine over his misuse of the word 'hacker'. And how could I miss it now myself! rofl. I agree that the proper word to use is 'cracker' after all. However, isn't 'cracker' = 'malicious hacker'?

      Thanks a million for your reply, cjf. It is (not surprisingly) thorough and to the point. I'll take some time to go over the links you've provided here.

      # Under Construction
        However, isn't 'cracker' = 'malicious hacker'?

        The exact definition of a cracker as provided by the jargon file is "One who breaks security on a system." However it also notes that a hacker is, among other things, "A person who enjoys exploring the details of programmable systems and how to stretch their capabilities."

        It's easy to see how the two definitions can overlap. If I break the security of a system which I am authorized to perform a security audit on, which am I? This isn't a very important difference, the main distinction is more or less based on legality (although there are several exceptions).

        This may all sound very trivial, it's just a word right? Consider if in a year the major media outlets started using the term "programmer" to refer to computer criminals. Why change the meaning of a word because some reporters don't know what they're talking about?

      You are indeed correct in your Yet Another Update; the source is available to pmdevils and gods, and patches can be submitted by pmdevils, but only applied by gods.

      I thought this was a bad thing (see my bigest XP sink, Let the doors open Wide), but have since reconsidered -- reading the changelogs and seeing the number of security bugs fixed since then makes me belive that opening the source to randoms would increase greatly the risk of being hacked by trolls.

      We are using here a powerful strategy of synthesis: wishful thinking. -- The Wizard Book

      If systems were secure people like us wouldn't have jobs. So maybe MS isn't such a bad company the keep the IT sector booming with new security jobs(chasing the wild goose).


      Learn patience, you must.
      Young PerlMonk, craves Not these things.
      Use the source Luke.
        So maybe MS isn't such a bad company the keep the IT sector booming with new security jobs

        If Microsoft went out of business (something that will happen soon after the insurance companies get their act together) there would be just as many, if not more security jobs.

        This is partially due to the growth rate of the security industry, and partially due to the fact that a poorly configured Linux/BSD/whatever system is at least as vulnerable as a well maintained Microsoft system. Individual system security is also only a small part of the industry.

Re: Security matters: keep thy doors closed!
by FoxtrotUniform (Prior) on Jun 14, 2002 at 15:33 UTC

    merlyn started an excellent thread on writing secure Perl code here.

    Two things that really ought to be considered when securing a box:

    1. Follow your software. You don't necessarily have to follow BUGTRAQ (although it's a damn good idea), but if you don't at least check for security patches every week for your OS and daemons, you're in trouble. The Code Red worm proliferated as widely and as quickly as it did mostly because systems weren't being patched to close the hole it exploited.

      Of course, very few of us have the time to constantly monitor software for available patches and upgrades, evaluate any patches that come along, and install the useful ones in a timely manner. That's where our favourite system-administration language (no, not ksh!) comes along. Some clever work with Mail::Audit can pull interesting-looking BUGTRAQ messages out of the noise for your attention, and a weekly cron job to check the status of your favourite packages from the FreeBSD Ports tree (or Freshmeat, or whatever) can at least spare you the burden of remembering to do it by hand. (When I get a few dozen round tuits, I'll finish and post my stuff.)

    2. If you're running an MTA, ferglubsakes make sure that your box isn't an open relay. Open relay abuse isn't as sexy a computer crime as your bog-standard remote root exploit (or VBscript worm), but it is an attack: someone's using your box without your authorization to do (very impolite) things you didn't intend it to do. Make sure your MTA's locked down, and nobody's going to have to blacklist you.

    Update: Oh, and flame, flame for using the deprecated sense of hacker.

    Update 2: So merlyn didn't provide any concrete, spelled-out "this is a common problem, this is how you solve it" examples in that node, but IMAO the "design for security" mindset is at least an order of magnitude more important than a cookbook approach based on checking off a list of common vulnerabilities. That said, the thread as a whole is more useful than merlyn's node taken by itself -- not the least thanks to cjf's response -- so I've changed the wording a bit.

    The hell with paco, vote for Erudil!

      I wish following BUGTRAQ was a 'damn good idea', but currently I don't see the point in doing so.
      1. BUGTRAQ is a moderated list.
      2. CERT, SANS and others coordinates all advisories with the authors of the missbehaving package and all big Linux distributions. And together they decide when to release the advisory.

      From my point of view (sysadm) this s**cks.

      Anyone remember an advisory about Wu-FTPD six months ago. IIRC Redhat published there advisory as soon as they had a fix, and the other distributors and CERT(?) accused Redhat of not following the rules regarding how advisories should be published.

      I am not interested in the upgraded package, I want to know when someone find a exploitable security bug.
      If there is a security bug in some vital piece of software, like apache or ssh, maybe the right thing to do is shut the service down. But since we want be telled that the bug exist until RedHat/Mdk/Caldera etc etc etc all have updated package, we have production system with exploitable holes.

      Regarding the Perlmonks code: Doesn't the Perlmonks community hold all the best perl hackers on the planet?
      If the code could not stand the audit from it's own community, then maybe it's time to throw old things out, do it all over again and do it right (Flame, flame :) )
      merlyn has an excellent node on writing secure Perl CGI scripts here.

      Did you get the link right? You are talking about web site design, or lack thereof right? No offense to merlyn, but that node doesn't exactly provide any information about security. I certainly wouldn't call it an "excellent node on writing secure Perl CGI scripts."

      See my reply further down in the thread for more on that.

      Update in response to above: :-)

(wil) Re: Security matters: keep thy doors closed!
by wil (Priest) on Jun 14, 2002 at 17:07 UTC
    You raise some very good and very important points here. But one very big security threat that keeps getting overlooked is - your users.

    Either knowingly, or unwittingly, many of your system users are a very real threat to the security of the machine. From the most extreme simple things like; do they write down their passwords on a big postit note by their computer? Do they remember to log off at all? Do they tinker around and write their own CGI applications on your system without you knowing? And does this CGI program that you don't know about run Matt's Free Guestbook for everyone in Sales? Does the MD allow her 15 year old hacker son to play around on the laptop from home?

    IBM are running a good ad campaign at the moment highlighting this fact. They say something along the lines of "You've turned off all your unused ports and services. You've got the best firewall going but are you protected from Rose in Accounts?"

    Physical security is as paramount as virtual/connection security. Is your box locked under key? Do you have 24/7 surveillance on the box by cameras, anti-tamper devices? etc. Of course, how far you want to take this depends on how much you value your data.

    I just think these are highly important points people should be more aware of, and I constantly strive to bring these points further up our security agenda in work.

    Update: kudos to cjf for reminding me of the name of the woman in Accounts - Rose. :)

    - wil
Re: Security matters: keep thy doors closed!
by scottstef (Curate) on Jun 14, 2002 at 14:46 UTC
    You bring up some very good points. The only secure box is a turned off one with no connections. Most of the cracks that do happen fall into the category of what I call preventable. By this i mean if a patch had ben applied, or unneccessary services had been turned off, you would have prevented the attack. You mention a good point with telnet. IIRC was defaced like that. Most of the attacks that occur are the results of someone that read about some kewl haxor trick and ran numerous scans to find the needle in the haystack that was vulnerable. (see any apache server's logs around the time of code red).

    A few points that i stress to my coworkers- have only minimal services on each box. I hate to build a mail/web/ftp server on one machine. It creates way more headaches for me. Hardware is cheap enough now that I would rather build three seperate servers for public usage (if they do break in, it is easier to take one down than lose all three). I really do not belive in ftp for anything other than anonymous access. secure copy is a better option for me. All of my servers run email servers that are tightly configured to allow email usage for administrative usages only. Taking simple common sense steps can protect you. It may not be enough to prevent a determined hacker, but there is not a whole lot that can.

    "The social dynamics of the net are a direct consequence of the fact that nobody has yet developed a Remote Strangulation Protocol." -- Larry Wall

      Not to be pedantic or anything, but a box that is turned off with no connections can still be stolen, so it doesn't even stop there.
      The thing to remember is that the box doesn't have to be 100% secure, it just needs to look like a less appealing target than the neighbors'. (and all that'll do is reduce, not stop the problems)

        cjf beat me to the punch. These days, any script kiddie can fetch a suite of tools and start compromosing systems without having even a remote clue of what they're doing.

        Also remember that a cracker looking to add drones to his swarm for a staged attack (DDoS, putting an MTA on your box to use you as a spam relay, etc) does not care about the individual systems at all.

        Times have changed. Nowadays, your mere existence makes you an appealing target. (See Honeynet projects et al.)

        Makeshifts last the longest.

        The thing to remember is that the box doesn't have to be 100% secure, it just needs to look like a less appealing target than the neighbors'.

        The "I don't have to run faster than the Lion, only faster than you" idea doesn't apply in situation where practically anyone can automatically compromise thousands of systems a minute.

Re: Security matters: keep thy doors closed!
by Maclir (Curate) on Jun 14, 2002 at 19:19 UTC
    A good general principal with security is to start from the premise "everything is proibited except that which I explicitly allow". This starts with your server. Whatservices does it run? The default stuff in inetd, straight out of the box?

    We built our own firewall at the place that I use to work - there were two old Sun Sparcstation 10s (or 2s or some antique Sun hardware from the early 1990s) Each had on the motherboard an ISND port, which matched our (then) internet connection.

    We installed Solaris 2.6.1 (I think), then went through all the rc.d scripts brutally. There were only three TCP/IP daemons running - apache, DNS and sendmail. Lots of controls on those to limit who could connect to them.

    So, if your server physically cannot run may services that could pose a vulnerability, you are a few steps closer to a secure system.

Re: Security matters: keep thy doors closed!
by crazyinsomniac (Prior) on Jun 14, 2002 at 23:03 UTC
Re: Security matters: keep thy doors closed!
by Aristotle (Chancellor) on Jun 15, 2002 at 03:01 UTC

    One thing I'd like to mention is that I consider FTP useless for anything but anonymous access, for the same reason Telnet is - they're both unencrypted protocols.

    There are also a handful of FTP daemons that have been written explicitly for anonymous access exclusively and will present very little if any vulnerability. (The one I'm thinking (but don't remember the name) of doesn't contain a single file write call in the entire source, runs chrooted and drops root priviledges as soon as it has a connection before it reads a single byte from the connection.)

    Even so, making FTP work poses numerous problems to a firewall due to the way the protocol is set up, with the separation between data and control connections. It really is time to let this dinosaur die.

    Makeshifts last the longest.

      ...The one I'm thinking of (but don't remember the name)...

      There's probably a lot of these- it could be pureftpd that you're thinking of (or it could be something else!)

      From their splash page:

      Pure-FTPd is actively supported, and it was always designed with security in mind, and the code is always re-audited as new kind of vulnerabilities are discussed. Unlike other popular FTP servers, the number of root exploits found since the very first released version is zero.

      setenv EXINIT 'set noai ts=2'

        No actually, while pureftpd is good, it wasn't what I meant. This daemon had anon-something or other in its name and didn't facilitate any other than anonymous logins at all. It was explicitly written to run anon-FTP servers only with an absolute minimum amount of code. Can probably be found via freshmeat..

        Makeshifts last the longest.

Physcial Security
by gumby (Scribe) on Jun 15, 2002 at 19:00 UTC
    I would argue that physical security should be you're foremost consideration. I remember watching a rather amusing documentary a little while ago (British TV) following a kind of 'freelance' cracker. He described how one of the best sources of passwords and other sensitive information was the unmonitored garbage cans. In one scene he literally casually walked in(!!!) to an office building, laptop and equipment in hand, sat down in an office and began running packet sniffers etc.

    After concluding his business, he walked out (at no point during his 30-or-so-minute stay was he confronted by a member of staff) and phoned the head office up to tell them what he had just been doing, and suggested they had a security problem.

    Update: Oh, and if you want more example's of complete ineptitude when it comes to security matters, just take a look at the countless blunders attributed to the UK government...

Re: Security matters: keep thy doors closed!
by stefp (Vicar) on Jun 15, 2002 at 09:33 UTC
    You should run anything potentially insecure in a tigtht jail. jail helps you to correctly use chroot().

    -- stefp -- check out TeXmacs wiki

Re: Security matters: keep thy doors closed!
by hatter (Pilgrim) on Jun 17, 2002 at 15:37 UTC
    While people are talking about general security issues, I'd just like to drop in a link to the human firewall project which has lots of good info on making non-geeks aware of their role in keeping systems, networks and data secure.

    the hatter