Howdy folks,

For any of you setting up rules in your input_wan table and considering testing access by using the "Shields Up!" port probing utility at grc.com, note that their SYN probe tests are broken by the following entry in the default base case INPUT chain.

iptables -A INPUT -p tcp --tcp-flags SYN SYN --tcp-option \! 2 -j  DROP

When viewed with iptables -L, the rule appears as follows:

DROP     tcp     --     *     *     0.0.0.0/0     0.0.0.0/0     tcp option=!2 flags:0x02/0x02

Any connection tests from this website will show the ports as "Stealth" because the rule will silently drop these packets from the "Shields Up!" application.

Note that normal connection attempts work fine, as do most other port probing sites.  It's just grc.com which is mis-reporting due to the lack of the MSS TCP option they use in their SYN packets.

(Last edited by kaldek on 31 Mar 2008, 12:30)

Hi,
exactly ! I had the same problem cos I though that the portforwarding wasn't working
http://forum.openwrt.org/viewtopic.php?id=14527

Since this day, I recommend using http://nmap-online.com/ to test port forwarding since Shields Up! doesn't respect the RFC.

Tex

LOL, yeah maybe I should have searched the forums before I made my own post!

Actually I will ask one question.  What method did you use to trace where the packets were being dropped.  I just happened to notice that rule had the same number of packets and bytes in it as the prerouting_wan rule!

I assume you just turned on logging for the DROP target?

Hi,
I just run tcpdump do see what going on. When I saw that the packet is received but not forwarded/accepted, I had switch off the firewall and then it worked. So I had a look at the iptables and found the rule you mentioned.

Tex

Hi Folks,

Someone was nice enough to let me know about ShieldsUP!'s problem with OpenWRT-based systems.  Since I certainly want SU to work in every case, I have just added an MSS option (Maximum Segment Size) to GRC's outbound port-testing SYN packets.

You guys should note, however, that TCP options, including MSS, are truly optional, and that dropping inbound SYNs without an MSS option seems rather pointless to me.  It's not providing you with any sort of "protection" and it could cause you to be unable to accept valid incoming TCP connections -- as ShieldsUP! was previously showing.

But in any event, with that iptables rule in place, you will now find that ShieldsUP! will correctly show your router's open and connection-accepting ports.

All the best,
Steve Gibson.

Oh hey Steve.  I was just about to post that you'd fixed it, and here I find you've already been!

I think you have a point about the MSS setting in the default rules.  But then, there will surely be someone who can provide a justification for it that I'm not aware of as yet.

Cheers,

Kaldek

Hey Kaldek...

As a security fanatic I'd LOVE to know the logic behind that.  I sure can't see any.

The only possible use that I could imagine would be to prevent a DoS SYN flood through the firewall ... since "handmade" SYN packets (like mine and) like those produced by DoS bots, might well lack any MSS option (as mine used to).

So I suppose that the rule *could* be used to discriminate between regular TCP OS-stack built SYN packets and "others".  But in the case of a DoS flood, blocking the packets at the router or firewall won't, of course, do anything to avert an attack since it's the bandwidth in front of the router that would still be flooded.

So ... again ... I really don't see the logic.  And, if it were my iptables ruleset, I'd remove that one.

But, in any event, I'm glad to have made ShieldsUP! more compatible with what's actually out there in the real world.  That's my job! 

(And thanks for your confirmation that yesterday's change did the trick!)

All the best,
Steve.

The rule was added years ago when it was observed that the only TCP packets that didn't set the MSS were those from tools which worked by raw packet injection, typically script kiddie tools. While it's not nearly as effective as it once had been (many tools have adapted), it still works as a bozo filter.

Uh, no offense, Steve

No offense taken!  Thanks for the clarification.  I'm glad to know the rule's genesis!

All the best,
Steve.