Ok, you inspired me to check some of my assumptions. The database port example has never resonated with me since MySQL and Postgres both restrict to only local connections by more-or-less-default, plus are protected by a passphrase that anyone careful will set to a long strong randomly-generated string. But I started thinking about the other services that we would commonly run on a server...
* Redis offers very little security ([1]http://redis.io/topics/security). It's possible to restrict to local connections, but that is not on by default. Almost no authentication! * Memcached is in a similar boat. It can restrict to local connections, and sorta offers authentication, but both of those seem to be generally off by default. * MongoDB does seem to restrict to local connections by default, but authentication is opt-in. * Sphinx's searchd can restrict to local connections, but is not on by default. ...and so on. So fair enough! I should be using firewalls. I have thankfully never shouldered many sysadminning duties, so I haven't had a chance to screw this up too badly yet, but I'm glad I asked and didn't remain blissfully ignorant. So my next question is this: are you, dear Rubyists, using firewalls on all your machines? Am I the only one to contemplate the irresponsible alternative? On Fri, Apr 11, 2014, at 07:51 PM, bradleyland wrote: While trying not to be rude, I'm not sure where you got the impression that firewalls are somehow obsolete. The role of a firewall today is the same as it has always been: to stand between private hosts and the public internet. You've made several statements that I think involve incorrect assumptions: "when all sorts of stuff would leave open unsecured ports lying around." Define "unsecured port". Arguably, any port is an "unsecured port" if it's open to the internet. It's the sysadmin's prerogative as to whether the port should be secured (protected by a firewall) or not. Applications listen on ports. Sometimes you have an application running that you don't want listening to just anyone who connects to it. For example, let's say you're running MySQL on your database server, which will serve database connections to a cluster of three app servers. A firewall makes it possible to restrict connections on TCP port 3306 (MySQL) to specific hosts. MySQL has the ability to restrict logins to specific hosts, but it is not uncommon for networked software to contain vulnerabilities that allow remote attackers to obtain privileged information by sending specially crafted requests. The heartbleed OpenSSL vulnerability is a great example. A firewall allows you to restrict who can make such requests. These days, it's more common to run firewall software directly on the database server than it is to use a separate device. However, once your infrastructure grows past a certain point, running individual firewalls on every hosts becomes a pain to support, so you may eventually grow to a point where you want to run a private network that is entirely behind a separate firewall device. Firewalls allow a sysadmin to implement a policy called default deny. The policy of default deny is a good security practice. Under this policy, you deny all traffic by default, then specify exactly what you want to allow through. This protects you from accidentally exposing ports and software that you don't explicitly want to. Firewalls are alive and well, and if you run your own servers, I'd strongly encourage you to install a firewall. Set it up for default deny, and explicitly open ports to the services you want to allow. On Friday, April 11, 2014 3:15:33 PM UTC-4, Ian Young wrote: This is a genuine question, not trolling I promise. In this day and age, what is the benefit of firewalls? I know they were important in the old days of the web, when all sorts of stuff would leave open unsecured ports lying around. And I know they're still useful in, say, a small office with networked printers and whatnot. But on a modern web application server, is a firewall necessary? What benefits does it provide? -- -- SD Ruby mailing list [email protected] [2]http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [3][email protected]. For more options, visit [4]https://groups.google.com/d/optout. References 1. http://redis.io/topics/security 2. http://groups.google.com/group/sdruby 3. mailto:[email protected] 4. https://groups.google.com/d/optout -- -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby --- You received this message because you are subscribed to the Google Groups "SD Ruby" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
