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

Port-500/4500 UDP and 8094 failing PCI scans

Units are XG125W and XG135W running firmware SFOS 17.5.9 MR-9

Having issues with PCI scans failing port 500 UDP

We are using IKEv2 (above suggested standards) so strongswan is obviously enabled and disabling is not an option.

You can not add an ACL as those services for ACL are unable to be edited.

I tried creating a firewall rule to drop anything related to port 500 UDP from the firewalljust to see if the port would stop scanning.

I placed the rule at the top of the page and verified it was active and traffic still flows/port is able to be scanned

Once I can prove that it is dropping scans I will add an allow rule for the IPs that need to be able to access this.

Service Object

Drop rule

Port 8094

The device has been taken out of MTA mode and the SPX Portal settings have been pointed to Port9 which doesn't connect to anything and is completely separate from everything else.

Not sure how to nail these down. Any thoughts would be grand

Here is the failure on PCI scan (Some data omitted for privacy reasons)

Protocol     Port      Program
UDP           500    isakmp
TCP           8094    unknown

TCP 8094 www Title:
SSL Self-Signed Certificate
Synopsis:
The SSL certificate chain for this service ends in an unrecognized self-signed certificate.
Impact:
The X.509 certificate chain for this service is not signed by a recognized certificate authority. If
the remote host is a public host in production, this nullifies the use of SSL as anyone could
establish a man-in-the-middle attack against the remote host. Note that this plugin does not
check for certificate chains that end in a certificate that is not self-signed, but is signed by an
unrecognized certificate authority.

TCP 8094 www Title:
SSL Certificate with Wrong Hostname
Synopsis:
The SSL certificate for this service is for a different host.
Impact:
The 'commonName' (CN) attribute of the SSL certificate presented for this service is for a
different machine.
Resolution:
Purchase or generate a proper certificate for this service.
Data Received:

The Common Name in the certificate is : SophosApplianceCertificate_C1XXXXXXXXXX

This thread was automatically locked due to age.

Parents

0 lferrara over 4 years ago

For the 8094, you can allow the service only from LAN instead of ANY:

https://community.sophos.com/products/xg-firewall/f/firewall-and-policies/77017/how-to-block-port-8094-on-sophos-xg

You can change the Certificate by uplaoding a trusted certificate in Certificates menu and change the default certificate for SPX in Administration > Admin settings > Certificate

For the port 500, more information are needed to understand what is wrong with the scan.

IPSec is not in the list of Local ACL services. :-(

The list of services is not complete.
Cancel
Vote Up 0 Vote Down

Cancel
0 LuCar Toni over 4 years ago in reply to lferrara

For Port 8094, you could also launch a DNAT, if you want.

But most likely you should upload a trusted certificate, matching to your Hostname.

https://community.sophos.com/kb/en-us/127451

__________________________________________________________________________________________________________________
Cancel
Vote Up 0 Vote Down

Cancel
0 MichaelBolton over 4 years ago in reply to LuCar Toni

Jad,

It looks like your service object is set to TCP but it should be UDP. I have used the black hole method in the past for items that don't have ACL's and it has worked. I haven't' tested it in a while though. I will test and see. Just wanted to point out what I saw though. You would think they would have an ACL for ANY service though so you shouldn't have to do this, but that is another topic.

Mike
Cancel
Vote Up 0 Vote Down

Cancel
0 Jad Covington over 4 years ago in reply to MichaelBolton

Yeah an ACL would be nice. Good call on the UDP, I was going by what the "type* TCP/UDP" said, wasn't even paying attention to the drop down box. Thanks.
Cancel
Vote Up 0 Vote Down

Cancel
0 Jad Covington over 4 years ago in reply to MichaelBolton

Unfortunately changing the service to UDP did not fix the issue. Even tried using the default "UDP" service that comes on the device.
Cancel
Vote Up 0 Vote Down

Cancel
0 MichaelBolton over 4 years ago in reply to Jad Covington

I was able to get it working on a test unit running v18 because the NAT rules are separated. For v17, you need a business application DNAT rule pointing to a bogus server like 1.2.3.4 with IKE as the service. This is because the NAT rules are coupled with the firewall rule. I have not been able to test this yet though. In theory it should work. You will also need a DNAT rule above the black hole rule, using your WAN interface IP as the protected server.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 MichaelBolton over 4 years ago in reply to Jad Covington

I was able to get it working on a test unit running v18 because the NAT rules are separated. For v17, you need a business application DNAT rule pointing to a bogus server like 1.2.3.4 with IKE as the service. This is because the NAT rules are coupled with the firewall rule. I have not been able to test this yet though. In theory it should work. You will also need a DNAT rule above the black hole rule, using your WAN interface IP as the protected server.
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data