Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Half a Million Database Servers 'Have no Firewall' 322

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."
This discussion has been archived. No new comments can be posted.

Half a Million Database Servers 'Have no Firewall'

Comments Filter:
  • by Alphager ( 957739 ) on Wednesday November 14, 2007 @08:48AM (#21348537) Homepage Journal
    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
    • by phasm42 ( 588479 )
      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.
      • by trolltalk.com ( 1108067 ) on Wednesday November 14, 2007 @09:16AM (#21348759) Homepage Journal

        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.

        • Web Services? (Score:5, Informative)

          by keirre23hu ( 638913 ) <{j2k4real} {at} {gmail.com}> on Wednesday November 14, 2007 @09:20AM (#21348793) Homepage
          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? (Score:5, Insightful)

            by trolltalk.com ( 1108067 ) on Wednesday November 14, 2007 @09:58AM (#21349175) Homepage Journal

            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.

            • Good Point, but... (Score:5, Insightful)

              by keirre23hu ( 638913 ) <{j2k4real} {at} {gmail.com}> on Wednesday November 14, 2007 @10:09AM (#21349285) Homepage
              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: (Score:3, Funny)

                by cayenne8 ( 626475 )
                "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:Web Services? (Score:4, Interesting)

              by beh ( 4759 ) * on Wednesday November 14, 2007 @10:28AM (#21349459)


              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).

            • 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 app
              • Re: (Score:3, Informative)

                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 [mysql.com] - 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

          • Re: (Score:3, Insightful)

            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: (Score:3, Insightful)

          by MightyYar ( 622222 )
          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?
        • 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
        • This is what VPNs are for.
          • Re: (Score:3, Insightful)

            by plague3106 ( 71849 )
            I don't understand why everyone says to use VPNs when most decent database servers offer encrypted connections already.
        • by COMON$ ( 806135 ) * on Wednesday November 14, 2007 @09:57AM (#21349171) Journal
          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.

          • 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.

          • by Nazlfrag ( 1035012 ) on Wednesday November 14, 2007 @05:51PM (#21356107) Journal
            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.
        • 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 [wikipedia.org]. You never rely on a single point of failure, such as the authentication system of your database server, to protect yourself.

        • 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 se
    • Re: (Score:3, Informative)

      by myspys ( 204685 ) *
      You have.

      The more logical (and secure) solution would be

      {internet}
            |
      app-servers
            | (internal network)
      db-servers
      • Um, not quite. You missed something too:
        the proper setup looks like this
        {internet}
        |
        firewall
        |
        app-servers
        |
        db-servers
    • Chicago (Score:5, Funny)

      by deviantphil ( 543645 ) on Wednesday November 14, 2007 @09:49AM (#21349073)
      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.
  • what? (Score:2, Funny)

    by FudRucker ( 866063 )
    no comments?
    • Re:what? (Score:5, Insightful)

      by Anonymous Coward on Wednesday November 14, 2007 @08:59AM (#21348631)
      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? (Score:5, Insightful)

        by nurd68 ( 235535 ) on Wednesday November 14, 2007 @09:08AM (#21348701) Homepage
        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? (Score:5, Interesting)

          by ByOhTek ( 1181381 ) on Wednesday November 14, 2007 @09:54AM (#21349127) Journal
          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.
          • by nurd68 ( 235535 )
            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
          • 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.
        • 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.
      • Re: (Score:3, Insightful)

        by ByOhTek ( 1181381 )
        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 in
  • Not Suprising (Score:5, Informative)

    by Algorithmnast ( 1105517 ) on Wednesday November 14, 2007 @08:51AM (#21348563)

    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 [artima.com] 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 (Score:5, Insightful)

      by faloi ( 738831 ) on Wednesday November 14, 2007 @08:57AM (#21348607)
      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?"
    • by ajs318 ( 655362 ) <.sd_resp2. .at. .earthshod.co.uk.> on Wednesday November 14, 2007 @09:37AM (#21348943)

      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.
      • 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

        • Re: (Score:2, Insightful)

          by lwriemen ( 763666 )
          > 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 log
          • by Ed Avis ( 5917 )

            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'.

            Th

        • by pherthyl ( 445706 ) on Wednesday November 14, 2007 @11:54AM (#21350689)
          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: (Score:3, Insightful)

          by Just Some Guy ( 3352 )

          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: (Score:3, Insightful)

        by Ed Avis ( 5917 )
        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 (Score:5, Insightful)

      by failedlogic ( 627314 ) on Wednesday November 14, 2007 @09:39AM (#21348967)
      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.
      • by vadim_t ( 324782 )

        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 the

      • by mgblst ( 80109 )
        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: (Score:3, Insightful)

      by Ngarrang ( 1023425 )

      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

    • 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

      • 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 h

    • 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.

      • 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. Obvious

  • by daveewart ( 66895 ) on Wednesday November 14, 2007 @08:52AM (#21348573)
    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...
  • How many of these are production systems and not just developer's toys? If production systems, how many are mission-critical?
    • by deniable ( 76198 )
      More importantly, how many of them were extrapolated. He 'polled' 1 million random IPs and went from there.
    • Re: (Score:3, Interesting)

      by tgatliff ( 311583 )
      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
    • 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?
  • Yawn (Score:5, Insightful)

    by riffzifnab ( 449869 ) on Wednesday November 14, 2007 @09:00AM (#21348641) Journal
    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.
    • by J0nne ( 924579 )
      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).
    • by Gollum ( 35049 )
      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 p
  • Is that all?
  • Corporate Data? (Score:4, Insightful)

    by allcar ( 1111567 ) on Wednesday November 14, 2007 @09:01AM (#21348651)
    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."
  • by LordSnooty ( 853791 ) on Wednesday November 14, 2007 @09:13AM (#21348721)
    TFA mentions he works for Next Generation Security Software [ngssoftware.com].

    "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?
    • 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.

  • by IdleTime ( 561841 ) on Wednesday November 14, 2007 @09:14AM (#21348741) Journal
    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: (Score:2, Informative)

      by pshempel ( 61350 )
      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 p

  • So? (Score:2, Insightful)

    by ajs318 ( 655362 )
    # 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 data
    • 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

  • 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 th
  • And ... (Score:2, Insightful)

    by zolf13 ( 941799 )
    ... 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.
  • by sm62704 ( 957197 ) on Wednesday November 14, 2007 @09:35AM (#21348923) Journal
    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.
  • Well... (Score:5, Interesting)

    by ngunton ( 460215 ) on Wednesday November 14, 2007 @09:45AM (#21349023) Homepage
    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: (Score:3, Informative)

      by Seanasy ( 21730 )
      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.
    • by SmallFurryCreature ( 593017 ) on Wednesday November 14, 2007 @11:02AM (#21349891) Journal

      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

      • by ngunton ( 460215 ) on Wednesday November 14, 2007 @03:19PM (#21353969) Homepage
        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.
    • 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.

  • Doesn't surprise me (Score:4, Interesting)

    by ledow ( 319597 ) on Wednesday November 14, 2007 @09:46AM (#21349029) Homepage
    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?
  • 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
  • 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...
  • --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.

  • 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 n
    • 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.
  • 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!

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

    Links please. thx

  • Um... Not exactly. (Score:5, Insightful)

    by Minwee ( 522556 ) <dcr@neverwhen.org> on Wednesday November 14, 2007 @10:32AM (#21349507) Homepage

    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 [ngssoftware.com], then you'll have to forgive me for not being terribly concerned about this revelation.

  • 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.

Every successful person has had failures but repeated failure is no guarantee of eventual success.

Working...