Patrick, I agree with that argument but I don't think anyone here has ever seen that problem before. IPs are allocated to organizations. If you block the "Chinese hacker" organization then how many subs are going to be complaining about that?
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 "When you have eliminated the impossible, that which remains, however improbable, must be the truth." --- Sir Arthur Conan Doyle On Mon, May 4, 2009 at 9:37 AM, Patrick Shoemaker < [email protected]> wrote: > 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 > [email protected] > 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: [email protected] > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
