Another prophylaxis I would deem essential is port scanning detection and immediate blocking of the culprit, such behavior is often a precursor to “directed” attacks, and should never be ignored, It happens a lot especially around 5060-5090 but any such behavior is always either malicious or ill considered . (I am also a security freak)
Perhaps to preempt any reply
I take a more holistic approach, pretty well every “application”/service returned by:-
netstat -nplut|grep -v 127.0.0.1
needs individual attention at the firewall/IDS level (some can be grouped) as these services are otherwise intrinsically exposed on layers =>3 to any and all.
Also if you do a “cookie cutter” install, you expose a “fingerprint” that will take only a few millisecond to capture, that fingerprint if not otherwise coverted will identify your box to the clever but bad guys as “The Distro” they just need to wait till a flaw is discovered. then they can pounce. . .
Call me paranoid if you want, but just because I am , it doesn’t mean they are not trying to “get me”, I know because they have in the past, never on SIP directly, but definitely before I had a comprehensive Firewall solution though
@xrobau : maybe set the max allowed packet rate to (max number of packets the register process needs to succeed, including possible retransmits) * (min(how often the peer(s) needs to register/qualify)) every (min (register interval)) ?- both these latter figures AFAIU can be taken from SIP settings, and the first - from your knowledge of SIP protocol
And offer this as a calculated default - with advanced setting to view where it came from, and possibility to override if one wants OFC, when any of the above changes, this ratelimit figure also NEEDS TO unless it’s overriden.
@dicko: yeah like, you never know with computers, whether you are paranoid enough already, or not yet…
I do this with mail servers and I think this is also an important feature.
Once a device has registered successfully, it’s not going to be rate limited at all. This is only going to be for unknown devices. I don’t want to just block it straight away, because people do copy and paste passwords wrong, or connect to the wrong port, etc.
Anyway, that’s PROBABLY going to be implemented after I get the first build out, which - if I can manage to keep away from having to put out any other fires - should be in a couple of days.
If anyone’s interested in messing around with this and doing some alpha testing, I’ll create a new bug tracker ticket and add a couple of test packages there for people to mess around with.
I’ve also just cleaned up the licencing a bit - GPL licences can be confusing for people who don’t understand them, so I added a couple of of exceptions for people who are distributing unmodified packages – see https://github.com/FreePBX/firewall/commit/772ea354b3cbed7ca02c6442a643b31707341458 for the specifics, but technically anyone who redistributes a GPL or AGPL program is meant to provide their own source code distribution environment. This, I think, is a bit onerous, so as long as people aren’t modifying it, they can avoid that.
Also, if you are modifying it, send the patches back! This is a pro bono thing, and I’m putting a lot of brain sweat into making this as secure as possible. This doesn’t mean I’m right though – It just means that I’ve thought of SOME ways for people to get in, and I’m trying to block that. If you can think of a bug or feature, then tell me about it, or patch it, or anything.
OFC, the ‘formula’ was to be used for the ‘ratelimited’ connections only… I ‘only’ wanted to point that you should be able to calculate a ‘generous’ enough default rate limit just by looking at what settings are on FreePBX SIP settings already.
Thanks for making this work
(the opposite is also true and more important, I think: if you DON’T set the default to accommodate for values calculated from SIP settings (the general SIP settings and/or the SIP settings of individual extensions/devices), you might face a lot of false-positives causing legitimate hosts to get rate limited)
True of course, but simple examination of our logs reveals that most (not all) unwanted connections come from identifiable countries.
So geoblocking is likely to be generally useful, without being it being any total solution.
I’m in favour of using many contributory technologies and layers of protection, hopefully all working together in unison towards the same desired outcome.
Every little bit helps.
So allow only US addresses with ipset (it’s too big for traditional iptables) wait till tomorrow, then revise your current plan as being ineffective and pissing of your clients who go outside your geo-fenced territory.
Bugs are inevitable and security is never perfect.
I actually thought we discussed IPv6 here, but I’m guessing it was on IRC. My original statement was ‘It probably won’t work with IPv6 on its first release’, but then I looked at IPv6 growth, and it’s not something I can ignore now. So!
IPv6 support will be in there, by default.
Edit: Confirmed working!
And properly understands IPv6 addresses now, too.
Symbolic/object names for the networks/hosts ?
so it’s possible to use a network by object name in other rules (including networks assigned dynamically)
The ability to do reverse DNS lookups will happen. I realise it’s something people want.
That too, but I mean an ability to assign an ‘object label’ to an address or multiple addresses / address group / address list (be it a single address, a subnet, interface address or subnet, or the DDNS name) that can be then used in rules by the ‘object label’ name ?
(e.g. you could create an address list comprised of a host by name, a network/subnet numerical, a ddns result, name it e.g. ‘friends’, and do a ‘simple’ rule on your GUI to accept all from list friends but then you can change the list of ‘friends’ and that should update the internal representation too)
That’s what that screenshot I just posted above does.
Ahha! It’s Labor Day in the US tomorrow! This means I get TWO DAYS to Finish off Firewall.
For those that aren’t watching this on IRC, this is how the evolution of FreePBX Firewall has gone:
- I need to make sure I abstract all the firewall stuff out, so it can plug into various Firewall drivers. Firewalld, ufw, and iptables. I’m going to write it around Firewalld first, because I know how that works, and it’s pretty simple.
- Yay, Firewalld works, I can create stuff, and it’s working. OK, let’s start adding some complex stuff in…
- Wat. Firewalld, Y U SO SLOW?
- No really. When I do a firewall-cmd --reload, it wants to drop all packets for 5 seconds? That’s not cool, firewalld.
- Right. This is a pile of putrid debris. It’s buggy and terrible, and I really want to just abandon the Firewalld driver. I can’t believe it’s taking 60 seconds, on a fast machine, to regenerate the firewall rules of a ‘normal’ machine.
- Hi, Iptables. I love you. <3
- Ooh, look, you’re fast, and not stupid, and you don’t want to drop packets just because I asked you to reload.
Anyway. That’s what’s I’m up to now. Sorry about the lack of Development efforts recently, but when I discover things like ‘It’s impossible to upgrade the Distro with FreePBX 13’, I tend to get sidetracked.
However! Two whole days! Let’s see how I go. I still need to write a bunch of documentation and fill out the ‘help’ fields, but I’m almost at the point where anyone who’s actually interested in playing with it can install it and - hopefully - not lock themselves out of their systems.
And yes - 100% IPv6 compatibility. This is a critical feature for me.
Edit: Anyone who DOES want to play with the Firewall stuff - currently on C7 and C6 based distros - are more than welcome to join us on IRC (using the IRC client of your choice - I recommend IRCCloud.com as it has all the handy paste stuff and share files built directly into the client) on the FreeNode network, on the #freepbx or #freepbx-dev channels. Say ‘X-Rob’ or ‘xrobau’ to get my attention, that’ll make my IRC client flash and beep, and try to get my attention that someone’s trying to talk to me.
+1 for iptables l)
(and the rest of this post is just to pass 20char limit, ignore)