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 29346 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.
  • 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

    Well that changed the status to "closed" on the port scan, so its definitely strongswan that is listening.  Support tried to tell me it was RED but that was counter to all the published KB's.  

    Is there a way I can create an ACL or something to filter it?  I am assuming it is going to start up everytime I reboot the appliance?  I have another XG on which I have never activated IPSec or Cisco VPN and it correctly shows as "filtered" rather than "closed."   

  • +1 in reply to Bill Roland

    Alright so replying to my own thread, I think I have figured out a workaround.  I remembered this being a problem in the past with RED and somebody suggesting the workaround of creating a business rule and essentially publishing the port to a null IP address.  So I did that for UDP 500, and voila, it's now coming back as "filtered" since XG is now forwarding this traffic to essentially a black hole.  We'll see if its confirmed by the next PCI scan that will occur in the next 24 hours but my own port scan now show it as filtered, as it should be.

    I maintain this should not be necessary.  I have another XG where this behavior doesn't happen, I guess because I never activated IPSec on it and so whatever internal ACL that gets created to allow IKE traffic on UDP 500 for strongswan to listen for never happened.  Seems like a bug to me.

  • 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)

  • 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? 

    __________________________________________________________________________________________________________________

Unfiltered HTML