Karl Katzke

In a Symfony application that I’m working on right now, a number of administrative functions are intermixed with the user interface. Everything’s controlled with standard security permissions at the module level, and all should be well and good. But sometimes, your best defense against people trying to hack and cheat is not letting them figure out where things *should* even be — hence the “don’t even return pings, act like a black hole in the internet” firewall strategy.

One of Symfony’s innovative security features is it’s environments. For instance, on Dev you can set security access violations to show the security page, and on Live you can set them to forward to 404. You use the same configuration file on live and dev, but the environment settings controls what happens where. So someone’s trying to guess admin functions by name, searching for that one module that you accidentally left unprotected? They don’t even get a list of ones to check in the future, they just get 404 after 404. You, on the other hand, can set up logging to see who’s trying to find backdoors…

Since I control my environment at the server level (replacing all of the front controller static ‘dev’ and ‘live’ with _SERVER[’env’] variable calls, which are then set in Apache), I don’t have to worry about being in the wrong environment. Which means that I’m free to set dev settings and live settings and know that development will never get shown on live.

Security through obscurity isn’t much of a protection, but keeping people from gaining information that they can use to make educated guesses or do some social engineering (by far the most successful hacking strategy) IS a good strategy.