SSL Warnings

PCI tests are all automated and no human at your testing service looks at anything closely enough other than to say, "It looks like you have some things to work on."  It's a pet peeve of mine that they don't even keep track of your responses to the same issues at the prior test - you just need to keep that ready for them for the next time...

I've seen the argument made that the RED connection is actually more secure with a self-signed cert as that actually makes it more difficult for someone to gain access for nefarious purposes.  After all, it's not like this is something open to the public or that there is anything that the tester could see - their tests are not that sophisticated.

Cheers - Bob

Why is the UTM responding to port 3400 on all IPs?

It would be a feature request to be able to limit that as one can limit User Portal access.  The workaround is a blackhole DNAT for such traffic arriving on the "(Address)" objects you don't want to respond (see #2 in Rulz).

Cheers - Bob

It would be a feature request to be able to limit that as one can limit User Portal access.  The workaround is a blackhole DNAT for such traffic arriving on the "(Address)" objects you don't want to respond (see #2 in Rulz).

Cheers - Bob

So I would just set up a DNAT rule like so:

Traffic from Internet IPv4

Port 3400

To the outside NATted address of my SFTP server

Routed to a nonexistant server?

Yes, just be sure the blackhole DNAT is above the DNAT for your SFTP server.

Cheers - Bob

Is there a security risk associated with this port being open?   I suspect there is, so I would raise it as such with support.  The same behavior occurs with SMTP 25, but there is no incremental risk because port 25 is already open on the internet, and the traffic flows into the MTA in the same manner from ang source IP.  In this case, it seems 3400 should not be exposed at all.

This seems to have been fixed in one of the newer versions of firmware.