In a new post to the PHP.cc site today Arne Blankerts reminds us that not all security is about writing good code and handing data correctly - it's also about the systems they run on.

What seems to be so obvious for road traffic and its rules seems to be less obvious for many web developers. They tend to slack on defining (and monitoring) what is happening at the application level as well as the infrastructure level of their application. It is not enough to run a default install of your operating system of choice, add whatever services you need, and hope for the best. Considering the amount of money as well as damage to reputation, either directly due to fraud and abuse or indirectly by time lost to recover a hacked system or software, the "let's hope for the best" approach is of arguable quality. And we are not even considering general bugs here.

He mentions configuring the server, OS and network to ensure a higher level of security, noting that no matter how much work is put into secure code, if the attacker can get to points on the system they shouldn't, your app is still vulnerable.

But how can you tell if someone is actually trying to break in? Pretty much exactly as the police does for road traffic: with speed checks and by patrolling. A properly configured firewall will show as well as inhibit any unauthorized communication within the network and all you need to do is monitor the vital signs of your infrastructure.

In a recent post to his blog Mark Hamlin talks about some of his difficulties in getting XDebug and Netbeans working together from an OSX machine hitting a Ubuntu server.

For the past 18 months working with PHP, i've primarily used alternatives, not out of preference, but because netbeans xdebug integration consistently failed me. It would (might) work with a remote apache, but would not play with scripts executed remotely from the command line. I could be fairly sure my xdebug config was sound as I no problems with MacGDB and PHPStorm whatsoever.

With a little more investigation, he discovered that it was the OSX firewall causing issues. He found that, with a new incoming connection came a confirmation box to approve the connection. This, of course, wasn't passed along to Netbeans so he never saw it. In the end, he set up a reverse SSH tunnel to bypass the firewall completely (command included).

Sometime debugging PHP applications isn't as easy as just pointing your IDE directly at the server and starting to work. Derick Rethans has a new post talking about one such situation, remote debugging with a firewall in between you and the remote machine with XDebug.

The PHP debugging extension Xdebug has "remote" debugging capabilities for single-step debugging PHP applications. This works by setting your favourite IDE into listening mode and instructing Xdebug (with one of the handy browser extensions for example) to initiate debugging. [...] There could however be a firewall in the way that prevents Xdebug connecting directly to your IDE's IP address. That can be because the network you are on employs NAT. [...] In this case, there is no way Xdebug can connect to your IDE's IP address and port. Or is there?

His alternative requires SSH access to the remote machine - building a tunnel from your local machine to the remote server XDebug can use to get around the firewall. He explains the shell command to set up the tunnel and, a more graphical way, through the Putty ssh/telnet client. A quick call to "netstat" can tell you if things are working correctly or not. All that's left then is to point your XDebug to the port on the localhost and you should be good to go on debugging.

New from the php|architect blog today there's a post talking about a new book from Feisty Duck Publishing about ModSecurity for Apache and how that effects the world of PHP.

ModSecurity is a web application firewall. It can live in and out of the Apache web server environment, one of the most popular web servers around. ModSecurity is infinitely customizable and extremely powerful. The philosophy of ModSecurity can be summed up in a few words. Look, and only modify if I tell you to.

The author of the post (Orlanao Medina) thinks that this book is *the* resource for ModSecurity-related information, providing step-by-step information on how to work with the tool both inside and outside of Apache. It shares tips on blocking XSS attacks, brute force attacks and generally protecting your application in general.

In this recent post to the DevCentral blog (from f5.com) they ask why reusable code, one of the foundations of good development (especially in PHP) is so hard to secure.

Being an efficient developer often means abstracting functionality such that a single function can be applied to a variety of uses across an application. Even as this decreases risk of errors, time to develop, and the attack surface necessary to secure the application it also makes implementing security more difficult.

The article talks about a project the author was working on and how, when he came across a need for a component and found one that worked, they were surprised to see how difficult it would be to secure it without adding on extra code bloat. He describes some of the issue and talks about how the development of the component must not have included any thought into things like input validation or filtering. One suggestion is to employ a firewall to sit in front of the entire application and handle all of these things without changes to the code.

The Sanisoft blog has a new post today about a handy PHP utility you can use to put a "firewall" in your PHP application - Inspekt.

Everyone knows that you should filter your inputs most of the good programmers do it but when you are working with a large team of programmers on an open source project things slip up, errors do creep in, at times like this you wish for a mechanism which would prevent your team from making such mistakes, some thing which forces them to declare their intent.

One solution he mentions is the input_filter extension for PHP5, but this doesn't help most users since it's normally off by default and PHP5-only. The other solution, Inspekt, a modified version of the Zend_Filter_input component of the Zend Framework. An example is included and a list of filtering methods is too (like getAlnum, getDigits and getInt).

The Sanisoft blog has a new post today about a handy PHP utility you can use to put a "firewall" in your PHP application - Inspekt.

Everyone knows that you should filter your inputs most of the good programmers do it but when you are working with a large team of programmers on an open source project things slip up, errors do creep in, at times like this you wish for a mechanism which would prevent your team from making such mistakes, some thing which forces them to declare their intent.

One solution he mentions is the input_filter extension for PHP5, but this doesn't help most users since it's normally off by default and PHP5-only. The other solution, Inspekt, a modified version of the Zend_Filter_input component of the Zend Framework. An example is included and a list of filtering methods is too (like getAlnum, getDigits and getInt).

The Zend Developer Zone has posted their latest security tip today - this time dealing with the actual connection your application sits on (from Chris Hartjes).

The most secure application is one with no connection to the outside world.

As we've covered, you can't really disconnect the network from your web server if you are building web applications. You can however, carefully consider which servers need to be connected to the outside world and which can be inside your firewall. Beyond that, you can also evaluate how those servers that have to remain outside your firewall communicate with the ones inside.

No, his suggestion is not to take your application "off the grip" but more to limit access to things like database servers to help protect the data that lives inside it.

The Zend Developer Zone has posted their latest security tip today - this time dealing with the actual connection your application sits on (from Chris Hartjes).

The most secure application is one with no connection to the outside world.

As we've covered, you can't really disconnect the network from your web server if you are building web applications. You can however, carefully consider which servers need to be connected to the outside world and which can be inside your firewall. Beyond that, you can also evaluate how those servers that have to remain outside your firewall communicate with the ones inside.

No, his suggestion is not to take your application "off the grip" but more to limit access to things like database servers to help protect the data that lives inside it.