Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
 ·Shaw
| Difference a year makes, good news, bad news
I have posted a quick comparison of attacks and scans for February 2004 and February 2005. The good news, scan/attack sources are down about 20% (ie 20% fewer infected systems this year compared to last). The bad new is infected systems scan far harder so number of scans and attacks are up about 370% compared to February last year.
See »www.linklogger.com/year.htm for the charts and such.
Blake
--
Vendor: Firewall Logging Software »www.SonicLogger.com - SonicWall and 3Com »www.LinkLogger.com - Linksys, Netgear and Zyxel |
|
jvmorris
I Am The Man Who Was Not There.
Premium,MVM
join:2001-04-03
Reston, VA
| This is the part I found particularly interesting:
. . . about 60% of all logged events of all traffic logged which includes both inbound and outbound traffic, are inbound scans and attacks Taken in conjunction with your earlier statement that you found over a 300% increase in the number of scans (over the past year), that would suggest to me that, within another year or so, the ratio of unsolicited scans to authentic traffic is gonna start approaching the proportion of spam to authentic e-mail!
--
Regards, Joseph V. Morris |
|
astirusty
Premium
join:2000-12-23
Henderson, NV
 ·AT&T Southwest
| said by jvmorris  :This is the part I found particularly interesting: . . . about 60% of all logged events of all traffic logged which includes both inbound and outbound traffic, are inbound scans and attacks Taken in conjunction with your earlier statement that you found over a 300% increase in the number of scans (over the past year), that would suggest to me that, within another year or so, the ratio of unsolicited scans to authentic traffic is gonna start approaching the proportion of spam to authentic e-mail! Maybe when the beancounters at the ISPs start realizing the costs of all the scans (in wasted bandwidth) they will finally decide to act jointly with other ISPs to put an end to it.
1) Start egress and ingress filtering and logging.
2) Start disconnecting users that have systems that are scanning (based on logs).
3) Charge a reinstatement fee for users that were disconnected for systems that were scanning (and SPAMMING).
4) Join together to put some serious pressure on OS vendors that have produced easy to hack systems that come by default with minimal security turned on.
Ohhh, never mind I just woke up and I am back to reality now... They will simply charge everyone higher connection fees. |
|
jvmorris
I Am The Man Who Was Not There.
Premium,MVM
join:2001-04-03
Reston, VA
| I think there is a certain amount of ingress filtering, at least, being done by at least some ISPs. I did a quick check on the unsolicited inbound probes against my current IP address early this morning, fully 60% of them came from within my own Class B subnet, virtually all of which is (supposedly) residential/home DSL customers. So my ISP must be doing some sort of ingress filtering, at least. (I think Blake's experiences with Shaw(?) show an even higher percentage of users within his own subnet.
If it's now mostly within the subnet (as in my case), then more ingress and outgress filtering is unlikely to do much, I think. Of course, if my ISP simply shut down port 445 probes on its internal routers (within the subnet, that is) that would produce a 50% drop in the number of probes I'm seeing presently here. I don't think there's any practical reason why Port 445 traffic needs to be running around even within an ISP's subnet and that would undoubtedly have a certain impact on the load of the ISP's internal routers. (I've no idea how easy/difficult this is to do with that kind of router, which is far different from what we have in SOHO NAT routers, however.)
--
Regards, Joseph V. Morris |
|
astirusty
Premium
join:2000-12-23
Henderson, NV
·AT&T Southwest
| reply to Link Logger
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).
Not being a network expert by any stretch, I am sure there are some real administration issues that would make doing this result in numerous migraines. But, considering the costs of all the wasted bandwidth, it would appear to be worth a few headaches. |
|
Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
·Shaw
| reply to jvmorris
In Feb/2005 80% of all inbound 445 scans came from my local netblock x.*.*.*, drilling into this almost 98% came from x.x.*.* and at this level we see the spread of source for 445 scans. Hence you can say the most prevalent worms only vary the last two number of your IP Address when scanning. So if my local ISP wanted to drop their network bandwidth and load, they could by cleaning up locally infected systems or filtering various ports like 445.
I will add these three charts to my page which show this.
Blake
--
Vendor: Firewall Logging Software »www.SonicLogger.com - SonicWall and 3Com »www.LinkLogger.com - Linksys, Netgear and Zyxel |
|
jvmorris
I Am The Man Who Was Not There.
Premium,MVM
join:2001-04-03
Reston, VA
| reply to astirusty
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 |
|
jvmorris
I Am The Man Who Was Not There.
Premium,MVM
join:2001-04-03
Reston, VA
|  reply to Link Logger
Now that is an interesting set of graphics! 
But the last one is kinda scary! (That's the various Class C subnets there, isn't it?)
--
Regards, Joseph V. Morris |
|
astirusty
Premium
join:2000-12-23
Henderson, NV
·AT&T Southwest
| reply to Link Logger
said by Link Logger :drilling into this almost 98% came from x.x.*.* and at this level we see the spread of source for 445 scans. So if we want to clean up the internet of all these scans - we just need to get your entire sub-domain blocked?!?  
On a serious note, this information is very interesting. I am taking a SWAG here, but the viruses/worms are setup this way so they draw less attention? Because the hackers know (or believe) the ISPs have not in the past monitored or filtered at these levels?? |
|
astirusty
Premium
join:2000-12-23
Henderson, NV
·AT&T Southwest
| reply to jvmorris
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. |
|
Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
·Shaw
| reply to Link Logger
Comparing the Port 445 traffic from Feb/2004 as above, 61% of inbound 445 traffic was from my local netblock (x.*.*.*) and of that 73% was from my local netblock (x.x.*.*). So it might be said that worms have also become more focused in 2005 on local netblocks then they were in 2004.
Blake
--
Vendor: Firewall Logging Software »www.SonicLogger.com - SonicWall and 3Com »www.LinkLogger.com - Linksys, Netgear and Zyxel |
|
Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
·Shaw
| reply to Link Logger
So I got to thinking about this and want to see how each month looked in terms of scans/attacks and the number of unique scanning systems. The chart is rather interesting as we are doing much better then we were and there has not been a major new worm exploit since Sasser (last May) and even then Korgo did a much better job then Sasser did in terms of owning the internet.
The number of scans and attacks is on the decline (minor bump due to those lovely new unsecured Christmas computers), but we are doing better. I would venture to say that the release of SP2 had a very noticeable effect on reducing malware traffic on the net. I also believe that SP2 has also changed how malware authors generate IPs in their worms as they now use very localized scans and depend on email to actually distribute malware around the internet. Gone are the days (or at least no one is releasing such worms) when worms like SQL Slammer would own the internet after being started on a single system and then spreading out from there. I would be willing to bet that the bots which were used against DSLReports where initially sent out as email attachments and then once they infected a system they scanned the local netblock for additional recruits but didn't tend to scan outside their local netblock.
Keep it up gang as we might have turned a corner on internet security and things are getting better. I suspect there are a few more speed bumps ahead and by no means is it time to break out the bubbly and declare victory, but for the first time we are reducing the onslaught of attacks.
Blake
if your not running a firewall, what are you running???
--
Vendor: Firewall Logging Software »www.SonicLogger.com - SonicWall and 3Com »www.LinkLogger.com - Linksys, Netgear and Zyxel |
|
