System under attack, should I worry?

freepbx
Tags: #<Tag:0x00007fafd65c5c50>

#1

Hey guys, for three days now I’m constantly getting emails from fail2ban for failed sip attempts. After 8 hours I counted about 2000 failed attempts.
Should I worry or is this okay and fail2ban will handle it fine?

Ports opened:
TCP/UDP: 5060-5061
UDP: 10000-20000

Also UCP is accessible from the wan, but secured by an additional firewall and reverse proxy.

All passwords are secure.


#2

If you get that mant emails, its pretty certain fail2ban isn’t working as expected, so yes, eventually they will get through! , the maximum rate would be one email every “ban-time” for the jail

`less /var/log/(yourfail2banlog)

fail2ban-regex /var/log/asterisk/(yourlog) /etc/fail2ban/filter.d/(yourjail)`

would be a start , options to show missed lines etc available

fail2ban-regex --help

You didnt say how you installed fail2ban so I put the unknowns in()'s


(Itzik) #3

If there’s no need to keep them open publicly, then lock it down.


#4

According to the fail2ban-log, ips are getting banned for 30mins, then unbanned, then instantly banned again. Doesn’t seem to extend the ban time if this happens regulary.

I actually don’t remember manually installing fail2ban, I believe it already came preconfigured with the distro.


#5

If 5060 & 5061 aren’t opened, how should the pbx communicate with the provider?


(Itzik) #6

Allow these ports from your SIP Provider’s addresses only.


#7

Enable and adjust the recidive jail in fail2ban , (this works better on current versions of fail2ban). best though, don’t bind to 5060 (or anything close to it )


#8

Trunks either are IP based so send SIP to your PBX as defined, (allow those IP addresses in your firewall) or if using ‘registration’ are informed by your successful registers to the VSP (likely still allow those IP addresses also, but a well formed router will happily forward ‘related’ traffic correctly.

Given the above, if your SIP channel driver of whatever flavor binds to a port which is NOT 5060 for incoming connections and you add tell all your endpoints to use the same NOT 5060 but your defined BINDPORT you will not get less attempts against 5060 at the external interface, but you will find that your PBX replies are just not there. Problem Solved. For belt and braces, after you see its working, drop 5060 at your firewall’s INPUT chain


#9

I have to apologize. Found the problem, someone (with very high probabilty me) stopped one of our firewall services responsible for stopping these attacks. Problem solved!


(Moussa) #10

Accidents happens :slight_smile:. Now you have the firewall up will be a good idea to restrict access to TCP/UDP: 5060-5061 to your trusted IPs (your site, remote sites, SIP providers, etc). dicko’s approach will provide additional defense for your system.


(Franck Danard) #11

There’s always soem risk to expose your system directly to the WAN (port forwarding).
For trunks, sometimes there’s no choise, but for any extension, you can use any VPN connections under UDP.
OpenVPN works fine.
But I worked some years with a paranoiac rules with my fire wall (just accept only trusted IP address). That works fine too.


#12

Besides closing things off security wise where possible, I make the fail2ban block last for 48 hours, eventually they will give up.


#13

I changed the Ban Time in Fail2Ban to -1. Blocks them permanently.

Watch your log files. My Fail2Ban Log Files filled the disk .


#14

Watch your logrotate settings . .


#15

I should clarify, my Fail2Ban log files filled the disk before I switched the ban time to -1 - because the switch was blocking IPs for 10 minutes but then after 10 minutes the attack was still going on so blocking again. Changing it to -1 prevented it filling the disk, because once blocked it didn’t re-appear.


#16

There’s almost never a valid reason to expose any of the ports on your PBX to the public. Remote trunks that use registration will open the ports for responding packets automatically.

If you have remote extensions and cannot service them by registering directly with a service provider, they should connect via OpenVPN, which is included with the FreePBX Distro and most linux distributions.


#17

hmm, External extensions need access through the interwires , but you are going to have to help every one of your /android/apple/windows/whatever clients setup VPN’s over their lack of understanding (perhaps including yours :slight_smile: ) ?

(how would a ‘remote extension’ register with ‘a service provider’ and be able to be part of your PBX?)

Otherwise a great idea . . .

examples . . .

I have a iphone . . . .
I have an android . . .
I use Windows . . .
I use MacOs
I use an OBI
I use an . . . . . . . . . .


#18

If someone is using an external extension, then you’re already setting up their phone and/or their softphone. You can set-up an VPN at the same time.

Remote extensions can register to a service provider and use the service provider’s internal extension system to get into your system. They can also use a regular DID to call into your system. There are lots of ways to do it.


(system) closed #19

This topic was automatically closed 31 hours after the last reply. New replies are no longer allowed.