how-to block ads
|
jvmorris
I Am The Man Who Was Not There.
Premium,MVM
join:2001-04-03
Reston, VA
| reply to astirusty
Re: Difference a year makes, good news, bad news
Sorry, I needed to take a minute and go over there and refresh my memory.
Okay, I was talking about some really simple port-filtering on these routers (man, I wish someone would give us the name for what these things are called!). And, specifically of outbound traffic to Port 445 (anywhere, not just on the local subnet). I don't think there's any valid reason for outbound to Port 445, at least not in the context of ISP blocks ostensibly serving home/personal/SOHO users. I'd need to do a bit more research, but obviously blocking outbound to Ports 135-139 is another possibility. This, of course, would have no impact on a home/personal/SOHO user who wanted to use any of these capabilities within their private LAN. The ISP's routers would never see this traffic.
Now, Keith (in the other thread) brings up another kind of simple filtering that could be done on these particular routers: checking the ostensible source IP addresses to ensure that they are legitimate for that router and the subscribers that should be connected to it. Any ISP that wanted to do this could largely eliminate the possibility that their subscribers were being used in attacks relying on spoofed IP addresses.
I think that both of these kinds of filters should be fairly low overhead on the router CPUs.
If the filtering were done, I think it would allow a lot of attacks like the recent DDoS here at DSLR to be quickly minimized. . . . I may be wrong, but (based on my understanding of what has just transpired here) that requires a very different kind of filtering, . . . and one with far higher overhead. Filtering on source IP wouldn't have much impact; they were apparently valid, not spoofed, IP addresses. Nor would filtering on destination port (TCP 80, I believe in this instance). That would effectively cut off everyone on that netblock (infected or clean) from being able to browse the web!
No, I think you'd either have to do deep-packet inspection (DPI, I think is a term coming into vogue these days) to ascertain the actual contents of the packet or you'd have to monitor the volume of packets being sent to a particular remote IP address. I think both of these are far more CPU-intensive tasks than what Keith and I have discussed. And the rules wouldn't be simple. In the first case, you'd need a signature for the packets that indicated a problem (and that could literally change in a matter of hours). I don't think there was any malicious code in the packets being used to DDoS BBR/DSLR (but I could be wrong on that, since I'm not privy to the research done). In the second instance, what constitutes an unusually high volume of packets to a particular remote IP address is very likely to vary from one remote IP to another.
--
Regards, Joseph V. Morris | |
astirusty
Premium
join:2000-12-23
Henderson, NV
 ·AT&T Southwest
| said by jvmorris  :said by astirusty :If the filtering were done, I think it would allow a lot of attacks like the recent DDoS here at DSLR to be quickly minimized. . . . I may be wrong, but (based on my understanding of what has just transpired here) that requires a very different kind of filtering, . . . and one with far higher overhead. Filtering on source IP wouldn't have much impact; they were apparently valid, not spoofed, IP addresses. Nor would filtering on destination port (TCP 80, I believe in this instance). That would effectively cut off everyone on that netblock (infected or clean) from being able to browse the web! Poor (dumb) wording on my part. I really meant "filtering" here to encompass the entire concept of egress/ingress filtering / logging at the ISPs connection to the outside world and the users to their ISP, and the idea of the ISPs cooperating together. Additionally the partial automation of tracking down the sources of the scans/attacks and terminating their connections. | |
|
