PostgrSQL & ZA

AndyS · February 2016

Hi,

in several threads it was reported, that there are serious problems of PostgrSQL with several firewall products (not ZA only). The reason is that the open source hackers chose an own philosophy of using a direct channel. But this violates all security guidelines.

But after a longer discussion with the ZA technical support, they proposed a possible solution:

-----------

Thank you for contacting us.

Hello Andreas. Allow me to assist you on this. The PostgrSQL is compatible with ZA Security the thing is that ZA blocks the program because it has it's own direct access to the server. The ZoneAlarm is blocking this connection between your PC and the network.

That is why I need you to create a VPN to unblock this connection or you can click "Remove" the PostgrSQL from the application list to remove the program from application monitoring.

Thank you for providing us the caption. Yes, that is the application control listing program.

Please refer on this link to understand about the application control: http://download.zonealarm.com/bin/inclient/ZA_HelpCenter/program_control_overview.html

Please feel free to contact us if you have any additional questions.

Best regards,

Rayman M.

-----------

The point is that I removed the PostgrSQL from my PC after the problems which occured with the upgrade to 4.8. So at the moment, I'm unable to verify the proposed best practice solution.
Perhaps someone else here with the latest ZA (14.1.011) installed can try it out.

Think, we're thankfull for a report.

Andy

ShelLuser · February 2016

AndyS said:

The reason is that the open source hackers chose an own philosophy of using a direct channel. But this violates all security guidelines.

They're not. You can see as much in the 'ContentCluster' directory, located under your Daz Application folder. On my PC: C:\Users\Peter\AppData\Roaming\DAZ 3D\cms\ContentCluster. This is the actual database directory, and where some configuration files are being kept. Just look at the top sections of 'postgresql.conf':

#listen_addresses = 'localhost'       # what IP address(es) to listen on;
                   # comma-separated list of addresses;
                   # defaults to 'localhost'; use '*' for all
                   # (change requires restart)
#port = 5432               # (change requires restart)
port = 1024
max_connections = 100           # (change requires restart)
# Note: Increasing max_connections costs ~400 bytes of shared memory per
# connection slot, plus lock space (see max_locks_per_transaction).
#superuser_reserved_connections = 3   # (change requires restart)
#unix_socket_directories = ''   # comma-separated list of directories
                   # (change requires restart)
#unix_socket_group = ''           # (change requires restart)
#unix_socket_permissions = 0777       # begin with 0 to use octal notation
                   # (change requires restart)
#bonjour = off               # advertise server via Bonjour
                   # (change requires restart)
#bonjour_name = ''           # defaults to the computer name
                   # (change requires restart)

What you seem to forget is that PSQL is a network based program; it's a server intended for client/server operations. So obviously it will listen for incoming network connections. But as you can see above it'll bind (restrict) itself to the localhost by default (127.0.0.1) which is a very common thing to do. It's also something which cannot cause any problems because it makes remote connections totally impossible. Only clients running on the same computer will be able to get access.

So if some firewall programs react to something listening on the localhost then trust me: that's their problem and display of mismanagement and not that of the involved software, in this case PostgreSQL. Simply because there is no security breach nor any chance of starting one.

Same more or less applies to warnings for outgoing connections to the localhost.

hphoenix · February 2016

ShelLuser said:

AndyS said:

The reason is that the open source hackers chose an own philosophy of using a direct channel. But this violates all security guidelines.

They're not. You can see as much in the 'ContentCluster' directory, located under your Daz Application folder. On my PC: C:\Users\Peter\AppData\Roaming\DAZ 3D\cms\ContentCluster. This is the actual database directory, and where some configuration files are being kept. Just look at the top sections of 'postgresql.conf':

#listen_addresses = 'localhost'       # what IP address(es) to listen on;
                   # comma-separated list of addresses;
                   # defaults to 'localhost'; use '*' for all
                   # (change requires restart)
#port = 5432               # (change requires restart)
port = 1024
max_connections = 100           # (change requires restart)
# Note: Increasing max_connections costs ~400 bytes of shared memory per
# connection slot, plus lock space (see max_locks_per_transaction).
#superuser_reserved_connections = 3   # (change requires restart)
#unix_socket_directories = ''   # comma-separated list of directories
                   # (change requires restart)
#unix_socket_group = ''           # (change requires restart)
#unix_socket_permissions = 0777       # begin with 0 to use octal notation
                   # (change requires restart)
#bonjour = off               # advertise server via Bonjour
                   # (change requires restart)
#bonjour_name = ''           # defaults to the computer name
                   # (change requires restart)

What you seem to forget is that PSQL is a network based program; it's a server intended for client/server operations. So obviously it will listen for incoming network connections. But as you can see above it'll bind (restrict) itself to the localhost by default (127.0.0.1) which is a very common thing to do. It's also something which cannot cause any problems because it makes remote connections totally impossible. Only clients running on the same computer will be able to get access.

So if some firewall programs react to something listening on the localhost then trust me: that's their problem and display of mismanagement and not that of the involved software, in this case PostgreSQL. Simply because there is no security breach nor any chance of starting one.

Same more or less applies to warnings for outgoing connections to the localhost.

Actually, based on what you listed, the only parameters that particular file is setting is port and max_connections. In many unix-originated systems, the '#' (hash) mark is the indicator for a comment....a line that doesn't get used. In other words, all the other lines (the ones with the # at the beginning) are being ignored.

So it looks like it is opening port 1024, with up to 100 connections, and allows connections from ???. (edit) I'm not sure how to read the 'default' comment about the listen. Normal ANSI sockets coding you listen ON a port....not which ports can connect TO it. The IP addresses specified says what the socket is configured to listen ON (like if you have multiple network adapters, which a server can have.)

(edited to add)

This is really ZA's issue. The AV code should allow you to set exceptions for programs/services/etc to open and maintain ports and exclude from scans (for known false positives). Almost ALL firewalls and AVs have these features. If they aren't there, or aren't working right, that is the AV's problem, not the server program.

AndyS · February 2016

Hi,

I thought you wanted to apply constructive results.

Daywalker Designs · February 2016

AndyS said:

Hi,

I thought you wanted to apply constructive results.

Constructive results would be uninstalling ZoneAlarm and installing something else that doesn't require a convoluted configuration to use a locally hosted database, or any other software application that uses TCP/IP to communcate enable communication between two applications on the same PC.

namffuak · February 2016

I see no explanation in the so-called work-around that would explain why ZA explicitly blocks Postgres even when ZA has been disabled.

AndyS · February 2016

???

If you disable ZA, there's nothing anymore (of ZA) which can block PostgrSQL. So perhaps your Windows firewall continues blocking it.

AndyS · February 2016

Hi daywalker,

daywalker03 said:
Constructive results would be uninstalling ZoneAlarm and installing something else that doesn't require a convoluted configuration to use a locally hosted database, or any other software application that uses TCP/IP to communcate enable communication between two applications on the same PC.

I have applications running on my PC doing TCP and UDP comminication to each other. No problems regarding ZA.

joeyteel · February 2016

hphoenix said:

ShelLuser said:

AndyS said:

The reason is that the open source hackers chose an own philosophy of using a direct channel. But this violates all security guidelines.

They're not. You can see as much in the 'ContentCluster' directory, located under your Daz Application folder. On my PC: C:\Users\Peter\AppData\Roaming\DAZ 3D\cms\ContentCluster. This is the actual database directory, and where some configuration files are being kept. Just look at the top sections of 'postgresql.conf':

#listen_addresses = 'localhost'       # what IP address(es) to listen on;
                   # comma-separated list of addresses;
                   # defaults to 'localhost'; use '*' for all
                   # (change requires restart)
#port = 5432               # (change requires restart)
port = 1024
max_connections = 100           # (change requires restart)
# Note: Increasing max_connections costs ~400 bytes of shared memory per
# connection slot, plus lock space (see max_locks_per_transaction).
#superuser_reserved_connections = 3   # (change requires restart)
#unix_socket_directories = ''   # comma-separated list of directories
                   # (change requires restart)
#unix_socket_group = ''           # (change requires restart)
#unix_socket_permissions = 0777       # begin with 0 to use octal notation
                   # (change requires restart)
#bonjour = off               # advertise server via Bonjour
                   # (change requires restart)
#bonjour_name = ''           # defaults to the computer name
                   # (change requires restart)

What you seem to forget is that PSQL is a network based program; it's a server intended for client/server operations. So obviously it will listen for incoming network connections. But as you can see above it'll bind (restrict) itself to the localhost by default (127.0.0.1) which is a very common thing to do. It's also something which cannot cause any problems because it makes remote connections totally impossible. Only clients running on the same computer will be able to get access.

So if some firewall programs react to something listening on the localhost then trust me: that's their problem and display of mismanagement and not that of the involved software, in this case PostgreSQL. Simply because there is no security breach nor any chance of starting one.

Same more or less applies to warnings for outgoing connections to the localhost.

Actually, based on what you listed, the only parameters that particular file is setting is port and max_connections. In many unix-originated systems, the '#' (hash) mark is the indicator for a comment....a line that doesn't get used. In other words, all the other lines (the ones with the # at the beginning) are being ignored.

So it looks like it is opening port 1024, with up to 100 connections, and allows connections from ???. (edit) I'm not sure how to read the 'default' comment about the listen. Normal ANSI sockets coding you listen ON a port....not which ports can connect TO it. The IP addresses specified says what the socket is configured to listen ON (like if you have multiple network adapters, which a server can have.)

(edited to add)

This is really ZA's issue. The AV code should allow you to set exceptions for programs/services/etc to open and maintain ports and exclude from scans (for known false positives). Almost ALL firewalls and AVs have these features. If they aren't there, or aren't working right, that is the AV's problem, not the server program.

Unlike most database servers PostgreSQL defaults to a sane setting for the listen address. If you don't specify otherwise it will only listen on localhost for TCP/IP connections (AKA: 127.0.0.1 (IPv4) and/or ::1 (IPv6)). On Unix OSes it uses a unix domain socket if one is configured, and on WIndows it will use a named pipe by default unless you explicitly tell the client to use TCP/IP networking instead.

ZA's real issue is they don't whitelist localhost -> localhost connections by default whereas most other firewalls do as it's actually pretty stupid to block that as a default setting considering it can break lots of things in really interesting ways. :)

namffuak · February 2016

AndyS said:

???

If you disable ZA, there's nothing anymore (of ZA) which can block PostgrSQL. So perhaps your Windows firewall continues blocking it.

See Rob's post here http://www.daz3d.com/forums/discussion/comment/593430/#Comment_593430 - the only way he could get ZA to stop interfering with Postgres was to uninstall ZA.

Tugpsx · February 2016

Just spoke with ZA technician and was provided a new version of ZA (ZASPSetup_141_048_000.exe) that works with DAZ products. He also provided a ZAClean.exe file which i was instructed to use in order to remove all traces of previous ZA installation before installing the new version.

Tested the new version with DIM, DAZ 4.9 and Carrara 85 64bit all started without the usual hickup or hang.

AndyS · August 2016

Hi Tugpsx,

I only can agree partially.
I tried the same and after the install of DAZ 4.9 everything worked fine. CMS completely operating. So for the first time I was really satisfied. :)

But !!!

After restart of the computer later, DAZ wasn't able to connect to CMS anymore and froze for ever. PostgrSQL didn't have any problems. It was running with 7 processes started by the DAZ startup. But DAZ itself couldn't connect and failed.

So the solution still is not clean.

What is your status? What else did you adjust?

Notifications

PostgrSQL & ZA

Comments

Adding to Cart…