Andy Johnson wrote:
I think the point of many on this list is, they are a transit provider, not a security provider. They should not need to filter your traffic, that should be up to the end user/edge network to decide for themselves.
How is this different from a transit provider allowing their network to be used for spam? Seems the same hands-off argument was made wrt spam a decade ago but has since proved unsustainable. Our particular problem is with an ISP in Wisconsin, NETNET-WAN. We get tens of thousands of scans to netbios ports every day from their /19. This is several orders of magnitude more netbios than we see from the rest of the net combined. It's eating nontrivial bandwidth and cpu that we pay real money for. They've had our logs for months but seem incapable of doing anything about their infected customers. The suits recommend documenting time and bandwidth costs and sending a bill with a cease and desist request. My question is not what can we do about bots, we already filter these worst case networks, but what can we do to make it worthwhile for bot-providers like NETNET to police their own networks without involving lawyers? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
On Thu, 18 Aug 2005, Roger Marquis wrote:
My question is not what can we do about bots, we already filter these worst case networks, but what can we do to make it worthwhile for bot-providers like NETNET to police their own networks without involving lawyers?
Establish and document a history that determines peering with that network, or it's providers, presents a significant risk to your network, or that of your customers. If you've got a view into your traffic that looks like this: (Select source, proto, dstPort, count(destination) from flows where packets < 4 group by source, proto, dstPort order by count descending) Source proto dstPort count 62.149.195.129 6 42 13018 203.69.204.250 6 445 12889 213.123.129.237 1 2048 12693 70.17.255.43 6 443 12685 217.132.56.139 6 4899 11056 209.181.111.12 6 135 8148 221.210.149.97 6 4899 7368 212.24.201.220 6 135 6451 172.131.83.244 6 135 6025 209.188.172.66 6 445 5055 80.177.36.162 6 445 4982 64.121.65.197 6 4899 4262 64.32.117.250 6 135 3954 213.144.99.241 6 445 3493 64.231.44.65 6 135 3157 213.123.129.237 6 139 2988 222.84.236.98 6 1023 2414 222.84.236.98 6 9898 2398 64.228.209.103 6 135 2305 Determining who to consider peering with gets a lot easier. (ASN's left off to annoy the truly curious.) As a provider, we don't want to be filtering heavily, as it invariably leads to making allowances for Customer X. The management overhead, as well as the impact on packet processing, is too great. It's easier for us to be able to monitor and report to our customers what's affecting them, and make sure they have the right tools in place to protect them from these kinds of shenanigans. - billn
If you have an offending network that does not respond to abuse/complaints, your best course of action is to no longer communicate with that network. That is your own choice as an end-user/network operator. Complaining to their upstream or transit provider will only get them to switch providers. The traffic will continue. An alternative solution as you mentioned, involves some laywers, and attempt to recover compensation for the damages. Good luck with that one though. From the looks of it, you'll spend more money in court than you would have just blocking them. We can't force other networks to "play nice". As we all know, the Internet is an open network. Protect yourself, and make sure you are not one of the internet scum sending out this stuff, but don't depend on others to play nice with you. Transit providers should not be CONTENT filtering their customers (for free anyways, I'm all for selling security services). This does not mean they have no responsibility to keep a proper abuse/security staff. If a transit provider has a customer who is constantly infecting/spamming/etc and fails to act, by all means take action and drop the customer. My main point is, if we depend on our transit providers to act as Internet nannies, we are promoting poor end-user network management. --- Andy Roger Marquis wrote:
How is this different from a transit provider allowing their network to be used for spam? Seems the same hands-off argument was made wrt spam a decade ago but has since proved unsustainable.
Our particular problem is with an ISP in Wisconsin, NETNET-WAN. We get tens of thousands of scans to netbios ports every day from their /19. This is several orders of magnitude more netbios than we see from the rest of the net combined. It's eating nontrivial bandwidth and cpu that we pay real money for. They've had our logs for months but seem incapable of doing anything about their infected customers. The suits recommend documenting time and bandwidth costs and sending a bill with a cease and desist request.
My question is not what can we do about bots, we already filter these worst case networks, but what can we do to make it worthwhile for bot-providers like NETNET to police their own networks without involving lawyers?
Roger Marquis wrote:
Andy Johnson wrote:
I think the point of many on this list is, they are a transit provider, not a security provider. They should not need to filter your traffic, that should be up to the end user/edge network to decide for themselves.
How is this different from a transit provider allowing their network to be used for spam? Seems the same hands-off argument was made wrt spam a decade ago but has since proved unsustainable.
Our particular problem is with an ISP in Wisconsin, NETNET-WAN. We get tens of thousands of scans to netbios ports every day from their /19. This is several orders of magnitude more netbios than we see
from the rest of the net combined. It's eating nontrivial bandwidth
and cpu that we pay real money for. They've had our logs for months but seem incapable of doing anything about their infected customers. The suits recommend documenting time and bandwidth costs and sending a bill with a cease and desist request.
My question is not what can we do about bots, we already filter these worst case networks, but what can we do to make it worthwhile for bot-providers like NETNET to police their own networks without involving lawyers?
Route them through a modem using 4800 Baud. They will very soon look what is eating their bandwidth and hopefully find those netbios packets. Blocking port 445 will prevent me from using "ssh -p 455" to reach my clients. Using 4800 baud will slow me down but it will not stop me working. Does anyone really use port 22 for ssh? I cannot use it because of all those wordbook attacks. Nobody cares to stop those. Regards, Peter and Karin Dambier -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) +1-360-448-1275 (VoIP: freeworldialup.com) mail: peter@peter-dambier.de http://iason.site.voila.fr http://www.kokoom.com/iason
On 8/18/05, Roger Marquis <marquis@roble.com> wrote:
Andy Johnson wrote:
I think the point of many on this list is, they are a transit provider, not a security provider. They should not need to filter your traffic, that should be up to the end user/edge network to decide for themselves.
How is this different from a transit provider allowing their network to be used for spam? Seems the same hands-off argument was made wrt spam a decade ago but has since proved unsustainable.
This is where the abuse teams at the service providers need to have management approved thresholds for different types of abuse and be empowered to take action. If your customer is caught port scanning (hacking, worm propogation, etc) twice within a two day time frame or something, the abuse team should be able to null route/filter the ports without further warning. If they are spamming and after repeat notifications they do not stop, have an escalation process that goes from suspension to termination of service. There are plenty of automated complaint scripts out there for all types of abuse, so you don't have to look at everything yourself.
Our particular problem is with an ISP in Wisconsin, NETNET-WAN. We get tens of thousands of scans to netbios ports every day from their /19. This is several orders of magnitude more netbios than we see from the rest of the net combined. It's eating nontrivial bandwidth and cpu that we pay real money for. They've had our logs for months but seem incapable of doing anything about their infected customers. The suits recommend documenting time and bandwidth costs and sending a bill with a cease and desist request.
My question is not what can we do about bots, we already filter these worst case networks, but what can we do to make it worthwhile for bot-providers like NETNET to police their own networks without involving lawyers?
-- Roger Marquis Roble Systems Consulting http://www.roble.com/
participants (5)
-
Andy Johnson -
Bill Nash -
My Name -
Peter Dambier -
Roger Marquis