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 ?

  • 1
    Could you show the logs? – Braiam Dec 6 '14 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 Dec 6 '14 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 Dec 6 '14 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 Dec 13 '14 at 19:11
  • @Michael Hampton - What makes you believe I don't understand my firewall rule? – Martin Vegter Dec 13 '14 at 19:17
  • 3
    Because you said so yourself. And, because your first two rules are reversed. – Michael Hampton Dec 13 '14 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 Dec 13 '14 at 19:26
  • 2
    Yes, and that's how legitimate traffic gets blocked. – Michael Hampton Dec 13 '14 at 19:27
  • @Michael Hampton - I am sorry, but I don't follow – Martin Vegter Dec 13 '14 at 19:28
  • 3
    "the problem must be on your side, because I don't get these problems anywhere else" Nonsense logic. – Lightness Races with Monica Mar 4 '15 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 Mar 6 '15 at 13:20
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.

  • 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 Dec 6 '14 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 Dec 13 '14 at 19:22
11

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 .