Guest User!

You are not Sophos Staff.

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

"Closed" not "Stealthed" ports

Guys,

I've just deployed ASL on my ADSL connection at home, and I'm very with one exception.

I've used the "Shields Up" service at Steve Gibson's GRC site, and while it shows most ports as "stealthed", the ports 21 (FTP), 80 (HTTP) and 139 (IDENT) are reported as being "closed".

How do I change the config of ASL to drop incoming packets on these ports too?


This thread was automatically locked due to age.
  • Hi,

    just enable /Network/Portscan Detection/.

    Maybe you want to exclude your internal Lan ?!?

    ..
     Claus
  • Nope, portscan is already running...

    FWIW, it's port 113 and not 139 that is closed - port 139 is correctly stealthed.

    Any other thoughts?

    UPDATE: Default portscan exclusion of Any->Any wasn't helping! Now only port 113 is showing as closed...

    [ 01 December 2001: Message edited by: YuppieScum ]

  • Just a little sidenote here... why do you care so much for "stealthed" ports? I think this is somewhat of a hype. 

    AFAIK, so called "stealthed" ports are ports where the firewall drops the response totally - also known as blackhole. 

    An issue related to using blackhole, is that a portscanner actually will spend more time at your site, as the portscanner will wait for the request to timeout. 
    This may not really be all that bad, but this way, you are leaving the scanner with the idea that you have alot to protect...

    Best regards,
    Ørjan Sandland
  • I agree with Ørjan Sandland firewalls spend a LOT of time dropping the packet request rather then denying it.  So its pretty much just easier to deny the request
  • Thing is though, if the firewall thats "denying" requests, then you're effectively getting into a conversation with your attacker, which he (or she) can then compromise to start a denial of service.

    I'd much rather drop than deny, as the timeout becomes someone elses problem...
  • Yuppie, may I ask what kind of a "conversation" you are referring to?

    We are after all talking about CLOSED ports here, not open ports available for tcp connects (3way handshakes) or even resets.

    Oh, the timeout may become your problem, if someone decides they are going to figure you out anyway. Then they will then hit you twice instead of receiving a reject and moving on.

    Best regards,
    Ørjan Sandland

    [ 02 December 2001: Message edited by: Ørjan Sandland ]

  • The whole point in closing ports is so he can't deny services.  there is no handshake or server communication involved.

    Client hits server...  port ### is closed so he is rejected enrty.  End of story there is no furthere action can be taken.  That is the point of a firewall
  • Correct me if I'm wrong, but AFAIK, there are no handshake involved if you set a port to reject. The port is after all closed, not open and allowing a three way handshake take place.

    If someone is in the process of enumerating my firewall from a location that triggers a reject (as opposed to a drop) - what are they going to do?

    Anyone around that can shed some real low-level tcp/ip light on this?   [:)] 

    Ørjan
  • The way "drop" vs "deny" was explained to me (a long time ago, so forgive me if I get it wrong) is...

    Deny: 
         Attacker interrogates a port. 
         Firewall checks it's rules and decides the port is closed to that originator. 
         Firewall sends a "deny" message to the originator.[/list]

      At this point, the firewall has (a) announced the existance of a machine at this address and (b) extended a challange to the attacker. Also, if he forges the "return address on his packets, you've also given the attacker the means to DoS you (return address doesn't exist) or to use you to DoS on a 3rd party (return address is someone elses).

      Drop:  
      •    Attacker interrogates a port. 
           Firewall checks it's rules and decides to drop the packet.
           Attackers has to wait for his IP stack to time out, then tries another port or moves on.[/list]I know which behaviour I'd rather have from my firewall   [:)]

        [ 10 December 2001: Message edited by: YuppieScum ]

  • That was a pretty nice comparison between the two. It definately sounds correct to me.

    Sure I see why you want to do a drop instead of a deny. You basically don't want to give away the fact that this ip is populated at all.

    In an ideal world this is great. But in the real world where I live ;-), there are such things as published services.... ports like http/https/ssh that are required to be open. 

    When the attacker realises that you are drop'ing his packets, you may very well have raised the bar in regards to how much effort he/she will take to hack your system. Surely, when you have stealthed a port, you must have something (more than the ip "next door") to hide.

    And of course, not to speak of a DNS entry...
    If your firewall is defined in some sort of DNS, which is the issue for many users with NAT systems, you have already given away your presence.
    If you use the web, any decent discussion forum will log your IP-address - and voilah.
    If you use email, your smtp server will give away your IP-address to any recipient of your emails.
    Perhaps this is an issue with news too, but I really never looked at that.

    If you lie very still and make no waves, you are correct; a drop will not give you up to a potential hacker - while a deny/reject definately will.

    Unfortunately, there are so much else that reveals your presence, that you might just have caused the hacker try twice on your site if you are discovered.

    Just my thoughts.

    Best regards,
    Ørjan Sandland