Securing FreePBX from attacks
-
The responsive firewall doesn't use Fail2Ban as far as I can tell.
I'm currently looking up a blocked IP as well.
In my case I think my phones are registering unregistering to much.. and it's causing the IP to be banned by the RF.... now to find out why the phones are doing that.
-
@dashrender said in Securing FreePBX from attacks:
The responsive firewall doesn't use Fail2Ban as far as I can tell.
I'm currently looking up a blocked IP as well.
In my case I think my phones are registering unregistering to much.. and it's causing the IP to be banned by the RF.... now to find out why the phones are doing that.
It does.
-
@scottalanmiller said in Securing FreePBX from attacks:
@dashrender said in Securing FreePBX from attacks:
The responsive firewall doesn't use Fail2Ban as far as I can tell.
I'm currently looking up a blocked IP as well.
In my case I think my phones are registering unregistering to much.. and it's causing the IP to be banned by the RF.... now to find out why the phones are doing that.
It does.
I have IPs listed as blocked in the RF, but my fail2ban log is 100% empty.
Please explain. -
@dashrender said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@dashrender said in Securing FreePBX from attacks:
The responsive firewall doesn't use Fail2Ban as far as I can tell.
I'm currently looking up a blocked IP as well.
In my case I think my phones are registering unregistering to much.. and it's causing the IP to be banned by the RF.... now to find out why the phones are doing that.
It does.
I have IPs listed as blocked in the RF, but my fail2ban log is 100% empty.
Please explain.What's to explain? Why do you feel that RF blocking something and Fail2Ban not logging is meaningful?
-
@scottalanmiller said in Securing FreePBX from attacks:
@dashrender said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@dashrender said in Securing FreePBX from attacks:
The responsive firewall doesn't use Fail2Ban as far as I can tell.
I'm currently looking up a blocked IP as well.
In my case I think my phones are registering unregistering to much.. and it's causing the IP to be banned by the RF.... now to find out why the phones are doing that.
It does.
I have IPs listed as blocked in the RF, but my fail2ban log is 100% empty.
Please explain.What's to explain? Why do you feel that RF blocking something and Fail2Ban not logging is meaningful?
Forgive me if I sound thick, but I'd interpret having no logs as one of three things: 1. The service's logging mechanism not turned on. 2. No activity is being seen that would generate a log. 3. The service itself isn't functioning; thus, not producing logs.
If a blocked IP list in the RF = fail2ban activity, then that answers the mystery.
As far as my query, I see activity in the fail2ban file when viewing Reports > Asterisk Log files in the GUI. What I'm wondering is why there are no jails listed if I run
fail2ban-client status? The answer to this is probably, "Hey Eddie! Go read up on fail2ban and don't be a n00b;" however, that's my current puzzle.
-
@eddiejennings said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@dashrender said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@dashrender said in Securing FreePBX from attacks:
The responsive firewall doesn't use Fail2Ban as far as I can tell.
I'm currently looking up a blocked IP as well.
In my case I think my phones are registering unregistering to much.. and it's causing the IP to be banned by the RF.... now to find out why the phones are doing that.
It does.
I have IPs listed as blocked in the RF, but my fail2ban log is 100% empty.
Please explain.What's to explain? Why do you feel that RF blocking something and Fail2Ban not logging is meaningful?
Forgive me if I sound thick, but I'd interpret having no logs as one of three things: 1. The service's logging mechanism not turned on. 2. No activity is being seen that would generate a log. 3. The service itself isn't functioning; thus, not producing logs.
Seems a bit extreme. Given that Fail2Ban is integrated into another service and not being run on its own and that "you" did not configure it yourself so have no specific expectation of behaviour, those are some pretty wild assumptions to make for what would be totally normal behaviour by design.
-
@scottalanmiller said in Securing FreePBX from attacks:
@eddiejennings said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@dashrender said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@dashrender said in Securing FreePBX from attacks:
The responsive firewall doesn't use Fail2Ban as far as I can tell.
I'm currently looking up a blocked IP as well.
In my case I think my phones are registering unregistering to much.. and it's causing the IP to be banned by the RF.... now to find out why the phones are doing that.
It does.
I have IPs listed as blocked in the RF, but my fail2ban log is 100% empty.
Please explain.What's to explain? Why do you feel that RF blocking something and Fail2Ban not logging is meaningful?
Forgive me if I sound thick, but I'd interpret having no logs as one of three things: 1. The service's logging mechanism not turned on. 2. No activity is being seen that would generate a log. 3. The service itself isn't functioning; thus, not producing logs.
Seems a bit extreme. Given that Fail2Ban is integrated into another service and not being run on its own and that "you" did not configure it yourself so have no specific expectation of behaviour, those are some pretty wild assumptions to make for what would be totally normal behaviour by design.
Since, as I've learned in this thread, Fail2Ban is integrated into the Responsive Firewall it does make sense that it might not produce specific logs. However, I fail to see how my general assumption about logs is wild. It is not reasonable to ask "why?" when you look for logs and see none, given that you might not already know that no logs is normal behavior, rather than say "oh well, this thing must not produce logs."
-
@eddiejennings said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@eddiejennings said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@dashrender said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@dashrender said in Securing FreePBX from attacks:
The responsive firewall doesn't use Fail2Ban as far as I can tell.
I'm currently looking up a blocked IP as well.
In my case I think my phones are registering unregistering to much.. and it's causing the IP to be banned by the RF.... now to find out why the phones are doing that.
It does.
I have IPs listed as blocked in the RF, but my fail2ban log is 100% empty.
Please explain.What's to explain? Why do you feel that RF blocking something and Fail2Ban not logging is meaningful?
Forgive me if I sound thick, but I'd interpret having no logs as one of three things: 1. The service's logging mechanism not turned on. 2. No activity is being seen that would generate a log. 3. The service itself isn't functioning; thus, not producing logs.
Seems a bit extreme. Given that Fail2Ban is integrated into another service and not being run on its own and that "you" did not configure it yourself so have no specific expectation of behaviour, those are some pretty wild assumptions to make for what would be totally normal behaviour by design.
Since, as I've learned in this thread, Fail2Ban is integrated into the Responsive Firewall it does make sense that it might not produce specific logs. However, I fail to see how my general assumption about logs is wild. It is not reasonable to ask "why?" when you look for logs and see none, given that you might not already know that no logs is normal behavior, rather than say "oh well, this thing must not produce logs."
Asking why is NOT what you did. You made three extreme assumptions INSTEAD of asking why. Had you asked why, the answer might be simple - it's not supposed to log or you are looking in the wrong place. Instead, you didn't ask why but decided it must be broken and came up with three ways you felt in might be broken in. Very different things.
-
@scottalanmiller said in Securing FreePBX from attacks:
@eddiejennings said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@eddiejennings said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@dashrender said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@dashrender said in Securing FreePBX from attacks:
The responsive firewall doesn't use Fail2Ban as far as I can tell.
I'm currently looking up a blocked IP as well.
In my case I think my phones are registering unregistering to much.. and it's causing the IP to be banned by the RF.... now to find out why the phones are doing that.
It does.
I have IPs listed as blocked in the RF, but my fail2ban log is 100% empty.
Please explain.What's to explain? Why do you feel that RF blocking something and Fail2Ban not logging is meaningful?
Forgive me if I sound thick, but I'd interpret having no logs as one of three things: 1. The service's logging mechanism not turned on. 2. No activity is being seen that would generate a log. 3. The service itself isn't functioning; thus, not producing logs.
Seems a bit extreme. Given that Fail2Ban is integrated into another service and not being run on its own and that "you" did not configure it yourself so have no specific expectation of behaviour, those are some pretty wild assumptions to make for what would be totally normal behaviour by design.
Since, as I've learned in this thread, Fail2Ban is integrated into the Responsive Firewall it does make sense that it might not produce specific logs. However, I fail to see how my general assumption about logs is wild. It is not reasonable to ask "why?" when you look for logs and see none, given that you might not already know that no logs is normal behavior, rather than say "oh well, this thing must not produce logs."
Asking why is NOT what you did. You made three extreme assumptions INSTEAD of asking why. Had you asked why, the answer might be simple - it's not supposed to log or you are looking in the wrong place. Instead, you didn't ask why but decided it must be broken and came up with three ways you felt in might be broken in. Very different things.
As far as the text as it was typed, you're 100% correct, I didn't ask why. The process in my head was "Why are there no logs? No logs must mean [insert the three things I listed]." So my failure is two-fold. First, I need to add a 4th and 5th option to my thought process of "Why are there no logs" which includes 4. There aren't supposed to be logs. 5. There are logs, just in a different location. Second, I ought to type my exact thought process rather than assume a person would think that I've asked myself "why" and came up with X result.
-
I think I can now answer my own question. Since Fail2Ban isn't acting on its own, it won't have any jails listed.
-
@eddiejennings said in Securing FreePBX from attacks:
I think I can now answer my own question. Since Fail2Ban isn't acting on its own, it won't have any jails listed.
Potentially, yes. I'd expect something to log somewhere, but that F2B doesn't do it itself is not surprising.
-
If this is truly the case of integration, it stinks that 2 hours of searching for info on how to find things in logs, settings came up so short - i.e. seeming little/no documentation. Now because Scott will accuse me of something I'm not intending - I'm not accusing them of not having any documentation, but I will say I find it extremely difficult to find if such documentation does exist.
-
Current task is now figuring what "invalid data" is being sent by my external test users to cause the firewall to think they're attackers.
-
@eddiejennings said in Securing FreePBX from attacks:
Current task is now figuring what "invalid data" is being sent by my external test users to cause the firewall to think they're attackers.
ug.. I have this exact problem!
-
To clarify, this is negatively affecting people from making calls with Linphone. I'll deal with UCP access and such later.
-
@eddiejennings said in Securing FreePBX from attacks:
Current task is now figuring what "invalid data" is being sent by my external test users to cause the firewall to think they're attackers.
UDP?
-
@scottalanmiller said in Securing FreePBX from attacks:
@eddiejennings said in Securing FreePBX from attacks:
Current task is now figuring what "invalid data" is being sent by my external test users to cause the firewall to think they're attackers.
UDP?
In @Dashrender's case he has Yealink desk phones as the only thing on site and the site is getting blacklisted by the responsive firewall. As soon as he white lists the IP, the phones register.
-
@jaredbusch said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@eddiejennings said in Securing FreePBX from attacks:
Current task is now figuring what "invalid data" is being sent by my external test users to cause the firewall to think they're attackers.
UDP?
In @Dashrender's case he has Yealink desk phones as the only thing on site and the site is getting blacklisted by the responsive firewall. As soon as he white lists the IP, the phones register.
Oh, the RP not the outside edge firewall. Odd, okay.
-
@scottalanmiller said in Securing FreePBX from attacks:
@jaredbusch said in Securing FreePBX from attacks:
@scottalanmiller said in Securing FreePBX from attacks:
@eddiejennings said in Securing FreePBX from attacks:
Current task is now figuring what "invalid data" is being sent by my external test users to cause the firewall to think they're attackers.
UDP?
In @Dashrender's case he has Yealink desk phones as the only thing on site and the site is getting blacklisted by the responsive firewall. As soon as he white lists the IP, the phones register.
Oh, the RP not the outside edge firewall. Odd, okay.
Yeah. Forgive my lack of clarity.
-
Other oddity. Both redacted IP addresses are the same.
