Responsive Firewall always blocks "good" external users

firewall
Tags: #<Tag:0x00007f7021082a58>

(Yois) #41

Right, self signing the module doesn’t work.

So I just hacked validator.php and commented out the sig checking rules, but I can still only load the PHAR directly with PHP, I can’t get fwconsole or the GUI to load the firewall.

What’s so strange is that despite all of the changes I made nothing is effective. I’m quite certain that this is all due to signature issues. The files are definitely changed and I rebuild the PHAR file, and all of the rules are still unchanged.

I see your le cert rules, I’m just doing the same thing but making the rules more sane.


#42

Keep hacking. Did you try copying over the module sig?


(Tom Ray) #43

There is a whole development outline and how to properly write, update and do bug fixes of code (and even submitting new modules) right here:

https://wiki.freepbx.org/display/FOP/Developer+Corner+Home


(Yois) #44

Ty, this doesn’t apply to firewall as it has an internal validation mechanism to verify signatures.

As @jerrm suggested, I kept hacking and bypassed the validation by commenting out line 55 in validator.php before compiling the phar.

I’m testing my changes but I must have a syntax problem… Will keep everyone posted.


(Yois) #45

OK, so I have this tested and working on my system. The pull request is here:
Pull Request #92: FREEPBX-22170 - Prevent false positives in RFW - FreePBX GIT

Essentially, what I did was add a 90 second bypass to the responsive firewall for the first time we see a packet from an IP address. While this functionality was supposed to be there previously, the existing code would not remove successful registrations from the whitelist, and therefore the second time the whitelist would need to be used it wasn’t available and would cause a false block.

I also fixed the issue that registrations hitting the RFW were not always appearing in the UI, by marking the packets earlier in the chain so that they show up as soon as they hit the RFW, not after they fail it first.

What is still unsolved is that fail2ban is working alongside the RFW, and the rules in fail2ban precede RFW. Because of this, a misconfigured devices will cause FAIL2BAN, not RFW, to DOS an entire site. While I can understand the security involved, the likelihood of a sleep deprived sysadmin mistyping credentials is so much more likely than an inside job attack, that I would like to see fail2ban either disabled once RFW is enabled, or that the ruleset should be further down in the IPTABLES chains so that packets allowed through RFW should not be blocked by fail2ban.

Awaiting community feedback if these changes are smart or not.


#46

I’ll try to fire up a distro image. Need to see the generated rules.


(Alex Brainin) #47

Why not use an encrypted VoIP tunnel for that? For example, with Ringotel, you’ll need to white-list only one IP address in your Firewall and no problem connecting any number of mobile/remote users from any public network. You’ll need less than 10 minutes to set it up.


(Simon Telephonics) #48

Unless I’m mistaken about the purpose, the whole point of the responsive firewall is that you don’t need to use VPNs and whitelists and you can have your system open to remote and mobile users without getting clobbered by every scanner that roams the Internet.


(Alex Brainin) #49

Sure, you can leave that working, just never had an issue with blocking “good” mobile and remote users.


(Tom Ray) #50

Well part of this issue here was that a location with multiple users and a dynamic IP was hitting rate limits because of too many requests from the same IP in X time period.

The logic, as I’m seeing it here, is that as long as the IP has a good SIP authentication then it shouldn’t be rate limited at all. Meaning if account 1 on the random IP auths fine, then all other requests from that IP aren’t checked for Y requests in X time. Per the example of 20 employees all ending up at the same hotel on a spur of the moment trip no one could plan for. Otherwise the hotel IP would be block and they all couldn’t connect.

I feel that is flawed logic.


(Yois) #51

Can you explain why?


(Tom Ray) #52

I have but I will do a quick refresher.

SIP credentials are compromised in some fashion. Bad actor starts sending calls and successfully auths. Now bad actor can go crazy because nothing outside of “concurrent calls” will stop them. So sure they get 3 calls going and then all the rest are rejected until those 3 calls complete. So during those 3 calls the system is just being hit over and over and over again. Rinse and repeat. Basically, if the extension has a high concurrent call setting or is unlimited then nothing is stopping those calls from just going through all the time.

Oh and the added bonus, the IP is also allowed to now just hammer other accounts in a brute attack to try to bust those creds and then start using other accounts to make calls.

I mean, it could end up being really bad.


#53

Or one phone with more than a couple of programmed BLFs behind a dynamic IP.

Fail2ban should still trigger in that scenario.

As @yois suggests, there could be better coordination between the firewall daemon and fail2ban. Even with @yois fix, f2b could still kick in and block good traffic if there is too much bad stuff.

Arguably, the firewall daemon could subsume all of the fail2ban functionality for SIP to possibly allow for more awareness.


#54

One solution might be found at

It is an easy way to add ipsets to fail2ban yet still have access to the ipset otherwise, I would expand the above idea into the ignoreip concept for known-good hosts (a whitelist)


(Yois) #55

Here is my proposed fix for the F2B problem:
Compare Yois / firewall-fix - FreePBX GIT

This is completely untested as of yet.


#56

Ignoreip is not inclusive of unbanip. I think you would need both for this approach.

That said, not sure about this. @BlazeStudios has a valid point and there should be a backstop to RFW.

At minimum should not be the default behavior. Maybe as a tunable.

I would look at moving the f2b rules into their own chain so they can be called in a more intelligent manner and bypassed during the 90 second window.

An IP could be unbanned(not ignored) upon a first successful registration.

My thoughts on the flow:

  • IP changes
  • Unauth’d packets come in from the new IP
  • Recent list shows it’s a new IP, bypass f2b and give 90 second window for Client, Asterisk, RFW to work it out and update.
  • Upon successful auth, clear the IP in RFW.
  • If f2b was banned inside the initial window, unban if it’s the first time we’ve auth’d the IP.

At that point additional devices for the IP would be allowed through, but f2b can still kick in if there are repeated bad acts from the IP.

Would need to work through the f2b placement. I could see discussion on separate placement for UDP and TCP, if the calls should be before or after the state rules, etc.


#57

Or perhaps we could just only accept TLS connections for our clients.


#58

Good for now, but eventually not,

Unless client certs are required, TLS is just a minor speed bump for the bots when they decide there isn’t enough low hanging SIP fruit.


#59

Well, requiring client certs is not completely out of order, but how will the bots derive the domain that the certificate was issued to? There is no requirement that you use the same domain as your website nor what dig -x would return.

(And maybe consider not being a low hanging fruit in the interim )


(Rob Thomas) #60

openssl s_client -connect host.name:443 < /dev/null | openssl x509 -noout -text

That’s how ALL SSL scanners work. They parse the certificate first.