Equipment Support > Hardware By Brand > Linksys > BEFSX41 Stealth & Closed Ports and AFP

BEFSX41 Stealth & Closed Ports and AFP

It is actually better if the port is stealth coz there'll be no sign of intrusion that will happen. hackers using port based software will detect the ip address as non existent if they probe your address using a particular port. if the hacker detected that this ip address is closed on a particular port, then he'll find another way of running into your system by using a different port.

said by buggy device:

---

It is actually better if the port is stealth coz there'll be no sign of intrusion that will happen. hackers using port based software will detect the ip address as non existent if they probe your address using a particular port. if the hacker detected that this ip address is closed on a particular port, then he'll find another way of running into your system by using a different port.

---

reply to buggy device
(If you read the question again, it wasn't about which is better (closed or stealth), but why the results vary between tests.)

You might want to sniff the WAN traffic to see the actual packets, there's no other way to decide how the GRC comes to the posted conclusions.

better converse this with GRC on the way they test the ports. btw, have you tried running the test again without the router?

reply to skj
It's a bug in the advanced firewall protection when subjected to scans that exceed 1000 ports.

If you check your firewall log you will likely see an entry similar to: Ceiling for number of connections reached dropping packet.

One of the previous posts on this:
»[wired] BEFSX41 and Extensive Port Scan

Regards,

CrazyM

reply to buggy device

said by buggy device:

---

better converse this with GRC on the way they test the ports. btw, have you tried running the test again without the router?

---

reply to CrazyM

said by CrazyM:

---

It's a bug in the advanced firewall protection when subjected to scans that exceed 1000 ports.

If you check your firewall log you will likely see an entry similar to: Ceiling for number of connections reached dropping packet.

One of the previous posts on this:
»[wired] BEFSX41 and Extensive Port Scan

Regards,

CrazyM

---

reply to skj
hopefully, linksys is already aware of this issue and has released a firmware to fix it.

reply to skj

said by skj:

---

So are we to assume when subjected to over 1000 port scans it removes the port stealthing?

---

I know it has been raised as an issue for some time. I have not heard if the newest firmware version addresses this issue.

linksys engineers should know for a fact that ignoring this concern will just create an enormous problem and not a single individual is looking for a way to resolve it. try to forward this to linksys SKJ and see what workaround they can provide you with...

reply to CrazyM

said by CrazyM:

---

At the time of that linked post the results seemed consistent. Under intense scan from from a single source, when the number of inbound ports scanned reached 1000, the router/firewall would start providing a closed response instead of stealth (no response).

---

said by SYNACK:

---

said by CrazyM:

---

At the time of that linked post the results seemed consistent. Under intense scan from from a single source, when the number of inbound ports scanned reached 1000, the router/firewall would start providing a closed response instead of stealth (no response).

---

This is actually not a bad stance and can avoid other problems.

For example, if your computer crashes while gaming, or you get an IP that was just used by a file share client, you'll get tons of probes and they won't end because the other side is never notified that the service no longer exists. A closed response will provide that notification (This is especially important for stateless protocols such as UDP).

Overall, closed vs. stealth is not really a security issue, both are equally secure. Even a closed port is completely safe.

Sometimes "stealth at any cost" indirectly causes too many other problems. Stealth is mostly hype.

---

reply to skj
I supposed we should have better explain this problem to the community. Let's just say that Linksys is aware of this. Let's add that firmware 1.44.11t does not fix this problem. And before diving into the specifics of the problems, let's specify that even though this is a conceptual problem, it does not permit a hacker or an intruder to get to your local network. The ONLY side effects of this bug is purely and simply the fact that under some circumstances (that I am describing below), the BEFSX41 will advertise its presence on the internet that's it, that's all. Note that this problem is not present if you disable the SPI firewall (as known as advance firewall) simply because the problem is in the SPI firewall itself.

A good SPI firewall keeps states about established TCP connections. These states allow the firewall to discards any packet that do not match a precise set of condition much better than a regular NAT firewall would do. A good SPI firewall keeps such state when a given TCP connection is fully connected (meaning the first 3-way handshake is completed). The problem with the BEFSX41 SPI firewall implementation is that it starts maintaining states on TCP connections even if the 3-way handshake is not completed. If you get a DoS attack using a TCP SYN flood on different ports in a very short amount of time, you will exhaust the BEFSX41 SPI TCP connection state table. So far that is not that bad. The problem comes from the fact that when it has exhausts its connection table, the BEFSX41 starts replying with SYN/RST and that is what the nanoprobe test is complaining about. Replying with SYN/RST is a standard response when not behind a firewall BUT THAT IS NOT THE DESIRED BEHAVIOR FOR A GOOD SPI FIREWALL .

The BEFSX41 SPI bug is about replying with SYN/RST packet thus revealing the IP address existence to the internet. That is what Linksys has to fix in their next firmware version.

Again as I said before. This bug does not open holes for hacker or intruder but rather advertise the presence on the internet with those SYN/RST.

Thank you Flogator for your detailed explanation which explains the issue very clearly.

My two cents is if I knew of this fault I would of never bought it because this is fucking crap. If I wanted to be seen Then I wouldnt of pick the option to not be pinged. I picked an advance firewall for security and they knowing I am still connected doesnt show much of a security measure. I think linksys or cisco since they are connected should get off there ass and fix it. Advance firewall doesnt look so advance if you are seen when in precious standard BEFSR41 v2 never showed me up in stealth as far as I know. So somone needs to push the paper on this issue and fix it. This is a big disappoint to me on linksys products, if they cant get the job done and fix this issue then they shouldnt be in business. Advanced firewall my ass if it cant keep me stealth completely.

-illusion

Ps. My comments, I am sure most will be close to my view just not as pissed off as me.

rboone18, if you are patient, in the mean time you could disable the advanced firewall until the next firmware version (assuming this will be fixed then). Disabling advanced firewall will make your BEFSX41 act like a BEFSR41. Otherwise, I may recommend you some other brand router with very similar features but slightly more expensive.

said by Flogator:

---

rboone18, if you are patient, in the mean time you could disable the advanced firewall until the next firmware version (assuming this will be fixed then). Disabling advanced firewall will make your BEFSX41 act like a BEFSR41. Otherwise, I may recommend you some other brand router with very similar features but slightly more expensive.

---

reply to skj
Just for your information, despite that fact that this bug is present in the SPI firewall, I still have the advanced firewall enabled on both of my routers. Remember that you need to be flooded with TCP SYN packet for this problem to exhibit itself. Furthermore, I prefer have the SPI firewall enabled than otherwise.