Equipment Support > Hardware By Brand > Linksys > [wired] BEFSX41 and Extensive Port Scan

[wired] BEFSX41 and Extensive Port Scan

Re: [wired] BEFSX41 and Huge Port Scan

reply to SuperImp
I just took a look at this and found the results interesting. With having Advanced Firewall Protection (SPI and Denial of Service protection) enabled, my results are similar, with ports up to 1000 being all Stealth and the rest Closed. But when Advanced Firewall Protection is disabled, then all the ports are Stealth. My guess is that the closed (instead of Stealth) are due to the Denial of Service protection - I'm just surprised that this protection would wait so long to kick in.

Yeah, that seems to be the case. It's really no security risk really, but a bit odd how it's implemented. 'DoS/Ongoing Port Scan' protection seems to be triggered in about 20 to 30 seconds of continuous hits from the same IP before going into "Closed" status. The IP isn't ignored however though, the router just instantly acknowledges back "Closed" for about a 10 second time period, regardless if the rest of the packets are able/unable to be sent to the remote ports. Thanks for giving the time to test it out, was wondering if anyone else had noticed it prior to this

reply to SuperImp
wow..this is intersting, i will try to scan it and post the result. So will my friend who implements 2 linksys BEFSX41 routers in his lan. Maybe my friend will get some different results.

Thank you for noticing.
Tak

Makes no sense to me. This isn't a denial of service attack. I've got 3 different SPI routers, all ICSA certified, and they show up completely stealth on the new GRC nanoprobe scanner. I've run a Linux scanner directly over a 3 foot Ethernet cable to WAN port of the routers and they don't skip a beat.

This is a bug. If you ask the router for stealth, you should get stealth. The sx41 has as much horsepower as the other 3 routers (2 ZyWALLs and a Sonicwall).
[text was edited by author 2003-04-30 20:40:36]

Yeah, I wonder if the Techs are aware of this. Might as well shoot an email to LinkSys or maybe the Techs have viewed this? Since the router is seeing the continous packets, it's triggering some sort of event procedure on the router (Port Scan/DoS/etc). However, the solution for the problem shouldn't be replying automatically (even though the scans aren't even making it to the last round of ports, from watching my LOGS) back as "Closed" but instead with "Stealth". Since replying with "Closed" is still safe in most cases, unfortuanately it's a sign to others that the box is still alive and pingable.
[text was edited by author 2003-04-30 21:38:20]

reply to SuperImp

Re: [wired] BEFSX41 and Extensive Port Scan

I agree. This is a bug unless someone can explain why it is a feature.

reply to SuperImp
Well, I didn't mean to refer it as a protection mechanism, especially for DoS (Which it really isn't as bbarrea said). I think LinkSys has a method to deal with extensive hits from malicious attackers or in this case an extensive port scan (Scanning 1000+ ports within 25-35 seconds), but in this case it seems to be a bug. Since rather than replying back with "Stealth", it's being acknowledged as "Closed". Which as you stated is a weakness. The original method of GRC's port scanning tool scanned only a handful of well known exploited ports, in which BEFSX41 handled it right. The same method of GRC's improved scanner enables to scan the range of 1-1056 in a very quick manner (35-40 seconds for the standard broadband) which demonstrates a flaw in how LinkSys handles it.

Edit: Also, variables in the router configuration also play a role. For example, if I turn off logging I'm able to get more "Stealth" ports... but still end off with quite a few "Closed" ports in the final portion of the scan. As is enabling or disabling Advanced Firewall support and possibly some other options.
[text was edited by author 2003-04-30 22:19:33]

reply to Flogator
Of course, my guess is/was just a hypothesis. Since all ports are Stealth when Advanced Firewall Protection is off, the lack of all Stealth appears due to one of the features of the Advanced Firewall Protection. It would seem more likely due to the denial of service function than the NAT. I'm just guessing that this actually functions as more of a port scan detection and blocking system. If that is correct, it would be detecting a port scan, and then blocking all connection attempts from that IP. While it might be doing so in a way that makes the machine detectable, it is also shutting down all connection attempts from that IP address, and therefore protecting your machine. I stress again, that this is just my best guess as to what is happening.

reply to SuperImp
If you are testing the SPI Firewall then advanced firewall support must be enabled. If you disable advanced firewall then you have basic NAT protection. We could speculate on failure mechanisms based on your observation of turning off logging gets more Stealth ports. Not worth it because this is a bug, plain and simple.

You can generate a lot of port scans in a short time using nmap or Nessus in Linux (nmap Windows version is slowwww). Anyone got a linux box to see if WAN or LAN scanning while connected directly to sx41 causes more problems? Now that would be interesting. I've seen some routers lockup with LAN side nmap scanning.

reply to SuperImp
Updated News:

My friend who has 2 BEFSX41 routers installed on his LAN and I got the same result:

Results from scan of ports: 0-1055

0 Ports Open
53 Ports Closed
1003 Ports Stealth
---------------------
1056 Ports Tested

NO PORTS were found to be OPEN.

Ports found to be CLOSED were: 1003, 1004, 1005, 1006, 1007,
1008, 1009, 1010, 1011, 1012,
1013, 1014, 1015, 1016, 1017,
1018, 1019, 1020, 1021, 1022,
1023, 1024, 1025, 1026, 1027,
1028, 1029, 1030, 1031, 1032,
1033, 1034, 1035, 1036, 1037,
1038, 1039, 1040, 1041, 1042,
1043, 1044, 1045, 1046, 1047,
1048, 1049, 1050, 1051, 1052,
1053, 1054, 1055

Other than what is listed above, all ports are STEALTH.

TruStealth: FAILED - NOT all tested ports were STEALTH,
- NO unsolicited packets were received,
- NO Ping reply (ICMP Echo) was received.

reply to SuperImp
Has anyone ran the nanoprobe test with different flavor of the BEFSX41 firmware? It would be interesting to see the results. The various firmware version I am aware of are 1.43, 1.43.3, 1.43.4, 1.44, 1.44.3, 1.44.7 and 1.44.8. I am also guessing that some of you might have 1.44.11 or even 1.45. If you are using any of these firmware version, could you post your results of the "All Service Ports" GRC nanoprobe test?

Thanks.

reply to SuperImp
My router uses 1.43 and get CLOSED port result.

Remember my friend who implements 2 BEFSX41 in his LAN. The gateway mode of BEFSX41 uses 1.44.3 and the router mode of BEFSX41 uses 1.43.

reply to SuperImp

said by CrazyM:

---

.....obviously their idea of "dropping packet" and mine are not quite the same.

---

I agree as well. Hopefully they know about this bug and it will be released in the upcoming firmware. Although it really isn't that huge of a deal anyway, since the router refuses the persistant IP... just not in the likely method we expect. Thanks again for everyone testing/diagnosing the issue.

Depends on how you see this. Functionality wise, this does not break anything since the connection is refused anyways. The only concern that I have is this is advertising your existence. Again, perhaps it is a question of interpretation but for me, the advantage of having an SPI firewall is not only does it protect you from outsiders but it also hide your computer/network from the rest of the internet. This gives you this little advantage when we will find the next vulnerability in the BEFSX41.

Whatever our reasons are, I think we all agree to say that this is a bug in the BEFSX41 firmware. For now, we know the problem exhibits itself in firmware 1.43, 1.44 and 1.44.3. Are there any other firmware where this was tested on?

This was tested on firmware 1.44, Nov 22 2002

Yeah, I know what you mean by advertising your existence during the short period it refuses the incoming queries. Just not the high priority bug to the extent of say... rather than refuse and send "Closed", it caused a buffer overflow on the router which gave remote access to the router as well as disabled all SPI/Firewall functions. That'd suck, but extremly and highly unlikely for all that to occurr in one event