Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 5 subscribers
  • Views 2167 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

PCI scan detected TCP port 5432 (opened) on our Sophos Q9 fwall's ip

Claude Belmonte

Hello Team,

we have a Sophos Q9 fwall.

Some days ago we were scaned due to PCI audit.

The result of this scan is that scanner found the next issue:

Threat:

The service detected a database installation on the target. Databases like Oracle, MS-SQL, MySQL, IBM DB2, PostGgresql, Firebird and other are detected. The database instance is listed in the result section below.

Impact:

Information disclosing database type will lead attacker to perform more targeted attacks.

Solution:

Users are recommended to encrypt the database information and handle the situations where any error is leading to disclose some sensitive information like database type and its version.

Result: 
PostgreSQL server instance detectedPOSTGRESQL instance detected on TCP port 5432.



We cheched Sophos instance and found active PostreSQL service on that Instance. 


Can you please provide any information how we can close this item/vulnarebility?   
Thank you.


This thread was automatically locked due to age.
Parents
  • 0

    Pryvit Claude and welcome to the UTM Community!

    Those scans are generic and totally automated. Most of the time, the people that run the tests and interact with customers are clerks with no formal training.  I doubt that port 5432 is open at all.

    The underlying database for Reporting in UTM is PostgreSQL and that is a widely-known fact.   Unless your password for root is root, I think an attacker will spend several centuries trying to break into the hardened Linux that UTM is based on.

    Good luck with your scanning service - hopefully, they have someone that's knowledgeable that can get them to see that this is a pointless positive and possibly erroneous.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi There, 

    Sorry for the delay in response, I need some clarification on this vulnerability scan

    I'm sure this port is not exposed to the internet, it’s restricted within people’s network only! I'm thinking the Qualys scanner is detected this incident is because when it's trying to scan all external ports in the Sophos firewall. Is that because, By default, PostgreSQL listens on port 5432 which may tried to access any external services via these external ports? As far as I know, we have not configured any external server PureMessage to communicate with Sophos. 

     Here is the port listen details from sophos...

    <M> fwall5d:/root # lsof -i -P -n | grep LISTEN | grep 5432

    postgres   4664  postgres    4u  IPv4     13969      0t0  TCP *:5432 (LISTEN)

    postgres   4664  postgres    5u  IPv6     13970      0t0  TCP *:5432 (LISTEN)

    <M> fwall5d:/root # netstat -tulpn | grep LISTEN | grep 5432

    tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      4664/postgres       

    tcp        0      0 :::5432                 :::*                    LISTEN      4664/postgres       

    <M> fwall5d:/root # 

     

     

     

    Below is the scan result!!

    QID: 19568
    Severity: 2   
    CVSS Base: 5    AV:N/AC:L/Au:N/C:P/I:N/A:N
    CVSS Temporal: 3.8    E:U/RL:U/RC:UC
    PCI Compliance Status: FAIL    
    • The QID adheres to the PCI requirements based on the CVSS basescore.
    • Automatic Failure: Open access to databases from the Internet
    Category: Database
    Port/Service: 5432 / Database (tcp)
    False Positive: N/A
    Bugtraq ID: -
    CVE ID: -
    Vendor Reference: -
    Last Update: 12/02/2019 at 19:00:00
    Threat:

    The service detected a database installation on the target. Databases like Oracle, MS-SQL, MySQL, IBM DB2, PostGgresql, Firebird and other are detected. The database instance is listed in the result section below.

    Impact:

    Information disclosing database type will lead attacker to perform more targeted attacks.

    Solution:

    Users are recommended to encrypt the database information and handle the situations where any error is leading to disclose some sensitive information like database type and its version.

    Result: 
    PostgreSQL server instance detectedPOSTGRESQL instance detected on TCP port 5432.
  • 0 in reply to Claude Belmonte

    I still think it's a false positive.  I just tried to telnet on port 5432 to the IP from which you posted above (mods can see a poster's IP) and the port is closed.

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Sophos Team,

    We have a similar issue reported on the DNS as well while executing the external canner part of the PCI check, We are using internet DNS points to our on-prem DNS server (forwarder), We have up to date patch, is there any workaround to fix this issue?

    https://docs.sophos.com/msg/pmx/help/en-us/msg/pmx/concepts/GSGPrereqPorts.html
     

    DNS Server Allows Remote Clients to Snoop the DNS Cache

    216.220.59.222
    mail.psigate.com
    QID: 15035
    Severity: 2   
    CVSS Base: 5    AV:N/AC:L/Au:N/C:P/I:N/A:N
    CVSS Temporal: 4.8    E:H/RL:W/RC:C
    PCI Compliance Status: FAIL     
    • The QID adheres to the PCI requirements based on the CVSS basescore.
    Category: DNS and BIND
    Port/Service: 53 / DNS and BIND (udp)
    False Positive: N/A
    Bugtraq ID: -
    CVE ID: -
    Vendor Reference: -
    Last Update: 06/12/2019 at 19:00:00
    Threat:

    The DNS server was found to allow DNS cache snooping. This means, any attacker could remotely check if a given domain name is cached on the DNS server.

    This issue occurs when a target DNS server allows an untrusted client to make non-recursive DNS queries for domains that the target DNS server is not authoritative on. If the target DNS server consults its cache and replies with a valid answer (the IP address or "does not exist" NXDOMAIN reply), it is vulnerable to this attack. This tells the attacker that someone from the target network recently resolved that particular domain name.

    QID Detection Logic (unauthenticated):
    We make a DNS A query for testdeadenddummy.qualys.com from the target DNS server. The Recursive Query flag is set in this query. This means that the target DNS server will recursively search for the address of testdeadenddummy.qualys.com domain name and reply with an IP address to our scanner. If we do not get a reply we quit without posting a vuln.
    - Next, we make the same DNS "A" query for the same domain-name name testdeadenddummy.qualys.com. However, this time we leave the "Recursive Query" flag unset. This means, we are requesting the target DNS server to check its cache or pre-defined DNS zone information for the IP address of the testdeadenddummy.qualys.com domain name. (If no information is present there, it should not find this information recursively from other DNS servers, and should simply reply with a non-found message). Since no other DNS server will have a zone for qualys.com, if we do get a reply, it has to be from the cache. If we do not get a response, we quit.
    - If we do get a valid IP address in the reply, it means the DNS server consulted its cache and replied with the IP address of a site it recently cached. So an attacker can see what sites are cached in the DNS server by making non-recursive "A" requests for them.

    Impact:

    DNS caches are short lived and are generated by a recent DNS name-resolution event. By repeatedly monitoring DNS cache entries over a period of time, an attacker could gain a variety of information about the target network. For example, one could analyze Web-browsing habits of the users of a network. By querying for DNS MX record caches, one could check for email communication between two companies.

    Information gathered from the DNS cache could lead to a variety of consequences ranging from an invasion of privacy to corporate espionage. The above mentioned paper presents a couple of attack scenarios where this vulnerability can be used.

    Solution:

    Here is a suggested solution for the Microsoft Windows DNS server. One rigorous solution involves what is known popularly as a "split DNS" configuration.

    • The idea is to have two separate DNS servers, one for the DMZ/perimeter of the network that faces the public Internet, while the other is internal and not publically accessible.
    • The external one has zone information about only the hosts in the DMZ region which need to be accessed from the Internet. It has no information about the internal hosts with non-routable addresses.
    • The internal one has all the authoritative information about the internal hosts, and also static entries for the services in the DMZ region (so internal users can access those if required).
    • Typically, the internal DNS server will be Active Directory integrated, with (secure) dynamic updates enabled.
    • The external DNS server will typically be a standalone (not integrated with the Active Directory) server without any dynamic DNS updates enabled.
    • To prevent the unrelated DNS cache-poisoning vulnerability, also configure the registry as explained in Microsoft Knowledge Base Article 241352 on both the DNS servers.
    • Both the DNS servers can be named with identical domain names, such as example.com without any conflicts.
    • The external DNS server should be set as a "forwarder" in the DNS settings of the internal DNS server. This means, for any DNS query (A/PTR) that the internal DNS server receives, that it is not able to resolve, it forwards it to the external DNS server for resolution.
    • Through the "DNS" MMC snap-in, Recursion should be enabled on the external DNS server, and disabled in the internal one. This prevents the internal DNS server from attempting to resolve DNS queries if the external one fails to do so.
    • To reinforce the last configuration, the internal DNS server should be set as a "slave" DNS server through the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters" key's "IsSlave" value set to 1.
    • Finally, to prevent cache snooping on the external DNS server, create a "MaxCacheTtl" DWORD entry with value set to 1 under the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters" key of the external DNS server. This makes the TTL of any cached DNS entry on the external DNS server equal to 1 second, effectively disabling caching on it. Since for any query originating from the internal network, both the DNS servers cache the responses, performance is not affected at all even by disabling the external cache - repeated future DNS queries will be picked up by the internal DNS server and replied to from its cache.
    This separates the external DNS proxy from the internal DNS cache, and prevents any DNS cache snooping from the public Internet.

    For BIND and the understanding of the issue this URL will be helpful. http://www.rootsecure.net/content/downloads/pdf/dns_cache_snooping.pdf

    Result: 
    Server's cache timeout for IPv4 addresses is more than 3 sec.
Server's cache timeout for IPv6 addresses is more than 3 sec.
Reply
  • 0 in reply to BAlfson

    Hi Sophos Team,

    We have a similar issue reported on the DNS as well while executing the external canner part of the PCI check, We are using internet DNS points to our on-prem DNS server (forwarder), We have up to date patch, is there any workaround to fix this issue?

    https://docs.sophos.com/msg/pmx/help/en-us/msg/pmx/concepts/GSGPrereqPorts.html
     

    DNS Server Allows Remote Clients to Snoop the DNS Cache

    216.220.59.222
    mail.psigate.com
    QID: 15035
    Severity: 2   
    CVSS Base: 5    AV:N/AC:L/Au:N/C:P/I:N/A:N
    CVSS Temporal: 4.8    E:H/RL:W/RC:C
    PCI Compliance Status: FAIL     
    • The QID adheres to the PCI requirements based on the CVSS basescore.
    Category: DNS and BIND
    Port/Service: 53 / DNS and BIND (udp)
    False Positive: N/A
    Bugtraq ID: -
    CVE ID: -
    Vendor Reference: -
    Last Update: 06/12/2019 at 19:00:00
    Threat:

    The DNS server was found to allow DNS cache snooping. This means, any attacker could remotely check if a given domain name is cached on the DNS server.

    This issue occurs when a target DNS server allows an untrusted client to make non-recursive DNS queries for domains that the target DNS server is not authoritative on. If the target DNS server consults its cache and replies with a valid answer (the IP address or "does not exist" NXDOMAIN reply), it is vulnerable to this attack. This tells the attacker that someone from the target network recently resolved that particular domain name.

    QID Detection Logic (unauthenticated):
    We make a DNS A query for testdeadenddummy.qualys.com from the target DNS server. The Recursive Query flag is set in this query. This means that the target DNS server will recursively search for the address of testdeadenddummy.qualys.com domain name and reply with an IP address to our scanner. If we do not get a reply we quit without posting a vuln.
    - Next, we make the same DNS "A" query for the same domain-name name testdeadenddummy.qualys.com. However, this time we leave the "Recursive Query" flag unset. This means, we are requesting the target DNS server to check its cache or pre-defined DNS zone information for the IP address of the testdeadenddummy.qualys.com domain name. (If no information is present there, it should not find this information recursively from other DNS servers, and should simply reply with a non-found message). Since no other DNS server will have a zone for qualys.com, if we do get a reply, it has to be from the cache. If we do not get a response, we quit.
    - If we do get a valid IP address in the reply, it means the DNS server consulted its cache and replied with the IP address of a site it recently cached. So an attacker can see what sites are cached in the DNS server by making non-recursive "A" requests for them.

    Impact:

    DNS caches are short lived and are generated by a recent DNS name-resolution event. By repeatedly monitoring DNS cache entries over a period of time, an attacker could gain a variety of information about the target network. For example, one could analyze Web-browsing habits of the users of a network. By querying for DNS MX record caches, one could check for email communication between two companies.

    Information gathered from the DNS cache could lead to a variety of consequences ranging from an invasion of privacy to corporate espionage. The above mentioned paper presents a couple of attack scenarios where this vulnerability can be used.

    Solution:

    Here is a suggested solution for the Microsoft Windows DNS server. One rigorous solution involves what is known popularly as a "split DNS" configuration.

    • The idea is to have two separate DNS servers, one for the DMZ/perimeter of the network that faces the public Internet, while the other is internal and not publically accessible.
    • The external one has zone information about only the hosts in the DMZ region which need to be accessed from the Internet. It has no information about the internal hosts with non-routable addresses.
    • The internal one has all the authoritative information about the internal hosts, and also static entries for the services in the DMZ region (so internal users can access those if required).
    • Typically, the internal DNS server will be Active Directory integrated, with (secure) dynamic updates enabled.
    • The external DNS server will typically be a standalone (not integrated with the Active Directory) server without any dynamic DNS updates enabled.
    • To prevent the unrelated DNS cache-poisoning vulnerability, also configure the registry as explained in Microsoft Knowledge Base Article 241352 on both the DNS servers.
    • Both the DNS servers can be named with identical domain names, such as example.com without any conflicts.
    • The external DNS server should be set as a "forwarder" in the DNS settings of the internal DNS server. This means, for any DNS query (A/PTR) that the internal DNS server receives, that it is not able to resolve, it forwards it to the external DNS server for resolution.
    • Through the "DNS" MMC snap-in, Recursion should be enabled on the external DNS server, and disabled in the internal one. This prevents the internal DNS server from attempting to resolve DNS queries if the external one fails to do so.
    • To reinforce the last configuration, the internal DNS server should be set as a "slave" DNS server through the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters" key's "IsSlave" value set to 1.
    • Finally, to prevent cache snooping on the external DNS server, create a "MaxCacheTtl" DWORD entry with value set to 1 under the "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters" key of the external DNS server. This makes the TTL of any cached DNS entry on the external DNS server equal to 1 second, effectively disabling caching on it. Since for any query originating from the internal network, both the DNS servers cache the responses, performance is not affected at all even by disabling the external cache - repeated future DNS queries will be picked up by the internal DNS server and replied to from its cache.
    This separates the external DNS proxy from the internal DNS cache, and prevents any DNS cache snooping from the public Internet.

    For BIND and the understanding of the issue this URL will be helpful. http://www.rootsecure.net/content/downloads/pdf/dns_cache_snooping.pdf

    Result: 
    Server's cache timeout for IPv4 addresses is more than 3 sec.
Server's cache timeout for IPv6 addresses is more than 3 sec.
Children
Unfiltered HTML