Just to follow up on this thought, the main "unintended consequence" I had in mind was a customer running some sort of security verification suite against his/her own servers. If I were an IT employee using this sort of software from outside my network, and all of a sudden certain IPs or subnets can no longer access my company's network for some unknown reason, I would not be pleased. I would be expecting my ISP to get packets from point A to point B, not to babysit connections for me.
If this feature were offered as an opt-in service, then it would be a completely different story. Of course, this probably isn't an issue at all for most residential and SMB customers. Patrick Shoemaker Vector Data Systems LLC shoemak...@vectordatasystems.com office: (301) 358-1690 x36 http://www.vectordatasystems.com Butch Evans wrote: > On Sat, 2009-05-02 at 17:51 -0400, Patrick Shoemaker wrote: >> There's another linux program out there called BFD that does the same >> thing: parses logs and creates IPTABLES rules, but it doesn't use >> python. Google it and see if it will work for your application. > > Again, this is a good approach, but is (for my taste) a little to > reactive. The approach that Eje was speaking of is more proactive. It > is the same approach that I take when providing firewall applications to > my own customers. It goes a little like this: > > Create a firewall for the router itself that will explicitly permit all > of the traffic you wish to allow to connect via ftp or ssh. How you > accomplish this is up to you. > > Watch for connections by ssh/ftp/other that are NOT valid. Grab the > source address of those offending ssh attacks. > > In the firewall that protects your network, deny all traffic from those > that were detected as attempting to connect to your firewall router. > > Watch for NEW ssh connections and set some reasonable limit for how > often a specific IP may attempt a new ssh connection. You have to pick > the right number here in order to prevent false positives. It's all > about finding an appropriate rate of new connection attempts. > > If an IP "trips" the above set of rules, then deny them further traffic > into the network. > > It's really not that complicated. It's not "easy" maybe, but not > complicated. You simply have to have a router with some decent firewall > capability (iptables based). > > >> Also, this might go without saying, but I'd recommend against applying >> any router-based rules to customer subnets. That approach is ripe for >> unintended consequences, and can create a troubleshooting nightmare for >> your customers. > > I disagree. Done right, you don't have "unintended consequences". And > even if you do, it's rather easy to take care of those as they come > up. > -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
