Please create an account to participate in the Slashdot moderation system


Forgot your password?
The Internet

Ask Slashdot: Securing Web Servers Against Cracking 177

Bryan Andersen asks: "I'm looking for information on securing web servers against hacking. In particular, I'm interested in securing Apache on Debian Linux and OpenBSD, but discussion on other server/OS combinations are welcome. Links to sites with good information would be greatly appreciated."
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Securing Web Servers Against Cracking

Comments Filter:
  • by Anonymous Coward

    Run Linux 2.0.36. Don't run Linux 2.2 (c.f. DOS attack and filesystem corruption in 2.2.4and5)

  • by Anonymous Coward
    Too bad its a PDF.
  • I quickly browsed the comments and haven't found anything about this:

    Kernel security levels and file flags:

    File immutable and append only flags (chflags(1)) in combination with kernel security levels add quite a bit of additional security in case a hacker gained root access.

    All *BSD* offer this, I think Linux nowaday as well, but I'm more of a BSD guy so I'm not sure. The second edition of the "holy bible of security" (Garfinkel & Spafford's wonderfull "Practical UNIX & Internet Security") says only FreeBSD, NetBSD and BSDI, but mine was printed 1996, thinks probably have changed since then.

    In case you don't know: If the kernel runs in security levels >0 even root can't change an object that's flagged "immutable". I guess, you can imagine what "append-only" means, it's usefull for logfiles.

    Managing a system using security levels is a little more complicated since you have to reboot it to single user mode from time to time. So if you need zero downtime you need two boxes.


    chrooting is well known and a must for ftp. So why not use it for web as well? You don't gain that much but it's an easy step. (The chrooted jails are not hyper secure, but surly make cracker's life harder)
  • by Anonymous Coward
    1) remove any "test" "config" etc cgi
    2) close all port you dont use/need
    3) under OpenBSD use IPFilter (look in FAQ)
    it is heavily used for firewall and can run
    on the same server + more
    4) apache comes secure pre-configured in OpenBSD
    (and installed by default of course)
    5) do syslog to another computer too for
    acces/validation etc
    (jut in case)
  • by Anonymous Coward
    A lot of folks on this forum will scoff, but if security is a prime concern, MacOS and WebStar is actually a pretty good combination. There was a contest in Sweden about two years ago that invited all comers to crack a Mac web server (denial of service didn't count, you had to change the default page). The prize was quite a few Kroners (sp?) -- the equivalent of a couple of grand $US -- and the server was set up with the default settings (no security guru came in to tweak it).

    The first contest ran for a couple of months with no one claiming the prize. A few weeks into the second round someone finally cracked it through a WebStar plugin. They don't run the contest anymore, but you can check get some info at:

    Of course, there are a few basic criticisms that every Linux user will point out:

    1) Macs are slow web servers -- basically true, unless you go the MacOS X Server/Apache route (but then you're just back to UNIX). But what exact loads do you need to support? A web server is just a delivery truck for pages -- what size truck do you need? Are your needs tractor-trailer sized or panel-van sized? Additionally, the Mac web server takes a lot less effort to set up. Depending on your technical expertise, the Mac may be less hassle for you (if the recommendation "just recompile the kernel" doesn't make you shudder, then this probably doesn't apply to you).

    2) MacOS is unstable -- *not* true. The MacOS admittedly lacks memory protection, but the OS itself is plenty stable. This is a subtle but important distinction. My Mac ran for five months as a web/database/fileserver and router with no problems. The only reason I rebooted was that I upgraded the OS to 8.6, and it has run fine since. Plenty of Mac web servers have uptimes of months or even years -- but if you do have a misbehaving app or extension you'll probably know within a week. Otherwise, it will chug merrily along.

    3) Macs don't multitask well -- kind of related to (1). Since the Mac uses cooperative multitasking, it's better off being just a server and not a server/personal workstation (response gets a little sluggish). May or may not be a factor in a given installation.

    Again, with enough expertise and advice (like above) you can make Linux/Apache plenty secure, but it never hurts to know all the options.

  • by Anonymous Coward
    Totally agree. Most things happen to the OS. i.e. the rootshell hack a while back was said to be done with just a simple sniffer and grabbed the login & passwd via not using ssh. Like most people who have suggested stuff, I would locked down the OS as much as possible. Use an independent machine that is just running ssh, httpd, and sendmail if you need email but make sure it is current and watch your relays. Use /etc/host.deny/allow, shutdown ftp to none or only appropriate users. Make sure you keep up on security updates from rootshell, OpenBSD, etc.

    If your really paranoid, rotate your logs more frequently and run cron to place the old log files in different directories/servers. Its not full proof but at least it makes the hacker make a couple of more steps to to try and cover his/her tracks. Make sure you know what daemons your running, the timestamp, and filesize. I have seen many hackers go into a server and replace a daemon with the same name but instead its a trojan . The person never knows what hit him until it is too late.

    I also use a monitoring software that looks at UDP and TCP transmissions. It is called Sentry by Abacus. It is pretty cool because if someone is scanning your ports, Sentry logs the IP down what port they tried to scan, automatically puts them into /etc/host.deny, and screws their ip route up if they ever got access to the machine.

    An of course whatever anyone else has to say. I hope this helps.
  • by Anonymous Coward
    I would like you to meet my cousin who cracks into houses. He too feels the same way. But for some strange reason people cannot seem to take a joke. They are always upset with people who break into houses and take things away. In fact, my cousin was once arrested and sentenced to five years. I hope people can learn some lessons from the online world and learn to take things a little more easy. After reading you inspirational post my cousin is thinkink of creating a code of conduct when people's homes or wallets are stolen. May be you could help him out with this. Of course I dont have any experience with this but what about the city authorities have a graffiti wall where people can go and write about thier losses. This way the home crackers too will know all about cracks in the city and this way people can send a message that says "you got me.. but wait for next round"
  • by Anonymous Coward
    I never tried it but I think that VMware [] could be used if you can afford the software, the loss of performance, and the time to configure.

    Basically you would install a FreeBSD/Linux distribution in your VM, which would be used as the server.

    With your host Linux machine, you'll use masquerade/ipchains or bridging so that your virtual machine would never be able to send or receive a single packet on your ethernet network, except going to your router. You'll also arrange that the communication between your host and your guest OS is only done with TCP/IP in the direction host -> guest.

    That way the external machines should be relatively safe from crackers. Once your installation is done, you'll just copy the image (or the HD partition) each time you boot the VM. If it is compromised, you just have to copy again and reboot the VM.

    Now the problem is to access/put data in your VM ; there are several solution:

    • Using VMWare on a standalone partition. Basically you have a raw partition image in a file on your Linux host machine, that you mount with loopback, and can change freely. When you're done with your changes you just do a 'cat mypartition.ext2 > /dev/hda4' and run VMWare on /dev/hda4. When you want to access log files you stop the VM and then either copy /dev/hda4 for archival purpose or mount it and retrieve log files for instance, before erasing it the next time. You can have twice the same partition so that you could run VMware, say either on /dev/hda3, /dev/hda4 while you're examining or copying the other partition (you rotate partitions).
    • Mounting your guest OS partition in your Linux host. That way you'd be able to change files from your Linux OS. The problem might be that the cracked guest can try to exploit actively bugs in the NFS/samba client of your guest OS, by sending him crap (that's why mounting the partition of a stopped guest OS is more secure ; although you'd need to force an e2fsck first). You must be careful to never execute programs on your guest mounted partition though.
    • You can write scripts that wait on some TCP/IP port of your guest, for your host OS (alone) to send a tar archive that they would extract. A similar protocol could be used to retrieve files (or with a networked backup software running in your guest).
    Note that the major advantage of VMware, compared to buying another box, is that even if your machine is compromised, it won't be able to snoop your Ethernet (if your host is properly configured), which is a bad bad thing. The equivalent alternative to VMware is to run a standalone machine alone on its own ethernet segment, and to arrange to have a boot disk that transferate the whole system from another machine. And even then you'd need to be careful that your machine won't be able to crack your router at the other end of the ethernet segement.

    Also the ability to run to several VMs on copies of the same partition/image or different images, is the source of a number of fun tricks.

    The nice thing about VMware is that once you have set a distribution you are able to copy it everywhere. As crackers don't seem to grow up and as security models of most used systems are staying poor (Unix/Windows), I expect some commercial plug-and-play products "webserver in a virtual machine" to appear for servers that are expected to have a low load.

  • by Anonymous Coward
    Sure, almost all criminal activities have perpetrators who try to rationalize their behavior as being "just a game". If their victims don't see it that way, well, that's just more evidence of how much the victims deserved whatever they got, right? In fact, all forms of hostile behavior have people who use this excuse. "Hey, I was just having a little fun..." is pretty much the motto of the predatory, antisocial loser.

    An actual game, for those who lack the requisite social skills to figure it out, is something that all participants choose to participate in, voluntarily, for their own (and perhaps others') entertainment. There are no involuntary participants in a game.

    If you have the brainpower for cracking, then why don't you ponder that concept until you comprehend it?

  • by Anonymous Coward
    BSD kernel has a notion of securelevel. While some argue that it is not as perfect as it could be, it will do the job
    most of the time to stop your average "script kiddiez". Securelevel is simply the level with which your kernel runs -
    each level implementing different protections and checks. This description is taken from the init(8) man page:

    The kernel runs with four different levels of security. Any superuser
    process can raise the security level, but only init can lower it. The
    security levels are:

    -1 Permanently insecure mode - always run the system in level 0 mode.

    0 Insecure mode - immutable and append-only flags may be turned off.
    All devices may be read or written subject to their permissions.

    1 Secure mode - the system immutable and system append-only flags may
    not be turned off; disks for mounted filesystems, /dev/mem, and
    /dev/kmem may not be opened for writing.

    2 Highly secure mode - same as secure mode, plus disks may not be
    opened for writing (except by mount(2)) whether mounted or not.
    This level precludes tampering with filesystems by unmounting them,
    but also inhibits running newfs(8) while the system is multi-user.

    If the security level is initially -1, then init leaves it unchanged.
    Otherwise, init arranges to run the system in level 0 mode while single
    user and in level 1 mode while multiuser. If level 2 mode is desired
    while running multiuser, it can be set while single user, e.g., in the
    startup script /etc/rc, using sysctl(8).

    For example, if all your system does is web serving, you can safely set your securelevel to 2. However, if you are
    running an X server, setting your securelevel to 1 or higher will give you problems because X server needs to
    open /dev/mem and /dev/kmem for writing, and securelevel of 1 prevents doing so. One way around this is to set
    your securelevel after you start your X server, but IMHO if you are running X server you already have other
    security issues to worry about then kernel securelevel.

    - from
  • by Anonymous Coward on Tuesday June 01, 1999 @03:32PM (#1871162)
    the LASG is available here [], a free 150+ page document on securing Linux.

    -Kurt Seifried
  • by Anonymous Coward on Tuesday June 01, 1999 @04:17PM (#1871163)
    Many SCSI hard drives have a write protect jumper. This will have the same effect as a CD, but be a lot less obvious to the potential cracker, especially to one who isn't top notch in the clue department.

    'course, who knows what sort of undocumented SCSI mode changes can be done to your average modern drive. There might be a back door to re-enable writes.

    At the end of the day, of course, everything you do is just one more hurdle and makes it that much less likely you get broken into; you cannot make a system perfectly secure without pulling all the plugs (and maybe that won't even be enough).
  • by Anonymous Coward on Tuesday June 01, 1999 @05:16PM (#1871164)
    Use Linux IP Port Forwarding [] on your HTTP ports from the firewall to the servers. The servers will have different IP addresses and attacks will have trouble getting out of the server, particularly if they are non-Internet IP addresses.

    Also put the Deception Tool Kit [] on an old machine, preferably in a DMZ, and let the script kiddies think you're running a single machine and that it behaves differently than it really does. They have time to waste, so let them waste more time.

  • by Anonymous Coward on Tuesday June 01, 1999 @06:02PM (#1871165)
    I will personally come to your house and cut your damn head off if you DENY all ICMP or ever tell anyone else to do the same!

    Denying all ICMP breaks path MTU discovery and will cause weird random TCP behavior across the internet. Read the FAQs.
  • by Anonymous Coward on Tuesday June 01, 1999 @06:25PM (#1871166)
    Use a modern os that uses packages (Redhat/Debian)
    Be on switched ethernet
    Unplug from network
    Install OS but with only needed packages.
    Turn off all services.
    Use MD5 shadowed passwords.
    Get stackguard.
    Compile all CGI's & SSH & Apache w/ stackguard.
    Get a recent kernel and Solar Designers no-stack patch.
    Configure no root logon (even in ssh).
    Configure SSH to deny by default
    Config SSH to only accept connected from good places.
    Start SSH and Apache services
    ipchain default deny all incoming
    ipchain allow ICMP
    ipchain allow incoming on port 80
    ipchain allow incoming on ssh
    ipchain deny outgoing w/ low source if possible (check proc for the lowest auto port (dont have linux handy))
    Remove all system utils you are sure you dont need, use find to scan for SUID files and remove all SUID you do not HAVE to have (even things like ping and such).
    Go through the system and remove write permission from most files (anything you can).
    Set the ext2 immutible flag on system and other static files.
    Setup remote syslogging to a box with nothing more then console access (little 386 or sumpting).
    Install tripwire (with cron to check and all, set to email and page)
    Backup frequently.
    Pray to approiate 'force'.
    Plug into network.
    Subscribe to cert/bugtrack/etc.
    Install security updates for everything you have installed, when they come out.
    Use SCP to upload content.
    If comprimised nuke it, get content (no scripts or bins!) from backup. Goto step 1 and try harder..
  • by Anonymous Coward on Tuesday June 01, 1999 @03:32PM (#1871167)
    I have cracked/hacked many a web server. Most if not all allowed us to exploit poorly configured mahines or applications. A good admin will beat us everytime.. but most places wont pay for a good admin. The hardest computers to crack are the ones limited to the least ammount of accesss they allow. So.. if you dont use it..dont run it. IE if your not using a ftp server why allow ftp access? why not turn off the deamon.. then sshd to move files. Its secure.. and will close all the hundreds of ftpd exploits. Now some would say that a good firewall rule will solve this.. but as I have beaten many a fire wall why not just shut down the stuff your not going to need. This applies to just about every deamon you can think of.. if you dont need it, kill it. Now after that some good firewall rules wont hurt. If this is only going to be a web server then I would only allow your web server port.. firewall with a seperate machine.. then only run your webdeamon. If you need other access allow other machines to do that for you.. your web sever is the big juicy target. Owning a ftp server is all nice and good but If i dont need the space / bandwidth then I really wont bother. Warez kiddies wont even bother to own a system so many ftp server allow anon access that its just funny.. why waste the time on something you can get for free. Really the kernel or OS that you use doesnt really matter.. its how well you configure it.. Its no harder to root/crack a Misconfigured OpenBSD/debian/Irix/winNT/or any other OS. You will see attempts.. but with good backups you should be off line for only a few hours. If you do get hacked make sure that you follow the code of ethics.. most hackers/crackers wont destroy more than they need to get their message up.. So for not killing your file system you should give copies of all the hacked files to so that they can mirror it. They will get it anyways but its like saying " you got me.. but wait for next round"
  • That's all good and well, but people have to start accepting the fact that the mainstream media has embraced the word hacker as a term for malicious hackers, ie crackers.

    That's nice and all, but if the general public started refering to arsonists as "firemen" don't you think the fire fighters would be a little upset about this? Lots of people in the general public also refer to hard disk space as "memory". Just because the general public says one thing doesn't mean that we have to accept it.

    Knowing the difference between "Hacker" and "Cracker" is a sign of knowladge... Othewise you simply come across as some script kiddie.

    More when I get to work...

  • Hmm... I didn't know that there was a means for the kernel to forbid "chattr". But I'm sure this is far enough ; you can do everything you want if you are root, by peeking/poking in /dev/mem, or /dev/hda(or maybe even /proc/kcore).

    But with a high enough securelevel, even root can't poke around in /dev/mem, or any of the raw disk devices....
  • How do you get the list of all programs that are setUID (root)? I know what it means, but the only one I know of is passwd. find / -perm +4000


  • How do you get the list of all programs that are setUID (root)? I know what it means, but the only one I know of is passwd.

    find / -perm +4000


  • Kha0s Linux [] is an attempt to create a VERY secure version of Linux. Currently it is in development. Look around. . .
  • Good usefull info here. Sure, a lot if it is already know, but confirmation from the other side always helps:)

    So for not killing your file system you should give copies of all the hacked files to so that they can mirror it. They will get it anyways but its like saying " you got me.. but wait for next round"
    I didn't even know there was a code of ethics (as such) to these things. So done properly (???) cracking and being cracked is really just an elaborate game. Cool (sort of), but I don't intend on participating (other than possibly saying "you got me" when appropriate).
  • Thanks for that, it was an interesting story.

    However, I'm ambivalent about my own comment as I don't endorse cracking, nor approve, but I can see how it can be a game under the right circumstances.

  • If you want to find any suid program:

    find / -perm -04000 -print

    Or if you're only interested in suid root programs:

    find / -perm -04000 -user root -print

    This will include directories and non-executable files, which may not be a bad thing.

  • That aside, I would suggest that you run only the services on your system that are absolutely necessary for your application.
  • Reminds me of an article I read somewhere that said Macs made the best web servers. The reasoning was that since they had practically no functionality as servers, it would be hard to exploit them. Not putting down Macs (never used one), just thought it was funny at the time and this reminded me of it.
  • Cracking contests prove little. For a start they are usually rigged heavily in favour of the vendor, probably use closed systems and they generally target the wrong threat group.

    The last point bears expanding: When you offer $10k to "crack a webserver" you are attracting amateurs. The people who you should be really worried about have a vested interest in your continuing belief that a system is secure, this belief can be worth far more that a one-off payment of $10k.

    An excellent treatment of this topic can be found in Uber-cryptographer Bruce Schneier's excellent Cryptogram newsletter [].
  • Well, for starters, don't run Linux 2.2.x or Windows NT. Both are really buggy, and you probably don't want filesystem corruption or a bunch of gaping wide holes in your kernel. OpenBSD, Linux 2.0.36, VMS, or the latest version of Solaris are all good choices.
  • Posted by d106ene5:

    Dump the lame encrypted PDF Kurt.

    Ever heard of the web? Its an innovative way to securely distribute documents - you should check it out!

    You've only succeeded in limiting your audience.
  • Posted by d106ene5:

    The only port that anyone can connect to should be 80.

    How do you suggest we upload files onto the machine? Log into it?

    You need to keep port 22 open for ssh.
  • Posted by Brendan Byrd/SineSwiper:

    If you are a web hosting service and you don't use suEXEC, you are an idiot! Now, if you haven't heard about it before, that's fine. But, if you are reading this message and you haven't already read through the Apache info on it and drawn up a battle plan to implement it, you should shut down your web hosting service and leave it to the pros.

    For one, I'm sick and tired of getting e-mails about directories that get created by my Perl scripts and they have an owner of nobody because some dumbass forgot to setup suEXEC on their hosting service.

    Believe's not hard to do. I'll write a FAQ/HOWTO on it some day.

    Brendan Byrd AKA SineSwiper
    Computer techie, PERL master, and all-purpose Internet guru
  • Posted by d106ene5:

    So keep them closed unless absolutely necessary.

    Port 80 - http
    Port 22 - ssh

    Of course there is more to it than this - secure CGI, for example... but at a base minimum you should seal off ports.
  • --Data is real enough when you LOSE it, you stupid AC! Having backups isn't quite 100% consolation for the feeling you get after you've been VIOLATED.
  • openBSD seems good. havent tried it yet.
    also, if your web serving needs are simple,
    use tinyhttpd. less hassel, and less load.

    if you do use linux, i also find 2.0.36 to work
    better than 2.2.x for such things.
  • If you read BUGTRAQ & similar lists, it quickly becomes apparent that many vulnerable systems just have insecure defaults. You can take advantage of the average script kiddie's inability to adapt to unusual operating systems by running something a little different. Instead of Linux on intel, why not run one of the BSDs (esp. OpenBSD) or something even more exotic (e.g. OS/2, VMS, BeOS). If you run a webserver, consider something other than Apache or at least heavily check the config files. (repeat for every other necessary server daemon)

    Please - don't think I'm advocating security by obscurity as that isn't my intent at all. I just think that anyone attacking one of my servers should have to do a little more than download the latest exploit script. Even a simple file path/name modification is beyond an amazing number of script monkeys.

  • In the latter Apple][ days (When the PC was soon to be available), a hacker was someone who could (amongst other things) create a patch to change a game or remove the protection on it (and often found it more fun than playing the game), and a cracker was someone who applied those patches (following excruciatingly detailed instructions) in order to get free games (or sell copies to others) and proclaimed his/her own greatness for doing it.

    In other words, what we once called crackers are now script kiddies, and what was once a hacker who broke into systems (particularly if they alter the system once in) is now a cracker.

  • Social Workers Party

    I'm always amused by this name, since none of them have done a days work in their lives. They're the party of parasites, who live off the effort of the workers.

  • If you're using tripwire correctly, you should be able to restore from backup without worrying about rogue binaries & scripts. One of the reasons for doing full system backups is to get the system "BACK UP" with very little down time. Reinstalling your binaries & scripts can take a long time. Of course, if you're using FreeBSD, it's easy to keep track of previously installed ports and reinstall them from source in a matter of hours. If you're using Linux (not my forte) I guess you could reinstall bins from SRPMs and the such. Don't forget that some people admin machines that are thousands of miles away. Popping the CD back in and reinstalling isn't usually an option.
  • nope. doesn't resove sometimes. I can't figure it out. half the servers I query see me just fine, other's don't. Nearness (hop wise) isn't a factor. Servers in Cali see me just as easily as servers in Boston. Haven't tried overseas ones though.

    Looking through the logs, it looks like my name server wasn't able to connect to itself, a problem we sometimes see but haven't been able to resolve.

    The domain is set up identically to the dozen other virtualhosts I run on that machine, but mixdown is the only one which has named problems (www.mixdown doesn't work, but mixdown does and vice versa). they *all* have problems with the name server not connecting to itself from time to time. This is all BIND 8.
  • why not just deny TCP while you're at it? if you want a site on the internet, do it right. Don't bitch and whine that you want your site accessable and then don't play by the rules.

    get a decent firewall if you want security. don't deny ICMP just because you don't know how to protect your system properly.
  • by tzanger ( 1575 ) on Tuesday June 01, 1999 @03:26PM (#1871192) Homepage
    Start with the basics: remove any modules you are NOT using. Be careful with your CGI useage. Make sure they don't get executed anywhere any user can write to.

    Use ipchains to deny incoming packets that come in from outside interfaces with local network IPs. That includes denying traffic from your IP when it comes in from eth0. Block all the "private" ips (,, etc.) which are coming in on outside IPs. That will stop most spoofs which rely on your system trusting itself dead in their tracks.

    I run my little knowledgebase at [] and while the knowledgebase itself is not secure (anyone can read, write and edit articles), I feel the underlying system is quite secure. When I get the database stuff more functional, I'll tighten up access.

    I'd appreciate anyone who finds holes to mail [mailto] me. Also, if you want to screw around with the database a little, go ahead. :-)

  • You can do that with rpfilter in the 2.2 kernels, you don't need ipchains.
  • by Troels Arvin ( 1850 ) on Tuesday June 01, 1999 @04:03PM (#1871194) Homepage

    Use shadow passwords. That way, a malicious web writer can't grab the encrypted passwords and try to break them. It's easy: "pwconv" is the (only) command to run if your system is relatively modern (this may be somewhat specific to the Linux implementation of the shadow password system?).

    If you need to protect the users from each other, you might consider:

    • Using Apache's suexec [] system. However, some people say that the system is so complex that there is risk of actually decreasing security due to misunderstandings; your milage may vary.
    • If you use PHP, consider running it in 'safe mode'

    Some general purpose Linux/unix related security links:

    Finally: Keep your system up-to-date with the latest official patches. Consider joining the BugTraq mailing list [].

  • Now, I'm not a GNU/Linux vs. Linux zealot, though I do think that recognition of the standard-bearer of free software ideals is warranted when it comes to Linux.

    That said, when someone, like Debian, chooses the GNU/Linux name over just plain Linux, I think that choice should be respected.
  • by Effugas ( 2378 ) on Tuesday June 01, 1999 @04:00PM (#1871196) Homepage
    If you don't want a site hacked, *period*, I suggest you consider a CD-R based server. Let all development occur on, well, development machines, burn a copy of the static site, and have the dynamic material imported in from a backend database.

    Lets see how easy it is to hack a server where not even *root* can modify the configuration files.

    I'm still waiting for an entire Linux distribution I can boot off a CD-ROM using either a floppy drive or a web site to cache settings. It'll be significantly easier to deal with these CD Lockboxes once the various kernel configs for a semi slow medium serving mechanism are developed.

    There will be a few issues with switchovers under a CD-ROM system, incidentally. Updates are no longer a matter of FTPing; it's more along the lines of using Fake(beautiful app) to have two identical servers doing failover for eachother.

    Fairness dictates I remind the reader that, no, this isn't 100% effective--a remote root compromiser might still be able to link into the running(but binary non-modifiable) process and somehow redirect some pointer mechanisms to manipulate what files are distributed on the website, but that's orders of magnitude more difficult than echo "THIS SITE SUX" > index.html .

    Keep in mind, if you have a backend writable database it's going to be the next target. Intrusion detection on high, keptain.

    Email me or visit my site if you want to discuss all this stuff further. If you have experience with ARP/ICMP spoofing attacks, I need you to read something I'm in the process of putting together. Ahhhhh yes, I'm geeking out on security as of late. (Can you tell?)

    Yours Truly,

    Dan Kaminsky
    DoxPara Research

    Once you pull the pin, Mr. Grenade is no longer your friend.
  • wrt to the above comment, here's some things u can do...
    • turn off initd

    • compile and run ssl
      dont run services u dont need
      seek and research all setUID programs
      read lots and lots of documentation

    got these from a unix admin site...just rabbiting them off my palm, memo-list, hack :)
  • not that i can find but a quick look at here [] and search for 'unix'.

    or u could read and digest this forum and extract the best bits, create a checklist yrself from this forum and post it :)

    pilots are vc :)
  • It's also a ready slur for ignorant white people.

    Of course, if the shoe fits... :o>

  • I realize that many Linux user are on a budget; this advice is more for business-type users who have a T1 and some more resources.

    The poster is right about ICMP, with regards to the RPF's. Dire warnings aside, a lot of people deny ICMP and work just fine.

    A better solution is to program your choke router (that's ther router between your server(s) and the Internet) to block ICMP from passing into your network. The router can answer ICMP queries like MTU size, without exposing your server farm to cracker sniffing with ICMP.

    You can also get fancy and deny specific ICMP. For example ICMP echo is not necessary, and ICMP netmask discovery gives out information you may not want to share. Neither of these steps break any legitimate network operations.

  • You can see all the setuid binaries on your machine using something along the lines of
    find / -perm +4000
    Be warned, on a typical system that will actually come up with quite a lot...
  • why not to run inetd?

    well, take a look al /etc/inetd.conf. you can see there things like telnet, ftp, ..., echo, chargen, imap, ...
    if you are running web server you do not want this stuff so you disable it. and if you disable it, then inetd is running but doing nothing. so you disable inetd too.

  • Most modern systems come with shadow passwords enabled out of the box, although if you're running a less security-conscious system you may need to run some command like pwconv or whatever the above poster is referring to. Check your vendor's documentation for details on this issue.

    An even better solution, however, is to get rid of passwords altogether! Be even safer, still. As other posters have pointed out, the only way in to your machine should be via ssh (1.2.27) and in using ssh you'll have the opportunity to use RSA Authentication. A hacker can't crack a password that doesn't exist!
  • Several machines got cracked last year where I work. The admin before me (I replaced him as a full-time admin) simply didn't have the time to chase after this cracker and close up all the holes that were open. (In his defense, his job description involved very little administration.) He did keep at least some kind of sense of humor about it, though. He changed the motd to read something like,

    "Ssheeesh, I just don't have the time to close all the holes you crawl in through! Okay, I throw my gloves in the ring. I concede. You are a better hacker than I am an admin. Now move on to bigger and better things so we can get on with life!"

    I'm not sure what the cracker code-of-ethics says when the admin verbally concedes. :) But, in this case, the cracker defaced the motd (with a vulgar reply) and continued to wreak havoc on our systems. (The attack was definitely unprovoked. Our systems run on a small university subnet and don't have much to offer compared to larger companies' resources.)

    Things have been quiet since I came along, fortunately. The powers-that-be realized that maybe they did need a full-time administrator given all the down-time caused by this cracker.

    Just thought I'd share this anecdote ...

  • by elsanto ( 5098 ) on Wednesday June 02, 1999 @01:01AM (#1871205)

    StackGuard is a compiler approach for defending programs and systems against "stack smashing" attacks. Stack smashing attacks are the most common form of security vulnerability. Programs that have been compiled with StackGuard are largely immune to stack smashing attack. Protection requires no source code changes at all. When a vulnerability is exploited, StackGuard detects the attack in progress, raises an intrusion alert, and halts the victim program. Guard

    San Disk + IDE
    An interface board has been developed which allows a CompactFlashTM card to be used as a boot device on a PC. It takes advantage of a feature of the CompactFlashTM Card that allows it to emulate an IDE hard disk drive.

    Every network connection is made up of two IP address/port pairs. The API (Applications Program Interface) for network programming is called the Sockets API. The socket acts like an open file and by reading/writing to it you can send data over a network connection. There is a function call getsockname that will return the IP address of the local socket. Virtuald uses getsockname to determine which IP on the local machine is being accessed. Virtuald reads a config file to retrieve the directory associated with that IP. It will chroot to that directory and hand the connection off to the service. Chroot resets / or the root directory to a new point so everything higher in the directory tree is cut off from the running program. Therefore, each IP address gets their own virtual filesystem. To the network program this is transparent and the program will behave like nothing happened. Virtuald in conjunction with a program like inetd can then be used to virtualize any service.

    Personal note: using virtual services allows to separate users from *real* system accounts that maybe they will never use, so you don't have to care about dictionary attacks against root or another attacks that willcompromise all the system.

    If you use ssh, firewall support, external logs (using the serial port and an old computer), keep all important data (electronic commerce transactions, a user database, etc.) on a different computer using SSL and if you use the last, stable and secure version of your favorite applications, you will have a very robust and secure system.

  • Are you sure you want to protect apache? It would make more sense to protect the OS apache runs on. In which case lists/sites like buqtrack, l0pht, rootshell, etc. spring to mind.

    They don't actually crack apache but gain access by some means to the site it is running on just so they can leave funny looking grafity all over it.

    Also I gather that OpenBSD claims to be one of the more secure OS's out there.
  • How do you get the list of all programs that are setUID (root)? I know what it means, but the only one I know of is passwd.
  • I don't know if this would suit your purpose, but Slackware has a bootable CD distribution. I think it does require some drive space, but the bulk is on the CD. Steve
  • Why not just set the disk to "Read only"? Most decent (SCSI) drives have a jumper that allows you to make the disk "Read only" in hardware, which will give you *nearly* the same security as a CDROM. You could write the jumper up to an external switch, or even a relay controlled by some other (appropriately protected) machine.
  • by Nemesys ( 6004 ) on Tuesday June 01, 1999 @07:08PM (#1871210)
    Not only read the FAQs, read RFC1122, which IIRC
    is titled "Requirements for Internet Hosts"
  • Domino, athought it IS IBMs Baby, is still extra on most models, esp the 170e (Red Stripe) we have. The basic setup is the IBM HTTP Server for for OS/400 (quite a catchy name), but Apache is being ported as we speak.

    The Firewalling software that IBM makes, however, doesn't run on the '400 really -- It run on the Integrated Netfinity Card (formerly IPCS (formerly FSIOP)) inside a '400 box running NT. As much as a I like NT *cough*, I still think OS/400 is a bunch'a oats better.

    As for there not being any information, I've always thought in my heart of hearts that that is a strength. If "a big bad hax0r" doesnt know how to get information out of an OS/400 space, then theres nothing he can do. You're right in saying out machine is more than a dedicated server, though. It stores most of out Accounting, payroll, ledgers, etc-- But those are in OS/400 File space and most still require QSECOFR access to read.

    Oh yeah, SNA-over-twinaxial does suck. Its how IBM punishes us for not using OS/2. :)
  • by felix ( 7014 )
    It's clearly important to secure your box ...
    shut down as many services as possible, prefer ssh over telnet/ftp, is possible get users to
    pop/imap over an ssl tunnel, etc...

    But sometimes it just can't be helped, a cracker's
    going to get into your site. Through an os
    exploit, or a webserver exploit, or through some
    cgi/dynamic page goof. A really good thing to
    do in this case is to run your webservers in a
    chrooted environment, which helps a good deal
    should someone get in. They'll find themselves
    locked into a small area - the worst they can do
    is corrupt your web server data. They won't be
    able to get to your actual os.

    something good to do.
  • No matter how many books you read on security, it's typically experience that pays off in the long run. You should likely investigate hiring a UNIX admin that's been handling security for several years.

    Regardless, one would be best off using FreeBSD []; it has far fewer exploits than the slashdot-preferred Linux.

    Multiple layers of security is best for any machine; redundancy is the absolute key for security. You don't just have one level of restrictions which could be possibly exploited or tricked. For example, for ssh, restrict hosts in the sshd_config file, and compile in libwrap support, and use ipfw. By those actions alone, ssh is amazingly more secure.

    In terms of web-specific stuff, make sure to closely look over your httpd.conf to see what is available to your users. You should also make an educated decision about if you want to allow CGIs.

    Overall: Stay up to date with software versions.
    Daniel Baker - -

  • I've read that to make a web site REALLY secure,
    you should chroot your webdir, kind of like you do with anonymous FTP.

    Is there any truth to this? I just think it would be a big pain in the ass to copy over all of those perl directories and libraries... eek.
  • Get all your permissions right (e.g. kill off SUID unless the prog _really_ needs it _and_ gets run by other than root) chattr +i _everything_ that will take it, including directories. The +i bit doesn't care if you're root!

    You might like to put a few favourite cracker recipe scripts in /tmp first... or at least, scripts with the same names but that perhaps don't do _quite_ the same things...

    Then delete chattr. (-:

    You can always put in a floppy and run it from there if you want to change something.

    Also, mount as much as possible ro, nodev, noexec/nosuid and so forth, then mount a "fake" /etc over the top of the real one, with stuff like a "limited" fake fstab - and then delete umount.

    I guarantee hours of entertainment watching the script kiddies smacking their heads against the wall!
  • I think that the BIOS setting can control write access only when the BIOS is used to access the drive... so unless your running DOS on your server, I don't think this will do any good.

  • This method isn't the greatest, but if you have a secure box, this won't hurt.
    Here's the idea:

    Make the port numbers very high. Much higher than 1024, since that's as far as most port scanners go. That way, unwanted people won't know about them.
  • I have *never* in my life complained about another person's sig before, no matter how profane or crass they were. In this case I have to make an exception.

    I hope you'll seriously consider changing your sig. To make a joke out of the deaths in Colorado -- particularly while the wound is still fresh, so to speak -- is in appallingly bad taste.

    Perhaps you meant something else entirely. I can only hope so. But in view of what is an obvious interpretation of your sig for Americans, I hope you'll seriously consider using something else.

  • Whoops, shows how much I've been paying attention to that particular aspect of the security industry. Oh, well, MD5 still offer longer password lengths.
  • by Phexro ( 9814 ) on Tuesday June 01, 1999 @07:11PM (#1871220)
    Here's a quick(??) checklist:

    * Disable all the unused services. ftp, talk, biff, finger - the usual suspects. Make sure the inetd internal services (echo, chargen, discard, daytime, time) are disabled; there are some inetds that have overflow problems with these services, which will crash inetd.

    * Shadow passwords.

    * MD5 crypted passwords. Don't know if this is supported on RH, but Debian 2.0 or better does. This is a wonderful feature, it's settable in /etc/login.defs. It allows passwords longer than 8 characters (standard shadow limit), and to the best of my knowledge there are no password crackers which will crack MD5 hashed *NIX passwords. There's also lots of other fun stuff to mess with in login.defs, btw.

    * Strict firewall rules; allow only addresses that should be coming into your system (or network) in on only the interfaces configured for them. Reject anything else, and log it. Reject ports you don't use. When setting up firewall rules, use numeric IP addreses to prevent DNS spoofing attacks.

    * Make sure the line `ALL: PARANOID' is in /etc/hosts.deny - this will drop all connections from systems where the connecting ip and dns do not resolve properly; e.g. if a connect from comes in, and reverse-resolves to, but resolves to, the connection is dropped. This prevents DNS spoofing attacks.

    * Think about a chroot()'d webspace. Make sure the chroot() jail is writable only by a privledged user.

    * Never log in as root. Have a user account and use su or sudo.

    * Strong passwords.

    * Never ever perform a privledged operation (like su) over an insecure transport like telnet or rsh. ssh is your friend here.

    * Think about mounting your root partition read-only to prevent trojans. Maybe also set the ext2 immutable flag (chattr +i files) on areas which should not be modified; /bin /sbin /usr/bin /usr/sbin - etc.

    * Run a logwatcher which will filter your logs and mail suspicious entries to you. Abacus logwatcher is good. ( Set it up to page your alphapager if something funny happens. (All serious *NIX admins have alphapagers, right? right??)

    * Write an init script to alphapage you when the system changes runlevels.

    * Workstations make bad servers, and vice-versa. Don't use a server as your desktop machine.

    * Once you have a stable configuration, leave it unless you must change something. (bug etc)


    * Common sense.
  • Sometimes KISS means "keep it stupid simpleton"

    I have been seeing more and more of this with the flood of underexperienced sysadmins ("well i ran a linux box at home for a month, so I can run your company's servers")

    Simple is often not the best method, and in thwarting the attacks of the scriptkiddies and lameroids Simplicity itself is often a weapon used against the secure seeking admin.

    Byzantine methodolgoies in and of themself are not what is needed, but rather robust plans whos unravelings would require machinations and permutations of actions that only the sharper and more attentive of webwhacking minds would want to do the tango of attack with.

    KISS=Keep It Secure Smartly

    Anything else is just plain S
  • I have in my Palm V a basic checklist covering security measures for NT (rename admin, etc...), and many good ideas for Linux have been discussed. Is there a basic checklist covering Linux out there suitable for my Palm Pilot?

  • One thing that I have done now that I am home is to add a new [] channel to the Linux Security How-To. I set it to sync once a week so that way it dosen't waste time on a document that probably won't update that frequently. I will consider making a Doc file as Memoware proved to be useless except a better VI reference. And laser printers beware, I will be printing out many things here soon to hilight and use for the checklist, as I am currently setting up some new servers with SuSE 6.1.

  • by hawkfan ( 11267 )
    I meant append-only, not immutable :P
  • There are a few reasons.

    First, it keeps the ability to su restricted to a few trusted people, no matter who has the password. (root:wheel 4510)

    Second, it provides some sort of accountability, especially if your logging to a secure loghost or your logs are immutable. su will log who su'd and you know who's account was compromised / who screwed up.

    A third reason which may be less valid in most circumstances is it requires an attacker to compromise two passwords rather than just the root password.

    Just a few reasons off the top of my head.

  • Well, I don't know if the MacOS approach is so wrong -- A couple wrong decisions on a Linux or Windows NT install, and you've got an essentially open box. (What'd you expect - it's supposed to be easy!) On the other hand, if a network demon is running on MacOS it's only because you put it there.

    All of this might be mostly trival now for the individual with a dial-up connection. But I've already begun hearing about directed hack attempts (like let's see what's on the boss's computer) against people's personal workstations on Cable modems or DSL.

  • There are so many security problems with logging as root that people usually don't even report/investigate them. So you are opening yourself up to a range of things that haven't been tested/thought about by a larger group of people. Just imagine a trojan in KMail or Gimp for example.
  • You should do some digging, because there are known DOS attacks against the AS/400 (which is also probably running manufacturing production or the accounting system or something much more critical than your webserver). A newer AS/400 might come with Lotus Domino, so you would need tighten that up as well. IBM and others make firewalling software for the 400, which you probably should look into (if there isn't something like ipchains built-in).

    I know some folks who have put their 400 on the Internet, but considering that very few have done it and there's very little public information out there, I would be exxxtreeeemly cautious about it. With UNIX (or NT to a lesser extent) you at least have a base of knowlegable people who understand networking and security that you can draw on. Many of the really sharp 400 guys (that I've met anyway) seem stuck in the twinax and SNA era.
  • PDF's are *not* good for online content. They are great if you want to see an accurate print-preview before you eat up a ream of paper, but they are very awkward format to use for online documentation.

    They aren't editable without expensive, proprietary tools, for one thing. Secondly, the acrobat reader is SO SLOW and most people's monitors can only display half of a page at once at a readable resolution.

    PDFs should not be the primary format for open-source related online documentation. It goes against the entire philosophy!
  • Why run off a CD-R? You'll stop -almost- as many exploits just by mounting your partitions read-only, and get to keep your speed as well. Sure, if someone achieves a root-shell they can remount, but how easy is it to achieve a root shell if you can't write the drives? I'm assuming, of course, that the other advice in this column has been followed, and the only port offering services is the http port, and (although this hasn't been mentioned) that the web-server and cgi-bins are -not- running as root.

    At that point, a crack is going to take something like an exploitable memory overrun and a kernel (or driver) bug.

    In other words, you're eliminating cracking techniques that involve any sort of file overrun to directly write to the web pages (like the one that hit id software) as well as preventing people from achieving root by putting scripts in places where cron or init or some other helpful daemon is going to come along and execute them as root. (Of course, you'd hope the web-server couldn't write to init.d or root's crontab anyway, but, for the sake of arguing with myself and because there's probably a hundred similar exploits that I haven't thought of, being that I'm not a cracker myself.)

    My point generally being that running a website from CD is going to be very expensive timewise.

    Anyway, even if you don't make everything read-only, think twice before making a partition writeable. Everything's writeable on my home box, but - that's my home box. I'm not a target. (And even so I'm probably going to redo that configuration one day, when I have the time to shuffle partitions).

  • Reach around behind your PC. Locate and identify all of the following:

    Keyboard/mouse/trackball/touchpad connector cords
    Printer connector cord
    Speaker/video out/input cords
    Monitor connector cord
    Power cords
    SCSI connector cords

    And unplug everything else.

  • I'll never forget the AppleShare IP server I worked with about a year and a half ago that died (hard hang, power cycle required to reboot) when I sent it a single normal sized ping packet. That's network stability for ya!
  • How can we expect the media to refer to people who use computers for illegal activity such as breaking into systems as crackers when we cannot seem to do this ourselves. Think People!
  • >Hacking into FBI site
    >as to
    >Cracking into FBI site


    Cracking the FBI site

    this sounds better.

  • Many a modern BIOS (eg AMI BX)can be set to allow no commits to an IDE channel from the standard configuration utility. There is no futzing with jumper shunts. Some SCSI hosts also offer this feature in firmware.
  • 1st up, decide what the machine is going to do. Is it juts gonna be a web server? kill inetd and ensure it never runs again. Is it going to be used as a NFS server? kill all NFS daemons (rpc.* is usually a good start..) Is it going to shift mail about? Kill sendmail.

    Everytime you think you have killed something portscan your computer. You'd be amazed at how some stuff just keeps on appearing from nowhere...

    Seriously, linux is pretty bad outta the box. Try OpenBSD or NetBSD for security, I'm not overly familiar with FreeBSD but I assume that's OK too. The only reason I'm saying this is that you NEVER need everything Linux distro's supply with a full install. There's 1024 priviledged ports on a machine, and linux seems to want to open every damn one...

    Don't EVER install more than you need. If you aren't going to send and recieve mail on the machine, why run or install ANY mail software. Never gonna need FTP? Why install it? This saves disk space which is alway's a bonus and also limits the number of exploitable programs.

    The simplest rule to follow is:

    1) Need it? Leave it running
    2) Know ya don't need it? Turn it off.
    3)Don't know what it is? Kill it with extreme prejudice. You'll never know what it was, but at least some 3r33t hax0r won't exploit it...

    Use SSH if ya must login. NEver create more than the bare minumum of accounts you need. Run FTP if you must for access on a mad port, a really high port which is unassigned.

    And kidz. It's not cool to break into this guy's server just because you think he doesn't know what's going on...

  • inetd spawns services as defined in /etc/inetd.conf, so if you have something like imap in it, then when inetd hears a connection on 143 it will run the associated service, eg it will run imap. Most web servers (high load at any rate) run as standalone daemon. If it's just a webby box, then you probably don't need inetd (apart from running telnetd if you are st00pid and don't like the idea of ssh.)
  • Not only those: imagine the following _extremely_ real life scenario: There's a sniffer running an machine a. b is a production machine. 1) Bob log's in remotely as root, the sniffer captures the first 512 bytes and lo and behold, knows he can log in as r00t and also has the passwd. 2)Jef logs in as jef. Checks his mail, and the su's to root. The sniffer only captured his original passwd, and not the rewt account. Sure, he can get access, but getting r00t privs is a little harder for the attacker.
  • Here's one:

    Services running from inetd are slower than their standalone counterparts.

    Try running sshd in standalone mode, and try logging in several times. Now try the same thing spawned from inetd.
  • If I remember correctly it was hacked thru ssh, but only when sshd had been compiled with kerberos support. There was loadsa confusion over it all, with IBM (I Blame Microsoft) pre-emptively releasing an advisory before the full facts were known. I think it was only the 1.2.x proggies that were affected, but don't hold me to it.

    Why not ask Kit Knox?
  • There is a pdf viewer for linux - it is called something like acroread. Seek and ye shall find.
  • Try looking up the word hacker:
  • by kijiki ( 16916 ) on Tuesday June 01, 1999 @05:25PM (#1871246) Homepage
    I'll address the Linux part first, because I know the most about that.

    First off, do the obvious things like removing EVERYTHING you don't absolutely need from /etc/inetd.conf and your rc scripts. Shadowed passwords, not allowing root login remotely (use su) and only having ssh for remote access spring to mind.
    Now, if thats still not enough, look into the firewall support. deny ICMP, and access to ssh from anything but your machine. The only port that anyone can connect to should be 80.
    Finally, if you're getting hammered by the kiddies, you might want to look into things like Solar Designer's non-executable stack patch(its called secure-linux, and I think its at: Its not perfect, but its a great extra layer to stop the formulaic attacks. Also, things like StackGuard (a hacked GCC that generates code to try to avoid buffer overruns) may be helpful. If all this isn't enough, its time to break out the heavy iron.

    Which brings us to OpenBSD. Most of the stuff I said above applys, except for instead of secure-linux, you just use StackGuard. And firewalling uses ipfilter.
    No matter what you use, you want tripwire, and be sure to keep the database and the statically linked executable, and a safe kernel, on write-protected floppies.

    CGI security i'll leave to someone more qualified than I, especially since there are many great resources on secure CGI programming techniques, and a few on secure apache CGI configuration.
    Nothing will make a box 100% secure, but every little thing you do could prevent another attack, and eventually, the cost of attacking your server exceeds whatever gain the attacker would get.
  • * MD5 crypted passwords. Don't know if this is supported on RH, but Debian 2.0 or better does. This is a wonderful feature, it's settable in /etc/login.defs. It allows passwords longer than 8 characters (standard shadow limit), and to the best of my knowledge there are no password crackers which will crack MD5 hashed *NIX passwords. There's also lots of other fun stuff to mess with in login.defs, btw.

    Crack 5 does MD5 encrypted passwords and it came out in 96 so its been out there for a while. Actually, for crack you need to follow the instructions for free/open bsd md5 passwd files, but other than that it runs perfectly well. In this respect I think the *BSD camps do have better security features since they seem to have had a lot of the security stuff linux is adding now for a while.
  • The following site has list of basic links:

    (Yahoo-ish format, but links are much better reviewed and more relavent).
  • You have to expect the media to use the word 'hackers' as it has become a defacto term for describing this activity.
    Forget about computers for a sec, hacking something sounds like you are wrecking something - destroying it. The point is either word should be able acceptable. Hacking, cracking - both words have both double meanings in my opinion. It just depends on what context it is used. The word 'cracking' describes better some types of activity, and yet 'hacking' sounds better for others.
    Hacking into FBI site
    as to
    Cracking into FBI site

    To me, 'Hacking' sounds better to describe the sentance. We all know what it is meant destructively, so who really cares?

    I remember when Amiga were everywhere, Crackers were what we now Hackers, and Hackers were those who 'hacked' to cause data loss, etc.

    Both words can be used in either way. Stop being so pedantic :P

  • by fizzz ( 30154 ) on Tuesday June 01, 1999 @04:20PM (#1871264)
    They had a contest a few years back about trying to hack into a MacOS appleshareIP web server. The contest offered 10.000$ cash to whomever could crack the system, prove it and explain the process. Anything affecting only that one machine was allowed. Downing the server was not considered a crack, content had to change. There were no winner to the first run of the contest. However, and this led to a crack on the second contest, the server was only running the web server. Nothing more. I'm not even sure CGIs were allowed... The admins would update the server through a local appletalk network. Although in the end, if I remember properly, in the second contest, about one year after the initial one, someone cracked one of the new plugins added for additional functionalities; the real http server was never cracked. I'm not trying to argue that appleshareIP is a better product, nor even a good product, this was back at the beginning of ASIP 5. The product has evolved since then and its security features may have fallen a bit. However this does show that if there's no point of entry, except the strict minimum, on your server, then there is nothing to hack... But if you're trying to run all the latest web gizmos then you shouldn't be looking at security, just good backups. Hope this helps.
  • One of the neat things about the web is that it democratizes communication. Somebody once said that freedom of the press is only for people who own one. The web is hands down the cheapest way ever invented to communicate with millions of people. Maybe the Social Workers Party can't afford to print a million copies of a manifesto and convince Barnes & Noble to carry it, but it can have its own web site. The same goes for other organizations with unpopular viewpoints (, for example).

    Freedom of speech is meaningless without the freedom to listen; freedom of the press is meaningless without the freedom to read. My beef with the hackers who take down web sites is that I no longer have access to that information. Sure, the web site can hire a consultant to lock things down, they wouldn't have the problem, but this returns publication to what it was pre-web -- a rich man's perogative. For government sites, it means that we will continue to have to pay private companies for government data (like USGS topos and sat photos) that we already own, because the feds will point to this saying it's too expensive to distribute it for free.

    When I was an MIT student, we had a hacking ethic, which was "do no harm"; in fact we often tried to leave things a little better. Safety was paramaount, and minimizing inconvenience was an important concern. A good hack should leave a smile on the victim's face. If there were an "ethical" web hack, it would (1) maintain access to the original site off the hacked site, (2) be a one off affair not a repeated attack and (3) bear no malice. For example, replacing the FBI page with an episode guide to the Untouchables, with a prominent link to the original FBI page would be a cool hack.

    I don't believe in overreacting to every incidence of cracking; lots of cracker activity is just doorknob twisting and fairly benign, and the proper reaction is to tighten up security and move on. However, DOS against a web site of an organization for political or economic purposes is evil, and the perpetrators should be busted and do hard time.

    Web site cracking the moral equivalent of smashing a printing press because it produces literature you disagree with.
  • Well first off I personally would never run any of the R*services, it seems like there is a new root remote exploit for one of them every month.As for SSH, that seems to be what everyone recommends here but wasn't that how rootshell (the script kiddie 31337 site) got hacked, through a bug in SSH? And as for CGI programming, always keep things in mind like what if someone passed ";" in their arguments to the script. ie: you call mail %1 and the arguements are " ; mail -s passwd /etc/passwd". Of course thats also a good reason to use shadowed passwords. Oh yeah and if you do any programming for the server please never use sprintf or related functions. Reading BUGTRAQ would be helpful too - if you dont want to subscribe just goto
  • check /etc/inetd.conf and comment off the usual open services e.g. telnet, ftp, popxx, shell, login. install ssh and shadow the password file (redhat 5.x never used to do that -- run pwconv and grpconv). Check your system logs daily..install an updater to check for new bugfixes automatically (you get the rpm for it). Be really paranoid -- all good sysadmins are. Ensure no login account exists except for your account and root. never login as root - always su yourself and login via ssh from a trusted machine or your own webservers console.
  • Almost any website of worth changes periodically enough that such a technique is silly.

    There are adequate ways to secure a web site without doing this.

Whenever people agree with me, I always think I must be wrong. - Oscar Wilde