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

reply to Flogator

Re: BEFSX41 Stealth & Closed Ports and AFP

said by Flogator:

---

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.

---

Well if people voice there oppinion to linksys maybe they would fix it.

-illusion

reply to skj
As I've said before if you are not a fanatic about being "stealthed", this isn't even a problem.

Well, if they never attended to make it stealth then it should of never acted stealth. Now if they orginal made it to be stealth then they should fix what is broken.

-illusion

reply to Flogator
Flogator, I'm not familiar with the exact specifics of a SYN flood attack. You said, "If you get a DoS attack using a TCP SYN flood on different ports ..." Do SYN attacks use different ports or all the same? If you had a SYN attack, shouldn't/wouldn't the SPI function just drop the records of the connection state so it doesn't fill the table? I mean you get a warning from the router saying that it is a possible SYN attack, but doesn't the router actually do something about the problem?

I guess what I'm asking is, are GRC's probes a good simulation of a SYN attack or just a very fast port probe. This "unstealthed" port problem seems to be a scan-rate related bug.

If the router is scanned at a slower rare, I'm sure those ports above ~1000 wouldn't be showing. The connection state table has to have an update feature that replaces the "aged" data so it would never "overflow".

If it is scanned too fast, I just thought that the whole point of an SPI feature was that it would just note that a SYN flood was happening and drop the connection state data associated with the flood attack so as to not be overloaded. Now if the SX41 is probed between these two extreme speeds, then maybe that is where the bug comes into play.

reply to skj
Just to give a bit of back ground, a TCP connection is considered active when the 3-way handshaking is completed. Imagine the client requesting a connection to a server (connect() function call if you are familiar with C programming). This translate to a SYN packet from the client to the server. The server will accept the connection request (accept() function call if you are familiar with C programming). That acceptance is translated into a SYN/ACK packet. Although the server has accepted the connection, it is not considered completed until the client replies back with a ACK packet. Only from that point of view does the TCP connection is considered open for communication. Note that if the server refuse the connection request, it will generate a SYN/RST packet instead of a SYN/ACK (the same kind the BEFSX41 generates in the above bug).

Now to answer your question about port numbers. The SYN, SYN/ACK and ACK packets are at the first place TCP packets so these could indeed be using different ports but it could also be the same. If we bring back our BEFSX41 bug as an example, if the DoS attack uses SYN packet with the same port number, the BEFSX41 will be fine because it will not consume more than one entry. In this case the firewall is doing its job. The nanoprobe test (and so is the regular GRC test and other TCP port scan utilities) is obviously generating SYN packets with different port number. In this case, you should not consider these tests as DoS attack but rather as a TCP port scan. Between you and me, a good TCP port scan is a good emulation of a SYN flood attack. A TCP port scan test is attempting to create a TCP connection on multiple ports. As I shown you in my first paragraph, if you want to establish a TCP connection, it must start with a SYN packet.

You are correct, the GRC probe test is a good emulation of a DoS SYN attack by its nature. In real life though, a real attacker will generate pure SYN packets (without the intend of establishing a TCP connection) to flood a network and hope something along the way will crash and expose itself some vulnerability it can exploit. In the case of the BEFSX41 bug, these SYN packet must come fast enough on different ports before the BEFSX41 realizes what is going on and releases the states information. That is why if the port probe is too slow, the BEFSX41 will have enough time to realize the connection request is bogus thus releasing the states information.

Hope that helps clarifying that further. Basically when I stress tested this scenario, I had a sniffer in between the modem and the router and I could see these SYN packets requesting for a TCP connection. Then after a while (~1000 requests which suggests that their table of states information covers for only 1000 TCP connections) I saw the BEFSX41 replying with SYN/RST packets. Any one of you can do the same to verify that. Then if you read about the TCP protocol (RFC793), you will soon find about the 3-way handshaking.