Unsupported Remote - Accessing Postgresql 3CX V18

[INTRUS]

Good evening, everyone!

Turning to the forum to see if anyone will be able to shed some light on the issue at hand.

We've installed the latest 3CX v18 release using the official 3CX Debian ISO, and the local IPv4 of the server is set to 192.168.100.10/25. Everything is working well on the PBX side of things, however - when attempting to connect to the 3CX Postgres database, we're left clueless as to why the server keeps blocking our connection attempts from a PgAdmin client sitting on the same subnet (192.168.100.15), without any inline packet filtration.

As per traditional Postgres configuration for remote access - on the 3CX server, postgresql.conf has been configured to allow all interfaces to listen for incoming connections, by replacing "localhost" with "*".
Furthermore, pg_hba.conf has been configured to allow for any database to be reached from anywhere (0.0.0.0/0).

Third, since Debian 10 is based on nft and not ipt, the nftables.conf has been updated with the following line "dport tcp { 5432 } accept" under the pre-defined section "Other services".

Yet, while connecting from the PgAdmin client at 192.168.100.15, the following message appears:

"Connection refused (0x0000274D/10061)
Is the server running on host "192.168.100.10" and accepting TCP/IP
connections on port 5432?"

I'm fairly confused as to why the server keeps refusing incoming connections to Postgres, since in theory, above settings should suffice for this to be enabled.

Very grateful for any pointers, especially from users with greater 3CX Debian 10 experience, who may be aware of additional pre-configured deny rules on the server that may be taking place here.

Thanks in advance!

 

[Evolute IT]

The 3CX database is secured to prevent external access. Also, accessing it is unsupported and can cause problems if misused.

 

[INTRUS]

We've been able to do this just fine until V18. Please also explain how this block is pre-configurately enforced on a Debian system level by 3CX.

 

[Evolute IT]

We've been able to do this just fine until V18. Please also explain how this block is pre-configurately enforced on a Debian system level by 3CX.

Because security.

No one will help you access the DB. No one endorses that here.

Small tip: you probably need to check both the firewall tables (nftables) and the Postgres config. Keep in mind that you will be unsupported the second you change something.

 

[INTRUS]

I'm quite appalled by your "Because security" response.

Debian and Postgres are both open applications, and my last question was "how is this enforced on a system level by 3CX?" It also completely ignores the fact that again - we've been able to do this in all recent versions.
Essentially, we're reading data from the pre-configured 3CX Postgres database "database_single", using the "logsreader_single" account, and piping to our MSSQL back-end using a postgres ODBC driver. Again, been working like a charm for years.

Furthermore, your "Small Tip" is basically ignoring my first post where I've clearly outlined the already taken nft and postgres actions to allow for remote access.

I do however very clearly see your 3CX "badges", so if you're an "advanced" 3CX user, I presume you'll be the most qualified individual to answer this question, in theory that is?

Thanks again!

 

[Evolute IT]

I'm quite appalled by your "Because security" response.

Debian and Postgres are both open applications, and my last question was "how is this enforced on a system level by 3CX?" It also completely ignores the fact that again - we've been able to do this in all recent versions.
Essentially, we're reading data from the pre-configured 3CX Postgres database "database_single", using the "logsreader_single" account, and piping to our MSSQL back-end using a postgres ODBC driver. Again, been working like a charm for years.

Furthermore, your "Small Tip" is basically ignoring my first post where I've clearly outlined the already taken nft and postgres actions to allow for remote access.

I do however very clearly see your 3CX "badges", so if you're an "advanced" 3CX user, I presume you'll be the most qualified individual to answer this question, in theory that is?

Thanks again!

So, basically, the security of 3CX is more important than having access to the DB (which I will maintain you shouldn't.) Therefore, a lot of security measures have been implemented at the OS level during installation, specially if you use the ISO.

I do not know if v18 changed anything in this but it might have (I know v16 worked for this because I did it once to fix an issue in the DB), and in this case, only 3CX would know what it is. From my experience, you would be better off running a small C# or PHP/Python script as relay for the database. Connect locally and have sort of an API to query the DB.

Security in 3CX is extremely important and their main defense is obfuscation, so I wouldn't expect any staff members to tell us what changed.

 

[INTRUS]

Security in 3CX is extremely important and their main defense is obfuscation, so I wouldn't expect any staff members to tell us what changed.

Oh yeah? As in how 3CX backups store passwords in plaintext?

 

[Evolute IT]

Oh yeah? As in how 3CX backups store passwords in plaintext?

Backups can be encrypted.

 

[INTRUS]

Still doesn't change the fact. Encryption-at-rest has nothing to do with sanitation practices of included password data.

 

[VoIPTools]

I will chime in on this discussion. First, as has been mentioned many, many, many times on the forums, accessing the 3CX postgreSQL database directly will instantly flag your 3CX server as "unsupported" by 3CX. Below are some of the reasons why 3CX takes a strong position on this discussion:

• You mentioned that you were trying to access the database using PGAdmin. Are you aware that simply clicking on a database table name locks the entire table (all the records)? Can you imagine what that would do to a running 3CX server? What a support nightmare for 3CX!
  
  
• In my opinion, reading the information is far less concerning than writing to the database (however both are prohibited). Using ODBC to access PostgreSQL implies, whether intended or not, that you "could" make changes to the data using that connection. That certainly would be a very, very bad thing. You MUST ensure you are not inadvertently placing locks on records either programmatically (via a read/write ODBC connection) or via PGAdmin. If you are going to do this, make sure you are using a read-only connection.

Second, reviewing your efforts to connect to PostgreSQL remotely suggests that you have a pretty good idea of what is required for a connection. I am unaware of anything 3CX has done recently to lock down PostgreSQL further. However, keep in mind that EVERY change you have made to the PostgreSQL configuration is specifically prohibited by 3CX support. So, even if you never actually access the database, you have already placed yourself in an unsupported state. And unfortunately for you, they now know who you are...

I understand your position that PostgreSQL is an "open" database, but from the perspective of 3CX Support, they can not know what you are doing with the connection. For all they know you have been poking around in the database making changes, or inadvertently causing 3CX to be unable to write to the database intermittently. The potential for all kinds of crazy strage issues to result are simply too broad for them to support your 3CX going forward. PostgreSQL may be an open platform, but you cannot expect 3CX to support you.

Finally, in light of all the reasons outlined above, we cannot help you with this issue. We could get ourselves banned from the forums, jeopardize our 3CX partner status, and perhaps get our 3CX instances flagged as unsupported.

 

[Nick W]

PostgreSQL no, firewall, yes.
Not endorsing at all, but /var/lib/3cxpbx/Bin/nftables.conf is where the V18 firewall sits.