"Closed" not "Stealthed" ports

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

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

You are, of course, correct in what you say about published ports. If I indend "offering" HTTP, FTP or whatever to the "public", then of course the ports are open. However, they're only required to be open if you actually intend serving from them.

You're also correct regarding the "footprints" we all leave behind in our travels across the net (on UseNet, the server you post to will record your IP address, but the replicants, IIRC, will only know the server it was posted to). However, most users nowadays have dynamic rather than static IP addresses, so at best these traces point to where you were, not where you are now   [:)]  

 

quote:

---

When the attacker realises that you are drop'ing his packets, you may very well have raised the bar

---

This is really the crux of my original question: I have set all of my ports to "drop", as I wish to appear as if I'm not here, but ASL continues to repspond to probes on port 113 as "deny" against my wishes - thereby encouraging any attacker to try all the more. 

A drop is saying "nothing to see here, move along" whereas a deny says "there's something here, but you can't have it", but there's no point in dropping on just some ports - it has to be all or nothing...

I guess the most important thing here is that asl will not show you requests for ports.
If you are satisfied with your configuration, you may want to drop packets.
If you want to test a rule, it might be easier to deny- so you can see something in your life-log.
Anyhow, if you are offering ports, the most logical reason to drop is that you might save network traffic in not sending ICMP-packets... some people are looking for this to get your network down. I don't know if asl has a maximum of ICMP-packets/second beeing sent... can be useful ;-)

Chris
*by the way- I don't offer, so I drop ;-)*

I agree that it is a bit strange that you can't drop on port 113. Wonder what ASL techies has to say to this (also wonder how I can make them read this.. they should be pretty bored with us now ;-)

Regards,
Ørjan S

Well, just for laughs (and not being able to sleep), I've just run Up2Date to go from 2.016 to 2.019. 

I've also added an explicit rule to the packet filter (I now have 3 - "allow all from internal to anywhere", "drop all incoming on 113" (new) and "drop all incoming").

It's not made any difference. GRC's scanner still says port 113 (IDENT) is responding "closed" - deny rather than drop.

I had hoped that an Astato guy would have joined in by now... then again, I'm using ASL for free (except for an Xmas card + postage) so perhaps I shouldn't feel too hard done by...

On the other hand, has anyone else experienced the same issue?

Under most circumstances you are better off rejecting port 113 rather than dropping it - if you are a home user.  

The reason for this is that when you try to use POP and SMTP the server on the far end often sends an IDENT (113) packet to your machine before completing the request.  If you drop, you have to wait, if you reject, the machine on the other end assumes that you are non-unix and do not support IDENT and it stops asking and moves on to the business at hand.

Business users might not be quite as worried by this since they are more likely to be using the SMTP relay function and managing their own email systems.

Something to consider...

If you are a business with a public footprint and important information to hide then you don't really need to stealth.  This may seem counter-intuitive but it isn't.  It is the home user that may want to stealth so he/she may be able to avoid further scrutiny due to convincing a would-be attacker that they aren't even there.  If a business gets attacked though it isn't going to be because of a random scan; it is going to be because something wants something from your domain.  So if I scan Microsof.com and find stealthed ports it isn't going to convince me that they aren't there.  At that point there is no benefit to stealth over closed.

As for the 113 debate there is only one issue I can think of.  Email takes forever on many servers if the machine can't connect to 113 on the IP trying to get mail.  This is a hassle and it can be avoided by allowing 113 to touch the external interface of the firewall.  As far as I know this is toally harmless and keeps email instant rather than a 30-60 second process.

 [:)]

All the point regarding the pro's and con's of dropping or rejecting traffic on the IDENT (or any other) port as interesting and valid.

However they entirely miss the point of my original post!

I have deliberatly set the packet filter in ASL to drop ALL incoming packets on ALL ports, but the IDENT port still responds with reject. I want IDENT to drop too...