Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



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 @09: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
  • Not Suprising (Score:5, Informative)

    by Algorithmnast ( 1105517 ) on Wednesday November 14, 2007 @09: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.

  • by myspys ( 204685 ) * on Wednesday November 14, 2007 @10:00AM (#21348645) Homepage
    You have.

    The more logical (and secure) solution would be

    {internet}
          |
    app-servers
          | (internal network)
    db-servers
  • by lib3rtarian ( 1050840 ) on Wednesday November 14, 2007 @10:04AM (#21348665)
    Um, not quite. You missed something too:
    the proper setup looks like this
    {internet}
    |
    firewall
    |
    app-servers
    |
    db-servers
  • by trolltalk.com ( 1108067 ) on Wednesday November 14, 2007 @10: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 ) <{moc.liamg} {ta} {laer4k2j}> on Wednesday November 14, 2007 @10: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.
  • by COMON$ ( 806135 ) * on Wednesday November 14, 2007 @10: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.

  • by pshempel ( 61350 ) on Wednesday November 14, 2007 @11:10AM (#21349299) Homepage Journal
    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:Well... (Score:3, Informative)

    by Seanasy ( 21730 ) on Wednesday November 14, 2007 @11:16AM (#21349353)
    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 @12:02PM (#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 ozone_sniffer ( 778249 ) on Wednesday November 14, 2007 @02:57PM (#21352799)
    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:Web Services? (Score:3, Informative)

    by trolltalk.com ( 1108067 ) on Wednesday November 14, 2007 @03:41PM (#21353437) Homepage Journal

    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 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:Not Suprising (Score:2, Informative)

    by smellotron ( 1039250 ) on Thursday November 15, 2007 @01:24AM (#21359873)

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

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...