SOLVED Several issues with fresh install of IncrediblePBX 2020 on Centos 7

[tine]

The upgrade to Asterisk 17 did go through after all. I was getting things confused. When I did a "pbxstatus" from a SSH connection I can see "Aserisk 17.7.0 Incredible GUI 15.0.12.24", but the Dashboard was showing "Incredible PBX 2020 15.0.16.73.1" I was not reading thoroughly. Sorry about that. I would like to continue to try to rescue this system before I try a fresh install. I guess I can learn more this way. I believe if I tighten up the firewall I can solve some issues. So my only issue may be the " Log files". I configured the Log Files settings as per the instructions posted, but mine is still not working.

I don't have any port forwarding on the router.

I will send the snippets once I can get the logs working again.

I plan to do a fresh install tomorrow if I cant this this right. I see there is a Backup and Restore module. Thought I could just backup the necessary configs, but this is showing 62 modules. Which are the most important? Can i backup to a Flash drive?

 

[tine]

I have another IncrediblePBX 2020 that I had recently setup at another location and was comparing the firewall rules with this one I'm having issues with and can see that on both the first line in the Input Chain is to "allow ALL from anywhere to anywhere". This is the default that came with this installation. Unless I'm not understanding something, this maybe the cause of the hole in the firewall.

 

[wardmundy]

I have another IncrediblePBX 2020 that I had recently setup at another location and was comparing the firewall rules with this one I'm having issues with and can see that on both the first line in the Input Chain is to "allow ALL from anywhere to anywhere". This is the default that came with this installation. Unless I'm not understanding something, this maybe the cause of the hole in the firewall.

What is the actual rule that you claim is "allow(ing) ALL from anywhere to anywhere?" There is no such rule.

 

[tine]

Under Chain Input (policy Drop) there is an entry:
taget Accept prot ALL source 0.0.0.0/0 destination 0.0.0.0/0

ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Educate me as to what this mean.

 

[Eliad]

Under Chain Input (policy Drop) there is an entry:
taget Accept prot ALL source 0.0.0.0/0 destination 0.0.0.0/0

ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Educate me as to what this mean.

Iptables rules work from top to bottom. It is important to look at what is after this rule.

 

[wardmundy]

@tine: If you want to learn about IPtables, there are numerous resources on the web. The forum isn't the best place to take a college-level course. What the specific rule you're referring to means in Plain-English is DROP all incoming traffic from everywhere unless there is a rule below this one that allows the traffic.

The rule you're referring to applies to the loopback interface, lo, only. Don't use iptables -nL to decipher scope of actual rules. Use: iptables -vL

 

[Eliad]

Under Chain Input (policy Drop) there is an entry:
taget Accept prot ALL source 0.0.0.0/0 destination 0.0.0.0/0

ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Educate me as to what this mean.

Lets not forget this PBX is behind a DD-WRT router/firewall. If DD-WRT is setup correctly you should not see any hacking attempts into the PBX. If you see those then your entire network behind the DD-WRT is at risk due to DD-WRT configuration errors.

 

[tine]

That makes sense. Was reading it the other way around but it wasn't not making much sense to me. Was asking myself why would I need to whitelist any other IP if it is allowing all already. Even if DD-WRT is open, shouldn't this firewall also block the attempts so that I don't see them in the logs?

 

[wardmundy]

Correct unless you have modified the firewall rules. Post the sanitized log.

 

[hawk#1]

Even if DD-WRT is open, shouldn't this firewall also block the attempts so that I don't see them in the logs?

No, they should be seen in the logs. The log should provide a list of what happened. If DD-WRT blocked it so that it did not get to the firewall, then it will not be in the log because the firewall never saw the attempt

 

[tine]

The log is not working. I followed the instructions I received earlier in the thread but to no avail. Here is my firewall. Only added local IP to whitelist.

 

[wardmundy]

The two sections you added at the bottom of the file are exposing your server! Don’t mess with something you don’t understand. Don’t stick forks in electric outlets.

 

[wardmundy]

The server has been exposed. Delete it! Start over. Follow the tutorial. And don’t f*ck with the firewall.

 

[Eliad]

and fix your DD-WRT settings, it is exposing your entire LAN

 

[tine]

This is not making sense. The only thing I added was to whitelist LAN subnet by following your instruction to use ./add-ip. Yes, by mistake i added it twice, but I figured no biggy, as I had seen double entries in other parts of the iptables. Point be to the exact line that I messed up to expose the server. Or better yet, how should I have done the entry to whitelist the LAN subnet.

When I re-do my server I don't want to make any mistakes, so I like to understand where exactly I went wrong.

 

[Eliad]

Looking at your postings. I think your problems started when you installed Firewalld then you had to disable it. Probably during this process other components of the firewall become unglued.
I think Ward did a great job in making IncrediblePBX very secure out of the box, this is the main reason I did not go with regular release FreePBX . As he said do not mess up with the firewall settings.

 

[wardmundy]

@tine: FireWallD is a front-end for IPtables. If you re-enabled it, you trashed the Travelin' Man 3 firewall setup. So you did a bit more than just "following [our] instruction."

 

[jerrm]

Under Chain Input (policy Drop) there is an entry:
taget Accept prot ALL source 0.0.0.0/0 destination 0.0.0.0/0

ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

I don't see any such rule in the iptables-save output you posted. Where and WHEN do you see that rule?

 

[jerrm]

The two sections you added at the bottom of the file are exposing your server!

What two sections are you referring to? The nat and mangle blocks? They look standard to me.

But I'm still on post-surgery drugs.

 

[wardmundy]

@jerrm: I must be, too. He was simply misinterpreting the iptables -nL data. Still awaiting his logs showing a breach.