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."
In a nutshell... (Score:1)
Run Linux 2.0.36. Don't run Linux 2.2 (c.f. DOS attack and filesystem corruption in 2.2.4and5)
Too bad its a PDF. (Score:1)
security level+file immutable flags, chroot (Score:1)
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.
chroot:
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)
executable code (Score:2)
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)
Since you asked about other combos... (Score:2)
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:
http://hacke.infinit.se/docs/rules.html
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.
Re:protecting apache (Score:2)
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
An of course whatever anyone else has to say. I hope this helps.
What about home crackers? (Score:2)
Another solution: VMWare (Score:2)
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.
Re: A game? (Score:2)
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?
*BSD already have something similar... (Score:2)
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,
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
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
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 http://www.freebsd.org/~jkb/howto.html
Linux Administrators Security Guide (Score:3)
-Kurt Seifried
Re:Methods for assuring uncrackablity (Score:3)
'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).
Block all at Firewall and use ProxyIP (Score:3)
Also put the Deception Tool Kit [all.net] 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.
DO NOT DENY ICMP!! (Score:3)
Denying all ICMP breaks path MTU discovery and will cause weird random TCP behavior across the internet. Read the FAQs.
Heres what you should do. (Score:4)
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..
A cracker's opionion (Score:5)
Re:Hacking??? You mean Cracking I think. (Score:1)
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...
Re:security level+file immutable flags, chroot (Score:1)
But with a high enough securelevel, even root can't poke around in
Re:setUID ? (Score:1)
---
Re:setUID ? (Score:1)
find / -perm +4000
---
Secure Distribution (Score:2)
Re:A cracker's opionion (Score:1)
Re:A cracker's opionion (Score:1)
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.
finding suid programs (Score:2)
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.
We're talking cracking, not "hacking" here (Score:1)
Re:example : AppleShare IP (Score:1)
Why cracking contests prove little (Score:1)
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 [counterpane.com].
Combinations (Score:2)
Re:Linux Administrators Security Guide (Score:1)
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.
Re:Securing Linux/OBSD (Score:1)
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.
I'll take this reply to scream suEXEC! (Score:1)
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 me...it'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
Ports are how people get into your system... (Score:2)
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.
Re:What about home crackers? (Score:2)
another combination (Score:1)
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.
Stay off the beaten path... (Score:1)
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.
Re:Times-a-changin (Score:1)
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.
Re:Freedom of speech==freedom to hear (Score:1)
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.
Re:Heres what you should do. (last step flawed) (Score:2)
Re:I guess someone found a hole (Score:1)
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 mixdown.org 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.
Re:DO Deny ICMP (Score:1)
get a decent firewall if you want security. don't deny ICMP just because you don't know how to protect your system properly.
securing apache (Score:3)
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 (10.0.0.0/8, 192.168.0.0/16, 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 mixdown.org [mixdown.org] 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.
Andrew
Re:securing apache (Score:1)
General Linux (and unix) security links (Score:4)
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:
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 [geek-girl.com].
It's Debian GNU/Linux, please (Score:1)
That said, when someone, like Debian, chooses the GNU/Linux name over just plain Linux, I think that choice should be respected.
Methods for assuring uncrackablity (Score:4)
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
http://doxpara.netpedia.net
Once you pull the pin, Mr. Grenade is no longer your friend.
golden rules for unix box admin (Score:1)
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
Re:Linux security checklist for the Pilot? (Score:2)
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
Another reason "crackers" is overused (Score:2)
Of course, if the shoe fits...
J.
Don't DENY... BLOCK ICMP (Score:1)
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.
find(1) is your friend. (Score:1)
Re:why inetd? (Score:1)
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.
Re:General Linux (and unix) security links (Score:2)
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!
Re:A cracker's opionion (Score:2)
"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.
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
Jason.
more alternatives (Score:3)
StackGuardk Guard
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.
http://www.cse.ogi.edu/DISC/projects/immunix/Stac
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.
http://www.tapr.org/tapr/html/Fcfa.html
Virtual-Services-HOWTO
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.
And...
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.
protecting apache (Score:1)
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.
setUID ? (Score:1)
Slackware? (Score:1)
Uncrackability - Set disks to R/O in hardware (Score:1)
Re:DO NOT DENY ICMP!! (Score:3)
is titled "Requirements for Internet Hosts"
Re:Securing OS/400? (Score:1)
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.
chroot (Score:1)
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.
Experience and redundance. (Score:3)
Regardless, one would be best off using FreeBSD [freebsd.org]; 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 - dbaker@cuckoo.com - dbaker@distributed.net
newroot/chroot? (Score:1)
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.
who remembers chattr? (-: (Score:2)
You might like to put a few favourite cracker recipe scripts in
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"
I guarantee hours of entertainment watching the script kiddies smacking their heads against the wall!
Re:Write-only firmware enforced . . . (Score:2)
Re:Port shell game - Security by obscurity (Score:1)
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.
Re:Your sig (Score:1)
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.
Re:Checklist (Score:1)
Checklist (Score:5)
* 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
* 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
* 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;
* Run a logwatcher which will filter your logs and mail suspicious entries to you. Abacus logwatcher is good. (http://www.psionic.com/abacus/) 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)
* BUGTRAQ
* Common sense.
Re:Another solution: VMWare:The Kiss off (Score:1)
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
Linux security checklist for the Pilot? (Score:1)
-----
Re:Linux security checklist for the Pilot? (Score:1)
-----
Doh. (Score:1)
Reasons for needing to login then su. (Score:2)
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.
Re:example : AppleShare IP (Score:2)
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.
--
Re:secure the OS+webserver. (Score:2)
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.
--
Re:Securing OS/400? (Score:2)
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 (Score:1)
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!
Re:Methods for assuring uncrackablity (Score:2)
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).
The ultimate in security (Score:1)
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.
-josh
Re:example : AppleShare IP (Score:1)
Re:protecting apache (Score:1)
Re:Times-a-changin (Score:1)
>as to
>Cracking into FBI site
try:
Cracking the FBI site
this sounds better.
Write-only firmware enforced . . . (Score:1)
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.
Re:R*services, SSH, and CGI (Score:1)
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...
Re:inetd? (Score:1)
Re:Reasons for needing to login then su. (Score:1)
Re:inetd? (Score:1)
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.
Re:R*services, SSH, and CGI (Score:1)
Why not ask Kit Knox?
Re:Too bad its a PDF. - go get acroread (Score:1)
-----
aryeh
Re:notice what the guy asked (Score:1)
http://www.tuxedo.org/~esr/jargon/
Securing Linux/OBSD (Score:4)
First off, do the obvious things like removing EVERYTHING you don't absolutely need from
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: www.false.com). 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.
Re:Checklist (Score:2)
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.
links (Score:2)
http://www.networkice.com/advice/OS/UNIX/
(Yahoo-ish format, but links are much better reviewed and more relavent).
Times-a-changin (Score:2)
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.
e.g.
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
example : AppleShare IP (Score:3)
Freedom of speech==freedom to hear (Score:2)
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.
R*services, SSH, and CGI (Score:2)
secure the OS+webserver. (Score:3)
That's Silly (Score:2)
There are adequate ways to secure a web site without doing this.