I'm with the author on this one. It's impractical to create a whitelist for a webserver (assuming it is intended to be a publically accessible webserver), but desirable for say sshd. As long as the hack mentions this, I don't see a problem.
This is a terrible example for a "firewall". Basically it only blocks known attackers? What kind of firewall is that? The script should allow whitelist.txt and drop everyone else. It would be MUCH MUCH easier (and safer).
The current way,you have to wait until someone attacks you, then add them into the blacklist.txt file.
I think it's really a question of what works for your application. Some environments favor an "innocent until proven guilty" approach, while in other applications this could be suicidal.
Take a public Internet site, for example. While a "deny all" policy with a specific whitelist for permitted clients might be more secure, it just isn't feasible if you don't know ahead of time where your clients are coming from. If the vast majority of users on your site are responsible, doesn't it make more sense to just toss out the troublemakers as they arise?
Of course, many people argue that the concept of the firewall is dead, anyway. One very flexible and increasingly popular way to deal with unwanted traffic is to run a full intrusion detection system, like Snort. That way you get good reporting with realtime incident response, without locking out the legitimate users.
It's always a matter of the right tool for the right job. In many circumstances, the blacklist neatly fills a particular need.
I agree that it is not very convenient to have to manually edit the blacklist. Ideally, a script would parse log files, either from an IDS or syslog, and automatically update the blacklist when a threshold for repeated undesireable behaviouris reached.
