I was thinking of the case where the IT person is running the security audit tool from a trusted network, like a branch office or their home connection.
Probably an obscure case. But annoying if a customer ever gets burned by it. My philosophy is that the ISP should be responsible for the most basic network-level protections, such as uRPF enforcement, blocking RFC1918 address space, etc. Any fiddling above layer 3 should be done on an opt-in basis. This is what works for my customer base (no residential), YMMV. Not saying it's what should be done in every case. Patrick Shoemaker Vector Data Systems LLC [email protected] office: (301) 358-1690 x36 http://www.vectordatasystems.com Josh Luthman wrote: > 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/ -------------------------------------------------------------------------------- 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/
