Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 43 subscribers
  • Views 29412 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

How do I close UDP Port 500?

Bill Roland

I am failing a PCI scan because UDP Port 500 is showing as open|filtered on Nmap scans.  I see that this is the ISAKMP service.  However I do not have any IPsec connections defined, I have Cisco VPN disabled, and I even went so far as to create a Deny/Drop firewall rule for everything incoming hitting port 500, put it at the top, and that still doesn't work.

How do I find out what service on the XG has this port open and then close it?



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

    One thing to attempt is to stop the related daemon on the XG which is enabled by default.

    From the advanced shell option on the XG run the following:

    # service strongswan:stop -ds nosync

     

  • 0 in reply to FHF

    Please post the ramifications of disabling this.  What functionality is lost? 

  • 0 in reply to John Woodall

    Hi John,

    "strongswan" service is responsible for establishing IPsec-based VPN connections.

    Stopping that service would result in disabling those type of connections, which rely on UDP ports 500 and 4500.

    If there is no business need and you wish to tighten security further, then you may consider the actions/suggestions highlighted. 

     

    NOTE: if the XG was to restart, then that service would be started automatically, so Bill Roland's suggestion is better suited.

  • 0 in reply to FHF

    That's what I thought. 

    And if we need the IPSec VPN between sites, and UDP 500 is showing as open and failing a PCI Compliance scan - how do we secure it?

    I have created a WAN-WAN rule for UDP500 that only accepts connection from specified FQDN hosts.  This is fine if I know my remote IP/FQDN, but would be a problem if the remote side is dynamic and we're using Aggressive mode.

    What is Sophos solution?

  • 0 in reply to John Woodall

    This is still failing.

    How can Sophos put out a so-called business class product that doesn't pass PCI compliance? (which really isn't very strict)

Reply Children
  • 0 in reply to John Woodall

    I took a quick google search for this. At the moment, nearly every vendor is struggling with those "ports". 

    I cannot test it right know, but as far as i know, UDP500 should be closed in case of not using IPsec for any. 

    __________________________________________________________________________________________________________________

  • +1 in reply to LuCar Toni

    Well, part of the issue I believe is that you can't even use the firewall to restrict where UDP500 can connect from.

    I had restricted my IPSec VPN to specific FQDN and it was open to the world.  This means it's not REALLY isolated.  It only means it won't successfully connect.  That's not the same.

    It should pass through the firewall FIRST, then connect to an internal service for the IPSec VPN

  • 0 in reply to John Woodall

    You can. Simply use the DNAT process and send this to nowhere. 

    But - As far as i know, if you build up a site to site connection and tell the appliance explicit the peer via IP, is port500 still open? 

    Because i have many customers, which could pass the PCI Test without any issue. 

    Do you use remote access IPsec? 

    Do you use Respond only on XG? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    We had used IPsec VPN to Sonicwalls at 2 remote locations; I tried shunting UDP500 to nothing - still failed the test.

    Since we have moved to RED appliances I had to use [service strongswan:stop -ds nosync] to disable that service and now we're passing.

  • 0 in reply to LuCar Toni

    manbearpig said:

    I took a quick google search for this. At the moment, nearly every vendor is struggling with those "ports". 

    I cannot test it right know, but as far as i know, UDP500 should be closed in case of not using IPsec for any. 

     

    There is some internal, hidden ACL that gets opened up the first time you enable IPsec, so that even if you later stop using it, the port remains "open" and when the PCI scan happens, strongswan is listening and you get all the failures.  Of course a connection won't work since there's nothing configured, but the point is when you stop using IPsec, the port should go back to being filtered/closed.  I ultimately just DNAT'd it to a null IP address and that was the end of that.

     

    Its a problem because even if you appeal it with the PCI vendor (I tried), they won't approve it and you have to do something about it or else you're out of compliance.  

Unfiltered HTML