dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
57685

Time Out$
Premium Member
join:2002-04-28
North Myrtle Beach, SC

Time Out$ to jvmorris

Premium Member

to jvmorris

Re: Closed vs Stealthed Ports

"I'm going to request WildCatBoy to at least modify my original posting in this thread to carry this correction"

Does that mean people will also their 'thumbs' up votes back?

This thread is still cooking with or without the onions.

You just have to peel them under cold water sometimes.

Stonedonkey
Premium Member
join:2001-05-15
Corte Madera, CA

Stonedonkey to jvmorris

Premium Member

to jvmorris

Re: BIG Mea Culpa!!

said by jvmorris:
I screwed up; actually, I screwed up big-time. I know it now and it's my responsibility to 'fix' it, as best as possible.

I have personally learned a ton from this thread. I don't think your errors are as bad as you think. You should be patting yourself on the back for doing such back-breaking research, for no more reward than that of finding out the answer to a confusing conundrum.. And you caught your errors, so no biggie, right?

Best. Thread. Ever.

jvmorris
I Am The Man Who Was Not There.
MVM
join:2001-04-03
Reston, VA

jvmorris to jaykaykay

MVM

to jaykaykay

Re: Closed vs Stealthed Ports

jaykaykay,

Mama tole' me there be days like these!

nevertheless
Premium Member
join:2002-03-08
St Catharines, ON

nevertheless to Wildcatboy

Premium Member

to Wildcatboy
said by Wildcatboy:
As far as I am concerned there are inherent advantages when you run in the stealth mode and this is not due to what the hacker would think or guess but basically due to the fact that if you don't respond to SYN packets you spend less memory and CPU time during a SYN flood attack, your IP can't be successfully used as a decoy to scan others and you make it much harder for intruders to fingerprint your machine, Also methods that use ICMP unreachable messages from your computer to map your Internal network by incremental changes to TTL and constantly probing you, will not succeed if they don't get a response at all.

I'm not terribly sure how much CPU time you really will be saving, even during a flood. Your machine still must read the wire, still must at least parse the header of the packet to determine where this packet is connecting to, and then it must lookup a ruleset to just drop the packet. Certainly not a no-op.

Also, it seems to me from the above statement and other places that the agreed-upon benefits of 'stealth' are as follows (correct me if I'm wrong, of course).

1) Less CPU time. I wouldn't mind someone actually working on this sort of thing to see the true impact on CPU load. I really doubt there'd be a lot of difference over dropping or replying.

2) Bandwidth If someone's DoSing you, either your inbound traffic is pooched and your outbound is clear(stealth), or both your inbound and outbound are pooched(closed w/ replies). Assuming the DoS is worth the name, even with 'stealth', service-wise you're still dead in the water--you won't reliably get any return packets to any outbound request of yours.

So, really, for Bandwidth the only concern is that by replying to packets you're doubling your bandwidth utilization for whatever time period you're being DoSed.

3) Decoy Packets Not respnding to 'decoy' packets, possibly causing remote machines to be damaged/investigated using your resources.

4) Remotely mapping an internal network.

I find this argument somewhat dubious as the whole point of any firewall is to block unwanted/unecessary traffic. You don't need to be stealth to block ICMPs that shouldn't be passed onto your home network (non-routable) anyway (I can't see that anyone using a personal firewall would actually be running anything other than NAT/ICS).

5) It's fun to make other peoples' jobs more difficult
quote:
The disadvantages are that if you don't know what you are doing you may cause problems with your connection to your ISP and you'll make it more difficult for them to troubleshoot the problem.
Very much agreed.

How's about a compromise, then. Your firewall answers the first X packets properly, then tarpits the rest. Answer, say, the first X packets and then only 1% of the rest of the packets that are sent to you--or none until a particular 'event' stops happening.

If X is small enough, a decoy attack using you won't be sufficient to bring down or damage someone else, and you can't really do anything about the inbound traffic anyway. You save bandwidth on outbound traffic, yet you still provide at least a minimum amount of necessary traffic to ensure that someone/thing troubleshooting might get the drift.

Sure, tracking things like this will take up CPU time, but, honestly, most consumer PCs on the Internet are way overpowered for what they're doing (save games, or some such).

I'm pretty sure I can set this sort of thing up with my firewalling software (iptables), 'tho I can't say that I've ever tried.

jvmorris
I Am The Man Who Was Not There.
MVM
join:2001-04-03
Reston, VA

jvmorris to Wildcatboy

MVM

to Wildcatboy
said by Wildcatboy:
... In JV's experiment the number of log entries recorded are either due to the more events that were being logged or just a mere coincident because unlike what JV thought, he was running stealth in both occasions. . . .
Yes, just wanted to confirm this to remove any lingering doubts. Regardless of what I may have thought at the time, the 'stealth vs unstealthed' results that I previously posted were, in actuality, all the results from being 'stealthed'. Indeed, if you look at that .zip file, you'll see that the results are virtually identical. However , if you compare the BLOCK ICMP Echo Request/Reply results with the PERMIT ICMP Echo Request/Reply results, I saw a definite difference in that result. Me, personally, I'd still run with the ICMP BLOCK rules for a variety of reasons, but if any of you ZA users see a difference between running 'stealthed' (high security) and 'unstealthed' (medium security), it may well be due to little more than the fact that ZA appears to also block the ICMP comms when run in 'stealthed' mode.
quote:
. . . . Until we find a volunteer to test this thoroughly we can't even tell you if there's a significant increase in hits when being scanned while stealth. . . .
Agreed. Incidentally, CrazyM has a whole raft of PSFs available, he might be able to do it. And I think someone else offered to play guinea pig at one point, but I don't think they ever indicated if their PSF was switchable.
quote:
As far as I am concerned there are inherent advantages when you run in the stealth mode and this is not due to what the hacker would think or guess but basically due to the fact that if you don't respond to SYN packets you spend less memory and CPU time during a SYN flood attack, your IP can't be successfully used as a decoy to scan others and you make it much harder for intruders to fingerprint your machine, ...
On that note, the Intrusion Protection feature in NIS 3.x/4.x is going to shut down SYN floods, anyway (unless you explicitly add the IP involved to the Exclusions list). The NIS/NPF AutoBlock feature is essentially a form of 'stealth' in and of itself, as far as I can tell.
quote:
. . . . The disadvantages are that if you don't know what you are doing you may cause problems with your connection to your ISP and you'll make it more difficult for them to troubleshoot the problem.
Also agreed. Indeed, there are documented issues of some early ZA (free?) users experiencing this particular problem (and without using ICS/ICF, I might add). Don't know if this problem continues to exist, one way or the other. If it does, that might be a consideration, of sorts. However, like you, I don't see it as all that big a deal as to whether one runs "medium security" in ZA (free) or "high security" in ZA (free). Consequently, the solution is readily available to ZA users without needing to upgrade to ZA Pro, as I understand it.
jvmorris

jvmorris to Stonedonkey

MVM

to Stonedonkey

Re: BIG Mea Culpa!!

Stonedonkey,

Oh, stick around, man! Wait 'til I start trying to "rationalize" how I screwed it up! Then, the fit will hit the shan!
jvmorris

jvmorris

MVM

Re: Closed vs Stealthed Ports

said by jvmorris:
Yep, that's what I'm currently seeing. .... I really would like to know why it used to show closed at GRC, but now shows stealthed regardless of what I do.
Okay, this is a prior response that I need to correct. In fact, NIS/NPF (and probably Atguard back to version 3.1) never showed 'closed' results (in general) at GRC's "Probe My Ports" site. True, there are some special cases that occurred from time to time, but that's not germane to the general thrust of this thread.
jvmorris

jvmorris to R2

MVM

to R2
R2,

Okay, I need to correct the following:
said by R2:
CrazyM -- I would think it would be highly possible for all Software Firewalls to respond in either a 'closed' or 'stealth' manner. I believe that is exactly what JVM can do with his NIS firewall (correct?). ....
No, the statement that I indisputably made (and to which you refer above) was incorrect. NIS/NPF has always provided a 'stealthed' response if an port not in use by a listening server application is queried, as far as I can currently tell.

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

R2

MVM

It's OK -- you don't have to go about correcting these!!

jvmorris
I Am The Man Who Was Not There.
MVM
join:2001-04-03
Reston, VA

jvmorris

MVM

R2,

Okay, this is where one of the massive corrections needs to be made. Bear with me a second.
said by jvmorris:
.... Well, frankly, I'm getting a bit baffled here myself as to what the situation is with regards to NIS, especially 3.0 FE on Win 98 SE. As WildCatBoy indicates (and I will confirm after having seen the raw logs), there's absolutely nothing different in the NMAP log if I run Unstealthed and PERMIT the ICMP Echo Request/Reply and if I run Stealthed and BLOCK the ICMP Echo Request/Reply. The NIS firewall event logs are effectively identical in either case, also.
Okay, first, before I confuse the hell out of everyone based on a chronologically earlier response to WildCatBoy, then I was talking about traceroute results using Visual Route 6.0a via a London UK web-based server; these comments above, on the other hand, are based on WildCatBoy doing an NMAP probe directly from his system against mine. Not the same benchmark at all (and WildCatBoy did not run an integrated ICMP scan when these tests were conducted, just so ya know.)
said by jvmorris:
So, that leaves an interesting question: At the moment, just what does the "Stealth Blocked Ports" option accomplish? . . . .
Okay, time for the (part of the) rationalization. (Maybe I can sneak it in here and no one will notice! )

It seems to me that Symantec has a semantic problem (which is doing a lot to add to my confusion). In their KnowledgeBase URL (previously quoted), they treat "Stealthed" and "Blocked" as synonymous terms. However, when (as below) they talk about "Stealth Blocked Ports", it's quite obvious that 'stealth' and 'blocked' must be interpreted differently. Nowhere (that I've found) does Symantec ever define the terms "blocked ports" or "unused ports", which is what the whole discussion (vis-a-vis NIS/NPF) revolves around. And it gets worse, much worse.
You see, the early versions of NIS/NPF were almost indistinguishable from the last versions of WRQ's AtGuard firewall, so venerated by many. Well, "BLOCK" in AtGuard was a firewall rule action, complemented by PERMIT and IGNORE (which was really a 'log only' option). At that time, 'BLOCK' and 'stealth' had no one-to-one correlation (primarily because I don't believe the latter term was in use at that time). Not finished yet. You see, AG implicitly BLOCKED all ports for which there was not an explicit PERMIT statement; this was known as the 'Implicit Block Rule', and was the default behavior for AG. But, dating all the way back to NIS/NPF 1.0, Symantec introduced a subtle twist on this concept with their "Unused Port Blocking"; this tended to remove some of the firewall events that, in AG, would have produced an "Implicit Block rule" firewall event. So, what does Symantec's current option to "Stealth Blocked Ports" really mean? Does it apply to firewall events that would normally be covered by either the 'Implicit Block Rule' or by 'Block Unused Ports' -- or does it apply to something else? Apparently, it applies to 'something else', which is not explicitly defined in the Symantec documentation. (I can guess what 'something else' really is, but I'd prefer not to at the moment.) And I'm still not finished. At some point (as any user of Sven's Schaefer's NIS Log Viewer is well aware), Symantec introduced a new action to the firewall event log. In addition, to being able to log events that were associated with an action of "Block", "Permit", or "Ignore (log only)", Symantec introduced a new action: "Stealthed". Well, in the context of what's been said previously, what the heck does that mean?
quote:
According to the NIS 3.0 Help file,
quote:
Stealth Blocked Ports. Causes blocked ports to not respond at all to inquiries from the Internet. When your computer receives an inquiry on a blocked port, it can respond that the port is closed, or it can not respond at all. If your computer responds that the port is closed, it passes an important piece of information to the inquiring computer: that there is a computer there. If your computer does not respond at all (stealth), the inquiring computer learns nothing.

From my preceding comments in this posting, it should be clear that part of the confusion I'm trying to deal with has to do with the question of what does 'Stealth blocked ports' mean as opposed to what does 'stealth unused ports'. Unfortunately, neither of these terms is well defined in any Symantec documentation that I've found to date, so it's sort of left as an exercise for the readers to divine the intent themselves. (That's not really a good idea, guys.)

What (I suspect) we are dealing with here is another example of that old adage: "Too many cooks (especially over too long a time period and too many restaurants) spoil the broth."
quote:
Well, that's certainly the way my system used to respond, but it's not the way it responding right now. . . .
And, once again, the above statement is factually incorrect; and I need to once again acknowledge it.
. . . .

jaykaykay
4 Ever Young
MVM
join:2000-04-13
USA

jaykaykay to jvmorris

MVM

to jvmorris

Re: BIG Mea Culpa!!

It already dood that! Now, back to the chopped liver.

The WiseGuy
@optonline.net

The WiseGuy to Wildcatboy

Anon

to Wildcatboy

Re: Closed vs Stealthed Ports

__________________________________________
Said by WCB
But can you tell me what the difference is between running in high security and medium Internet Security in ZA? As far as I know Nothing. Except of course for the lack of Stealth feature in Medium there's nothing else that ZA doesn't do in medium that it does in high, is there?
-----------------------------------

I don't know all the differences, but in testing the other day, I found that with ZAF 2.6.357 set to medium, it allowed the GRC scan to connect to Trillians Ident server on Port 113 even when I denied Trillian permission. I saw the same sort of the behavior with the Beta of ZAPlus when it was set to ask and I denied Trillian permission under Medium security. Under High internet security, ZAF showed stealth on Port 113 even with Trillian listening.

Also in the default settings in ZAPlus High Internet defaults to disallow Net Bios out but with Medium security you would need to check the box.

jvmorris
I Am The Man Who Was Not There.
MVM
join:2001-04-03
Reston, VA

jvmorris to R2

MVM

to R2
said by R2:
It's OK -- you don't have to go about correcting these!!
Well, I damn well better correct my replies to Randy, or I'll never hear the end of it!
LowWaterMark
Premium Member
join:2002-05-16
Wallingford, CT

LowWaterMark to jvmorris

Premium Member

to jvmorris
I wanted to outline a few of the settings possible in Zone Alarm Pro to effect how it responds...

As noted many times above, ZAP enables "stealth mode" simply by moving the Security level slide bar for the Internet Zone up to the "High" setting. If you've left all other custom settings in that Security window at default, it gives you a nice message stating "-Stealth mode: firewall hides all ports not is use by a program." See the post from R2 which shows an image of the ZA screen I'm quoting: »Re: Closed vs Stealthed Ports

Interestingly enough, if you make any custom changes within the Internet Zone, such as "Allowing outgoing DNS" or another, that message regarding stealth mode no longer shows in the summary window (at least in my ZAP v2.6.362).

Well, what if you want to stay in stealth mode for everything else, but as people have mentioned, you want to send an RST/ACK back to whatever computer keeps banging on port 1214 (kazaa), 1433 (ms-sql) or 6346 (gnutella) - which are the 3 ports I'm hit on most often even though I've never run any of these protocols. Well, ZAP does let you do this without lowering the entire zone's security down to Medium (which drops stealth entirely).

All you need to do is go into the Internet Zone Custom Settings pane in Security Settings and add the desired port(s) to the line "Allow incoming TCP ports: " (You must check this line for it to be enabled, of course.) ZAP will no longer block this port's activity and it will instead pass the request through to the OS (or app, if you have one listening on the specified port).

I ran some port scanning tests and found that the ports set in this way, under the conditions described, will now "respond to" rather than ignore these requests. If you have no program listening on the desired port, than your OS will return a closed port type response (RST/ACK).

So, if you are fully stealthed in Zone Alarm and wish to give some guy a "closed" (RST/ACK) response in hopes of stopping further automated connection retries from apps like kazaa, simply add the port (even temporarily) to the permissions list noted above. (Just make sure you aren't running the app and have it listening on that port )

Another thing I've done for insurance purposes, is used the custom settings for the Internet Zone to configure compatible settings for High and Medium Security settings, so that if I do choose to lower from High (stealthed mode) to Medium, the exact same rules are being enforced (except for the stealthing cover provided in High setting). What I mean is, if I'm NOT Allowing some function in the High setting (say incoming ICMP Echo-Ping), then in the Medium setting section, I make sure I explictly Block that function. This type of balance allows me to shift from Stealth to non-Stealth, for the entire PC, without any "configurable" rules in ZAP changing. (Obviously, if Zone Alarm Pro has some other built-in functionality hardcoded in the application, as stealthing is, I can't control that.)

This does make ZAP fairly functional to your needs at the moment without major reconfiguring required.

Also, I'm not sure it was clear from all the above, or maybe I'm missed it in all the different posts, but you can be in Stealth mode with ZAP and still choose to turn on or off your responses to ICMP Ping requests. If you check the custom setting "Allow incoming ping (ICMP Echo)" in Internet Zone, then you will remained stealthed to all TCP application port requests, but respond to Pings. (Maybe this was already clear )

This has been an amazing thread. I've only been on DSLReports for a few weeks - joining it when I got my DSL in mid/late May, but the civility and intelligence seen here is fantasic. I'm glad to be a part of it.

If anyone needs a test target who's running Zone Alarm Pro in either stealth or non-stealth mode, let me know. My machine runs few/no services to speak of, so I'm not worried about "being seen" on the Internet anyway. And I'm on a PPPoE DSL service which changes my IP at each login, so I'd be glad to participate. Thanks all

jvmorris
I Am The Man Who Was Not There.
MVM
join:2001-04-03
Reston, VA

jvmorris

MVM

Goin' WAAaaayyy down below in your posting . . . .
said by LowWaterMark:
. . . .Also, I'm not sure it was clear from all the above, or maybe I'm missed it in all the different posts, but you can be in Stealth mode with ZAP and still choose to turn on or off your responses to ICMP Ping requests. If you check the custom setting "Allow incoming ping (ICMP Echo)" in Internet Zone, then you will remained stealthed to all TCP application port requests, but respond to Pings. (Maybe this was already clear )
No, it wasn't (at least to me); so thank you for clarifying that point. (This is ZAP, not ZA (free), correct? )
quote:
This has been an amazing thread. I've only been on DSLReports for a few weeks - joining it when I got my DSL in mid/late May, but the civility and intelligence seen here is fantasic. I'm glad to be a part of it.
I agree (but I keep waiting for the other shoe to fall later this evening!
quote:
If anyone needs a test target who's running Zone Alarm Pro in either stealth or non-stealth mode, let me know. My machine runs few/no services to speak of, so I'm not worried about "being seen" on the Internet anyway. And I'm on a PPPoE DSL service which changes my IP at each login, so I'd be glad to participate. Thanks all
Ahhhh! We shall, in all probability, send you the Meister shortly (as soon as he quits screwing around doing weird things like earning a living. Look to the skies! (well, at least check your IMs regularly over the next few hours)
LowWaterMark
Premium Member
join:2002-05-16
Wallingford, CT

LowWaterMark

Premium Member

said by jvmorris:
No, it wasn't (at least to me); so thank you for clarifying that point. (This is ZAP, not ZA (free), correct? )
Correct - Zone Alarm Pro 2.6.362

Randy Bell
Premium Member
join:2002-02-24
Santa Clara, CA

Randy Bell to jvmorris

Premium Member

to jvmorris

Re: BIG Mea Culpa!!

said by jvmorris:
In short, going all the way back to the AtGuard 3.1 trial version in Dec 1999, and proceeding upwards since the release of NIS/NPF 1.0, shortly thereafter, both AtGuard and NIS/NPF have consistently operated in a stealthed manner when unsolicited external communications have been received at a port on which no server application has been listening for input. Yes, there've been some glitches (notably in the NIS 2.50 to 2.54 period) which were subsequently corrected, but that's a different subject. I'm still trying to fully understand how I got confused on the subject, but that's a different issue entirely. Right now, the important point to make is that I was wrong in my earlier statements regarding how AG and NIS/NPF handle 'stealth'. Sorry, guys, not much else I can say at this point.
The important thing is that you've now publicly corrected the former misstatement, and all is well. It never made sense to me why NIS/NPF wouldn't be stealth when the competition (such as ZA) was stealth, so I'm glad you corrected this misstatement; that makes much more sense now. Does anybody recall or know when ZA first appeared with a stealth capability? Steve Gibson's website references ZA 2.0, but I'm sure there were versions earlier than this. I'm just curious whether ZA has always been stealth too.

CrazyM
Premium Member
join:2001-05-16
BC Canada

CrazyM

Premium Member

ZA and stealth

said by Randy Bell:
I'm just curious whether ZA has always been stealth too.
Now you are making me think back to the days when BID was one the greatest things since sliced bread on a particular web site
If memory serves me right, ZA has always provided "stealth" to unsolicited inbound scans.

CrazyM

jaykaykay
4 Ever Young
MVM
join:2000-04-13
USA

jaykaykay to Randy Bell

MVM

to Randy Bell

Re: BIG Mea Culpa!!

said by Randy Bell:
I'm just curious whether ZA has always been stealth too.
It has always been that way, back as far as I can remember. Granted, I didn't have the beta version of the first one, but I've had ZA for quite some time, and that has always been a feature.

Randy Bell
Premium Member
join:2002-02-24
Santa Clara, CA

Randy Bell to jvmorris

Premium Member

to jvmorris

Re: Closed vs Stealthed Ports

Thanks, JKK and CrazyM, that makes good sense, that ZA has always been stealth -- and therefore, it makes sense Norton would too, to keep up with its competition. I suppose other firewalls like Sygate have been stealth for a long time too.

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

R2 to jvmorris

MVM

to jvmorris
OK, now I am confused -- yeah, yeah -- what's new?:) Doesn't this image:

»/r0/do ··· alth.gif

...imply that NIS has the OPTION to stealth ports?? Am I to believe that the "Stealth Block Ports" check box there is just an illusion??

What is the difference between checking that box and not checking it?? If I check it = the ports are Stealth. If I don't check it = they are still Stealth??

[text was edited by author 2002-06-11 20:29:57]

CrazyM
Premium Member
join:2001-05-16
BC Canada

CrazyM

Premium Member

said by R2:
OK, now I am confused -- yeah, yeah -- what's new?:) Doesn't this image:

...imply that NIS has the OPTION to stealth ports?? Am I to believe that the "Stealth Block Ports" check box there is just an illusion??

What is the difference between checking that box and not checking it?? If I check it = the ports are Stealth. If I don't check it = they are still Stealth??

That particular (non)option is what added to the confusion.
Selected or not appears to make no difference in how NIS responds to scans. [edit] Either way NIS is stealth.

CrazyM
[text was edited by author 2002-06-11 20:39:13]

jvmorris
I Am The Man Who Was Not There.
MVM
join:2001-04-03
Reston, VA

jvmorris to Randy Bell

MVM

to Randy Bell
said by Randy Bell:
Thanks, JKK and CrazyM, that makes good sense, that ZA has always been stealth -- and therefore, it makes sense Norton would too, to keep up with its competition. I suppose other firewalls like Sygate have been stealth for a long time too.
Ummm, Randy, you seem to be busting ass to avoid acknowledging the obvious. Norton and AtGuard were stealth long before Zone Alarm even existed. These products therefore weren't 'doing it' to keep up with ZA/ZAP.

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

R2 to CrazyM

MVM

to CrazyM
said by CrazyM:
That particular (non)option is what added to the confusion.
Selected or not appears to make no difference in how NIS responds to scans. [edit] Either way NIS is stealth.
That is ludicrous -- of course. NIS should either do away with that checkbox -- are better yet -- make it work!!:)

CrazyM
Premium Member
join:2001-05-16
BC Canada

CrazyM

Premium Member

said by R2:
That is ludicrous -- of course. NIS should either do away with that checkbox -- are better yet -- make it work!!:)
I'm with making it work

CrazyM

jvmorris
I Am The Man Who Was Not There.
MVM
join:2001-04-03
Reston, VA

jvmorris to R2

MVM

to R2
R2,

Oh, you weren't paying attention in that long-winded reply I made to you earlier! (Well, I can understand that; and, yes, it was long-winded.)
said by R2:
OK, now I am confused -- yeah, yeah -- what's new?:) Doesn't this image ....
...imply that NIS has the OPTION to stealth ports?? Am I to believe that the "Stealth Block Ports" check box there is just an illusion??
I think I can safely disagree with CrazyM's response on this one. The critical word is 'Blocked' in 'Stealth Blocked Ports'. Like you, I'm still waiting for Symantec to provide a definitive description of that single adjective. (No, I really don't know what it means specifically, at the moment.) However the default stealthing applied by the more recent versions of NIS/NPF (at least since NIS/NPF version 2.50) only seems to apply (by default) to ports on which no service is listening for unsolicited inbound comms. In one sense, that's rather obvious; and, indeed, as far as I can tell, if this box is not checked NIS/NPF will make no attempt whatsoever to stealth the port that may be used by a listening service. It seems, as I read the NIS Knowledgebase and Help File a bit more closely, that NIS/NPF, with this option checked will (at least in some instances) also stealth a port that is inadvertently listening for unsolicited inbound communications. However, there also seems to be a rather vague acknowledgement (on Symantec's part) that this may not necessarily work in all situations.

Now, why should you care? Well, if you've (unknowingly) installed a RAT, this can (could?) be real important. Need some input from some of the guys that play with RATs to establish this, however, in the absence of any inputs from Symantec.
quote:
What is the difference between checking that box and not checking it?? If I check it = the ports are Stealth. If I don't check it = they are still Stealth??
I think the distinction, as noted above, relates to whether or not there's a listening service running on a particular port. Most of us don't run them (knowingly), so we wouldn't see any difference. However, if one is unknowingly running one, this option could be quite important.

I'm just guessing here, need some input from someone with more definitive knowledge.

R2
R Not
MVM
join:2000-09-18
Long Beach, CA

R2

MVM

I was paying attention, but it does not fully make sense (of no fault of yours -- instead the blame lays at Symantec's feet). "Stealth Blocked Ports" is quite the wording, isn't it? How do we interpret that?

CHECKED means:

1) Don't Stealth 'NON-Blocked' Ports (define 'blocked')?
2) Stealth Ports only ports where there is no service listening?
3) Stealth ALL Ports?

UN-Checked means:

1) Don't Stealth Anything?
2) Only Stealth 'NON-Blocked' Ports?

I must admit it is too confusing for my simple brain to figure out...
[text was edited by author 2002-06-11 22:13:55]

Wildcatboy
Invisible
Mod
join:2000-10-30
Toronto, ON

Wildcatboy to jvmorris

Mod

to jvmorris

I'm here JV, I'm here lol. Although we are not discussing a single topic here, this is a good thread indeed. As for your suggestion that I should edit or remove some of those comments, I'm not sure where I can start in this thread lol.

I certainly don't think it's necessary though. This is not a lecture and we don't really have to get everything right. This is a discussion and in all discussions you can find correct opinions and wrong suggestions and that's how the discussion grows and reaches a conclusion. Sometimes people are civilized and intelligent to accept their mistakes and keep the discussion going on the right track and sometimes they just stick to what they said, wrong or right.

This is a good discussion and I think I'll just let it go on the way it has been.

CrazyM
Premium Member
join:2001-05-16
BC Canada

CrazyM to jvmorris

Premium Member

to jvmorris

Still confused

said by jvmorris:
I think I can safely disagree with CrazyM's response on this one.
Rightfully so it would appear after I did some more testing...
said by jvmorris:
The critical word is 'Blocked' in 'Stealth Blocked Ports'. Like you, I'm still waiting for Symantec to provide a definitive description of that single adjective. (No, I really don't know what it means specifically, at the moment.) However the default stealthing applied by the more recent versions of NIS/NPF (at least since NIS/NPF version 2.50) only seems to apply (by default) to ports on which no service is listening for unsolicited inbound comms.
Agreed, ports with no listening service appear to be stealthed regardless of this setting, contrary to what the setting would imply.
said by jvmorris:
In one sense, that's rather obvious; and, indeed, as far as I can tell, if this box is not checked NIS/NPF will make no attempt whatsoever to stealth the port that may be used by a listening service.
Unchecked, port 135 which is listening on my W2K system, will now show as closed as it is blocked by my rules.
said by jvmorris:
It seems, as I read the NIS Knowledgebase and Help File a bit more closely, that NIS/NPF, with this option checked will (at least in some instances) also stealth a port that is inadvertently listening for unsolicited inbound communications.
As in the case of default W2K services.

jv...looks like the confusion and apologies are running rampant
said by R2:
CHECKED means:

1) Don't Stealth 'NON-Blocked' Ports (define 'blocked')?
2) Stealth Ports only ports where there is no service listening?
3) Stealth ALL Ports?

UN-Checked means:

1) Don't Stealth Anything?
2) Only Stealth 'NON-Blocked' Ports?
From my quick testing again...

Checked - will stealth listening blocked ports.
Unchecked - blocked listening ports will respond as closed.

Everything else would appear to be stealthed regardless of this setting (famous last words )
said by R2:
I must admit it is too confusing for my simple brain to figure out...
Well you are not the only one confused

CrazyM

dja
Happy to Help
Premium Member
join:2002-03-25
Niagara

dja to jvmorris

Premium Member

to jvmorris

Re: Closed vs Stealthed Ports

Click for full size
Ok. Because of a 'cr@pware I installed yesterday I didn't post a second shot an hour later, but an hour is not sufficient anyway so, Yesterday over a 24 hour period at 'medium' I posted 12 alerts. Today, over the last 24 hours 'stealthed', there were 90 alerts (750% of medium).