Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: Security matters: keep thy doors closed!

by FoxtrotUniform (Prior)
on Jun 14, 2002 at 15:33 UTC ( #174571=note: print w/ replies, xml ) Need Help??


in reply to Security matters: keep thy doors closed!

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!
:wq


Comment on Re: Security matters: keep thy doors closed!
Re: Re: Security matters: keep thy doors closed!
by cjf (Parson) on Jun 14, 2002 at 15:45 UTC
    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: :-)

Re: Re: Security matters: keep thy doors closed!
by nacka (Friar) on Jun 15, 2002 at 11:06 UTC
    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 :) )

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://174571]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (17)
As of 2014-11-28 08:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (194 votes), past polls