13

I am using a rather restrictive firewall on my machine, mostly to block potential port scanning. If any IP address sends me a unsolicited packet (packet that is not a response to my query) the IP address gets blocked for X minutes.

-A INPUT -i  wlan0 -m recent --name PORTSCAN --update --seconds 300  -j   DROP
-A INPUT -i  wlan0 -m conntrack   --ctstate RELATED,ESTABLISHED      -j ACCEPT
-A INPUT -i  wlan0 -m recent --name PORTSCAN --set                   -j   DROP

This rule never blocks legitimate websites. The only "legitimate" website that gets blocked are the stackexchange websites.

This happens constantly. I did not have time to investigate further, but the problem must be on your side, because I don't get these problems anywhere else.

Is your website scanning peoples machines ?

11
  • 1
    Could you show the logs?
    – Braiam
    Commented Dec 6, 2014 at 16:30
  • 4
    Do the two icons next to StackExchange in the top bar ( Recent Inbox Messages resp. Recent Achievents: ... ever change (red backgrounded number, +10/20 etc green highlight)? If not you seem to be blocking unsolicited updates of your page that are based on other peoples actions (upvoting, commenting).
    – Anthon
    Commented Dec 6, 2014 at 16:57
  • @Braiam - I am sorry, but I don't keep a record of rejected packets. I also do not have sufficient technical skills to troubleshoot this. But the firewall rule that I am using, --ctstate RELATED,ESTABLISHED is standard iptables rule. Anybody who is interested can test it himself.
    – Martin Vegter
    Commented Dec 6, 2014 at 22:41
  • 3
    Logging the traffic would be a good start. And running a firewall that you don't understand is generally considered a Bad Idea.
    – Michael Hampton
    Commented Dec 13, 2014 at 19:11
  • @Michael Hampton - What makes you believe I don't understand my firewall rule?
    – Martin Vegter
    Commented Dec 13, 2014 at 19:17
  • 3
    Because you said so yourself. And, because your first two rules are reversed.
    – Michael Hampton
    Commented Dec 13, 2014 at 19:22
  • @Michael Hampton - what do you mean the rules are reversed? The --update rule must be first, to drop the already blacklisted IP addresses. Only clean IP addresses get to the second line and get a chance to pass the RELATED,ESTABLISHED test. I don't understand the "recent module" internals (I have not studied the code), but I understand what the rule does.
    – Martin Vegter
    Commented Dec 13, 2014 at 19:26
  • 2
    Yes, and that's how legitimate traffic gets blocked.
    – Michael Hampton
    Commented Dec 13, 2014 at 19:27
  • @Michael Hampton - I am sorry, but I don't follow
    – Martin Vegter
    Commented Dec 13, 2014 at 19:28
  • 3
    "the problem must be on your side, because I don't get these problems anywhere else" Nonsense logic.
    – Lightness Races in Orbit
    Commented Mar 4, 2015 at 12:35
  • @MartinVegter You're blocking legitimate traffic, and that (what you're doing) is how. You might understand your rules, but you don't understand how those rules might block legitimate traffic.
    – user13757
    Commented Mar 6, 2015 at 13:20

2 Answers 2

Reset to default
21

Gonna throw out a wild guess: your filter sees web socket traffic as "unsolicited".

We use websockets to provide real-time updates for various events happening on the site. If you're blocking HTTP responses that fall outside of a strict window, this will probably break.

If that doesn't jibe with what you're seeing, you'll have to post more info.

2
  • thanks, but this is standard iptables rule: --ctstate RELATED,ESTABLISHED. I have no idea about the inner workings of this module, but I would expect it inspects packets and decides whether it is related to existing session or not. Apparently, some packets fail this test.
    – Martin Vegter
    Commented Dec 6, 2014 at 22:46
  • 9
    @MartinVegter iptables --ctstate (and other forms of state tracking) are not always up to date with the way the web works. In this case you are the one blocking websocket traffic. You need to allow this traffic and leave it up to your browser to authenticate it with existing sessions (or reject it). It is not the job of a firewall to implement and be able to verify all communication protocols, only to decide which protocols you want to use. Stop blocking the protocol and the standard systems that use websockets will start working again, simple as that.
    – Caleb
    Commented Dec 13, 2014 at 19:22
12

Your "anti-portscan" rules do not play well with long-lasting, low-traffic connections. The StackExchange sites use such connections in the form of websockets to update the status bar. If a status bar update arrives after the connection-tracking timeout has expired, the server that sent the update will be blocked for five minutes.

This sort of thing is why you need to understand the inner workings of the firewall modules you use.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .