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
shoemak...@vectordatasystems.com
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 <
> shoemak...@vectordatasystems.com> 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
>> 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/
>>
> 
> 
> --------------------------------------------------------------------------------
> 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/


--------------------------------------------------------------------------------
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/

Reply via email to