Half a Million Database Servers 'Have no Firewall'

An anonymous reader writes "There are nearly half a million database servers exposed on the Internet, without firewall protection according to UK-based security researcher David Litchfield."

Comments

Have i missed something?

[Alphager]

I thought letting the accessible through the public IP is the first step to separate Application-server and DB-server. DB-Server {internet} App-Server

Re:Have i missed something?

[phasm42]

Exposing it through TCP/IP is separation enough (exposure to the intranet). There's nothing to be gained by exposing it to the internet at large.

Re:Have i missed something?

[myspys]

You have.

The more logical (and secure) solution would be

{internet}
      |
app-servers
      | (internal network)
db-servers

Re:Have i missed something?

[trolltalk.com]

That's not true.

For example, you may have a stand-alone java app at multiple locations that can query the database directly, so you'd definitely open up the port.

This is just another example of "OMFG LOOK AT ME!!! I FOUND TEH SECURITY HOLE!" bullshit. Same as "your computer is broadcasting its IP address."

Not everything has to go through a bloody web server.

Their "idea" of a vulnerability was if the port was open - not if they could gain access.

Re:Have i missed something?

[MightyYar]

Wouldn't it be safer to connect to the database through a VPN or other encrypted connection (ssh, etc)? I still don't see why you'd want your database right out there on the public internet, no matter how much trust you have in the authentication... why have more points of entry than is necessary?

Re:Have i missed something?

[SatanicPuppy]

Even there, you can do a fine grained firewall to allow connections to specific other servers. I do that stuff all the time.

If you're talking more about a consumer app that talks to a database, that should be routed through ssl, etc, and well authenticated.

I do agree, however, most databases can be "exposed" without too much risk, and that risk is justifiable for certain types of applications. Lock down your high-access user accounts to local-only access, and allow authenticated connections. There is always the danger of a "Slammer" situation (I must be getting old; the number one google hit for slammer is a "gay sex club"), but if no one can access your database, then you're pretty much limited to local applications, or feeding data through multiple security levels to an exposed server, which has a high performance hit.

Re:Have i missed something?

[SCHecklerX]

This is what VPNs are for.

Re:Have i missed something?

[COMON$]

Well even if you are not handling requests through a web server, which there are some cases where this is the best option. You should do some IP restriction. In the cases where I have set up a SQL server with a port open, I restrict access to that port by only allowing MY ips to hit it. Even then just the IPs that need access, don't go overboard and allow every IP you have get to it.

I have mentioned this several times on slashdot but there is a severe lack of actual professionals in control of networks out there. I would say that there are all too many who have never even thought about security at this level, they just make sure that they have control of their users and pat themselves on their back for being able to make two servers talk across a WAN.

This all derives from the misconception that you have to be 40+ to be a seasoned professional in the business world. The IT security field is a very new one relatively, some of the best security personnel are much younger than I am but never get considered because even with 5 years experience, a degree and several certifications, they are only 24 and therefore not worthy of note. (no I am not ranting about myself, I ahve a wonderful position for someone my age, but I know many IT geeks who get passed over because of their age, although no one would ever admit it.) Get the 40 year old guy who was a sociology major and did data entry for 10 years before being asked to take over NT environments. This way you get a 'seasoned' guy because he has a few more wrinkles and that makes him a better 'fit' and definitely must make him more capable.

Re:Have i missed something?

[trolltalk.com]

Well, don't forget the story this weekend about the guy who was a 26-year-old IT professional working for an IT security company who pled guilty to using a botnet of 250,000 PCs - customer machines - to do numerous frauds.

Ethics has nothing to do with age.

My point was that the basic premise of the article - that the presence of the open port in and of itself was a sufficient metric to be able to say "OMG INSECURE" - is not valid in and of itself.

One good example - we have an app that sits on port 80. To the world it looks like a web server, but its not. Why would you run something other than a web server on port 80? Well, first, its usually open, hence accessible w/o having to change anything on the client end. We could just as easily run it on port 3306, 22, 443, or whatever, just by changing the config file.

Re:Have i missed something?

[Anonymous Coward]

This is retarded. You should not have your database traffic going unencrypted over the internet. That is a serious security flaw. You should be using a VPN.

Re:Have i missed something?

[tobiasly]

For example, you may have a stand-alone java app at multiple locations that can query the database directly, so you'd definitely open up the port.

No, at the very least I would use IP-based rules to restrict access to all but the hosts running the java app. It's a technique known as defense in depth. You never rely on a single point of failure, such as the authentication system of your database server, to protect yourself.

Re:Have i missed something?

[plague3106]

I don't understand why everyone says to use VPNs when most decent database servers offer encrypted connections already.

Re:Have i missed something?

[coyote-san]

Some databases support encrypted connections. I believe postgresql does.

Re:Have i missed something?

[Anonymous Coward]

"they just make sure that they have control of their users and pat themselves on their back for being able to make two servers talk across a WAN."

I think it's more like the tools for managing security from an easy to use interface suck. Security right now is in the dark ages.

Re:Have i missed something?

[Curunir_wolf]

Yes, I hate this kind of alarmist crap. Clueless boss reads this crap and all of a sudden there is a new policy that needs to be implemented right away.

The one I'm dealing with now was because some asshole like this one decided the big security threat nobody is paying attention to is flash drives. ** OH NOOOS -- DO SOMETHING ** So of course without even thinking about loss of productivity or how easy the workarounds are, we are mandated to disable all USB ports on every workstation. WTF?

Supposedly this provides better security. What it really means is that users will discover that their flash drives no longer work, so instead of carrying their work home in their pocket, they email it to themselves over the Internet.

Stop this madness!

Re:Have i missed something?

[DragonWriter]

Sure, if you are providing the apps and the db. If the apps and db are not merely physically separated but also organizationally separate, there is no reason for them to not access each other over the internet. This may, for lots of organizational and competitive reasons, be uncommon in practice, but other than using a bad, insecure database server in the first place, there is no reason that it should be a particular security problem.

Fundamentally, a database server that takes connections over TCP/IP ought to be secure enough to expose on the public internet, and if it isn't, the fundamental problem isn't "you don't have it firewalled", but "you have an insecure database server". If you can exploit a database server over its TCP/IP connection, it is not safe for internal use either, since if you trusted your internal users without limit, you wouldn't need all the user and role-based security included in most database server software, and if it can be exploited to gain access beyond that which users are supposed to have, this is a problem if the exploit is from within as well as if it is from without. Except in a limited number of circumstances (such as a db server that exists solely to serve a particular web application and access to which is physically limited to only completely trusted users and the application itself), there aren't a lot of cases where having a fundamentally insecure server behind a secure firewall really addresses the security concerns.

Re:Have i missed something?

[COMON$]

Your statement about ethics is kind of true, but there is a large amount of age discrimination in the IT field. It mostly comes from the built in mentality that age represents experience in a field. But in young fields this is not true, however when interviewing individuals the older interviewee or the older employee will always get hired or promoted, unless they are a flat out ass.

Yes you can run on any port you want, but in his research he defined his search parameters so that the recipients of the findings of the research could interpret them. My guess is, you are in the minority in your understanding of ports, ssh over port 80? NO WAY, is a response I commonly get. Or wow, you can do VNC over port 80, that doesnt make sense....

The point here is it is a bit scary knowing that there is a lack of knowledge in the port management/security area and his findings are the numbers they are. I would say the report is accurate.

Re:Have i missed something?

[COMON$]

Easy to use and security never go hand in hand. It is always a battle of Ease of use vs security, you should know this.

Re:Have i missed something?

[illumin8]

Get the 40 year old guy who was a sociology major and did data entry for 10 years before being asked to take over NT environments. This way you get a 'seasoned' guy because he has a few more wrinkles and that makes him a better 'fit' and definitely must make him more capable.

Half the people I work with are like that. It sucks. Their lack of skills and basic fundamental knowledge really shows and makes me have to dumb everything down so that they can comprehend the most basic concepts. But that's why I make the big bucks. They bring me in to fix the problems caused because they couldn't be bothered to hire someone that actually knows what they're doing. Far better to hire the "reliable" guy that won't ever quit because he would never be lucky enough to get anything other than a minimum wage job in the first place.

Re:Have i missed something?

[bl8n8r]

> For example, you may have a stand-alone java app at multiple locations that can query
> the database directly, so you'd definitely open up the port.

Fine, but this is where ip filtering, along with service metrics, are prudent, responsible and a necessity. It seems there is a knowledge and motivation gap with much of this paradigm however; most people are simply too lazy, too time burdened, or haven't any interest in taking appropriate security precautions. This is why we have such large, commonplace data breaches where everyone stands around saying "how did this happen". Articles like this alert people to the larger problem and make them think.

Re:Have i missed something?

[Sproggit]

............"Fundamentally, a database server that takes connections over TCP/IP ought to be secure enough to expose on the public internet"........

Nope nope nopity nope.
The issue is not with a secure (or otherwise) port being exposed to the internet, the real security issue is the question of where has business logic just been moved?
REGARDLESS of whether the database server listenes on port 35530, has super duper extra strength nine fafillion bit crypto (now with more caffiene!!! (tm) ) and only accepts connections from your permanently manned shell server in Bratislava.
YOU (as in your server) should be in charge of ALL the logic that determines whether data from a client machine is valid data.

Putting ANY tier execpt a resticted presentation tier on ANY machine outside of your direct control and audit is an invitation for someone (and experience teaches, someone that business has explicitly granted access), to fsck with the data going to the database.

Next thing you know, some guy from the mailroom is driving a Bugatti in the Bahamas, and you get called to a board meeting with nothing but your dick and your oh so nifty firewall ruleset printout in your hand.

Simple, no?

The Sproggg

Re:Have i missed something?

[ozone_sniffer]

Even if you need to go through "teh internets" to access your (your application's) DB server, you should at the very least do so through an SSH tunnel, preferably using certificate authentication. That in itself eliminates the need for the open DB server port on the remote interface. Otherwise, AFAIK, someone could sniff your SQL queries and find out the database user/password, just to mention one possible issue.

Re:Have i missed something?

[trolltalk.com]

No, thinking that everything is so important that it needs to be totally secure and have a gajillion layers of "protection", each with their own leaks, is retarded. Somehow, I don't think that a list of shared bookmarks, bor example, is "need-to-know" stuff.

You can lock down access by client domain, by ip, by database, by password, by user, by table, by time of day, by field, by lookup in another field, whatever. A heck of a lot more options than an ftp or http server, and there's no reason you can't encrypt the session.

Re:Have i missed something?

[trolltalk.com]

If you don't care who accesses it for read permissions, leave it open. You can set access rules in any half-decent database that allows only write/update permissions from specific ips, domains, users, etc. And you can always encrypt your connection. Getting your underwear all in a twist when the security provided by the database is better than most web apps ... well, think about it - this is just a knee-jerk reaction.

Not all data is all that important.

Re:Have i missed something?

[trolltalk.com]

"they email it to themselves over the Internet."

Lovely - so, knowing most people, google/microsoft/yahoo have a copy :-(

I just ssh into my home box :-)

I needed a 300 meg file from my home box earlier this week - sftp to the resuce.

Either you believe your people are trustworthy and won't give the data to competitors, or, if you can't trust them, you should fire them.

Re:Have i missed something?

[trolltalk.com]

Funny thing is, where I'm working, the bias is against older people. "We tried a half-dozen, and they all had issues." Since then, we've gone through I don't know how many people in the 20-to-40 age bracket, but I'm still here :-)

In the last year, the bias has shifted back to the over-50 group in larger businesses, because, IF they've been in the field for a couple of decades, they're worth it, and generally don't have the "need" to get into "pissing contests" about who knows what - they've had a couple of decades to work it out of their systems, or they use slashdot to proxy their luser abuse :-)

Re:Have i missed something?

[trolltalk.com]

Mysql supports encrypted connections, and another poster pointed out that so does postgresql. For mysql, you can REQUIRE that remote client connections be encrypted.

You can also limit the hosts, etc., from which you allow connections, and you can give them read-only access to only certain fields, etc.

That said, I ssh into my home server when I'm at the office - its just drop-dead easy. I wouldn't normally consider accessing the db directly from a client app for end users as being a "good thing", but all this hand-waving over an open port, as if that is by itself a huge security risk, well, that gets my goat. Any decent db can be locked down pretty tight.

Re:Have i missed something?

[ozone_sniffer]

http://vil.nai.com/vil/Content/v_99992.htm

OK, this was 4 years ago, but what guarantees it won't happen again? Granted, SSH and friends also have had/will have their own bunch of problems. But that's beside the point, all software will. However, I'd like to ask, in which would you trust more, on a DB for implementing encryption or on an SSH server?

Given, I think TFA goes a little bit too far on the sensationalism, but I doubt all those servers are properly configured with encrypted connections, and god knows what else might be open besides the DB server.

Bottom line: it's not the end of the world, but it's not good news either.

Re:Have i missed something?

[Workaphobia]

This kind of article reinforces the management perspective mentioned in another recent article that firewalls == security. While most people would attack that equality by saying security is a process and thus much more than firewalls, I never really liked firewalls to begin with. All they are is a place to centralize some rules, which is great but it's not as if they give you any primitive or insight that you didn't already have before. Why block a port when the port isn't even open to begin with - besides centralization and efficiency, from a security perspective what does it offer you, especially when you trust the security policies of all the machines on your internal network?

Re:Have i missed something?

[en4ca]

I don't understand why everyone says to use VPNs when most decent database servers offer encrypted connections already.

One assumes there are cases where you may not be able to configure the application utilising the database to use such an encrypted connection. The application may be closed source, or its configuration may not be under your control. In such cases, a VPN is viable alternative.

Re:Have i missed something?

[Nazlfrag]

Simple solution to the age problem - grow a beard. A bearded IT professional commands fear and respect from his less hirsute colleagues, with his utter contempt for the mores of civilised society bristling boldly from his chin. Caution - only recommended for male IT workers.

Re:Have i missed something?

[turbidostato]

"from a security perspective what does it offer you"

Simplyness or the KISS principle. Number one security mandate, that is.

Re:Have i missed something?

[turbidostato]

"but other than using a bad, insecure database server in the first place, there is no reason that it should be a particular security problem."

Except, of course, that there's no good secure database server in first place. This is no news since there's no good secure "real big bunch of code lines for complex processes" either RBDM or anything else, to start with.

Re:Have i missed something?

[trolltalk.com]

The encrypted connection (at least w. mysql) uses the OpenSSH libs. If the libs are b0rked, using ssh probably isn't going to be much of an improvement.

Re:Have i missed something?

[ozone_sniffer]

That's a pretty specific database/case. I for one, would rather be on the (IMHO) safer side, and have the infrastructure ready in case a DB server change is required, and the new one does not support that functionality.

Re:Have i missed something?

[trolltalk.com]

As you can see, firebird, maxdb, mysql and postgresql all support encrypted connections.

Oracle can be configured to as well.

Instructions for JDBC (java database clients) encryption.

That should be enough options for now - so pick your favorite poison :-)

Re:Have i missed something?

[bhalter80]

Also the VPN endpoint is a more security focused device IOW it specializes in allowing/disallowing access where as the database server specializes in fetching/storing gobs of information. If you are utilizing VPN and you disable a user's account they can't even get to the open database server's port to try to wreak havoc instead they get stopped by a presumably much more robust piece of access control software. If you don't use a VPN that user who's account has been disabled is left with several possibilities including trying to brute force it or using some other password that they can gain through social engineering because remember they can't get access using their credentials but they still have access to the open port.

Re:Have i missed something?

[adolf]

Maybe -- and I realize that you'll think I'm going out on a limb here -- the reason to keep a database open to the network is so that end-users might be able to use an interface which doesn't fucking suck?

Contrary to modern opinion, not everything lends itself well to being presented in a web browser. In fact, it is my considered opinion that most web interfaces are a complete abomination[1]. Some applications just don't work that way at all[2].

And, yeah, sure - one could always create an extra (non-SQL) middle layer, and hide the DB behind that. But that involves more work, and doesn't really solve any of the authentication/security issues, only obscures them. This is, of course, not security: if it's adequately secure for a PHP script on a web server somewhere to access an SQL datebase somewhere else, then it is also adequately secure for an end-user application to do the same, at least in a business setting.

It's just another open port. It is no more, and no less, dangerous than ports 80, 25 or 123.

[1]: Media storage. It's a pain in the ass to manage an otherwise-fine program like Gallery, chiefly because of the assumption that everything must be inserted into the system via a PHP script running on a web server. Which is not only long-winded and stupid, but makes it painful to actually put anything into the system. There are dedicated applications for this, but they also communicate with the web server, and tend to behave erratically. And never mind trying to store and peruse things like personal music and video collections with a database and a web-browser front-end - the basic concept is so broken that few even try, and all of them fail.

[2]: Point of sale is a lousy thing to run over a web browser. It's a real motherfucker (impossibility?) to sanely integrate simple things like cash drawers, unique input devices like credit card and bar code readers, and receipt printers in a program like Firefox. Conducting HTTP transactions in a generic browser instead of simple SQL queries in a custom end-user application can really slow things down. A middle layer would fix some of this, sure, but that just does more of making Apache look like a third wheel than it does to fix anything.

Re:Have i missed something?

[sipatha]

For example, you may have a stand-alone java app at multiple locations that can query the database directly, so you'd definitely open up the port.

True that.

After all you still have to supply a username and password, connect via ssl, and you can change the default port and passwords, you can restrict IPs that connect to you machine on the card.

The point is you don't need a fully fledged firewall to protect the db server

--
I'm not sure if that was my USD$0.02 or ZWD$0.02, or i still owe you, :)

Re:Have i missed something?

[COMON$]

"or they use slashdot to proxy their luser abuse :-)"

Ok that made me chuckle :)

In all seriousness there is problems on both ends with age discrimination. I am on the younger side being in the 25-35 age bracket so I sympathize more with my baby brethren. But I notice that colleagues of mine were always getting passed over for promotions even though their resume had more years of experience and plenty of knowledge to back it up (knowledge does not make you good at your job of course). But it could also be that it was more that at the time I was working for the state and it would be interesting to me to see average age at state agencies as compared to private sector. There just seems to be a warm and fuzzy feeling to having someone older being promoted, maybe because people still associate maturity/wisdom with age.

Re:Have i missed something?

[trolltalk.com]

Glad you liked the "or they use slashdot to proxy their luser abuse :-)" bit.

One thing I've noticed is that the "lack of social skills" stereotype is true for a lot of people in the IT industry; it certainly took me a long time to see that social skills are the MOST IMPORTANT part of any project. Hate to say it, but you can "really know your shit", but without the ability to listen more than speak, and to also pick up the unspoken stuff, reading between the lines, knowing when to say less, etc., you're only contributing a portion of what you can really contribute.

Unfortunately, age doesn't guarantee that, but it increases the odds. Also, if your "crew" has a problem with someone higher up, you'll have more of a chance having it addressed if you have someone older on your team bitching about it.

We code because we enjoy "the chase" - the solving of problems, some of them rather abtruse. We enjoy crafting something, we enjoy the "art". Still, we also have to be able to communicate on all levels, and unfortunately, this is an art that most people, not just programmers, need to be constantly working on. Sure, we're the worst offenders - hence the stereotype - but at least we have the lingo for it (herding cats, luser abuse, etc) so we know that we have our work cut out for us.

Unlike certain "management" people, who tend to make diagrams with 4 squares, and tend to try to put people into one or more of those squares, as their "personality types", then wonder why people get pissed off. You can't "box people in". All those "motiviational" speakers who indulge in such fantasies are full of crap, and should learn to think outside the box.

Re:Have i missed something?

[trolltalk.com]

On a side note, according to one of the links I posted elsewhere in this thread, with Oracle, the user name and password are never transmitted in cleartext, even if the session isn't encrypted. Not a bad idea, and something I suspect the rest of the food chain will eventually adopt as SOP.

Re:Have i missed something?

[COMON$]

took me a long time to see that social skills are the MOST IMPORTANT part of any project.

Recently we just hired a contractor, I remember one of the contractors that interviewed knew PHP like the back of his hand and he made that apparent. However, I elected for the guy who knew a little less and was much more patient in the interview. Projects get hung up way too much on miscommunication as it is.

I may not be able to recite the OSI 7 layer model for networking but I know the general layout and can explain projects to management easily, this makes me a great employee. However, the caveat is that some people know what they are doing in security but tend to be a little less "well spoken" and get put in charge of it. When it comes to security I definitely would lean more on the jerk who knows too much than the guy who is really nice about it...as long as the jerk is under the management of someone who can reign them in.

As for putting people in boxes....unfortunately this is something as programmers and Admins we have to deal with. It has been my interpretation that Programmers and Admins are a bit more analytical than other departments, not saying that other departments aren't smart, they just don't understand scope the same way. Everyone else sees IT, they don't distinguish between social and antisocial, Developers vs Designers, or for that matter Network Admins and .NET devs. We are just computer people who have a hard time communicating.

But back to the original topic at hand, the hiring procedures for IT are still being ironed out, there are a lot of untrained people from the 90s in IT management positions and they will tend to hire people like themselves. So it will be a while before IT becomes a pro organization, basically when those of us with a BS or BA in the area become management in our 40s and 50s even then it will take another 10-20 years for their hiring policies to take effect.

Re:Have i missed something?

[kayditty]

You're right. You don't understand. So why are you posting? They're not talking about encryption; they're talking about having ports exposed to the internet. If you use a VPN, you can have a service listen only on its local interface, but still be able to access it remotely through a VPN tunnel.

what?

[FudRucker]

no comments?

Re:what?

[Anonymous Coward]

Well this is quite simple and not really all that mysterious.
If you secure your server correctly in the first place.
Close up, secure and encrypt ports that consume passwords and serve data.
You don't have a problem! Within reason of course.
I that gets breached, a firewall won't protect you from an attack either.

Du...

I wonder how many people know that firewalls don't actually do anything.
Accept keep useless network fanboys employed.

Re:what?

[nurd68]

Thank you. It's about time someone else realized this.

Firewalls are good for:
- Helping to limit access to services which don't have built in access limits (think tcp-wrappers++)
- Helping to protect a pile of machines over which you have little to no control (a bunch of desktops in the office, for example).

When talking about servers, if you sufficiently harden your machine, a firewall does very little, especially if the service being compromised is one which the firewall allows pretty much anyone access to...

Re:what?

[ByOhTek]

But that assumes that everything is programmed properly and infailable.

To be human is to err, and every Application/OS I've seen is programmed by humans. An extra layer of security doesn't hurt, especially against the bugs we don't know about yet - most bugs/security flaws weren't know about/understood prior to being fixed, and prior to fixing, they could have been exposed.

Also, consider that you might have a server with several ports open, some which by nature must be intranet only, others which must be intertnet also. In these cases a firewall helps keep things safe.

Yes, there are ideals on how things should be done, and in an ideal world, a firewall would not be necessary because (a) all the software would be programmed to be impenetrable by external network attacks, and (b) nobody would attack you anyway.

However, only the delusional live in an ideal world. And even then, only they know it...

Re:what?

[ByOhTek]

You have to assume all of the hardening works properly - stuff that is supposed to stay local-only, stays local-only, no issues with the operating system's and driver's general network code that will let something through anyway, no applications will open up ports you weren't aware of, etc.

Now, sure, you can say "It's open source, it's got all kinds of people looking at it, of course it is secure." But face it: people make mistakes, and the more subtle the screwup, the more people it will take to find it. Eventually there will be a screwup too subtle for all the people looking to find. Then you have potential setup errors, something was missing in the documentation or overlooked by the individual doing the install/test, etc. You now have a vulnerability. Yes, none of these mistakes *should* exist, and having a firewall *shouldn't* be used as the *primary* method of protecting your system, but extra defense is good. The more software you run, the wider the variety of operating systems you run, the more likely one of these errors is to happen. A firewall is cheap (usually), and it happens to block this kind of attack.

Yes, relying on a firewall as your only means of defense is stupid, and there is a lot it doesn't protect, but a door lock doesn't defend against all means of entrance - it doesn't mean you shouldn't lock your doors. A firewall *is* a nice backup to have in case of human error in the programming or setup of an application.

Re:what?

[Anonymous Coward]

Helping to protect a pile of machines over which you have little to no control (a bunch of desktops in the office, for example).

Sorry, you've never done network security for a mixed group have you? This is the group where a firewall is the least useful. They will get hit by the "dumb lump between keyboard and chair" vulnerability attacks ten times over long before a single attack that a firewall could prevent the first remote exploit it would protect from.

Conversely, you are least likely to see that "dumb lump between keyboard and chair" on a server with a decent admin, because he or she will not be browsing random websites or reading email on the server, and he or she will know enough not to have retarded passwords (unless the organization scraped from the bottom of the barrel to get him/her).

Re:what?

[nurd68]

So then you've pretty much proven my original point - firewalls are of marginal usefulness. You need to harden machines and be careful in your use of them. If you can't, you're pretty much done. :-)

Re:what?

[nurd68]

I don't know about you, but when I say "listen on this interface only", and then check that it is, I'm pretty sure that it won't spontaneously start listening on other interface. Throwing a firewall over a service which doesn't listen on a given interface is kind of useless.

Now, if you're talking something like "allow from 192.168.0.0/24" having a hole in it, you're right. Such a rule implemented at the service level + at the firewall level does help protect against a bug in either, giving you an element of defense in depth.

Problem is, most folks just throw up the firewall, which means that you're back down to one point of failure. Now, you can argue that the firewall is simpler, more thoroughly vetted, etc, and you have a point.

But, your point is well taken. I think we can agree on:
- Defense in depth is good.
- Having a firewall is no substitute for hardening machines.

Re:what?

[Maximum Prophet]

Most firewalls are just a computer running an OS with firewall software as the only application. If you are running CheckPoint firewalls on Solaris machines and there is a bug in the Solaris OS, it's the same as if your Solaris machines were directly exposed on the Internet.

Router ACLs can protect you against OS bugs and rouge applications opening up ports you don't expect. While routers are not bug free, they are simpler and more hardened than a firewall appliance.

Re:what?

[Anonymous Coward]

However, they still have a use. Relying on a firewall only, is stupid, but not having one isn't terribly brilliant either.

Your post read as the extreme of "firewalls are useless and you shouldn't bother with them", which is just as bad as "firewalls are the [last|best]+ line of defense". Both tend to ignore various types of problem.

From most to least effective:
1) Educate your users
2) Harden your systems + have regular updates
3) Firewall

Depending on the situation, 1 and 2 may flip.

Re:what?

[Just Some Guy]

To be human is to err, and every Application/OS I've seen is programmed by humans.

I tend to avoid VB.NET, too.

Re:what?

[deets]

what about stateful inspection?

Re:what?

[Just Some Guy]

I don't know about you, but when I say "listen on this interface only", and then check that it is, I'm pretty sure that it won't spontaneously start listening on other interface.

I'm never that sure. The name of an interface is nothing more than a string in a config file, and people are always forgetting to copy strings safely or forget to initialize them and so on. Maybe the version you have today works as documented. That doesn't mean that tomorrow's version is guaranteed do.

Re:what?

[Bellum Aeternus]

Some of us are forced to run Windows. Linux locking down, maybe. Windows is another story?

Re:what?

[Bellum Aeternus]

Dang, should'a used Preview. That question mark isn't supposed to be there. Windows IS another story.

Re:what?

[afidel]

While routers are not bug free, they are simpler and more hardened than a firewall appliance.

No, they aren't. Checkout the size of a typical firewall firmware download (not Checkpoint) vs even a minimal IOS download. You will see that the routers software is MUCH larger and more complicated. Even if Cisco isn't your preferred router vendor almost all the big boys have similar sized codebases because they try to support much the same featureset.

Not Suprising

[Algorithmnast]

This isn't so suprising:

• Most C programmers don't bother to check the return of system calls like printf()
• Most C++ programmers have no idea what an invariant is.
• There are a lot more people who can "just put together a database for us" than can tell a company why they do or don't need one
• Most users of computers have little to no security on their machines.

The world at large is uninterested and/or unaware of security when it comes to computers.

Re:Not Suprising

[faloi]

And don't forget the "Good news, we just made your application/database/whatever accessible to the everybody!"

I've seen a number of things cobbled together just to get a department or company through something that suddenly become available to a lot more people than the original target audience. It's a good argument for never taking short cuts when you're programming, but I'm sure there are a lot of people that have gotten something out on a deadline only to turn around and look at it later and say "What came over me to do it that way?"

Re:Not Suprising

[tritonman]

Does this mean that creating a wrapper class for cout and cerr was a bad idea? Like a base abstract class that has two implementations, one for cout and one for cerr and an interface on top of it?!?!

Re:Not Suprising

[morgan_greywolf]

Most C programmers don't bother to check the return of system calls like printf() Because they almost always don't fail and it makes for really ugly code? Besides, if a printf() or fprintf() to stdout or stderr fails, you're hosed in spectacular ways anyway.

Re:Not Suprising

[Anonymous Coward]

Most C++ programmers know that printf is not a system call

Re:Not Suprising

[Anonymous Coward]

It's not surprising there is always an smartass commenting "it's not surprising" on every spamming article here. Nothing ever surprise these aholes and saw'em coming last Tuesday. Wonder if the buggers will say the same when I sneak up behind them and smack'em upside the head - "it's nor surprising I've got smacked upside the head. Everyone knows..." (follow-up smack at this point).

Re:Not Suprising

[Anonymous Coward]

The GP's point is valid, but he should have used a better function as an example.

Too many times I see unchecked malloc()'s, realloc()'s, etc. Those need to be checked, but I think you can get by without making sure your printf()'s are working.

Re:Not Suprising

[ajs318]

Most C programmers don't bother to check the return of system calls like printf()

And what exactly are you supposed to do when printf() returns false? Display an error message?

If you can't correct it, you needn't detect it.

Re:Not Suprising

[failedlogic]

I'm not an IT worker, but I think the idea that because some people don't know what "xyz" is, ignores a basic pretense in this circumstance. I'm not going to pretend this example explains all or some of the 1/2 non-FW DB servers.

I've worked and volunteered for several non-profit, NGOs and small businesses. And worked in B2B sales selling computer equipment to them. Generally the IT staff is an outside consultant who does a few things (whatever they're able to afford). Setting up of complex computer equipment and software is often left to someone who's able to understand the instruction manual but no IT training (so it could be the receptionist, the director or somewhere in-between). Setting up a firewall is expensive and doesn't fit into many budgets of small organizations. Someone with no IT training may also think a DB server or networked printer needs no firewall.

Let me put it this way: as a non-IT worker, I haven't put 100% of my resources behind studying I.T. (software, hardware) etc. I've programmed computers and used computers since I was born. Despite being somewhat knowledgeable in TCP/IP and reading firewall and comp. security books (mostly for self-interest), I'm not confident I can even configure an adequate firewall for my home computer. Things like FreeBSD's IPFW are supposed to be "easy" to setup. Not my experience. Its sheer confusion. MS, Apple and some OSS firewalls are supposed to make it even easier. Block this port, block that port and that's it??? don't think so. I'm not even 50% confident this solution provides adequate protection esp for a NGO, non-profit, SMB or home computer. So how is someone not as well-read supposed to setup a firewall on a limited budget? But a pre-built hardware solution? Still that needs to be setup and configured too. And even then, you still have to be knowledgeable enough to *test* whatever solution you're using to actually make sure it works and keeps your system well protected.

Not a trivial or inexpensive task. But people with no training or knowledge are often asked to do this.

Re:Not Suprising

[kamochan]

<nitpick>

• Most C programmers don't bother to check the return of system calls like printf()

Most C programmers do not consider printf(3) a system call.

• Most C++ programmers have no idea what an invariant is.

Most C++ programmers I know of are heavy users of assert(3). But maybe that's just a local phenomenon.

• There are a lot more people who can "just put together a database for us" than can tell a company why they do or don't need one

I know a lot of consultants, and from my perspective just the opposite holds true... *shudder*

• Most users of computers have little to no security on their machines.

Most users of computers have a lot of security in their machines. Since Windows dominates the marketplace, that security is indeed typically not on.

</nitpick>

Re:Not Suprising

[morgan_greywolf]

Well, that's different. malloc() and realloc() can and do fail.

Then again, I first learned C programming on the MS-DOS platform, where malloc() and realloc() might not only fail, but with no virtual memory support and being limited to 640K of RAM, were often likely to fail, so I just got in the habit of checking such things.

Re:Not Suprising

[Tony Hoyle]

Whilst I'd agree that checking malloc should always be done, in reality on a modern OS malloc almost never fails (unless you do something silly and ask for 8gb on a 32bit machine) - all you do is drive things more and more into swap until the entire machine slows to a crawl.

Re:Not Suprising

[Ngarrang]

The world at large is uninterested and/or unaware of security when it comes to computers.

I would lean towards the 'unaware' part of your statement. I have no numbers to back up my opinion, but I am thinking that the vast majority of computer users don't have a clue about what they are using. Most know just enough to be dangerous to themselves and their PC. I see this at work where a user has been using a PC for the last 10 years, but still effectively knows nothing about it. To them, it is just a tool.

I believe that wide spread knowledge of security and privacy practices won't come into play until another generation has been born and our oldest generation dies off. A kid born in 2000 has been exposed to computers since they were born and will be more aware. We have too many Baby Boomers and Generation X'ers who have to make an effort to adapt to the new knowledge, but are just too lazy.

Re:Not Suprising

[johannesg]

Most C programmers don't bother to check the return of system calls like printf()

So what? Do you really think the number of characters written is important, interesting, or vital to security in some way? More importantly, what will you do if you find that not all characters were written? Or that too many were written, and your buffer has overflown (this means the catastrophe has already happened, so chances of actually detecting that condition are slim).

Most C++ programmers have no idea what an invariant is.

...or how it relates to databases having no firewalls. I sure don't.

There are a lot more people who can "just put together a database for us" than can tell a company why they do or don't need one

There are far too many people who think they know about databases when really, they don't, too. Always harping about normal form-this, normal-form that - but half of them haven't even heard of (D, E)-normalization even though this is a vital technique to obtaining good database performance.

Most users of computers have little to no security on their machines.

So you are saying that the reason many databases are unprotected is because many systems are unprotected? That's some stellar reasoning there, Captain Obvious!

Re:Not Suprising

[mikael]

And you'll be really hosed if you don't. The best way to see this happen is to full up a disk drive until it is 99.9% full. Then try running applications that automatically load and save their configuration files. The file will be loaded, the application will run, and once complete, it will end cleanly. Or so you think. The next time you try running that application, it segmentation faults.

Maybe a more sensible think to do is to check the amount of free disk space and give a warning.

Re:Not Suprising

[Algorithmnast]

And what exactly are you supposed to do when printf() returns false? Display an error message?

If you can't correct it, you needn't detect it.

Well, to answer another poster - yes I was being insufficiently precise when I used the term system call. printf() is a C library call.

To answer the quote above: in C and C++ printf() [including fprintf() and sprintf()] returns an int, representing the number of characters formatted and written out - and not including any null byte appended as a string terminator.

In C, an error message and potentially an exit was in order.

In C++, in an exceptional situation then an exception may be appropriate to throw.

No offense intended, but in no case should any programmer fail to see that "If you can't correct it, you needn't detect it." is rubbish. If I were told that in an interview, then I'd recommend against hiring the person who stated it.

Oh wait, I have refrained from hiring such interviewees. I know that those who subscribe to such broken ideas are typically more damaging than they're helpful. IOW - "More trouble than they're worth."

Re:Not Suprising

[houghi]

I am currently working on a database for company knowledge and the first thing I have in the back of my mind is that information might be available to more people that I anticipated.

To me that means that I will not put some data online, untill I am sure how this can be blocked for sure. Also in the back I am thinking about data security. If I am not sure, I do not put it online.

Re:Not Suprising

[morgan_greywolf]

What does free disk space have to do with a printf() or fprintf() to stdout or stderr?

Re:Not Suprising

[Anonymous Coward]

• ...and most Slashdot users don't know that printf is not a system call

Re:Not Suprising

[lwriemen]

> No offense intended, but in no case should any programmer fail to see that "If you can't correct it, you needn't detect it." is rubbish.

Not necessarily rubbish if it is justifiable. In state machine construction, there are two choices to make for invalid events: ignore or can't happen. Can't happen events should be handled as exceptions, but ignore events can be ignored. There are cases where it is perfectly valid to ignore the return event of a printf.

Managers/companies who can't be flexible where logic dictates can be more trouble than they're worth as well.

Re:Not Suprising

[Algorithmnast]

So you are saying that the reason many databases are unprotected is because many systems are unprotected? That's some stellar reasoning there, Captain Obvious!

No. That's not what I'm saying. If that had been what I was saying then your titling me as Captain Obvious would not have been as silly as it was.

I was pointing out something that about 2 people understood by their posts: Most "experts" aren't.

I've written most types of software at one time or another, and for the most part people are only interested in how to do "the job" well enough to get paid and then go on to the next hack.

And yet, what they should be doing is learning how to write good software, instead of writing borderline flamebait.

Re:Not Suprising

[vadim_t]

Block this port, block that port and that's it???

Indeed not. What you do is to first block everything, then unblock only what's needed.

This is really not all that hard to setup. It runs a web server? Ok, open port 80. It needs to run SSH? Open port 22, if possible restricted to the ip addresses the admin uses (this can backfire if the admin needs to administrate using a PDA in the middle of nowhere though)

Firewalling is really quite easy on that level. Now if you want to do things manually with iptables then you need a good knowledge of TCP/IP, and a good understanding of how things get filtered. Firewalling a server should be pretty easy, but if you have users it can be pretty tricky to have a configuration that provides security without driving people mad

Re:Not Suprising

[mgblst]

It is really not that simple. Block everything. If something is not working, start logging the firewall, and find out what ports it needs. Then decide whether you really need that application to access the internet, and open them up if you do. Very easy to do in Linux.

True that people with no training or experience are asked to do this task, but i mean, honestly it is not such a great problem. Most things are working ok.

Re:Not Suprising

[Ed Avis]

You can't correct it, but you should at least notify the user rather than continuing blindly. For example, if you are writing to an output file with printf() and the write fails, you shouldn't go on to tell the user that the file was saved successfully.

For 'almost impossible' conditions, dying immediately with an error message is maybe not ideal, but still a hundred times better than silently ignoring the error and reporting success.

Re:Not Suprising

[Ed Avis]

In state machine construction, there are two choices to make for invalid events: ignore or can't happen.

This may be true, but failure to printf() is not an invalid event. It's an entirely possible outcome of calling printf(), one that is documented in the manual page. You need to design your state machine so that there is an appropriate state and transitions for the 'output failed' case.

Failure to write a file is not something that 'cannot happen'. And usually, it is not something you want to 'ignore'.

There are cases where it is perfectly valid to ignore the return event of a printf.

Indeed, but it's a good rule of thumb to always check it and do *something* to handle errors, unless you specifically know that output failures aren't cared about here.

Re:Not Suprising

[Ed Avis]

So what? Do you really think the number of characters written is important, interesting, or vital to security in some way? More importantly, what will you do if you find that not all characters were written?

Do *something*, anything to flag the error and alert the user - do not just continue blindly and pretend all is well. Few bugs are more annoying than the one that writes a zero-length output file and then tells you your data has been saved.

Re:Not Suprising

[js92647]

Whilst I'd agree that checking malloc should always be done, in reality on a modern OS malloc almost never fails (unless you do something silly and ask for 8gb on a 32bit machine) - all you do is drive things more and more into swap until the entire machine slows to a crawl. I don't quite get what you're saying. Are you saying that you would agree that checking malloc should be done, with the exception of a system that has a lot of memory (ie your "moderm" OS)? Regardless of how much memory the computer has or what kind of an architecture the OS is running on, the least you can do is at least make sure that memory allocated correctly!

Having said that, yes; the computer will have enough space to store a char* to some N-sized, null-terminating string. Doesn't mean someone won't try to overflow the damn thing. Having said that I see this kind of Slashdot rhetoric all the time, picking on some majority that is somehow incompetent at programming, checking for errors and overflows, and so on. I am a university student and even I do basic things in C like make sure malloc returned a valid pointer, use a temp pointer when calling realloc, always make sure to call free, and so on. Granted I'm nowhere near knowledgable as I would like to be, I try.

Re:Not Suprising

[Randyj70999]

and C is it's own virus.

Re:Not Suprising

[ajs318]

If you were writing to a file then yes, it is important to check that the write was successful -- after all, you might have run out of disk space or something. But then you would be using fprintf() rather than printf().

My point (which, I'm pleased to note, managed not to escape at least one person with mod points) was that most of the time, STDOUT and STDERR are the same device. So if printf() goes tits-up, it's highly unlikely that any attempt to display an error message will work either. (I suppose you could exit non-zero, but who checks exit codes in shell scripts?)

Re:Not Suprising

[Ed Avis]

If you were writing to a file then yes, it is important to check that the write was successful -- after all, you might have run out of disk space or something. But then you would be using fprintf() rather than printf().

Not necessarily, e.g. gzip <in >out. You can't really assume that your standard output is unimportant or that failures to write it can be ignored. Of course if your application is just generating chatter messages perhaps it doesn't matter if they get lost; but those should probably go to stderr anyway.

My point (which, I'm pleased to note, managed not to escape at least one person with mod points) was that most of the time, STDOUT and STDERR are the same device. So if printf() goes tits-up, it's highly unlikely that any attempt to display an error message will work either. (I suppose you could exit non-zero, but who checks exit codes in shell scripts?)

Well, quite. But do the right thing and at least the user will have the possibility to write robust scripts calling your program. If they choose to write flaky shell scripts that plough on ignoring errors, that's their choice, but don't force it on them.

Myself I tend to write perl scripts more than shell scripts and always check the exit status (if only to die with an error message).

Re:Not Suprising

[Anonymous Coward]

Most C programmers don't bother to check the return of system calls like printf()

printf() is not a system call. It's a libc function. And I'd say that the majority of C programs don't need to check the return value of printf().

If you're doing file I/O that matters, check the result of fprintf(), fflush(), and fclose(), sure. This is even true of programs that might get redirected to a file, as the filesystem might run out of space. But adding error handling to some frivolous printf() meant to display something to the user is kind of... frivolous.

Re:Not Suprising

[Ephemeriis]

Setting up a firewall is expensive and doesn't fit into many budgets of small organizations.

This simply isn't true. It's almost harder not to set up a machine/network with a firewall these days.

Pretty much every PC shipped in the last couple of years has a software firewall of some sort built into it. Any router you buy is going to have at least a basic NAT firewall in it. A number of cable and DSL modems now have built-in routing and firewall capabilities. And if you're actually setting up a publicly visible server of any kind you'll already want a beefier router than those available at Staples/Wal-Mart/Office Max, and I can guarantee it'll have firewall capabilities.

So how is someone not as well-read supposed to setup a firewall on a limited budget? But a pre-built hardware solution? Still that needs to be setup and configured too. And even then, you still have to be knowledgeable enough to *test* whatever solution you're using to actually make sure it works and keeps your system well protected.

Not a trivial or inexpensive task. But people with no training or knowledge are often asked to do this.

If you've got somebody with no training or knowledge setting up a network/server/router/whatever...it's probably going to be low-end stuff. If you're spending 10's of thousands of dollars on hardware you don't have the secretary set it all up. And if you're going with low-end stuff it is, more or less, secure out of the box. I'm not saying that a little Netgear WGR614 is going to hold up to a determined attack, but it isn't going to forward database traffic out of the box. You'll need to intentionally forward the ports to do that...

Which is certainly something your average human being can do. Most low-end routers have very friendly GUIs that make configuration fairly straight-forward. But it still takes conscious effort to make the network insecure.

Re:Not Suprising

[johannesg]

I was pointing out something that about 2 people understood by their posts: Most "experts" aren't.

And you were attacking programmers why...? Because they are such an easy target? Because programmers are typically in charge of external security, in your worldview? I still don't see what the first point in your post had to do with anything - it would be at best borderline relevant in a discussion about good programming practices, and even then only if you want to be extremely pedantic. By mentioning those specific items in this context you are very loudly implying that programmers are at fault for not installing firewalls. I pose that programmers have no business touching firewalls or system configuration - that is a job for system maintainers.

And yet, what they should be doing is learning how to write good software, instead of writing borderline flamebait.

BORDERLINE flamebait? Damnit, I should try harder... Oh, and I smile on your implication that I don't already know how to write good software ;-)

Re:Not Suprising

[pherthyl]

Well, to answer another poster - yes I was being insufficiently precise when I used the term system call. printf() is a C library call.

Insufficiently precise? Holy weasel words batman. You were wrong.

Re:Not Suprising

[pherthyl]

Indeed, but it's a good rule of thumb to always check it and do *something* to handle errors, unless you specifically know that output failures aren't cared about here.

Bingo. I don't think anyone is arguing that important output shouldn't be checked. But if I write a printf for debug output or just a status message, I'm not going to bother checking the return value.

Re:Not Suprising

[cdrguru]

Excellent thinking. What makes you think that anyone without training and knowledge should have any business adminstering a computer? A lot of the problems today come from the idea that computers are simple to use and anyone should be able to buy one in a store, take it home and use it.

15 minutes later they download something that provides a gateway to using their computer to attack others.

Re:Not Suprising

[Deadplant]

bytes_printed = printf('super important info');
if bytes_printed == 0:
      printf('error! unable to print messages!);

WIN! /not a c coder and can't be bother looking up correct syntax.

Re:Not Suprising

[Algorithmnast]

I was pointing out something that about 2 people understood by their posts: Most "experts" aren't.

And you were attacking programmers why...? Because they are such an easy target? Because programmers are typically in charge of external security, in your worldview? I still don't see what the first point in your post had to do with anything - it would be at best borderline relevant in a discussion about good programming practices, and even then only if you want to be extremely pedantic. By mentioning those specific items in this context you are very loudly implying that programmers are at fault for not installing firewalls. I pose that programmers have no business touching firewalls or system configuration - that is a job for system maintainers.

And yet, what they should be doing is learning how to write good software, instead of writing borderline flamebait.

BORDERLINE flamebait? Damnit, I should try harder... Oh, and I smile on your implication that I don't already know how to write good software ;-)

sigh I wasn't suggesting that programmers are stupid/bad/etc/etc. I am one, and am not in management. I've been tasked for a while with doing technical portions of interviews. While I have been using things since Bitnet, and used to type-race 300 baud modems when they were state-of-the-art, I prefer my technical skills to the lies.... er, management track.

I was trying to suggest that if you wanted to bait me than you have more work to do. I have small children, and it takes a bit more effort than someone saying "You're a..." at me when they're upset.

And to answer your first presumption in the quote, I wasn't attacking programmers and I didn't imply anything, but rather you were inferring something I didn't intend - for your own reasons of which I'm neither knowledgeable nor interested.

What I was trying to do with my original post was to point out that most of humanity is a bit sloppy, and has a bit less of a work ethic than we'd like them to have when their work affects us - waiiiit for it.... - and that being in technology doesn't change that nearly as much as we geeks would like to think.

Re-read that last paragraph, and if you still want to whine about what I actually said, then I'll say some things you can mock me for... and then you can say that you baited me. (If it were done well enough, I'd even mod you up when it came time for more points... that is, if I were allowed to..)

Re:Not Suprising

[toadlife]

Your post made me snicker.

Re:Not Suprising

[DragonWriter]

No offense intended, but in no case should any programmer fail to see that "If you can't correct it, you needn't detect it." is rubbish.

IIRC, its a recommended "best practice" in several languages and environments. But there are underlying assumptions, particularly:

1) That the routines you are calling throw exceptions or do something similar on exceptional states, and
2) That the environment provides a reasonable default response to such exceptions.

In those cases, its a good idea to not check for any exception you can't correct or at least add some useful information to on the way out. You do need, however, to detect error conditions resulting from the way your code is used that aren't thrown as exceptions by lower-level code and throw them as exceptions yourself, leaving your clients to decide whether they can handle them or whether they should instead ignore them and let them bubble up.

So, its not "rubbish", but it needs to be understood in its proper context and not just blindly applied without regard to context.

I've mostly seen it as a recommended best practice in certain functional languages (the "don't program defensively" maxim of Erlang, for instance) where not programming defensively lets crashes happen when they should, which is the exact opposite of the result in C, where not programming defensively usually means that the program continues on happily even in a situation where it should crash.

Re:Not Suprising

[kisielk]

If you are a business (and if you are running a database server, chances are that you are..) and are not paying a professional to configure these things for you, you are just being plain negligent. If I were an investor, I'd be seriously calling these things in to question.

Re:Not Suprising

[flowsnake]

That is a virtuous policy and philosophy, but one which unfortunately is too often impossible to maintain in the face of impossible deadlines. Every design decision is a compromise. As there is no such thing as perfect security I don't believe we can ever be completely sure about the security of our data or systems; refusing to deliver until perfect security is implemented generally means nothing is ever delivered, and development projects are terminated by losing the contract rather than by achieving our unattainable goals.

Re:Not Suprising

[Anonymous Coward]

Sigh. I don't know is this is modded funny because people think you're right about an inane example, or because it's obvious.

If printf fails, your application should behave intelligently! If there's a critical error that is relevant to correct interpretation of the data being output, you should abort execution. If it is noncritical continue as you were, and seriously question why you were outputting anything anyway (maybe verbose mode?)

If I'm merging five files, and file #3 exists but is not readable, and you can't write to stderr or stdout and it's an important report--continue the task, but exit with an error code! Silent propagation of failure is one of the largest problems I've encountered in old codebases, and it just grows and grows poisoning everything and programmers have the audacity to blame the DBA or users for their lack of handling. Printf can fail, malloc can fail--exceptional cases deserve to be handled--if you don't know how to handle it, then your program is only partially corre

Re:Not Suprising

[z4pp4]

Why is it a bad thing to run a database with an open port on the Internet? This is may not be a problem if:
- The DB is properly protected against injection
- User logon to the DB is via secure keys
- The DB is patched
- The user that the DB daemon runs at has only read rights to binary files and only write rights to the DB files
- DB users are segregated properly.

In the end, for the complicated stuff the amount of security you need depends on the risk associated with what you need to protect.
For the simple stuff like avoiding getting pnwd, just check you daemon user, file system rights, remove privilege escallation - and you're miles ahead of what a firewall can offer.
As far as the printf argument goes, this is rather the "format string vulnerability" that you refer to, and has nothing to do with return values. Anyways, why not just use high-level languages with bounds checking functions when you interface to the web like normal people? Face it, C++ sucks for web stuff, only hairy men in underground labs use it on web pages...

Re:Not Suprising

[Anonymous Coward]

Do you mean suRprising? Otherwise I don't get your post...

Re:Not Suprising

[Just Some Guy]

To answer the quote above: in C and C++ printf() [including fprintf() and sprintf()] returns an int, representing the number of characters formatted and written out - and not including any null byte appended as a string terminator.

So, it's an error when printf() doesn't output the expected number of bytes. Check.

Ummm, how do you determine exactly how many bytes it should have written so that you can compare the values? I can't really think of any way you could correctly do that in a locale-sensitive manner without re-implementing printf() in the first place, at which point the whole think is moot and you're fired for dicking around too much on the job.

Re:Not Suprising

[elBart0]

What types of budgets are you talking about? You can get an entry level watchguard or similar device for around $400. Here's one for a little over $300. http://www.cdw.com/shop/products/default.aspx?EDC=999365 (no affiliation, just a quick search to find it)

These things are remarkably easy to set up, and with generally good instructions. I'm not an expert in that field either, but I've set them up before, with not a significant amount of effort. If you can afford Oracle licenses, you certainly can afford $400 for a firewall.

Re:Not Suprising

[rasputin465]

Reminds me of a quote I heard one time: "Coding in C++ is like high school sex. A lot of people talk about doing it, not a lot of people actually do it, and those who do, do it poorly."

Re:Not Suprising

[Algorithmnast]

Reminds me of a quote I heard one time: "Coding in C++ is like high school sex. A lot of people talk about doing it, not a lot of people actually do it, and those who do, do it poorly."

Sort of like my college calc professor who said, "Calculus is the beginning of real math - everything up to this was just baby math."

Or my saying, "Without proper use of templates, it's just baby C++ at best, C+ at worst."

Re:Not Suprising

[Algorithmnast]

So, it's an error when printf() doesn't output the expected number of bytes. Check.

Ummm, how do you determine exactly how many bytes it should have written so that you can compare the values? I can't really think of any way you could correctly do that in a locale-sensitive manner without re-implementing printf() in the first place, at which point the whole think is moot and you're fired for dicking around too much on the job.

Someone who thinks!!

Yep - that's why I turned to C++ in the first place. All too often I found that the logical conclusion was to call abort() or to not do enough when error conditions occur.

And neither of those options is usually sufficient in a complex program.

Re:Not Suprising

[sydneyfong]

To them, it is just a tool. It is just a tool. The fact that you also think it's a toy is besides the point.

We won't see widespread security and privacy practices until the costs of not implementing such things grow larger than the costs of hiring people to do it. It might only take you a few seconds to get a basic firewall running, but for lay people it's probably a few hours of reading, mingling and frustration -- and even then they'd probably mess up the settings and be no better than when they started.

Re:Not Suprising

[smellotron]

In those cases, its a good idea to not check for any exception you can't correct or at least add some useful information to on the way out. You do need, however, to detect error conditions resulting from the way your code is used that aren't thrown as exceptions by lower-level code and throw them as exceptions yourself...

Ahhh... reminds me of my take on an ideal C++ environment:

• Write everything to be as strongly exception-safe as possible (no memory leaks, provide transactional semantics where reasonable or expected)
• Throw exceptions whenever something truly exceptional happens.
• Don't ever think about catching an exception unless you can promise to do something more useful than your caller will.

One try/catch block inside main() is enough to spit out the failure and shut down gracefullyWhich raises a question: does anyone know if there is a way to make gdb automatically add breakpoints to all exception throw calls?

Re:Not Suprising

[smellotron]

So, it's an error when printf() doesn't output the expected number of bytes. Check.

If you read the documentation for those functions (man 3 printf), you'll see that an error is signalled by returning a negative value. The length is not to be used for error-analysis unless it's negative. It's more for something like this:

size_t sz = snprintf(buf, BUFSIZE, "VALUE=%f\n", myvalue);
if (sz < 0) throw std::runtime_error("oh crap!");
write(fd, buf, sz);

Re:Not Suprising

[smellotron]

So if printf() goes tits-up, it's highly unlikely that any attempt to display an error message will work either.

But if you have syslog, maybe that works... or maybe the logfile you have open works... or maybe you can open up an SMTP connection and send an email out. There's all sorts of reasons why some channel may fail and others are still available, and should be used to indicate a systemic failure.

(I suppose you could exit non-zero, but who checks exit codes in shell scripts?)

Hey! I do! If you write shell scripts and you don't care about return codes... maybe you shouldn't be programming. Let someone else do it right, so it doesn't start failing mysteriously in 3 years when some obscure part of the operating system changes and breaks your script.

Re:Not Suprising

[ioshhdflwuegfh]

Most C++ programmers have no idea what an invariant is. Most C++ programmers I know of are heavy users of assert(3). But maybe that's just a local phenomenon. What assert?

Only SQL server and Oracle?

[daveewart]

Given the approach he took, he could have checked for PostgreSQL and MySQL as well, which are presumably much more widespread (?) than the ones he was looking for...

Re:Only SQL server and Oracle?

[Anonymous Coward]

true ... what what corporate starting today would even think of a db-server without a firewall. Given the scares in news almost everyday i'd have thought lots of redundant security policies would be still in effect ....

Re:Only SQL server and Oracle?

[lordofwhee]

He obviously doesn't care about accuracy, so why should he be thorough? This way, it makes it seem there's a lot less secured DBs than there really are.

Re:Only SQL server and Oracle?

[Anonymous Coward]

If you read the whole article you will find he did check for MySQL.
He did find more installations of MySQL.
But if you also know the history of this guy, you will notice he normally
makes his money on services for MS-SQL and Oracle. Hence in the context I have
presented it perfect sense.

Needs more cowbell

[cthulu_mt]

My server is in county lock up for exposing itself.

Thank you; I'll be here all week.

Re:Needs more cowbell

[M. Baranczak]

"Rhonda...have you no shame! keep the briefcase closed, for chrissake! all your documents are falling out!" - Frank Zappa

Questions

[ciaohound]

How many of these are production systems and not just developer's toys? If production systems, how many are mission-critical?

Re:Questions

[deniable]

More importantly, how many of them were extrapolated. He 'polled' 1 million random IPs and went from there.

Re:Questions

[Anonymous Coward]

I'll believe him if he names them.

Re:Questions

[tgatliff]

It would appear that this guy is fishing for an article... Meaning, I strongly suspect somewhere, someone is trying to sell somebody something... For example: "(Sales person to business person) Sir, did you realize how many database servers were found to lack a firewall. Here, buy my product!!"....

It kills me the number of decisions that are made at the business level by simply watching commercials or reading articles. If I have another business person ask me if they should have "SAP", I think I am going to be sick....

Re:Questions

[Diakoneo]

This is kind of what I was thinking. I remember when I installed my first Linux firewall-router-etc system.

"Ooo! L00k at m3 I inst@ll teh UN1X! I am l33t L1nux dud3 now!!!!!11!1!11oneoneone"
Begin server install. Choose the following servers to install and expose to the internet...
Apache, MySQL, PHP, Telnet, tftp, etc.

"Ooo!!1! l33t L1nux dud3s like m3 want ALL teh servers! Inst@ll th3m @ll!!!11!!1!!"
And what you end up with is a system more vulnerable to the internet than if you just hooked your system up raw.
{sigh} I was so young and naive. Now I'm old and naive...

So what if it is not behind fw

[zeridon]

My db servers are behind no firewall but they listen only on localhost or sockets ... the link between application and db is done by intermediate https layer.

What's the fuss then?

Re:So what if it is not behind fw

[cbiltcliffe]

Presumably if it only listens on localhost, this guy wouldn't be able to find it, as he'd have no idea it was a database server by a portscan. So yours wouldn't count in this tally.

Yawn

[riffzifnab]

Just a quick list of stuff I would like to point out:

1. Because everyone knows that a firewall is the end all and be all of security.
2. How do they know they don't have a firewall and not just an open port?
3. Open port != DB server

Litchfield took a look at just over 1 million randomly generated Internet Protocol [IP] addresses, checking them to see if he could access them on the IP ports reserved for Microsoft SQL Server or Oracle's database. 4. Not all DBs are huge corporate DBs. Hell some versions of MS Office install SQL on your computer.
5. Maybe some of them actually need/want to have remote people access them (and they don't know about VPNs(lolz))
6. Yeah some people should get their shit together

Did Mr. Litchfield crash his BMW and wants a new one? This just smacks of "ZOMG!!! Ur ports are open, give me ur monies and I will fix u!" His company is even linked in the fourth paragraph. Next please.

Re:Yawn

[J0nne]

If you RTFA, you'll see he was able to identify the version of the server, and also the patch level (some of them weren't even patched against Slammer!).

nmap can tell you that kind of stuff, you know. Anyway, most of those servers are probably already compromised too. I've recently seen one try to spam a phpBB board (it ran sql server, IIS and some kind of ldap thing).

Re:Yawn

[Anonymous Coward]

Why is this alarmist slashvertisement for David Litchfield's consultancy front page material?

Re:Yawn

[riffzifnab]

Yeah you got me, I only skimmed the first page and then gave up on the article. I'll concede point 3 isn't valid in this case. I still think he's just trying to grab attention to drum up business.

Re:Yawn

[J0nne]

I still think he's just trying to grab attention to drum up business. I'm not going to disagree with you on that. That's pretty much what most security researchers do ;-). There are probably non-fearmongering security researchers, but they don't get headlines...

Anyway, not having a firewall doesn't make you unsafe automatically (as long as you have strong passwords, and everything is patched, and something like fail2ban is stopping bruteforce attempts, and you actually know what you're doing), but it wouldn't surprise me if a lot of them were set up by clueless admins.

Re:Yawn

[Gollum]

1. A firewall is not the be-all and end-all of security. But it certainly is a good starting point. You are making the assumption that the majority of people deploy systems with secure configurations. History has shown is that they do not.
2. Ok, if they *do* have a firewall, then the implication is that the firewall admins are incompetent. Better? I find it difficult to believe that that many databases *need* to be exposed to the random Internet.
3. Open port != DB Server, agreed. But if you connect to the port using the DB protocol, and get a response indicating the version of the DB in question, the odds are good that it *is* a DB. Read the article. He checks to see which versions they are, too.
4. Fair enough. Not too many install Oracle, though.
5. As you say in 6, some people just need to get their shit together.

Re:Yawn

[Ephemeriis]

1. Because everyone knows that a firewall is the end all and be all of security.

No, but it is a good place to start.

2. How do they know they don't have a firewall and not just an open port?

Fair enough. There might be a firewall in place that is deliberately configured to allow traffic. Not terribly secure, but could be.

3. Open port != DB server

Your average firewall, by default, blocks almost everything. Generally speaking you need to deliberately open the ports you want to use. If this is the case, why would you deliberately open ports that you don't need/use?

4. Not all DBs are huge corporate DBs. Hell some versions of MS Office install SQL on your computer.

Very true. Microsoft Outlook with the Business Contact Manager installs a SQL server on your PC. Symantec Backup Exec and Panda Antivirus both use a SQL server to store their information. A surprisingly large number of programs use databases these days, even in standalone desktop installs... Though I will again say that you'd have to intentionally configure your firwall to allow traffic to them.

5. Maybe some of them actually need/want to have remote people access them (and they don't know about VPNs(lolz))

Which is still insecure.

6. Yeah some people should get their shit together

Which, I think, is the whole point of the article. If you don't need access to your database from the Internet, those ports should not be open to the Internet. If you do need access to your database from the Internet, access should be configured in as secure a manner as possible - open ports responding to random IP addresses is not secure at all.

This just smacks of "ZOMG!!! Ur ports are open, give me ur monies and I will fix u!" His company is even linked in the fourth paragraph.

Indeed. The article is a bit sensationalist... And the methodology seems a little questionable as well. Why was he only looking for Microsoft SQL and Oracle databases? What about Postgres, MySQL, Sybase, Pervasive...there's tons of other database servers out there - and, again, a surprising amount of software installs a database these days.

Re:Yawn

[technicalandsocial]

3. Open port != DB server I guess I should have chosen another port to control my botnet with...

Re:Yawn

[riffzifnab]

Anyway, not having a firewall doesn't make you unsafe automatically (as long as you have strong passwords, and everything is patched, and something like fail2ban is stopping bruteforce attempts, and you actually know what you're doing), but it wouldn't surprise me if a lot of them were set up by clueless admins. Exactly. That was kind of the point of my first point (in a sarcastic kind of way).

Half a million?

[RandoX]

Is that all?

Corporate Data?

[allcar]

From TFA:

With no firewall, databases are exposed to hackers, putting corporate data at risk. How does he draw the conclusion that these are corporate databases? Nothing in the methodology provides this insight. I would expect that the majority of these are owned by kids and hobbiests, which would help to explain the preponderance of MS SQL servers over Oracle.
Also, the sample of 1 million is very small to be drawing these conclusions.
In short, "Nothing to see here - move along."

Re:Corporate Data?

[Anonymous Coward]

The Grammar Nazi asks, "Which of the following two is correct?"
a) "Yes, I consider myself a hobbyist."
b) "Dude, that is the hobbiest thing I've ever seen!"

donttagmebro

[Digitus1337]

Yes, off-topic but... whoever keeps tagging this stories with a variation of "don't tase me bro," cut it out! What's it going to be for this story? Don't expose me bro?

Re:donttagmebro

[ShiNoKaze]

It's called a meme. This is slashdot. Get used to it. Complaining about it just made it a permanent part of slashdot. Good job.

Re:donttagmebro

[BeerBrewingMan]

I for one welcome our new meme spouting overlords.

Re:donttagmebro

[somersault]

It's actually donthackme bro.. may I suggest donthackmebro;droptablepayroll; though?

Re:donttagmebro

[Anonymous Coward]

I'm pretty sure it's someone with several sock puppets spamming tags.

Used to think that it was editors, now I'm fairly sure that it's just an anonymous jackass.

You missed something too

[lib3rtarian]

Um, not quite. You missed something too:
the proper setup looks like this
{internet}
|
firewall
|
app-servers
|
db-servers

Re:You missed something too

[Poltras]

You all got it wrong. If you expose your data directly over the internet, you don't NEED an app server. Elementary.

Re:You missed something too

[morgan_greywolf]

Don't forget to turn off all the access controls! Makes it much easier to meet user demands for table changes. Just tell 'em to change it themselves! They can do it from anywhere!

Re:You missed something too

[azrider]

On a small scale you could do this with a DMZ LAN off the single firewall, or in a larger environment you'd have a second firewall.

Is this redundant? On my PIX's the DMZ rules (firewall) are separate from my trusted net rules (firewall).

There is (to my knowledge) a requirement that each discrete firewall set be hosted on a different piece of equipment.

Re:You missed something too

[azrider]

There is (to my knowledge) a requirement that each discrete firewall set be hosted on a different piece of equipment.

s/a requirement/no requirement/

My mistake (should have previewed)

Re:You missed something too

[ByOhTek]

your sig...

You are not a lawyer, you are a hairball?

(sorry, couldn't resist)

Re:You missed something too

[Anonymous Coward]

Actually, I think you both missed it.

{Internet}
|
firewall (HTTP deep packet inspection)
|
app-server
|
firewall (SQL deep packet inspection)
|
db-server

That is, of course, provided that your firewall can handle the traffic that your app-server is throwing at it... but like all things YMMV.

Re:You missed something too

[afidel]

If you use two separate boxes using two different vendors your are much less likely to have a single flaw expose you from the internet directly to the internal network. At least that's the way I've heard it explained. Personally I have always used a single firewall with a separate DMZ network.

Re:You missed something too

[Anonymous Coward]

You don't sa?

Comment removed

[account_deleted]

Comment removed based on user account deletion

Declaration of interest

[LordSnooty]

TFA mentions he works for Next Generation Security Software.

"In the fast-moving world of software security it pays to have allies you can trust. Government, business and software vendors all turn to the global expertise of NGSSoftware for the protection they need. You can rely on us too... "

He has a product to sell, the report features some flaky extrapolation of data ("well, if I found this many across a million servers, on the whole internet there must be LOADS!") - why are we bothering with this?

Re:Declaration of interest

[petes_PoV]

Yes, while I was reading the ./ post, I thought "I bet this guy sells security products". I'm sad to say I wasn't disappointed. (Does that make sense?)

If this had been an academic study or with no vested interest, it might have had credibility, instead it just comes over as FUD. Ignore.

Oracle's listener on port 1521

[IdleTime]

Just because the listener is accessible on port 1521 from the outside, doesn't mean the database itself is directly available.Depending on what identification method is set up, you may have to identify yourself to the listener first using one of many ID schemes before the listener will connect you to the database itself which may be well protected behind a firewall..

I wish he had known what he was writing about before he actually wrote the damn article.

Re:Oracle's listener on port 1521

[pshempel]

Well if you would have read the article before writing you would have read that he tested the systems for patches, that would mean the server would have to be running to do this.

There was one other disturbing finding in Litchfield's 2007 survey: Many of these unprotected databases are also unpatched. In fact, 4% of the SQL Server databases Litchfield found were still vulnerable to the flaw that was exploited by 2003's widespread SQL Slammer worm. "People aren't protecting themselves with firewalls and the patch levels are atrocious," he said.

About 82 percent of the SQL Servers were running older SQL Server 2000 software, and less than half of those had the product's latest Service Pack updates installed. On the Oracle side, 13% of the servers were running older versions of the database that no longer receive patches. These Oracle 9.0 and earlier databases are known to have security vulnerabilities, Litchfield said

Re:Oracle's listener on port 1521

[nstlgc]

I wish he had known what he was writing about before he actually wrote the damn article.
I wish you had looked up who he is and what he has done in the past before you make such a statement.

Re:Oracle's listener on port 1521

[TheZax]

Just because the listener is accessible on port 1521 from the outside, doesn't mean the database itself is directly available.Depending on what identification method is set up, you may have to identify yourself to the listener first using one of many ID schemes before the listener will connect you to the database itself which may be well protected behind a firewall.

The only difference between the listener being accessible from the outside and the database being directly available, my friend, is time. And of the 2 DBs he was testing for MS SQL and Oracle, not very much time...

Re:Oracle's listener on port 1521

[IdleTime]

Really?

Care to elaborate on this? I'm just sitting here looking at the source code for the Oracle listener, so maybe you can tell me which part of the listener will ensure that the database on a machine secured inside the network and not directly accessible from the outside can be accessed?

Re:Oracle's listener on port 1521

[TheOriginalRevdoc]

A lot of Oracle sites run their listener on a different port. (1521 is just the default.)

Re:Oracle's listener on port 1521

[TheZax]

Care to elaborate on this? I'm just sitting here looking at the source code for the Oracle listener, so maybe you can tell me which part of the listener will ensure that the database on a machine secured inside the network and not directly accessible from the outside can be accessed?

Here are 66 potential exploits for Oracle listeners, take your pick.

http://search.securityfocus.com/swsearch?sbm=%2F&metaname=alldoc&query=oracle+listener&x=8&y=7

So?

[ajs318]

# iptables -I INPUT 1 -dport 3306 -j DROP -- how hard can that be?

And the default combination of "root" and no password isn't as insecure as you think, because you still need to originate queries on the machine itself. You would have to get a web hosting account on the server (or find some idiot who wasn't chmod-ing uploaded files non-executable) in order to muck about. Or rather, giving each hosting customer their own database username and password and only GRANTing them permissions on their own databases is no more secure than having users use "root". Think about it; if you were running scripts on the server, then you could look in files in other people's home directories, where their database username and password would be clearly visible. There is no* workaround, either; the apache daemon has to have read access to every user's scripts, including the code used to undo any ad hoc obfuscation applied by users to passwords.

* Actually, you probably could have every user run an instance of httpd in their name, and listening on a non-privileged port which was firewalled off from the outside world. You'd then need one "master" server configured with a module which would do nothing but route incoming requests to specific ports based on hostname. I dread to think how slowly this would run.

Re:So?

[BlueParrot]

Think about it; if you were running scripts on the server, then you could look in files in other people's home directories, where their database username and password would be clearly visible. There is no* workaround, either the apache daemon has to have read access to every user's scripts, including the code used to undo any ad hoc obfuscation applied by users to passwords.

Rather than using built-in modules in the httpd daemon it can launch the interpreter for the respective scripts as the user in question? Maybe I am missing something here, but I would imagine this kinda thing has popped up before. It doesn't seem particularily impossible to write a daemon which will sandbox scripts to a single user, or failing that, forking to surrender privileges. Now I'll admit I'm no expert in the field, but given that it is perfectly doable I'll assume that the people who are have already optimised this to buggery.

Re:So?

[Anonymous Coward]

Using CGI scripts isn't fun though (I wouldn't want to be slashdotted on a cgi page), but with FastCGI things are pretty smooth. You get seperate interpreter and webserver processes, but without the overhead of forking off an interpreter on each request. Then assign different roles to the processes (in SELinux or AppArmor), and with PHP, use the suhosin extension.

Re:So?

[Anonymous Coward]

# iptables -I INPUT 1 -dport 3306 -j DROP -- how hard can that be?

That can be very hard depending on the installation. For the last customer I setup, it took me, a user of Linux in production environments since Nov 1993, about eight hours. First off, the kernel didn't have have support for iptables compiled in so "modprobe iptables" failed. That require downloading a compiler (along w/ ncurses, make, etc.). That took two hours. After that, downloading the kernel took about that long. Since they didn't have a copy of their .config, make config, make, and rebooting several times to find just the right options that Oracle needed to run along with the drivers they needed for their hardware took about three more hours. Total it was about eight hours of work even knowing exactly what to do. A new user could have easily taken a week or more even with guidance from a mailing list or phone support. You are absolutely wrong with your dismissive attitude.

Of course with Debian using a stock kernel it is as easy as running apt-get to install iptables and you already have the iptables modules installed, but that's a best-case scenario. Even then you have to know how to install software, what to install, and what command to type.

Re:So?

[smellotron]

# iptables -I INPUT 1 -dport 3306 -j DROP -- how hard can that be?

I don't think that's such a good idea... pointing people towards iptables is a good way to get half-ass firewalls that sorta work, but not really. Most people just aren't going to get the right firewall configuration (and I don't blame them). Better to advertise something higher-level than what essentially amounts to kernel interfaces!

Re:So?

[ajs318]

Let me guess ..... you were using some lame distro like Red Hat or SuSE. They are renowned for having kernels that are patched to christ and a faulty default config that doesn't even include basic stuff like gcc (omg oh noes!!!1! compiling is to ahrd omg!!11!). Oh, and they expect you to pay for them. Stick with One of the Three (Debian, Slackware, Gentoo) and you need never worry about a buggered-up kernel again.

Re:So?

[Anonymous Coward]

It was actually a Debian-based system from a vendor that supports Oracle. Their setup supports only one hardware configuration that you buy from them. There are obvious disadvantages to that, but for many people having something rock-solid with great support that just works is well worth the limitations. I couldn't get Oracle to run under the default Debian kernel so I had to start removing drivers and features.

Anyway, not everyone out of the box has iptables module available. That was my only lame point.

Pink Floyd theorem

[Rastignac]

We don't need no education, we don't need a firewall...

Re:Pink Floyd theorem

[Echolima]

Mother should I build a firewall.

Well known scare-mongering firm

[Anonymous Coward]

These guys are well known scare-mongers over in Europe and this is just another typical OMFG!!!!! press release. Its certainly not news and it wont make me any more likely to call these cowboys up the next time I am looking for some non-hysterical security advice.

Give me Marcus, Bruce, or these guys any day. When is the security industry going to move on from this FUD?

Next! AG.

Hierarchical vs. Relational Web

[Anonymous Coward]

Well, if the database management systems were themselves securely written like web servers typically are [supposed to be], there mightn't be a problem. We've known since the late 1970s that hierarchical databases suck and relational is the way forward. But the web remains rooted in a "services show a hierarchy" paradigm. Maybe what we NEED is a "world wide virtual database". That is the vision of http://ap5.com/wwvdb.html but unfortunately it's (a) in lisp (nothing against lisp, I love it, but it still tends to scare off people) and (b) not open source, just source-available (no redistribution rights).

Web Services?

[keirre23hu]

I don't want to sound like a shill, but isnt this the rationale behind SOAP and such? Why leave a DB port open on the Internet. I agree that TFA may be blowing things out of proportion, but still, seems like an unnecessary risk.. at a minumum ip-filter the port.. do something other than let Joe Script-Kiddie find the port and (depending on the db software) crack your system.

Re:Web Services?

[trolltalk.com]

The same argument could be made about ANY service/port, including http, ftp, etc. The premise of the article - that "port open == bad all by itself" - is junk.

And as we have repeatedly seen, accessing your db through a web server gives 2 different attack vectors - flaws in the web server, and flaws in the middleware.

Nothing except an unplugged box with the hard drive removed will ever be 100% secure.

Re:Web Services?

[markov_chain]

This attitude makes me sad. It used to be weird to want to close off access to stuff and in the process break the built-in openness of the Internet. Then the non-geeks moved in, and hungry-hungry-Hippo ensued-- now you gotta write a ten page position paper to justify opening a port. Meh.

Re:Web Services?

[beh]

The same argument could be made about ANY service/port, including http, ftp, etc. The premise of the article - that "port open == bad all by itself" - is junk.

You're missing something here - if you leave the DB port open, you must give your application/applet the necessary credentials to log in to the database; hence you're providing those to the outside. If you use a webservice, you may have the user authenticate himself, but also you can sanity-check data before forwarding it to the database.

If you don't take any precaution with your data, you're going to lose, no matter how many layers -- but somehow I can't find myself agreeing that giving the raw DB socket and passing all necessary authentication info to the world at large within the applet I'm sending out is a good way either. (of course, you can try and lock down the DB user so that the user within the DB can't do much damage, but you're still opening a hole through which you might also try and hack for other DB accounts with more permissions).

Re:Web Services?

[VorpalRodent]

Nothing except an unplugged box with the hard drive removed will ever be 100% secure.

Surely you don't believe that. It all depends upon the degree of unplugged-ness that the box is in (as well as how far removed the hard drive is). While I would agree that this is a step in the right direction, I would strongly suggest additional measures - like placing the box and hard drive in separate Faraday cages...60 meters underground...on opposite sides of the planet (preferably different planets). It's misrepresentations of security like this that get people in trouble.

"I unplugged my computer, so I'm safe."

"I dropped by hard drive in liquid nitrogen, shattered it, then melted it down and made it into a sculpture of Gandhi, so my computer can't be hacked."

Bah!

Re:Web Services?

[Alpha830RulZ]

I dunno. Any 500 dollar firewall would let you filter access to this port to allow only approved IP's to access it, which should usually be the web application server. I have to come down on the side of believing that that there are very few good reasons, if any, to expose the DB to a random access. While you are correct that perfect security is an elusive goal, this is a pretty easy hole to plug.

Your protest that this just moves the attack vector is a bit of a red herring, IMO. If you have a web application, of course you have risks in the web server and the middleware. Exposing your DB server just adds another risk point that is more straightforward and requires fewer skills to attack. That changes your risk points from 2 to 3. At the risk of being simplistic, I suggest that 2 is better :-)

Re:Web Services?

[plague3106]

You're missing something here - if you leave the DB port open, you must give your application/applet the necessary credentials to log in to the database; hence you're providing those to the outside. If you use a webservice, you may have the user authenticate himself

Huh? You can do that for the db server as well; it prompts for the credentials that will connect to the database. Most databases even have encrypted connections built in.

but also you can sanity-check data before forwarding it to the database.

That's certainly true.

If you don't take any precaution with your data, you're going to lose, no matter how many layers -- but somehow I can't find myself agreeing that giving the raw DB socket and passing all necessary authentication info to the world at large within the applet I'm sending out is a good way either. (of course, you can try and lock down the DB user so that the user within the DB can't do much damage, but you're still opening a hole through which you might also try and hack for other DB accounts with more permissions).

I don't see why managing logins which a web service uses is different than managing the logins for a database server. There's no need to have the application use one logon for everyone.

Re:Web Services?

[gallwapa]

$500 firewall? Pretty much any firewall Ive seen allows IP filters incoming and outgoing - heck, you could even do ACLs at the L3 switch or the router if you're feeling really frisky.

Re:Web Services?

[Anonymous Coward]

I don't see why managing logins which a web service uses is different than managing the logins for a database server. There's no need to have the application use one logon for everyone. But he explained just that! Logon to the database server implies permission to run arbitrary SQL on your server. Logon to a webservice lets the webservice control the operations and the SQL used. Yes, you could lock down your database permissions so there's no real risk in the first case but why give the user an extra attack vector?

Re:Web Services?

[richlv]

he probably works for checkpoint ;)
in the marketing department. .

Re:Web Services?

[jotok]

People often say "Nobody can ACCESS it, so it's secure."
That is, until the next 0-day comes out, or someone figures out how to access it.
Simply having your DB server exposed to the net--depending on authentication alone for security--is inadequate. You don't even have to spend money, just a little time, making it secure (another poster referenced VPNs--you could as easily tunnel your connection over secure sockets with an insanely long password known only to your automated java apps, and you'd be a lot better off).

Re:Web Services?

[fforw]

You're missing something here - if you leave the DB port open, you must give your application/applet the necessary credentials to log in to the database; hence you're providing those to the outside. If you use a webservice, you may have the user authenticate himself, but also you can sanity-check data before forwarding it to the database.

If you don't take any precaution with your data, you're going to lose, no matter how many layers -- but somehow I can't find myself agreeing that giving the raw DB socket and passing all necessary authentication info to the world at large within the applet I'm sending out is a good way either. (of course, you can try and lock down the DB user so that the user within the DB can't do much damage, but you're still opening a hole through which you might also try and hack for other DB accounts with more permissions).

There's basically no difference in the authentication for a webservice or a database.

If you need to sanity-check your data, this checks (also) have to be in the database. That's kind of the point of a database -- to have a storage for data with sane relations and content. The database server might be a bit more explorable but relying on unexplorability is security through obscurity.

Re:Web Services?

[plague3106]

Logon to the database server implies permission to run arbitrary SQL on your server.

Your point? Arbitrary sql doesn't mean you have access to any tables directly, it doesn't mean you can run code you want. Your logon can be very limited in the database objects that it can interact with or modify. Views and procedures can take into account your logon and limit access to data.

Yes, you could lock down your database permissions so there's no real risk in the first case but why give the user an extra attack vector?

Web services makes the solution more expensive and prone to failure and can kill performance if the application isn't already 'chatty.'

Its not as if adding another layer doesn't have implications, you need to balance with security.

Re:Web Services?

[trolltalk.com]

"if you leave the DB port open, you must give your application/applet the necessary credentials to log in to the database;"

The user can supply the credentials even with access to the db via an application (not an applet - that's for web browsers).

Remember, part of the access permissions for most databases is the host/ip, and all permissions can be very fine-grained - right down to individual fields in individual tables. It defaults to localhost, but you can add other hosts as well.

Re:Web Services?

[trolltalk.com]

1. Not all applications need to be "web apps"
2. Not all data is all that "critical"
3. DB engines support encrypted connections via SSL Here's how for mysql - you can REQUIRE the connection be secure.

   MySQL allows encryption to be enabled on a per-connection basis. You can choose a normal unencrypted connection or a secure encrypted SSL connection according the requirements of individual applications.

   Secure connections are based on the OpenSSL API and are available through the MySQL C API. Replication uses the C API, so secure connections can be used between master and slave servers.

4. the db engine can restrict the type of access via type of connection, ip, host, user, password, time of day, db, table, fields accessed, functions accessed, types of operations, etc. This is all built in - not something you have to code separately and hope you "got it right".

The "researchers" who claimed that an open port is, in and of itself, a security risk, need to realize that an open port is just that - an open port. It means nothing if you don't know how the machine is configured.

Re:Web Services?

[a_nonamiss]

Case in point: (Note, I am a sysadmin, not a programmer. Any solution that starts with "just change the application to..." is not an option for me. Plus, the application developer has long since quit, and I seriously doubt that we even have the source code for this application. But I digress...)

I have a legacy application (>7 years old, pre blaster worm) that requires an open MSSQL port. It's a mobile application, designed to use WAN connections from mobile phones, so an IP access list is not possible.)

I created a virtual machine running SQL 2000 (fully patched, of course) that resides in a DMZ. Actually completely separate (internal) network space from my office network. Additionally, I have restricted the SQL login used to be able to only update tables specifically used in the app. I have a pretty good linux based firewall running SNORT rules that I have specifically customized to block brute force attacks. In the case that someone sniffs a password, the only thing they could do is update tables with bogus data. (No delete, read, drop, alter, etc. permissions) The customer is aware, and they know that because they are unwilling to spend any money updating the app, they are taking on this risk.

So my server probably shows up if someone is doing SQL port scans, but I don't see what an attacker has to gain. They can't get any data, they can't compromise the server. If there were some zero-day exploit, I could just patch it and restore last night's backup. It's on a VM, so even if they were able to completely root the server, they can't use it as a vector to attack anything meaningful in my network. I suppose they could DoS my network, but what have they gained for all their effort? They've only accomplished making me drag my ass into the office and shut off the offending VM.

Am I missing something here?

Re:Web Services?

[en4ca]

Am I missing something here?

Yes - a zero day exploit implies there is no patch yet available. Also, there have been security vulnerabilities in VMs that allow you to affect the host in the past, which means it is also possible in the future.

At the least, you should have very restricted access to the internal network for the host the VM resides on, preferably limited to specific IPs and ports.

Re:Web Services?

[EugeneK]

Nothing except an unplugged box with the hard drive removed will ever be 100% secure.

Well, crap, and here I thought I was secured with my unplugged PC - now it looks like I'll be up late tonight removing the hard drive! Thanks for the security tip, though.

Re:Web Services?

[cecil_turtle]

I used up my modpoints yesterday, so I'll just agree instead - "The Intarwebs" port 80 HTTP only - there are plenty of other services that are perfectly acceptable, even designed to be, used directly. Porting everything under the sun over port 80 isn't some panacea. If a network is well-designed, the db servers will be in a DMZ anyway and there will be other layers of security. And there is no reason to believe that a web server is "designed to be publicly available" and other services are not.

Re:Web Services?

[hcgpragt]

The thing with databases is: It ,well, holds your data. You know: the meat and bones of your company.
If someone hacks your webserver that is kind of embarrasing. If someone drops your database you're toast.

Re:Web Services?

[beh]

I beg to differ - I certainly wouldn't add a DB super-user equivalent login to a web-service. If I open a DB port I am giving up a good deal of control over what can be done on the connection as well.

Also, the web-service grants you another layer of protection in that it doesn't offer all accesses to the database, but just the ones needed for the task at hand.

Sure, I have to code it in a way that SQL injection attacks etc. won't work - but I'd rather do that than trying to make sure that noone can get free access to my DB through a DB login I spread across the Internet.

Re:Web Services?

[trolltalk.com]

Well, people DO like to steal PCs. Removing all the recordable media isn't all that bad an idea, if (TRUE STORY) the night cleaners like to surf pr0n sites, and Windows users like to leave their pretty screen savers unlocked.

Re:Web Services?

[smellotron]

...isnt this the rationale behind SOAP and such? Why leave a DB port open on the Internet.

Why leave a SOAP port open on the Internet? What if I trust my DB vendor more than I trust the SOAP middleware? SOAP doesn't "protect" you from anything, it just moves the administration out frying pan (IP-based access control such as iptables, VPNs, and hardware by Cisco et al) and into the fire of a SOAP vendor—who, by the way, more or less implements the same sort of access controls as were previously available. Only now, there's more of a learning curve because the toolsets aren't as well-known.

Re:Web Services?

[Alpha830RulZ]

That sounds good to me, but I'm no expert, just someone who worries about these things for my own shop. The only thing you didn't talk about was the sensitivity of the data on the server. What you described gives me the paranoid willies, but I get those pretty easily. :-) If credit card numbers and SSN's aren't going through the server, you're probably in a reasonably safe position. If you have sensitive stuff on the db, well, then maybe you're not. It sounds like it's the customer's problem, and that you've taken prudent measures. If you (or the customer) got sued, I could see an opposing counsel making hay out of you not having the firewall, but I think I agree with your analysis that you've taken solid steps to protect the asset.

Re:Web Services?

[yoshi3]

Nothing except an unplugged box with the hard drive removed will ever be 100% secure. well, that beats running vista...

Re:Web Services?

[a_nonamiss]

Nothing sensitive at all to be had. No names, SSN, credit cards. Just survey information for a cleaning company. If someone took the time and effort to hack the server, they'd have full access to see how clean the bathrooms were for various companies around town. And just to clarify another point; the server IS behind a (pretty good) firewall. Any brute force attempts to crack passwords will result in an IP ban, especially if they try to use the sa account. (Since our app doesn't use that) I just have the MSSQL port (and only the MSSQL port) forwarded to the virtual server, segregated on its own network. (not even going through the same switch as my production network) The only real worry, as pointed out by a previous post, is the unlikely event that someone roots the machine, then figures out a way to use that to attack the host machine before I discover it's been rooted. I'd say pretty damn unlikely. It doesn't keep me up at night. Even if they got that far, it's not like we have anything on the host network worth stealing. HR information is segregated on a different network. I suppose they could see spaghetti source code for various projects my company is working on, but that's so damn convoluted even our programmers can't understand it.

I can see how this would work

[simong]

in a single server web/application server and database scenario for example. Where the database really only needs to communicate with the application server on loopback or localhost, the default setup probably listens on the first active IP address it finds (something is telling me that that has been the case with SQL Server for a long time, although I have to admit that I haven't installed SQL Server or Oracle of any kind for a long time either. It's then the admin's job to make it safe. I am sure that the same will apply to MySQL or Postgres although I seem to recall that the default action is to listen on localhost. It would be an interesting exercise to see if a scan fro MySQL and Postgres turned up similar results.

Re:I can see how this would work

[LurkerXXX]

MS SQL Server 2005 doesn't even have TCP enabled by default. You have to enable it /run the surface area configuration utility to get it to allow other machines to connect to it.

Any exposed ports are from older versions or admins who for some reason explicitly opened the ports to the world.

And ...

[zolf13]

... how many IP addresses have their TCP port 80 opened? Maybe let's start with installing firewall on 83.138.183.169, so I don't have to waste time reading useless research.

Accountability is lacking

[sm62704]

Litchfield said that, given the amount of press generated by corporate data breaches over the past two years, it's amazing to find that there are more databases exposed than ever before.

No it isn't. Now, if there were some penalty to losing half a million identities that was borne by the database owner instead of the poor schmucks whose identities were stolen, then it would be amazing.

But when your data is stolen, I'm the one who has to pay. Why should you care? You're not paying.

Re:Accountability is lacking

[JK_the_Slacker]

Wait... you pay when my data is stolen? That's awful nice of you, mister. Here I thought you didn't even like me.

Re:Accountability is lacking

[ivan256]

Clearly the only thing that gets stored in a database is sensitive personal information....

Re:Accountability is lacking

[sm62704]

Where were the mods? That was insightful.

MORE open DBs please. And... SQL == language

[CarpetShark]

While I agreed with most of your comments, this:

Hell some versions of MS Office install SQL on your computer.

Makes you sound like an amateur who's never used anything but Microsoft's database products. SQL is a language.

On another note...

There should be many MORE open databases online, just like there are many websites online. Then maybe this whole semantic "web" thing would've taken off years ago.

No surprise

[Anonymous Coward]

Unless you pay big bucks extra for a hardware firewall, the default setup for a Rackspace RHEL4 server has MySQL/SMTP/POP3/SSH open to the world. In fact, they recommend you keep it that way so that their monitoring software can watch your MySQL (I'd rather just bind to localhost and do my own monitoring, thankyouverymuch).

Billy Joel theorem

[Anonymous Coward]

We didn't start the firewall.

Well...

[ngunton]

I have a LAMP server in colo which is running a fair sized community site, and I use MySQL replication for instant backup of data updates to my home workstation. I can't afford to run redundant servers at the moment, so this is a nice "poor man's backup" (not hot spare, just a relative guarantee that if the server or colo center blew up suddenly then I'd at least have a copy of the data on my home box, losing at most a millisecond or so of updates).

Since my home is on cable, there isn't any static IP address to put in the server's iptables rules, and so I need to leave the mysql port on the server open. For security I use MySQL grant tables to specify that from outside only the restricted 'replication' user can have password access. Even if someone managed to guess the password for that user, the grants say that all they can do is replicate (and then they'd have issues because they wouldn't have any initial copy of the database). Since I don't store passwords in the db at all, it's fairly secure. Sure, it's not bulletproof, but as long as you're aware of the issues and take reasonable steps, it's very possible to have a database server intentionally open to the internet.

Even better, run the replication over ssl, then nobody can sniff anything from the stream. I haven't done that yet (until recently I was running an older version that didn't support ssl) but it is on my to-do list.

Another small thing you can do is to change the port that MySQL is listening on, but haven't bothered to go that far yet - the existing security seems to have been pretty solid.

Re:Well...

[Seanasy]

Not that you have to but you could use a SSH tunnel to do the replication. You don't have to expose MySQL to the Internet.

Re:Well...

[dysfunct]

Off topic and maybe obvious, but don't forget to make a backup of a mysql dump here and there on your home workstation. Replication will happily replicate an accidental DROP TABLE.

Re:Well...

[smellotron]

Another small thing you can do is to change the port that MySQL is listening on, but haven't bothered to go that far yet - the existing security seems to have been pretty solid.

That will stop any access due to network scanning (e.g. search the block 10.0.0.0/24 for anyone with an open port 3306), but it won't do jack shit about anyone who is actually interested in finding out if you have MySQL running. The tool nmap is particularly good at identifying protocols, and I'm sure it has MySQL figured out. Moving your server to a different port will not effect any additional security; it will just eliminate some of the noise.

Doesn't surprise me

[ledow]

Doesn't surprise me at all. First, there'll be a lot of database servers that are "supposed" to be accessible from the net for various reasons (which is ridiculous, yes, but there you go - at least use a whitelist of good IP's or something). Secondly, even a lot of NETWORKS are left unsecured without a decent firewall to hide behind. I've seen it happen on Internet-connected networks. Reliance on Windows to not let unauthenticated computers access shares is quite common - leave the ports open and make sure the services are locked down to provide service only to authenticated users, except for public shares - and that one we couldn't get working - and the one for John who doesn't like to enter his password from outside etc. It's a whole lot easier than that "opening ports" mess - or so some would think.

Third, you have things like Windows Firewall where for some things it's just easier to run without the firewall than with it (not that I'd do it, but I've seen it happen). Even something simple like OpenVPN over Windows Firewall in udp mode (the only decent performing mode in OpenVPN) is next-to-impossible to get running properly - the time you take to make it work is better spent installing a real firewall that can do the job (even ZA "just handles it"). A lot of servers are open but "hide behind" an external or hardware firewall on which necessary ports are then just opened. I remember trying to get my last workplace to install at least Windows firewall on clients and servers alike - the exceptions were already in place, the systems worked perfectly with it turned on, but they still wouldn't do it. Fortunately, they were behind an external firewall not configured by them - however a single virus could run rampant across the client PC's in a matter of minutes.

Fourth, most people have no idea what packets their networks send out to the world, or what ports are open - and they don't care until the day they notice that someone is accessing their system, which can be years after it was first compromised.

It's quite simple. If you can see it from outside your network, so can anyone in the world. If they can see it, they can attack it (and even sometimes if they CAN'T see it but know it's likely to be there!). If they can attack it and you don't update it, you could be in serious trouble. And even if you are firewalled off to the maximum, have up-to-date patches and proper security procedures attackers can still sometimes get through, but making their life as difficult as possible is not only fun but also productive.

Some people just don't care though. It's not going to change any time soon. Viruses and attacks are so common you hear things like "yeah, my laptop had a virus on it but I can't afford the subscription so I didn't bother clearing it up - made my computer a bit slow, though". Most people are just far too casual. You can even over-do the dramatics and explain possible dire consequences in exquisite detail. People go "Oh, really." and then carry on as they always have. Unfortunately, these people then go on to make websites for their friends, install servers for that charity down the road etc. and you end up with much worse problems.

Nobody cares anymore. Anyone serious will laugh at you if you're really that stupid to leave a server open to the world. The average joe doesn't know enough to see what you're laughing at and most people want things that work and sod the consequences. If that means running as admin with no firewall in order to save them having to learn about proper security permissions etc. then that's what happens - I know that every one of my users would make themselves admin given half the chance.

Hell, even my ISP blocks internet access to you if they see you have ports 137-139 open to the Internet and they take an awful lot of flak for it. They just redirect all your web traffic to a holding page that tells users how to fix the problem until they either a) fix it or b) tell the ISP to take it off. Guess which option is used the most?

Re:Doesn't surprise me

[AMuse]

>> First, there'll be a lot of database servers that are "supposed" to be accessible from the net for various reasons (which is ridiculous, yes, but there you go - at least use a whitelist of good IP's or something).

Look, I love security as much as any good paranoid guy, but what's with all the absolutism going on around here with regards to security?

"You should always whitelist IPS!!!" "You should NEVER EVER connect without SSH tunneling everything!!" "You must VPN to your data source!"

Some of us have to support groups of people for whom "SSH Tunneling" is like speaking an alien language. Some of their data is NOT so critical as to be the end of the world even IF it were exposed. Some of their clients won't support a VPN and even if it did, they'd forget to run it and call us for support all the time.

Computer security is the act of obtaining a balance between the usability of the system, the criticality of the data, and the needs of the owner of the data. If you can run a system with the DB port open to the world and mitigate potential threats through other means (IDS, SSL, strong passwords, chrooting, automatic patching, read-only access to nonsensitive data) then by god you are not doing anything wrong.

Some days it looks like computer security people are getting as bad as all the other zealots. "Microsoft is always evil", "Apple is always right", "If you have nothing to hide you don't need privacy" and "There's no excuse for a DB port to be public" all have the same thing wrong with them. They're absolutist and have no thought put into them.

Chicago

[deviantphil]

I saw David at the Information Security Decision conference in Chicago last week. He presented his findings there...he seemed quite geeked about it. I thought he might cream himself on stage he was so excited.

Printers too

[madleech]

That's nothing; while cleaning up a hacked windows server today, I happened across the IPs for a pair of Lexmark color laser printers. A little bit of digging later, I found they were wide open, sitting in the business centers at a couple of hotels in Washington DC.

My flatmate had great fun printing 40 pages of LOLCats transcontinental!

Next phase is to code up a genuine bit bucket: you pipe the bits in, they emerge goodness-knows-where from some poor sods randomly chosen printer :-) Might encourage them to secure things a little.

Re:Printers too

[cdrguru]

Absolutely. Cause as much havoc as you possibly can using this new toy "the Internet".

Do you wonder why people think only children are "online"? Oh, children, fraudsters and mischief-makers.

Yet Another Trumped Up Headline

[quangdog]

Of course there are many, many un-firewalled database servers on the internet - for all the reasons that have been stated in other comments it is frequently necessary to do so. However, the article does not point out if any other security techniques are in place at all with all the supposedly exposed databases.

Now, if the headline was "Half a Million Database Servers Left Configured With No Firewall, No Client Restriction, Default Root Credentials, and Listening on Default Ports" - then you have my attention.

Course, the sad fact is that my headline is probably just as likely to be true as the article headline, when you consider all the installs of databases other than SQLServer and Oracle (mysql, postgres, etc).

-- Kimball Larsen
http://www.kimballlarsen.com/

what about MSDE?

[alen]

SQL 2000 had MSDE, SQL 2005 it's Express Edition and i don't remember Oracle's name for it. Some desktop apps need a dumbed down database to write to and MS and Oracle let you distribute it for free as part of their app.

pretty sure most of these are just the lite versions of these databases on people's desktops or laptops while they are on broadband. a lot of devs also have dev versions of db servers. SQL 2005 Dev edition is basically the enterprise edition that lets you install it on XP and no limits other than a license

Re:what about MSDE?

[LurkerXXX]

Even the lite(express) version of SQL 2005 has TCP disabled by default. Only local pipes work by default. You have to explicitly enable TCP to allow other folks to connect.

Clueless researcher?

[flyingfsck]

Either this is the usual clueless researcher or a firewall vendor. Apparantly the real news is that half a million database servers are running some sort of Unix and are connected to the internet...

Re:Clueless researcher?

[wizkid]

David Lichfield has been a Database Security consultant, and is most likely responsible for forcing Oracle to actually fix a good chunk of there sloppy code. He's respected by a good chunk of the Security professionals, and probably considered to be a royal thorn for most the Database vendors out there. One thing he isn't is a clueless researcher. He's found and exposed (responsibly) many Oracle holes.

The security of any database, and application/front end be it web, financial or otherwise is a function of who sets it up. You can get away with putting a database in front of a firewall, if you lock the system down tight enough. I'm not recommending it, but it can be done using host based firewalls. The big question here is how many are out there that have been locked down??? If you can open a connection to the database from a anonymous remote host, it's not locked down!!!

Re:MORE open DBs please. And... SQL == language

[riffzifnab]

My bad, I should have said "install an SQL server" or maybe if I wanted to be really accurate "Microsoft SQL Server Desktop Engine", I was lazy. Yes I know SQL is a language used by a wide range of products, including a swath of OSS offerings. Now put your geek-peen back in your pants. d:

Re:MORE open DBs please. And... SQL == language

[riffzifnab]

On and before anyone grammar nazi's me (among other things) that should be "installs a SQL server".

And this is always a problem?

[CodeShark]

--as me first puts on the fireproof pajamas for the obligatory anti-PHP flamewar sure to follow--

How many of those are small, MySQL driven LAMP-3 setups -- you know, the kind that power millions of websites? Where a decent amount of care setting up Linux, Apache, MySQL, and the final P [whether that is Perl, Php or Python -- the three in the acronym above] good coding practices make the necessity of a separate firewall basically moot.

Re:And this is always a problem?

[Anonymous Coward]

How many of those are small, MySQL driven LAMP-3 setups[...]?

It depends. How many installations of MySQL listen on the MS SqlServer or Oracle ports? Zero? Thaaaat's it.

Re:And this is always a problem?

[Ephemeriis]

How many of those are small, MySQL driven LAMP-3 setups

Probably not many, considering they were probing ports specifically for Microsoft SQL and Oracle databases.

Re:And this is always a problem?

[RockedMan40]

" good coding practices make the necessity of a separate firewall basically moot." Well, I **MIGHT** go so far as accepting *perfect* coding might mitigate the need for a firewall, but never never never that a firewall is not needed. If you say you are a good coder, fine - I can go along with that. I am an excellent system engineer type - your code is only as good as the server I build for you. that firewall protects us both from 'accidental' misconfigs (we are human after all) and future exploits derived by a million script kiddies banging away at a million keyboards to eventually produce all the works of evil worm-coders everywhere.

Re:And this is always a problem?

[CodeShark]

oops. Missed that in my quick perusal, shoulda rtfa.

But firewalls are part of that hardening.

[Chabil Ha']

The firewall should be one of the first lines of defense. If that gets circumvented, you got all these other layers of defense in there. The firewall isn't the be all answer to security, it's a part of the complete armor.

Oracle is partly to blame

[illumin8]

Oracle recommends that you disable features such as iptables firewalls and SElinux, or else your database probably won't work. Stupid system administrators take it to the next level and leave it outside a physical firewall so that vendors/partners can access it. Authentication is usually done on an unsecured port 1521, where the username/password is sent in clear text. Very few sites even know how to enable encrypted database traffic on Oracle.

Oracle is mostly to blame with their idiotic processes that need rlogin access as root. Even though your Oracle database is running as user "oracle", it still needs to rlogin to itself as root every 2 seconds to run some unknown commands. The only way to secure an Oracle server is to completely firewall it off from the outside world and only let the application server talk to it.

Disclaimer: I'm a Linux sysadmin that builds Oracle database servers all day.

Re:Oracle is partly to blame

[hanshotfirst]

Very few sites even know how to enable encrypted database traffic on Oracle.

Also part of the problem is that Advanced Security Option (the part that encrypts DB traffic) is an extra-cost add-on. More cost? + More complexity? + Have to talk to my sales rep to decipher/haggle licensing? = Most shops pass on it.

Exception throwing!

[Walles]

Most C programmers don't bother to check the return of system calls like printf()

Most things shouldn't be written in C.

Don't know if printf() was the best example, but this is really the reason you want a language that throws exceptions when things go wrong. That either forces programmers to write error handling code (if the compiler requires you to catch a certain exception), or gives the runtime a chance to present a stack trace when an exception is thrown.

Instant maintainability improvement.

Re:Exception throwing!

[Algorithmnast]

Don't know if printf() was the best example, but this is really the reason you want a language that throws exceptions when things go wrong. That either forces programmers to write error handling code (if the compiler requires you to catch a certain exception), or gives the runtime a chance to present a stack trace when an exception is thrown.

C++ exceptions don't carry a stack trace with them - Java does.

In C++, we'd cover the code with unit tests and use exceptions to illustrate (via the unit tests) which sorts of uses would break the code. Using that feedback, we make the code bulletproof.

To be more precise - somewhere between the external interfaces and the core code there should be a line across which once you cross, all inputs are trusted. On the "outside" we can't trust the data, but we can once inside that line. Obviously verification is done at the place where we'd draw the line (or we can say it the other way around if you like: we draw the line where verification is done).

Inside the line we need not be as concerned about some error-checking - the checks for those conditions precluded by the verification we've done. But we still pay attention to things we can't control.

Cutting this short - I've just been given something productive to do. Hope this has benefited someone in the universe. :)

Re:Exception throwing!

[Walles]

C++ exceptions don't carry a stack trace with them - Java does.

There goes C++ off my list of recommended languages.

[unit tests, verification etc]

That's good practice independently of what language you're coding in. But when things fall apart for the customer (no amount of testing can prevent that), getting a stack trace and a more or less descriptive error message is really nice.

Good Point, but...

[keirre23hu]

Personally, I would rather have my webserver, which is designed to be publicly available, and quite easy to secure, available - vs. WormBait such as MSSQL. I can't think of one good reason to have your DB Server port open to the inet. Need to link it to a remote server? VPN... The argument about the only secure system being completly disconnected is true, but doesnt apply here. The point is there is something that the person managing the server want to make available, so there is inherent risk... the point is to take the "best" method to do that. The article is so much FUD, but doesnt excuse having the db port open to the inet.

Re:Good Point, but...

[EsbenMoseHansen]

Personally, I would rather have my webserver, which is designed to be publicly available, and quite easy to secure, available - vs. WormBait such as MSSQL. The fix in that case would be to switch MSSQL for a better database. postgress is free, and quite secure even on the internet.

Re:Good Point, but...

[Alan Doherty]

"The article is so much FUD, but doesnt excuse having the db port open to the inet." i dont't think the article is entirly fud as i have dealt with many clients who had their db port listening on their ip purely because the installers {application developers} never bothered to bind it to loopback so my estimate would be over 50% of the above mentioned open db servers WERE open and unaware, and it dosn't take too long to brute force the db {and unlike ssh ftp etc there are few with inbuilt reporting of attempted logins} {mitigating circumstance, most had ip-tables blocking access to {non-explicitly allowed} publicly listening ports. but most regularilly turned off ip-tables when developing/testing new services} binding the db porrt to loopback in all cases was a two second fix with zero impact on the webapp frontend. {this is just my experience others may differ}

Re:Good Point, but...

[toadlife]

[i]"WormBait such as MSSQL"[/i]

The last vulnerability discovered for MSSQL that could lead to a worm was many years ago. You must be confusing SQL with Oracle.

Re:Good Point, but...

[utopianfiat]

Why doesn't DB - Webapp - {internet} work? Why can't you have a DB on your local subnet?
This is particularly relevant since you could just as easily roll a couple virtual machines on the same subnet and just castrate the DB for internet access.

Re:Good Point, but...

[EsbenMoseHansen]

Why doesn't DB - Webapp - {internet} work? Why can't you have a DB on your local subnet?
This is particularly relevant since you could just as easily roll a couple virtual machines on the same subnet and just castrate the DB for internet access.

It might work, that would depend on what application we are talking about. It isn't really any more secure, though. It just means that instead of crackers having to crack the secure, well-tested db authentication (propably some assymmetric encryption based on a reputable library) they have to crack the webapp (or less likely, the web server). Webapps are not trivially secure.

So if I had, say, shops spread around with a central server keeping up a database for inventory and such, just exposing a reasonably hardened db to the net seems reasonable enough. That way, you could get cheap (dynamic ip) internet connections for each shop, and have an app connect directly from the shops to the db. It might be a better solution, it all depends.

Re:Good Point, but...

[cayenne8]

"Personally, I would rather have my webserver, which is designed to be publicly available, and quite easy to secure, available - vs. WormBait such as MSSQL."

Ahem...I think we were talking about real databases here.....

:-D

Re:Good Point, but...

[BronsCon]

I should patent this, but I'll put it out in the open, instead, as I'll likely never impliment it myself. Perhaps a substantial number of admins will see this and actually use it; maybe our personal and financial data will end up more secure. Yeah. Right.

Why not have a web app which simply acts as a proxy for the DB? Keep the DB login credentials out of the web app, entirely. Log into the web app over SSL and tunnel your DB queries through the web app. Seems simple enough to me; after logging in to the web app, you would still have to log into the DB, so compromising one doesn't automatically mean the other has been compromised as well.

If the web app doesn't default to a valid DB, but, instead, simply forwards queries to and from the DB server, it would require an attacker to know the login credentials for the web app and the login credentials of the DB. If the web app prevented listing available DBs, the attacker would have to know that ahead of time or be a good guesser. Likewise if the web app prevented listing of table and field names and types.

Once the database and the applcations meant to access it are created, working and deployed, there's no reason to allow such listings, anyway. If such listings are, for some reason, needed, they can be gotten by direct DB access on the internal network; there's no reason they should HAVE to use the web app internally, it would only have to be used by applications accessing the DB from a remote location.

Please, submit counterpoints; make corrections and additions. Let's give these admins something they can use to actually make their (and our) data safer.

Re:Good Point, but...

[afidel]

Yes, the number 8 overall and number 3,4,5,6,7,8 and 10 by price/performance database systems on the TPC transactional database benchmark is DEFINITELY not a real DB /duh

Re:Good Point, but...

[afidel]

Why not do a VPN? A VPN concentrator can be had for under $300 and remote sites can be connected with VPN gateways for under $100. Surely it is worth the piece of mind to not have your and your customers data exposed?

Re:Good Point, but...

[EsbenMoseHansen]

Why not do a VPN? A VPN concentrator can be had for under $300 and remote sites can be connected with VPN gateways for under $100. Surely it is worth the piece of mind to not have your and your customers data exposed? Because VPN have a lot of hidden costs, adds little or no security to the described setup and adds another point of cracking and failure? E.g., said contractor perhaps have a backdoor. He might not even know about it himself. Why add that 3rd party? Why have that extra costs, and extra fuss? Also, I have yet to see a totally transparent, never-fails, zero-setup VPN. Which means that the cost of the VPN is somewhat higher.

VPNs are good if you have an open internal, trusted network that you want selected machines on the internet to have access to, without having a clue to where those machines connect from. It's not a topology I'd recommend, but it's quite common. Of course, there might be more usecases.

Re:Good Point, but...

[EsbenMoseHansen]

I should patent this, but I'll put it out in the open, instead, as I'll likely never impliment it myself. Perhaps a substantial number of admins will see this and actually use it; maybe our personal and financial data will end up more secure. Yeah. Right. Don't worry, software isn't patentable here, yet :)

Why not have a web app which simply acts as a proxy for the DB? Keep the DB login credentials out of the web app, entirely. Log into the web app over SSL and tunnel your DB queries through the web app. Seems simple enough to me; after logging in to the web app, you would still have to log into the DB, so compromising one doesn't automatically mean the other has been compromised as well.

So you are adding a mediator. That means additional points of failure, another program that can be compromised (perhaps leading to a man-in-the-middle attack, steal the db credentials together with the webapp ones and use that?). I hope the extra step is worth it. Of course, there are the costs too: All those debugging hours to rule out (or in!) that it isn't the webapp that causes trouble. Then there is the state concern... webapps work on stateless transactions (in a sense) while db servers typically do not. So you have to bridge that gap, which isn't easy todo without adding information about the db in the webapp. Which again leads to more complexity in the webapp, which opens the way for more bugs. Remember, if you are going to add a mediator, make it *dead* simple.

If the web app doesn't default to a valid DB, but, instead, simply forwards queries to and from the DB server, it would require an attacker to know the login credentials for the web app and the login credentials of the DB. If the web app prevented listing available DBs, the attacker would have to know that ahead of time or be a good guesser. Likewise if the web app prevented listing of table and field names and types.
Sounds like you are unencrypting the transactions rather than wrapping them in the webapp --- how else would you know the forbidden requests?. Which means the queries are in plain text, leaving that webapp vulnerable for a fullblown crack.

Once the database and the applcations meant to access it are created, working and deployed, there's no reason to allow such listings, anyway. If such listings are, for some reason, needed, they can be gotten by direct DB access on the internal network; there's no reason they should HAVE to use the web app internally, it would only have to be used by applications accessing the DB from a remote location. That is security by obscurity. The article is probably better than I when it comes to explaining the cons and pros of that.

Please, submit counterpoints; make corrections and additions. Let's give these admins something they can use to actually make their (and our) data safer.

Done. I am a great proponent of KISS... keep it super simple ;) Keep the public and/or exposed interfaces small and simple, don't trust data from clients more than strictly necessary, and never store information you don't need. Passwords are a classic here: too many webapps still store the actual passwords. Use hashes. The same goes for creditcard information. You don't need to know the actual number, do you? You just want to know if it has been used before. So hash it. You only need the data in case the police comes by or something? Encrypt it using a public key, keep the private key somewhere else (a piece of paper in a bank box, e.g.), and make it really long. The police probably won't come a-knocking, so it's a good tradeoff. Plus, you can probably send the bill+a bit extra to them, so you're home free.

Re:Good Point, but...

[DragonWriter]

Why doesn't DB - Webapp - {internet} work?

If what you intend to provide on the internet is just a webapp, that architecture should normally work.

OTOH, if what you want to expose is a database to which other applications (web or otherwise) will attach over the internet, it clearly doesn't work. Admittedly, that's probably a rare use case, but there is no reason that you should be forced to build a webapp with a SOAP, XML-RPC, REST, or some other web-service interface and make your consumers code their software to that, when what you really want to do is expose a database to access across the internet and let your consumers code to the DBs normal TCP/IP interface.

Now, if your database is insecure, that's a problem with your database, just as it would be a problem with your web server if that was insecure. Using a web-service interface running on a web server that isn't vulnerable to exploits as a way of providing a gateway to data residing in a database server that is vulnerable may be a viable workaround for security problems with the database server, but I have to think that the best solution is to just use a database that is secure in the first place.

Re:Good Point, but...

[cecil_turtle]

This already exists, look into .NET Remoting for one example. I'm sure there are open source methods as well.

Re:Good Point, but...

[Anonymous Coward]

I don't think it is accurate it say MySQL is more secure than MSSQL. MySQLs security track record is abysmal at best. I at least cite sources to backup my retoric.

http://forge.mysql.com/wiki/Security_Vulnerabilities_In_MySQL_Server

Re:Good Point, but...

[pAnkRat]

No,

Coding direct to the database (layer) should only be done if the database (schema) is used for only one project.
Then, the DB should only be accesible to some restricted IP, most of the time this would be internal only.

If the DB (schema) will be used by multiple different projects,
it should be accesed over SOAP/XML/Rest/WhatEverProtocolDuJour _only_
Otherwise schema changes to the DB will affect more and more projects directly.
This would be the case for business, not for John Doe's Website.

Huibert Gill

Re:Good Point, but...

[EsbenMoseHansen]

You are arguing that adding an abstraction to the actual db helps keeping maintenance costs down. True, but not really a security concern. It is also something which is rather easily done with e.g. views, so the entire webapp can be saved, to the tune of millions of euros.

Re:Good Point, but...

[DragonWriter]

If the DB (schema) will be used by multiple different projects,
it should be accesed over SOAP/XML/Rest/WhatEverProtocolDuJour _only_
Otherwise schema changes to the DB will affect more and more projects directly.

If you can provide a consistent SOAP/XML/REST/etc. interface, you can provide a consistent interface at the database level, using views and related DB features. Ideally, at least; some db servers may be deficient in this regard, and of course you can work around this by using a web application to paper over server deficiencies just as you can with security deficiencies, but in either case you ideally shouldn't need to do that for technical reasons.

Re:Good Point, but...

[BronsCon]

Yeah, so, they steal the web app credentials. That gives them precisely nothinng. Rember, the web app does not store DB authentication info.

Further, communication over the internet, between the server requesting the data and the server running the web app would be encrypted via SSL. Communication over the LAN, between the server running the web app and the DB server could, optionally, be encrypted as well; they could also be the same server -- just firewall off everything but the HTTPS port. At no point does the data have to travel unencrypted. However, if you're truly that worried about internal data theft, you have bigger fish to fry than an internet-facing DB server.

The security gained from not leaving your DB directly accessible over the internet and preventing listing of available DBs and tables would be well worth the development and debugging time.

Further, if someone did compromise the web app and obtain DB credentials somehow, they would still have to obtain table names in order to access any data. I suppose that could, potentially, be quite simple to pull off internally, with or without the web app acting as proxy. To clarify an earlier comment I made in this post, if you're that concerned about internal data theft, you should reevaluate your hiring and security clearance procedures.

Nice strawman, though. I had to read it a few times to find the flaws in your rebuttal. Further, why are flaws found on some web apps which store passwords or credit card information relevant to this web app, which stores neither?

Thank you for providing such useful comments.

Re:Good Point, but...

[BronsCon]

Interesting, Microsoft itself touts it as being more efficient than web services but makes no mention of it being any more or less secure. The topic is security, so that's quite relevant, I should think. Admittedly, my research consisted of only two Microsoft sources and a Wikipedia article. I still find it disturbing that there was no mention of security whatsoever in any of them.

Re:Good Point, but...

[EsbenMoseHansen]

Yeah, so, they steal the web app credentials. That gives them precisely nothinng. Rember, the web app does not store DB authentication info. I agree that those would be worthless, but I can't see where I mentioned getting those would be a concern. Cracking the web app would, however be a major concern, as that might leave the door open to subsume the webapp (to log the db credentials or to log the dataflow)

Further, communication over the internet, between the server requesting the data and the server running the web app would be encrypted via SSL. Communication over the LAN, between the server running the web app and the DB server could, optionally, be encrypted as well; they could also be the same server -- just firewall off everything but the HTTPS port. At no point does the data have to travel unencrypted. However, if you're truly that worried about internal data theft, you have bigger fish to fry than an internet-facing DB server.

However, the data would still be in clear text at the webapp, so if the webapp is cracked, then any and all data read through the webapp woudl be available to the cracker.

The security gained from not leaving your DB directly accessible over the internet and preventing listing of available DBs and tables would be well worth the development and debugging time.

I do not know of any databases that offers that information without prior authentication. As that authentication requires db credentials, the webapp offers no additional protection.

Further, if someone did compromise the web app and obtain DB credentials somehow, they would still have to obtain table names in order to access any data. I suppose that could, potentially, be quite simple to pull off internally, with or without the web app acting as proxy. To clarify an earlier comment I made in this post, if you're that concerned about internal data theft, you should reevaluate your hiring and security clearance procedures.

I'm not that concerned... I merely maintain that the simple solution (e.g. postgres on the internet) is about as safe (or unsafe, if you prefer) as the complicated solution (webapp mediator). You gain a little by having an unusual setup, but loose some by making another attack vector available to the cracker.

Nice strawman, though. I had to read it a few times to find the flaws in your rebuttal. If it was a strawman, it was unintentional. I can't see what I've missed.

Further, why are flaws found on some web apps which store passwords or credit card information relevant to this web app, which stores neither? It was a tangent. I find that the only real protection against data theft apart from the usual encryption+authenticatino stuff is not having the data available in the first place.

Thank you for providing such useful comments. Likewise :)

IP Addresses

[Stooshie]

The IP addresses in the experiment were randomly created.

This means that their test could have hit some old woman's PC who happened to be dialled up over her phone line at the time, and using the IP address assigned to her by her ISP.

If she doesn't have a firewall, then of course the Oracle port could be open. Is this a security risk? Well if she only uses her computer for email then no.

Was an Oracle DB with customer's credit card details exposed to the world? Absolutely not!

I agree..

[keirre23hu]

the current state of things is not good... But its because money got involved. Where there is money, you can usually find corruption... All of a sudden people start breaking things with financial incentive (botnets, spam, etc) and it became a jumbled mess.

Re:I agree..

[baldass_newbie]

All of a sudden people start breaking things with financial incentive (botnets, spam, etc) and it became a jumbled mess.

You must be new to the game...script kiddies were cracking things long before there was financial incentives. The 'openness' of the gp's post is a pipe dream from before the first time one of his servers got nicked.

Links please...

[FlopEJoe]

There are nearly half a million database servers exposed on the Internet

Links please. thx

Um... Not exactly.

[Minwee]

Let's read the article and see what that headline really means.

Litchfield took a look at just over 1 million randomly generated Internet Protocol [IP] addresses, checking them to see if he could access them on the IP ports reserved for Microsoft SQL Server or Oracle's database.

He found 157 SQL servers and 53 Oracle servers.

He found open ports on just over 200 servers, which correspond to the ports used by two popular database servers. That's all. The article doesn't say that he actually connected to them, confirmed that there were real databases running there, or even identified the owners. He found two hundred open ports out of a million randomly chosen addresses on the Internet. But "0.02% of Internet Connected Computers May Or May Not Be Running Database Software" just isn't the kind of headline that grabs attention.

Unless there is a lot more detail, preferably from someone who isn't in the business of selling firewalls for databases, then you'll have to forgive me for not being terribly concerned about this revelation.

Re:Um... Not exactly.

[Anonymous Coward]

Insightful?

On page two of the article Litchfield discloses what percentages of the servers on these ports are unpatched (e.g. 4% of SQL Server databases were still vulnerable to the Slammer worm) or running unsupported versions of the databases. Obviously he did more than just check whether the ports were open.

Re:Um... Not exactly.

[Minwee]

"Obviously"?

That's a pretty big assumption with no supporting data.

Let me clarify. Without providing access to the actual data or any dropping any hint of the methodology beyond revealing the alarmingly small sample size (Here's a tip: That 4% of SQL Server databases would correspond to six actual servers if that statistic were based on the 2007 survey discussed on page 1. 13% of Oracle servers which are running unsupported releases? That's also six.) there's nothing more to see here than a salesman screaming about how everybody in the world needs to buy his product.

David Litchfield's work could be as legit as it comes, but none of it is in the linked article. Until he actually releases his survey to the public, instead of just leaking a few sound bites to the media, the conclusions are worth nothing.

So what?

[Ed Avis]

Why on earth should a database server need a firewall? Last time I looked, DBMSes required a login with a username and password before giving any access. I hope that the days of default passwords like scott/tiger are long gone, and if not, you should get a more secure database rather than masking the problem with a firewall (which does nothing to protect against internal attacks).

Hopefully the DBMS supports SSL or other encrypted connections so outsiders can't eavesdrop or hijack sessions.

Re:So what?

[scottmillerinva]

I guess the question I would have is why would the DB server even be on a publicly accessible network? While most posters are correct that DBs require authorization, best practices would dictate keep private data on a separate network. I would imagine a lot of these DBs are session state data and app config DBs. Either way, there is never a need to have your DB with an Internet accessible IP.

Re:So what?

[Ed Avis]

If you were talking about a genuinely separate network - air wall security - then I'd say you are often right. But I don't really see the difference between having a database server on a publicly accessible network with tight login security, versus putting it on a so-called 'private network' and then setting up VPNs and tunnels so that it's publicly accessible after all. That just moves all the authentication into the VPN. It's an advantage if you don't trust your database server to behave securely, but it would be better just to have a sensible authorization mechanism such as Kerberos on the database.

Re:So what?

[TheFuzzy]

Ed,

Sorry, no.

Speaking as a database contributor (PostgreSQL), databases should absolutely secured at the network level. If not by firewall, by making them only available on localhost, or only by VPN or SSL connection.

DBMSes are designed to be feature-ful, fast, and secure ... **in that order**. Which means that no DBMS is designed to stand up to a protracted, determined, knowledgable attack on an open port (athough some of us do better than others). At the very least, an attacker could DOS you by simply attempting a connection thousands of times a second, forcing the database to fork processes or threads.

Further, the most popular DBMSes (SQL Server, Oracle and MySQL) pretty much always have outstanding security exploits on their bug lists, and far more which were patched in the most recent update most people haven't applied. Even we fix 1-2 exploits per update these days, some of which are quite dangerous with an attacker who really knows their stuff.

Developers are *terrible* about setting good DB passwords. I absolutely can't tell you the number of times I've seen "temp/temp" as an authentication string in a production database, or "trust" authentication for the right IP (which can be spoofed) because a developer wanted a back door which didn't require typing his password.

For that matter, web developers are supposed to set up different permissions for the web user vs. the database owner, but this is a rare thing to see in practice.

So it's *way* important to firewall your database. Better yet, don't have it listen to the internet at all: set up the database to only listen to localhost or the private network.

--Josh Berkus

Re:So what?

[Ed Avis]

Yes, configure your database to listen only for connections on localhost. If you are moronic enough to leave it listening to the whole world and choose obvious passwords (or put the password directly in your program code which may then get leaked), then I guess a firewall would help, but it would be better just not to be stupid in the first place.

I agree with most of the points you mentioned, I just disagree with the tone taken by the article which is 'OMG database server with no firewall!'. If it's securely configured, it doesn't need one. And if it's badly set up, then you should just apply some common sense and fix it... sadly this doesn't generate enough money for firewall vendors.

I also don't like the way it refers to 'without protection' as if security were some thing to be applied afterwards like a coat of paint. I guess it's psychologically appealing to have some button in a control panel that says 'enable protection' and you don't have to think about it.

What difference does it make?

[mcrbids]

Why would a development system be any less likely to facilitate the spread of a worm than a production one? Other than the reduced risk of a negative data breach, what's the difference?

But furthermore, how many of those development servers contain slightly-stale copies of "real" production data?

Re:What difference does it make?

[Anonymous Coward]

Why would a development system be any less likely to facilitate the spread of a worm than a production one? Other than the reduced risk of a negative data breach, what's the difference?

It wouldn't, but I'm using it all day long so I'll notice it grind to a halt, and I (or anybody else) can take it offline. If we take a dev or test system down for a few hours to re-image it, our customers aren't hurt.

Alternatively: sad truth is that many production systems are still Windows, while many devs insist on Linux. Yes, I would trust a non-firewalled Linux system more than a non-firewalled Windows system.

But furthermore, how many of those development servers contain slightly-stale copies of "real" production data?

At the companies I've worked for, zero. Developers aren't allowed to see real data. We get "sanitized" copies of production only. Passing around prod_db is a security risk for other reasons, and it's simply inconvenient to pass around a 100GB database when a 10MB sample db can show you all the corner cases just as well.

Might I introduce you to SSH

[SmallFurryCreature]

A webserver needs at most three ports open, 80, for obvious reasons, 443 for https and 22 for ssh. That is it.

If you need to connect remotely to another service you do it via SSH.

Mysql is a database. Let it do databases. Let SSH do its job.

When I see people use your logic you make my jaw drop. SSH for live. EVERYTHING over ssh. ALWAYS. Full stop, end of story. No argument.

Exposing your database like this is insanity and you are asking for trouble. Mysql authentication is a joke and considering you are doing it this way, you probably have it setup wrong. Because what you are doing is wrong.

Tunnel over SSH. It is a most basic tool. Read up on it, NOW! Google: mysql tunnel ssh

Offcourse, next thing he will say is that he uses telnet for remote access, some admins would make ghandi loose his temper

Re:Might I introduce you to SSH

[Anonymous Coward]

I run Windows 2003 Server. What's this SSH thing? Is it under program files?

Thanks!

Re:Might I introduce you to SSH

[AMuse]

Absolutes are fun and all, but not practical. Sometimes you DO need your DB port exposed to the world. Sometimes SSH is not the answer, as much as I LOVE ssh.

For example, solve this problem using only SSH.

========
You are a volunteer for an animal rescue with, at most, 2 hours per week of spare time to support them.

The best free software currently available to support an animal rescue (http://sheltermanager.sourceforge.net) uses a MySQL (or Postgres) database to allow the Java client software to store data on animals, owners, surrenderers, finances and shelter operations like veterinary care.

There are 40 volunteers around the state doing data entry. They are not computer literate in any sense, but know how to use windows to double click the "Run my app" icon. Since they're working from their homes on their personal computers, they run versions of windows running from 98 to Vista. Also, some of them are on Macs. Since they're on Cable/DSL/Dial-up they will all have dynamic IPs. Some leave their software open for days at a time. They will stare at you blankly when you say things like "Run SSH first" and will constantly forget their "ssh" passwords. Some have wireless networks and laptops at home, and SSH timeouts become an issue when trying to SSH tunnel.
========

Now, I solved that problem by configuring the database client software to talk to a MySQL server with "REQUIRE SSL" for the database connection, and left the database port open to the world (GASP!!). However I keep the database patched frequently, I require SSL, I use strong DB passwords and have an IDS checking for brute force attempts. The root login is bound to localhost.

What's your practical, workable solution given the constraints above?

Re:Might I introduce you to SSH

[Lord Ender]

You allow ssh to be directly exposed to the internet? You've already been hacked. Check your ssh logs. I bet someone started bruteforcing your passwords within four hours of your box going online.

You should be requiring two-factor authentiction, either with smartcards or with one-time-passhprase fobs for ANY remote connections in to your internal network.

Re:Might I introduce you to SSH

[Hornes]

You might be able to implement a web service to expose only the logic of the application rather than the database itself. Authentication is provided by the web service, I believe. More info on security can be found here

Re:Might I introduce you to SSH

[ngunton]

Your reply might have prompted a reaction from me of "Hey, that's interesting, thanks for the tip". However the shrill and overly aggressive tone of it just left me cold, instead thinking "Wow, what an asshole" regardless of any actual points you might have had.

Here's a clue: You don't convince people by shouting at them, telling them they are completely, utterly, totally wrong (especially when the world really isn't as black and white as you are suggesting). I'm guessing you might the the type of person who would also try to tell me I'm completely, utterly wrong for using MySQL at all. I've long given up trying to reason with zealots.

In point of fact, your post is a good example of why I don't post all that much on slashdot or reddit any more. It seems that many people who "debate" online have given up on civilized discussion and instead jump straight to the kind of cut-throat, over-the-top, spittle-flying shouting match that typifies television "news" these days.

See, we could be talking about the technical merits of your argument, but instead you got me going on how you come across like a total dick.

Could the job be done using ssh tunneling? Probably, undoubtedly so. Does my setup work just fine for what it's doing? Absolutely, for the last eight years in fact. For me, the MySQL security model works just fine. As I said, I'll be using the SSL feature anyway as soon as I can get around to rebuilding MySQL with SSL enabled.

And incidentally, it's "lose", not "loose".

Bye now.

Re:Might I introduce you to SSH

[Anonymous Coward]

why not ssh for www access then motherfucktard?

a service is a service - the code is where the bugs are..

have you personally audited the authentication code path in HTTPD abc & mysql?

(or ssh for that matter)

why is one therefore better than another?

Re:Might I introduce you to SSH

[RajivSLK]

I would firewall the world and then set up a little web accessible script that would white list their IP.

When a user connects from a new place they would visit the login.foobar.com and then open up the application. It's an extra step, sure, but not super hard.

Cheers,
Rajiv

Re:Might I introduce you to SSH

[smellotron]

You should be requiring two-factor authentiction [sic], either with smartcards or with one-time-passhprase fobs for ANY remote connections in to your internal network.

Bah! I say if you want to send a remote connection, the only secure way to do it is TCP over snail mail through a trusted human relay (who will the netcat the data from his local desktop to the appropriate server, or bounce the mail). It's even better if you can convince the trusted human relay to just bounce everything.

Re:Might I introduce you to SSH

[Lord Ender]

Two factor authentication is the standard for any large company, these days. You're out of touch with the state of technology.

Re:Might I introduce you to SSH

[smellotron]

You're out of touch with the state of technology.

On the contrary, I don't think I've never really been in touch with the state of technology (in this particular arena) to begin with. I'm not an admin. My point of view is coming from the fact that to log in remotely at my present job, I need the little keyfob, plus a PIN to go with it, plus my Windows domain login... then my windows domain login again, because apparently the first time through wasn't enough to convince the system that I am me. There are many possible levels of security to select, and the more secure ones do come with increased cost. Not all companies are big, and if it's cheaper to just use SSH (or a VPN) and enforce strong passwords, then that may be more appropriate than fully-fledged two-factor authentication.

Re:Might I introduce you to SSH

[Anonymous Coward]

When I see people use your logic you make my jaw drop.

I might say the same about you. Running SSH on port 22 is a SUREFIRE way to get owned. It's a million times worse than an open database port. You clearly don't know what you're talking about if you can even bring yourself to talk about SSH as a security measure without mentioning this hugely important issue.

Exposing your SSH server like this is insanity and you are asking for trouble. SSH password authentication is a joke and considering you are doing it this way, you probably have it set up wrong, because what you are doing is wrong.

SSH must be put on a nonstandard port. It is a most basic concept. Read up on it, NOW! Google: ssh different port

Of course, next thing he will say is that he was trying to keep things simple for us tech-illiterate folk at Slashdot, condescending piece of shit that he clearly is.

Re:Might I introduce you to SSH

[digital bath]

Yea, he was kind of a douche, sorry about that. His points are extremely valid, though. I urge you to read up on SSH a bit - it would do more for you than recompiling mysql with SSL support would. An ssh tunnel is encrypted (that's the point) so no need for SSL support - plus, you get the added benefits that come with an extremely well tested security service.

Good luck with whatever you choose!

Exploits

[coyote-san]

The problem isn't remembering to change the 'sa' account password, or using an encrypted connection. It's the possibility of exploits that don't require account access at all. Hidden backdoors, DOS attacks by flooding the port with connection requests, even deliberately sending bad packets that take down the server. That's why you want the minimum necessary exposure for servers even if you have strong access controls within the application.

That said, I agree with everyone who says that you should also set up good security on the database server. E.g., the accounts with remote access may be limited to read-only views with stored procedures to create/modify records. This limits the damage even if somebody manages to get remote access since they can't just truncate tables or do blanket updates -- they have to trigger the correct stored procedures.

bad design

[pak9rabid]

If your application follows the n-tier or MVC architectures, there's no reason for your database server to be exposed in the first place. No database should ever be accessible directly from the Internet..ever. If you feel differently, then you probably need to reevaluate your design strategy.

Re:bad design

[smellotron]

If your application follows the n-tier or MVC architectures, there's no reason for your database server to be exposed in the first place. No database should ever be accessible directly from the Internet..ever. If you feel differently, then you probably need to reevaluate your design strategy.

I feel differently. Why should I write an application server on top of my database, when all of my real processing fits perfectly well (and is completely expressible) via a combination of views and stored procedures? If I give someone a database schema and a set of stored procedures they're allowed to call, I've simplified the API. I can switch my internals from Python to Ruby to Perl to C and none of it matters, because I'm using the database as the API.

The architectures that all involve using a database as a dumb storage device all assume that the database vendor can switch at any moment. I take it the other way... the database isn't going anywhere, but the languages used to work with it are easy to change. Of course, this involves using something at least as powerful as Postgres, and preferrably more (since PG is, afaik, still working on the permission system with functions).

Why a Firewall Anyway?

[Nom du Keyboard]

Why a firewall anyway? Why not just have computers that don't respond to ports where authorized programs aren't listening?

Re:MORE open DBs please. And... SQL == language

[Anonymous Coward]

I thought you use "an" when the following word begins with a vowel sound. So "an SQL..." would be correct. You would use "a" for following words that begin with an actual vowel, but do not have a vowel sound: "a Unicycle".

'Database Servers'

[hatchet]

The headline should read: Half a Million 'Database Servers' Have no Firewall.

Lets be honest here, only small percentage of those computers are actually servers, and of those that are - many have port 1433 port open for something other than database.

You install microsoft visual studio express, get SQL express to go along with it and because you don't have that stupid MS firewall enabled you automatically fall into beforementioned group. Newsflash, not every computer on internet is a server. And not every installation of SQL database has any data in it to live up to it's name.

Perfectly reasonable behaviour.

[EddyPearson]

"There are approximately 368,000 Microsoft SQl Servers... and about 124,000 Oracle database servers directly accessible on the Internet" Any DBA worth his salt KNOWS how to secure a SQL server without a firewall. Its not like 'sa' was left with a blank password and remote access enabled on these, its just an open port. One of our DB servers has port 1433 open to the WAN (it was that or a site to site VPN), it is perfectly secure, even if it wasn't a complete muppet could secure a default SQL Server install. Buy get this! I've found literally millions of servers with port 80 open to the WAN! I gather it's used for an rather obscure protocol called HTTP. If I take a random sample of 1000 HTTP and SQL servers, I'll bet I'd get more webservers I could break into than SQL Servers (simply because there are many more attack vectors for HTTP, insecure scripts etc). This article draws attentions to absolutely fuck all. David Litchfield is a well respected security researcher, I don't know why he see's this as such a big issue, that is, unless he's sitting on a 0day remote SQL server exploit, but I won't hold my breath.

Did the kids just get out of school or something?

[Curmudgeonlyoldbloke]

I can't believe I'm reading so many "why do I need a firewall on an Internet-connected database server" comments above.

Yes, the article looks like just a press release based on dubious extrapolation of data, but it doesn't mean that it's OK to have your company's application servers around the world capable of being accessed by anyone else around the world. If you trust Oracle, IBM, Microsoft or whoever else to write bug-free code you're a braver man than I.

And?

[ceeam]

Theoretically - there's nothing wrong with that. DB server is just another TCP server and most of those have their own security layer (user/pass etc) built-in. If not for bugs and exploits, and provided that you change default passwords, it's pretty OK.

Why is a firewall for an exposed port a must?

[Anonymous Coward]

If for whatever reason you want remote access to the DB server, you need to allow access on that port anyway. So if the DB is the only service on that server, a firewall is superflous.

Re:MORE open DBs please. And... SQL == language

[DragonWriter]

On and before anyone grammar nazi's me [...]

I don't think you've made that any less likely with that post...

Re:MORE open DBs please. And... SQL == language

[CarpetShark]

I was lazy. Yes I know SQL is a language used by a wide range of products, including a swath of OSS offerings.

Did you ever consider that it's exactly this kind of laziness which microsoft is counting on, when it uses generic names like "SQL Server" and "Windows" and "Word" for it's products? Your laziness makes you the puppet of a corporation which does harm on a daily basis, and yet you insult the people who simply point out the issue to you, trying to help you out. And I was trying to help you out, if you read my comment again.

We can thank him for Slammer

[gravyface]

Litchfield, who wrote the proof of concept code that was eventually used by Slammer, said that this many unsecured databases is enough to sustain another worm outbreak.

Database security

[kilodelta]

Back when I was managing several MySQL servers I was horrified to learn that the original setup used localodbc/localodbc for the database passwords for pretty much everything. In fact it had universal access to ALL databases with S,I,U,D! And they depended on an ancient SonicWall firewall to protect them.

Did an inventory of all databases and then went out and found out who did what to those databases. Created individual logins with express rights (Select, Insert, Update, Delete). Web apps if they were lookup only just got Select, whereas those who wrote would get Select, Insert.

We also blocked port 3306 on our Pix firewall. Good luck hitting those MySQL boxes. Servers have separete networks for internal and external traffic so web servers can communicate with database servers but people outside can only see the web server.

I say its FUD because

[keirre23hu]

The scanning method he used is not conclusive that all of the "hits" were vulnerable db servers. Also he only scanned for MSSQL and Oracle, What of Sybase, MySQL, PostGres, DB2, and all manner of other systems? MySQL has had a remote vuln in the past - I'm sure somewhere on the inet there are vuln versions running. I cant speak of the others. The bottom line is that his "research" misses a significant portion of whats running out there. How do you not add MySQL, when LAMP is a pretty prominent application foundation. I also dont see anything conclusive in TFA to show that it was more than verifying the port was open - how does he even know its actually the database running there? He specifically states that corporate data is at risk, but he randomly chose IP ranges, would it not make more sense to randomly chose IP ranges from those known to be corporate networks? (info is available - ARIN, RIPE, APNIC, etc). Without a more rigorous study the article is most definitely FUD, as you cant definitively draw any conclusions from the results. What the article does do, is causes a good discussion about why people should be more security-aware.

Begin Sarcasm: Because noone uses older

[keirre23hu]

unpatched versions of MSSQL. I am sure that all the shops apply all MS patches and update their software regularly according the MS Product Cycle. :End Sarcasm

Oracle security is a direct function of the DBA/SA's skill

I guess you could say the same for MSSQL, but this is slashdot, whats the fun in that?

Security genius, mathematical idiot

[Anonymous Coward]

His maths is screwed

>> Litchfield then relied on known estimates of the number of systems on the Internet to arrive at his conclusion:

Why did he do this? To get to the numbers he got to he would have to assume that 69% of the available inet addresses are in use (2.3 billion addresses). i.e. 368,000/157 = 2344 - each of his 1,000,000 addresses represents 2,344 other addresses giving 2.3 billion

Unless he knew otherwise he would also have to assume that only 69% of the address you valid (obviously you would have no idea unless you got the information from the owners or the net block owners), making that step unnecessary. The other explanation is he assumed 100% of his IP address are valid, which reduces his figure by 31% (from 655,000 to 500,000) - obviously there is no reason he would do that.

This leads me to believe that he must have some how ascertained that 100% of his generated IP address were valid e.g. by pinging them. The fact that could get a response from them means that he ignored all the well secured machines that would give no response to a ping.

This 'reputed' expert may know a little about security. I don't think he knows a thing about statistics (except in the 'lies, damned lies & ...' sense).

Re:MORE open DBs please. And... SQL == language

[riffzifnab]

Yeah I should have realized it was pointless and just hoped no one noticed. Looks like I might have been in the clear anyway. [shrug]

I cant argue with that..

[keirre23hu]

and no definitely not new to the game.. but security didnt become the big scare tactic that it is today until money got involved. Noone could possibly do double-digit time for port-scanning and things of that nature before Internet == Commerce. When big money got involved, all of a sudden there were financial transactions, billions of dollars of them, going on, online every day. And all I was saying is with the money comes the scrutiny (and the crooks).

Numbers Don't Work

[Anonymous Coward]

From 1 million random IP addresses. "He found 157 SQL servers and 53 Oracle servers. Litchfield then relied on known estimates of the number of systems on the Internet to arrive at his conclusion".

Results are only valid within the scope of the 1 million random IP addresses. Extrapolating out is a very poor assumption for a researcher to make. Within the data set, approximately 0.021% of those IP addresses had an SQL or Oracle server that is Internet facing.

Part II, and the real research, would seek to determine how many of those IP addresses HAD database servers that were NOT Internet facing. (E.g. Otherwise, we all well know the average human has approximately one testicle and one ovary).

Re:MORE open DBs please. And... SQL == language

[riffzifnab]

I'm sorry if you thought I was insulting you, that was not my intent. If you took offense please accept my apology. You'll note the "d:" at the end of the post indicating I'm joking about the geek-peen thing.

Unscientific

[Coolhand2120]

What random blocks were dipped into? What % were dynamic and what % were static? What % of the hosts scanned were 'fake' computers, honeypots? How can you tell if a server isn't behind a firewall that 'looks' just like another server? A lot of people, myself included, use loads of honeypots to confound hackers. For each REAL service I may have 2 or 3 honypots. I have a mail server that reports itself as no fewer than 5 different types of mail servers, and it's not even a real mail server, just something for the script kiddies to bounce off. Same with www, sometimes it's an Apache server, sometimes it's an IIS server, sometimes it's an Apple, sometimes it's a Sun. Knowing how much deception I place in my own network I wouldn't be surprised to find that half of the 'stats' dude has gathered (using what? nmap? eeye? who knows?) are just honeypots. And No, I don't keep the ports up to date on the fake machines, they are there to waste the time of, and identify, a would be hacker.

Disable mysql external access with skip-networking

[dananderson]

Disable mysql external access by adding this line to /etc/my.cnf :
skip-networking

This will prevent external access to MySQL, firewall or no firewall. All access will go through Unix sockets or named pipes. Restart mysql with /etc/init.d/mysql restart For me, no other configuration was required for several mysql-consuming apps, including php custom scripts, phpbb, phorum, and sympoll.

Where are the OSS databases?

[Dr_Barnowl]

Until they rank OSS databases on TPC-C alongside Oracle, DB2, MSSQL and Sybase, it isn't a valid comparison. But of course, many of the commercial RDBMS vendors have a clause in their license agreement forbidding you to publish benchmarks, so it makes sense that their chosen publicists (the TPPC) don't publish price/performance data for OSS servers ; when the bulk of the cost of your server is the per-CPU DB license, it can really make your price / performance ration look inadequate going up against free software.

Yes, MSSQL is still a real database.

Re:Where are the OSS databases?

[afidel]

Huh? only 9% of the cost of the #3 system on the price/performance listing is DB licensing ($6,000 of $68k) and that's with ZERO discount, standard open license discount is 28-33% so realistically it would only be ~6% for most companies. Granted at the high end you can pay quite a bit for CPU licenses, but then your generally going to be taking advantage of features that aren't available at any price from the OSS DB's.

Re:Where are the OSS databases?

[afidel]

I know it's bad form to reply to myself but the #1 overall system is similar as far as overall cost percentages, the Oracle licensing is $1.5M before discount of ~40% or about $900K out of a total system cost of $12M. Again the cost of the DB licenses is less than 10% of the overall system cost. For a company that is going to run their financials on one of these DB's there's just no incentive NOT to run the commercial DB, it's drops in the bucket in the overall system cost and the support contracts and name generally make the suits happy.

Unfirewalled Excel spreadsheets by the billions

[Michael O'Neill]

This is article is pointless. Presuming that because a database exists, that it means there's meaningful data at risk is irrational. How many unfirewalled Excel spreadsheets are on the Internet? I submit that 499,990 of the half million databases at risk have no meaningful purpose (or data). Databases are just that easy to spin up.

RE:Firewalls

[Nonillion]

"There are nearly half a million database servers exposed on the Internet, without firewall protection according to UK-based security researcher David Litchfield."

What?! Sheesh, now I suppose you're going to tell me that I cannot have a Windows box without virus / spyware / firewa &^%@@***Mh^^

NO CARRIER

Firewalls: Security through obscurity.

[MacDork]

An extra layer of security doesn't hurt, especially against the bugs we don't know about yet - most bugs/security flaws weren't know about/understood prior to being fixed, and prior to fixing, they could have been exposed.

I disagree. Why should I have to create an access control/permissions system when any proper database includes one? If the database's permissions system and security model fails over and over again, why continue using it? Wouldn't it make more sense to blame the vendor and change databases rather than blame the IT staff and patch the hole with a bandaid solution like a firewall?

In true PHB style though, firewalls are standard procedure. All firewalls effectively do is force all your traffic through some ridiculous port 80 xml-rpc/soap solution written in house that is going to be slower and just as prone to security holes, if not moreso. The only reason it seems secure is because it isn't a "standard" entryway that script kiddies are attacking. Security through obscurity is not security.

All you really have is a false sense of security until you're pWn3d by a dedicated attacker. In the meantime, you've ruined the efficiency of the network because applications that might have been able to listen for updates must resort to constant polling instead. You bandwidth needs explode as a result and that costs you lots of money.

Re:Firewalls: Security through obscurity.

[circamoore]

If you can backdoor the system by working over port 80 then your security policy isn't doing it's job. An internal server is an internal server whatever port it is listening on.
A firewall ensures that you only expose what you "officially" intend to expose (a firewall that simply filters port without checking IP is only half a firewall).

Re:Firewalls: Security through obscurity.

[Anonymous Coward]

A firewall ensures that you only expose what you "officially" intend to expose

If a network is vulnerable without the firewall, it is still vulnerable with the firewall.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:MORE open DBs please. And... SQL == language

[smellotron]

Did you ever consider that it's exactly this kind of laziness which microsoft is counting on, when it uses generic names like "SQL Server" and "Windows" and "Word" for it's products?

Having talked about databases with co-workers and friends enough, I would say that anyone even semi-professional understands by context that "SQL Server" refers to MSSQL specifically (actually, I've heard some people just refer to it as Sybase, but that's another issue). The only place I've had any ambiguouity was with one friend who was a new Windows admin, and didn't really understand the concept of SQL itself yet. So i guess... yes, you are correct; the generic names add some confusion. But it's nothing to get your panties in a bunch about, because it naturally weeds itself out as skill level increases.

Anyways, I'm a fan of straightforward names. I'd rather they call it "SQL Server" than something gimmicky like "RaptorServ". One of those is an accurate description of the role the product fills; another is... acceptable as a codename for a product, but certainly not for an end product. I've seen blogs where Visual Studio developers refer to Orcas, and before I knew that Orcas meant "Visual Studio 2008 development", I was completely lost.

Re:MORE open DBs please. And... SQL == language

[CarpetShark]

Well I guess we'll have to agree to differ on that then.

Simple rule to keep in mind

[trolltalk.com]

1. First-rate people hire first-rate people
2. second-rate people hire 3rd-rate people

Its the best indicator that "the smell of death" has attached itself to a project|company|whatever.

Re:Simple rule to keep in mind

[COMON$]

LOL, best quote of the day. You get a friend modifier for that one.