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
said by astirusty  :I believe it is going to take egress and ingress filtering not only where traffic comes into and out of an ISPs domain (where the ISP connects to the outside world), but also filtering done where the ISP's users connect to the ISP. Not the user end where the user modem or interface is (these would likely get disabled by hackers). But user egress and ingress filtering at the point where the ISP's connect the users to their network work (the users merge with the ISP's sub-nets). Yes, that was what I was thinking. There's a name for the routers/collectors/concentrators that provide this function, but it eludes me at the moment (not being at all experienced in that part of Internet architecture).
From running traceroutes directly from here (and regardless of whether I was using a dial-up or ADSL connection), I would typically pass through three or four 'internal' IP addresses before hitting the public internet. What we're talking about here is that very first IP address in the traceroute that's directly under the ISP's control, correct?
--
Regards, Joseph V. Morris | |
astirusty
Premium
join:2000-12-23
Henderson, NV
 ·AT&T Southwest
| said by jvmorris : What we're talking about here is that very first IP address in the traceroute that's directly under the ISP's control, correct? That is what I am thinking.
This type of filtering has been discussed at DSLR before and just recently in this thread »Re: BBR DDos - going after the bad guys
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. With the ISPs cooperating -- reporting, tracking and blocking could be partially automated. But as somebody pointed out, getting ISPs outside the U.S. to legally comply would be nearly impossible. You have to show them a financial reason to do so. Either that or we start WWW2, which is designed from ground up with hacker and crackers in mind. And all those wanting to connect to WWW2 have to comply with specific regulations. Pipe-dream! | |
jvmorris
I Am The Man Who Was Not There.
Premium,MVM
join:2001-04-03
Reston, VA
| 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. | |
|
