as can be seen from two other question I had I am looking for a secure webserver as there where discussion at work how safe tomcat really is.
But basically what I found on the net regarding how safe it is is greek to me. So I was hoping, someone could explain to me how safe tomcat really is? Like, is it possible to mess with java-code on the server or something like this?
I know this is probabaly a dumb question, but I really can't seem to find an answer that helps me to argument that writing an own server is not more safe than using tomcat or how it might be better to use tomcat.
Maybe someone knows a good way to secure tomcat and to minimize certain functions of tomcat? (I really dunno how to else explain it ...)
I hope you can help me.
Thnx in advance!
... dg
Writing your own server? As opposed to using Tomcat? That is a classic case of reinventing the wheel and (unless you are the NSA) likely to result in a less secure server. Rhetorical question: Why not write your own OS to go with it!
Tomcat 6 is a very mature, stable, current, well understood code base that has had zillions of very, very smart people reviewing, testing it, and operating it in production for years and years.
Tomcat is very secure.
maybe before, Tomcat was pretty unsecure, but nowadays... just anything having Apache under its name is enough for me to trust it. Anyway, security was ALWAYS imagination, there is not such thing existing in real life, so there would always be factor of (in)security.
Problem with Tomcat is like problem with Windows, no matter how 'secure' they built it, if there are millions of people out using it, hackers will have interest to invest their energy (and eventually, they will success) in finding way to break into it. So maybe to feel more secure, you can consider using something not wide used, but this will not help if hacker is intentionally hacking your site for some special reason, he will find out technology you are using and in this moment - it would be better it was Tomcat..
That is why is very important to 'get married' with open-source technologies like tomcat, since there is not big chance for a hole in system to live long, people have chance to fix things, you can always do the job yourself, do not have to wait for a new version etc.
Look at the changelog and count the security issues fixed;
Look at the CVE entries for Tomcat and see how the seem to you.
But all in all, it's a really bad idea to write your own Servlet Container, especially if the Tomcat security arguments are not clear to you.
If you need boss-convincing arguments, show him the serlvet spec you need to implement, and estimate time in the order of man-years ( not kidding! ), contrasting this with the 'download,unzip,start' option of using Tomcat.
I know this is probabaly a dumb
question, but I really can't seem to
find an answer that helps me to
argument that writing an own server is
not more safe than using tomcat or how
it might be better to use tomcat.
What you have to remember is that Tomcat has 1000s of hours of people looking at code and fixing bugs and holes. Thinking about writing secure code is easy. Doing it is extremely hard. There are lots of little things that can be overlooked which can contribute to a massive hole.
Tomcat is a secure server. However, it is even more secure to use Apache Web Server to proxy it. You can use mod_proxy to connect Apache with Tomcat using AJP or HTTP protocol. This is the safest configuration and you can leverage the many plug-in modules available for Apache Http Server.
Some tips for a secure installation:
Create a user to run Tomcat. Do not use the root user.
Uninstall the example applications.
Uninstall the manager application. If you use Apache to proxy Tomcat, you can safely keep the manager and make it available only through your local network.
While I'm no hacker, I'd find it hard to imagine how Tomcat would be your first port of call if you were trying to attack a system - after all it's running your code and is presumably behind a firewall and fronting servers. If this isn't that case, then it should be!
Once the network is as secure as possible remember Tomcat is just a Servlet engine - you're gonna have trouble exploiting with http requests. I'd focus on your application code, things like user authentication and avoiding the various injection attacks - this in my mind is the highest risk to your system and will exist whatever server you're running on.
As others have already mentioned, Tomcat is ready for production use and security of Tomcat itself is certainly better than what any small team could achieve while writing their own servlet server.
That said, the probably weakest point in a Tomcat setup is commonly the setup of the underlying OS.
Related
Hey guys, I've been browsing around on SO for quite some time and can't thank everyone enough.
I've finally come to a road block after ironing out the other bugs in my code: Tomcat 6's security manager combined with Java's security is stalling me. Basically, I've written a web application (that only trusted people will have access to, so I don't need the security lecture here :-D) that needs to access a local filesystem after it's done some parsing to locate directories.
After tons of google-kung-fu and all of the " and + searching in the world, I can't find how to turn off Tomcat 6's security manager in Windows, or how to effectively neutralize it combined with forcing it to start. Using "-security" in the config gui doesn't work and I've tried adding commas and newlines to separate it from the lone "start" that's there currently.
In addition to turning it off, I learned another mistake I was making: forgetting to include the default constructor (with no parameters) for one of my serialized classes. Remember to check GWT's (somewhat quirky) rules for serialization!
I've since gone back and turned the tomcat security back on, only giving my specific application to the resources it needs.
I have a WSGI application running in PythonPaste. I've noticed that the default 'Server' header leaks a fair amount of information ("Server: PasteWSGIServer/0.5 Python/2.6").
My knee jerk reaction is to change it...but I'm curious what others think.
Is there any utility in the server header, or benefit in removing it? Should I feel uncomfortable about giving away information on my infrastructure?
Thanks
Well "Security through Obscurity" is never a best practice; your equipment should be able to maintain integrity against an attacker that has extensive knowledge of your setup (barring passwords, console access, etc). Can't really stop a DDOS or something similar, but you shouldn't have to worry about people finding out you OS version, etc.
Still, no need to give away information for free. Fudging the headers may discourage some attackers, and, in cases like this where you're running an application that may have a known exploit crop up, there are significant benefits in not advertising that you're running it.
I say change it. Internally, you shouldn't see much benefit in leaving it alone, and externally you have a chance of seeing benefits if you change it.
Given the requests I find in my log files (like requests for IIS-specific bugs in Apache logs, and I'm sure IIS server logs will show Apache-specific requests as well), there's many bots out there that don't care about any such header at all. I guess almost everything is brute force nowadays.
(And actually, as for example I've set up quite a few instances of Tomcat sitting behind IIS, I guess I would not take the headers into account either, if I were to try to hack my way into some server.)
And above all: when using free software I kind of find it appropriate to give the makers some credits in statistics.
Masking your version number is a very important security measure. You do not want to give the attacker any information about what software you are running. This security feature is available in the mod_security, the Open Source Web Application Firewall for Apache:
http://www.modsecurity.org/
Add this line to your mod_security configuration file:
SecServerSignature "IIS/6.0"
Assume you are running a pure-HTML website on Apache. Just serving static files, nothing dynamic, nothing fancy.
Also assume all passwords are safe, and no social-hacking (i.e. phishing attacks, etc...)
Can a website of this nature basically be hacked? Can the server become compromised? Are there any examples for this?
Yes, such a server can become compromised. A very common vector, sadly, is FTPing to the server over an insecure wifi connection. Anyone listening closely can pick your password out of the air. (It's fun to be at a tech conference and have your password displayed on a screen for all to see, along with the other fools that sent their credentials in the clear over wifi.)
Another common vector is using a simple password and having it fall to a dictionary attack.
Sure it can be compromised, through security flaws in Apache itself. While it's true that adding more layers (like php, sql, etc) onto the server itself increases the potential for vulnerability, nothing is infallible.
Apache, however, is a very well-known open-source program, and the community does a good job of flushing out bugs like this.
Short answer: any internet-connected device has the potential to be "hacked"
You might be curious to read an article or two about "Securing Apache 2".
It is reasonable to say it is secure, but you may want to take note that Apache does come shipped with some modules already enabled.
Also, the goal of securing Apache should not only to secure the server instance itself, but to sandbox the server in such a way that you would limit the damage any such intrusion could do.
All of this information is of course contingent on the web server being the only exposed component on the box.
Anything "hackable" about the website itself would have to be a hack in Apache itself. If so, you've got bigger problems than just one website.
So, on a practical level, nope, given the "all password files are safe" conditions.
In theory it could be hacked but in theory anything can be hacked. In practice no. Because Apache didn't had any important vulnerabilities for several years.
This question is more security related than programming related, sorry if it shouldn't be here.
I'm currently developing a web application and I'm curious as to why most websites don't mind displaying their exact server configuration in HTTP headers, like versions of Apache and PHP, with complete "mod_perl, mod_python, ..." listing and so on.
From a security point of view, I'd prefer that it would be impossible to find out if I'm running PHP on Apache, ASP.NET on IIS or even Rails on Lighttpd.
Obviously "obscurity is not security" but should I be worried at all that visitors know what version of Apache and PHP my server is running ? Is it good practice or totally unnecessary to hide this information ?
Prevailing wisdom is to remove the server ID and the version; better yet, change them to another legitimate server ID and version - that way the attacker goes off trying IIS vulnerabilities against Apache or something like that. Might as well mislead the attacker.
But honestly, there are so many other clues to go by, I wonder about whether this is worth it. I suppose it could stop attackers using a search engine to find servers with known vulnerabilities.
(Personally, I don't bother on my HTTP server, but it's written in Java and much less vulnerable to the typical kinds of attack.)
I think you usually see those headers because the systems send them by default.
I routinely remove them as they provide no real value and could, as you suggested reveal information about the server.
Hiding the information in the headers usually just slows down the lazy and ignorant villains. There are many ways to fingerprint a system.
Running nmap -O -sV against an IP will give you the OS and service versions with a fairly high degree of accuracy. The only extra info you're giving away by having your server advertise that information is which modules you have loaded.
It seems that some of the answers are missing an obvious advantage of turning off the headers.
Yes, you all are right; turning of the headers (and the statusline present e.g. at directory listings) does not stop an attacker from finding out what software you use.
However, turning this information off prevents malware which uses google to look for vulnerable systems from finding you.
tldr: Don't use it as a (or even as THE) security-measure, but as a measure to drive away unwanted traffic.
I normally turn off Apache's long header version information with ServerTokens; it adds nothing useful.
One point which nobody has picked up on, is it looks like better security to a prospective client, pen testing company etc, if you're giving out less information from your web server.
So giving less information out boosts the perceived security (i.e. it shows you have actually thought about it and done something)
A very well known major drawback of using CGI is poor webserver performance. But how secure are CGI (mainly C/C++) based applications? Are there any major security holes in CGI architecture built on C/C++?
I would like to know some real life implementations of CGI based web apps/web sites. One that I know of is javaranch.com.
The major security hole I would see anywhere, C/C++ included, would be not using a standard, open CGI library, not reading its documentation, and thinking you're secure anyway.
don't re-invent the wheel. Use a CGI library. Some languages have this built-in (PHP probably does), others have it included (Perl comes to mind), others need you to grab it from elsewhere (C/C++). Make sure you know what it is, and that you use it. Do not try to implement it yourself. If you have to ask about security, you, like me, are not qualified to write it.
Read the documentation. If you're using a well-established library, there will be documentation on security issues and what you can do to avoid them.
Do not ever assume you're secure. I'm quite sure I'm not secure, even though I've followed all the rules in the CGI library for Perl, and the rules in the database interface library, etc. But I still assume I'm not secure, and keep it on the forefront of my mind when doing anything there. Should I ever be an expert on security, maybe I'll change my assumption. Not sure yet.
Security is always multi-faceted, and always incomplete. There are holes being found in all sorts of software all the time - software that may have been previously thought secure. And now we have many more best-practices for security than we did, say, 15 years ago. And we have SELinux for more security.
Of course, the question is - do you have enough security for your app? Does a reasonable effort get you a reasonable level of security? Of course, that's why I don't use C/C++, but I use Perl instead. It takes a lot less effort to ensure I don't overwrite memory in Perl than it does in C++. That's a level of security right there with no actual work involved.
CGI is no more insecure than any other WSAPI. It's all about what the program does with the code. All CGI does is set environment variables and handles off to the program.
Many sites are CGI based. Many PHP sites that are located on hosting are run in CGI mode - mod_php is hard to used in shared environment - no suid.
In general, running as CGI has lower performance, but better for security - you have no access to webserver internals (as with mod_perl and mod_php) so using vulnerabilities is harder. If you use cgi-bin, you non-execute files are not visible (a common bug of PHP programmers is that they have libraries with extension like .inc so source is shown when this file is requested directly).
Perl's taint-checking mode provides a marvelous way to increase security.