Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 42 subscribers
  • Views 7864 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

Port 113

midnightSun

Sooo when scanning the system i've noticed 113 is the only port showing as closed / reject. Since the other ports are Drop I've created a rule to drop 113 from all connections but SFOS isn't honoring the rule. Why?  Why would they decided to reject only 113?



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

    Where did you run the test from?

    Ian

    What is on port 113?
    Port 113 Details. Port 113 used for Identification/Authorization service. When a client program on your end contacts a remote server for services such as POP, IMAP, SMTP, IRC, FTP, etc. that remote server sends back a query to the IDENT port 113 asking for identification from your system...
    Should I close port 113?
    Although seemingly contrary to conventional wisdom of closing ports from hackers, this port, which is used for ident requests, should be opened. Port 113 initially was used as an authentication port, and later defined as an identification port (see RFC 1413).25 Dec 2016

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to rfcat_vk

    Having ident "open" to the internet is a terrible idea. I cant even take your response seriously. You should totally open 113 if you believe what you wrote.

    A security system / firewall should allow you to control what's allowed and what isn't. Bit of a security issue being scanners can identify the system because of it.  nmap even knows the system is based on the CyberRoam UTM which Sophos bought.

    echo "           __     __         __         __     __    _______               ";
echo ".--------.|__|.--|  |.-----.|__|.-----.|  |--.|  |_ |     __|.--.--..-----.";
echo "|        ||  ||  _  ||     ||  ||  _  ||     ||   _||__     ||  |  ||     |";
echo "|__|__|__||__||_____||__|__||__||___  ||__|__||____||_______||_____||__|__|";
echo "                                |_____|                                    ";

    ~~~ I miss Port 17. Remember using telnet to get the Quote of the Day? Maybe I'll set one up for all the port scanners.  ~~~ 

  • 0 in reply to midnightSun

    I copied those entries from a google search.

    With your reject did you create addend nat rule?

    A firewall will open and close ports as the various applications request access, so you might have had a mail client requesting an update. You did not answer whether you ran the test internally or externally.

    ian

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

Reply
  • 0 in reply to midnightSun

    I copied those entries from a google search.

    With your reject did you create addend nat rule?

    A firewall will open and close ports as the various applications request access, so you might have had a mail client requesting an update. You did not answer whether you ran the test internally or externally.

    ian

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

Children
  • 0 in reply to rfcat_vk

    Its a drop rule. Sending the traffic to nothing shouldn't be required.

    The port shouldn't be closed when all the other ports are Drop by default. It seems SFOS is doing some trickery on the backend. This isn't a new issue and has been around for 20 years with Astaro, CyberRoam, and SFOS. I just happened to be the most recent user attacking our own system and finding it. Maybe I'll just take it direct to Sophos Support and if I get an answer i'll inform the community. SFOS lists 113 as Auth but i don't see the system using it. Hence my questions.

    echo "           __     __         __         __     __    _______               ";
echo ".--------.|__|.--|  |.-----.|__|.-----.|  |--.|  |_ |     __|.--.--..-----.";
echo "|        ||  ||  _  ||     ||  ||  _  ||     ||   _||__     ||  |  ||     |";
echo "|__|__|__||__||_____||__|__||__||___  ||__|__||____||_______||_____||__|__|";
echo "                                |_____|                                    ";

    ~~~ I miss Port 17. Remember using telnet to get the Quote of the Day? Maybe I'll set one up for all the port scanners.  ~~~ 

  • 0 in reply to midnightSun

    How are you testing? I have just quickly ran a portscan on one of my environments with a V20 SFOS using the ShieldsUP page from grc.com and get all stealth ports but 443 which is open (and in our case expected to be open since the VPN portal is running on it).

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • 0 in reply to apijnappels

    Thanks for the reply. 

    I was using nmap. Below is using Shieldsup.  113 shows closed. This is basically a fresh install of v20.  So both scanners show 113 closed. 

    echo "           __     __         __         __     __    _______               ";
echo ".--------.|__|.--|  |.-----.|__|.-----.|  |--.|  |_ |     __|.--.--..-----.";
echo "|        ||  ||  _  ||     ||  ||  _  ||     ||   _||__     ||  |  ||     |";
echo "|__|__|__||__||_____||__|__||__||___  ||__|__||____||_______||_____||__|__|";
echo "                                |_____|                                    ";

    ~~~ I miss Port 17. Remember using telnet to get the Quote of the Day? Maybe I'll set one up for all the port scanners.  ~~~ 

  • 0 in reply to midnightSun

    Here is my SFOS v20 Home system I updated from 19.5.  113 isn't showing. Gurrrrrrrrr. 

    echo "           __     __         __         __     __    _______               ";
echo ".--------.|__|.--|  |.-----.|__|.-----.|  |--.|  |_ |     __|.--.--..-----.";
echo "|        ||  ||  _  ||     ||  ||  _  ||     ||   _||__     ||  |  ||     |";
echo "|__|__|__||__||_____||__|__||__||___  ||__|__||____||_______||_____||__|__|";
echo "                                |_____|                                    ";

    ~~~ I miss Port 17. Remember using telnet to get the Quote of the Day? Maybe I'll set one up for all the port scanners.  ~~~ 

  • 0 in reply to midnightSun

    Must be some reason that it is closed in one environment and stealth in the other... No clue however what migt cause this.

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • 0 in reply to midnightSun

    If you read further on that grc.com webpage:

    Adaptive IDENT Stealthing Experimentation

    The IDENT protocol's port 113 is quite problematical and tricky to stealth. If the user's port 113 is completely stealthed, connections to some remote Internet servers such as eMail, Internet Relay Chat (IRC), and others, may be delayed or denied altogether. For this reason, many NAT routers and personal firewalls do not attempt to stealth port 113, they settle for leaving it closed. One of the first things that caught my eye about the ZoneAlarm personal firewall was that it was clever about handling port 113: It "adaptively stealthed" the port.

    To understand the following discussion, you should familiarize yourself with the details of the IDENT protocol and port 113. Please read port 113's Port Authority database page before proceeding.

    Even after many years, the (free) ZoneAlarm personal firewall from Zone Labs is the only personal firewall to "adaptively" stealth port 113. Unlike any other firewall or NAT router (any of which could also do the same) this allows port 113 to be stealthed to any passing Internet scanners or probes, but "unstealthed" for any valid IDENT connection attempts originating from remote servers with which the user's computer is attempting to connect. (Since this could easily be done by any personal firewall or even NAT routers, I am hopeful that this feature might yet appear in other products.)

    "Adaptive Stealthing" means that when a TCP SYN packet arrives to request a connection to your machine's port 113, ZoneAlarm checks, on the fly, to see whether your machine currently has any sort of "relationship" with the remote machine (such as a pending outgoing connection attempt). If so, the remote machine is considered to be "friendly" and its IDENT request packet is allowed to pass through ZoneAlarm's firewall. But if the IDENT originating machine is not known to ZoneAlarm as a "friendly" machine, the connection requesting packet is dropped and discarded, rendering port 113 stealth to all unknown port scanners. It's very slick.

    IDENT, ZoneAlarm, and ShieldsUP!

    Even though your computer's web browser already has a relationship with the web server at GRC, our tests originate from a different "foreign" IP address. ZoneAlarm therefore drops incoming packets to port 113 from this different probing IP address and ZoneAlarm users see that port 113 is stealthed to passing Internet scans.

    To demonstrate how ZoneAlarm (and perhaps someday other firewalls or NAT routers) selectively "unstealth" port 113 — but only for known "friendly" machines — we simply initiate a connection from your web browser to the ShieldsUP! scanning IP. Even though the connection attempt will ultimately fail (since there's no web server at the probing address), ZoneAlarm will note the outgoing attempt and will unstealth port 113 for subsequent probes.

     Step One: Verify that our scan currently show port 113 stealthed. (You may wish to use one of the other remote port tests which will be faster than an entire 1056-port grid scan.)

     Step Two: Open a secondary web browser window to initiate a connection to the probing IP. (Users of Microsoft Internet Explorer can press Ctrl-N to "clone" their current browser window.)

     Step Three: In the secondary web browser window, click this URL or enter this address:

    https://4.79.142.206

    This second connection attempt will ultimately fail, but ZoneAlarm will notice the effort, which is all that's necessary.

     Step Four: Finally, refresh the port probe window or repeat the scan to check your system's current port status. You should find that port 113 is no longer "stealth" to the probing IP address because you are attempting to connect to it and it has been determined to be "friendly".

     Step Five: If you're curious, stop and close the secondary web browser window and periodically refresh your port probe window to see how long the "friendly" status persists before Zone Alarm returns the probing IP to unknown status and port 113 to full stealth.

    NOTE: Clicking the "http" link above may convince a clever firewall that the remote scanning IP is "friendly" and help to demonstrate its adaptive IDENT handling. But the packets sent to us with that link will also trigger our "Unsolicited Packet" detection since those packets were not received in direct response to our probes.

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

Unfiltered HTML