dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
57669

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

jvmorris to R2

MVM

to R2

Re: Closed vs Stealthed Ports

said by R2:
said by jvmorris:
Darn! We both agree with R2!
This is a clear sign that I am slacking off and not making my posts controversial enough...:(
Well, it takes practice. I'm sure you'll get the hang of it -- eventually.

MeeToo7
You Too?
Premium Member
join:2000-10-18
Ardmore, PA

MeeToo7 to jvmorris

Premium Member

to jvmorris
said by jvmorris:
They seem to have felt somewhat compelled to provide 'stealth' capability in response to Steve Gibson's hoopla on the subject and were consequently forced to defer other enhancements that had already been scheduled for NIS/NPF. No one at Symantec is now going to publicly confirm what I've said above; so don't even bother asking.

That certainly makes sense to me and I don't need any concrete proof to believe what you're saying. When you're selling a product and run into competition, the natural laws of business and capitalism demand that you respond that way. It's not unethical or immoral, it's just business

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

jvmorris to nevertheless

MVM

to nevertheless

Stealth, Traffic Clutter, and delayed response

said by nevertheless:
One of my issues with 'stealth' is that it's damaging to proper network functionality.
Yes, it is (and that's one of the complaints I heard unofficially from members of the Symantec NIS/NPF development team, which they will never, ever confirm or deny). It's basically an approach to enhance (in some unspecified manner) Internet security by not observing Internet standards for TCP/IP.

Can it have unanticipated (and unwanted) consequences? You bet! Somewhere around this forum (I believe it was Brendon Woirhaye's response to GT7697 regarding the print server foul-up from the late April update to NIS/NPF 4.0x), you'll find a tacit admission that Symantec modified its proxy servers in order to pass the PC Flank Stealth Test, which relies on non-standard combinations of TCP flags. That 'enhancement' is what screwed up print server functionality for those NIS/NPF users having a small LAN and running print servers. I'm still waiting to find out if some ZA/ZAP user (whose software will apparently 'pass' the PC Flank Stealth Test) can still use print servers. So far, it looks like there aren't any ZA/ZAP users running print servers, as there's been no response to this query.

From your basic response, I assume you are quite aware that the people who developed the IPv4 implementation of the Internet (which is what most of us continue to rely upon) did not design the protocols to be resistant to malicious intrusion attempts. (Indeed, I suspect that they were incapable of considering this possibility at the time the original work was being done.) I suspect that we will see some rudimentary efforts in this regard in IPv6 when it goes final.
quote:
Stealthing your ports or your machine causes unnecessary delays on remote machines as they wait for their connection to you to time out. This is supposedly a benefit of the stealth stuff, but in practice for those actually using the network, it's a downright nuisance. A simple mistyped IP will cause me up to 30 seconds of waiting, where it normally would cause me a few milliseconds.
Well, this goes back to the query in my original posting to start this thread which remains unanswered (to date). Do Stealthed systems contribute to Internet traffic clutter and delayed responsiveness? I don't think anyone's addressed this issue yet, so I'm glad you brought it up here. Maybe we'll now be able to get some answers on that query.
quote:
Apart from annoying user timeouts, ... they're making reliable testing of the network impossible.
Well, I know what you're talking about here, but could you elaborate a bit further for others?
quote:
In my daily work at a Cable ISP, I often come up with the problem of determining where the issue lies--our service, or the customer's machine. Most of the time it's a customer-side problem, yet I have no way of testing to see if the user is actually up--short of clearing the arp cache and seeing if his arp entry renews (9 times out of 10 it's a misconfigured firewall, or, worse, 2 firewalls at once). All of these at the client side are PEBKAC issues, of course, but they wouldn't be my problem if this useless concept wasn't so prevalent--it literally breaks The Internet.
Specifically, spell out PEBKAC, most of the people reading this thread don't know that acronym.
quote:
Closed port responses, ICMP echos etc. etc. are all part of the TCP/IP protocol for a reason, I am now unable to rely on these tools, because of this stealth phenomenon and it that's what really bothers me.
Not a bad two cents worth, at all. Thank you.
jvmorris

jvmorris to MeeToo7

MVM

to MeeToo7

Re: Closed vs Stealthed Ports

said by MeeToo:
. . . . That certainly makes sense to me and I don't need any concrete proof to believe what you're saying. When you're selling a product and run into competition, the natural laws of business and capitalism demand that you respond that way. It's not unethical or immoral, it's just business
MeeToo,
This is one of those "Yes, well, but ... " responses. Far too much of the publicly accessible information from Symantec is market-driven, so people tend to assume their developers have the same attitude.

I don't believe this is true, based on my correspondence with them over the past two years. As far as I can tell, most members of the Symantec development team for NIS/NPF saw the Atguard firewall technology as an ideal launching pad for a second-generation software-based personal firewall. And they don't like having their development agenda usurped by individuals outside the operation with a tremendous popular following who advocate 'solutions' to largely non-existent problems. (What, precisely, is the 'exploit' that exploits non-stealthed firewall-protected machines or the masquerade capability demonstrated by Steve Gibson's Leaktest? I don't know. I've never seen one documented -- and certainly not before Steve made such a big deal over these issues.)

I think they have (or at least had) very clear goals in mind (and in all honesty it's not as large a development team as some readers seem to assume). Even without the external 'nudges', there are a lot of things that these guys see as needing to be done. What are these other issues? I can only speculate and that wouldn't be fair to these guys, because I'm not a privileged correspondent with the team (and if I were, I certainly couldn't tell you anyway).

So, what's a guy to do if not rely on Steve Gibson or someone similar to identify 'deficiencies'? Well, one could always do what I do: Bitch; privately, via e-mail with the vendor of your choice. (This makes one incredibly popular with the vendor, at least in my experience. ) Some you win (eventually); some you lose, and some get deferred 'til the next release (or so). I liked R2's initial posting; I hope some of the vendors that frequent here read this thread and respond constructively to it.

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

nevertheless to jvmorris

Premium Member

to jvmorris

Re: Stealth, Traffic Clutter, and delayed response

said by jvmorris:
From your basic response, I assume you are quite aware that the people who developed the IPv4 implementation of the Internet (which is what most of us continue to rely upon) did not design the protocols to be resistant to malicious intrusion attempts. (Indeed, I suspect that they were incapable of considering this possibility at the time the original work was being done.) I suspect that we will see some rudimentary efforts in this regard in IPv6 when it goes final.
Back in the day the implementors had no reason to design the protocol with security in mind, but I've yet to see a real argument to support the idea that not responding to proper queries provides any benefit to security. I can't honestly say that I've gone looking for them, so if there is one, please someone present it!

There are changes to TCP/IP behavior that are necessary and are acceptable compromises--I can understand tarpitting DoSes (deliberately slowing down responses to certain kinds of suspect traffic) and such, but stealth just doesn't add any functionality other than Beavis & Butthead going "heheheheh...Cool!". (Again, my opinion)
quote:
Well, this goes back to the query in my original posting to start this thread which remains unanswered (to date). Do Stealthed systems contribute to Internet traffic clutter and delayed responsiveness? I don't think anyone's addressed this issue yet, so I'm glad you brought it up here. Maybe we'll now be able to get some answers on that query.
It certainly does. Stealth port 113 on your own box, then connect to an FTP server that tries to do an auth lookup on your IP. You're going to wait 30 seconds. It's perfectly OK for a machine to attempt an auth lookup, and if you don't want someone doing it, just close the port and the remote side will report failure, and continue on it's day. SMTP is similar.

See a discussion here:

»lists.insecure.org/incid ··· 071.html

Again, this is just the easiest example I can think of at the moment...
quote:
Well, I know what you're talking about here, but could you elaborate a bit further for others?
I thought I did!

Parts of the protocol were designed for testing and troubleshooting. Most users are aware of ICMP's ping functionality, which will echo back a response to determine if a host is alive, and how long it took to get the response. A host that does not participate in this type of request (stealthed) is not only lying, but will falsely show a negative result to a troubleshooter (or a network audit system).

On several networks this particular behaviour has been seen to wreak havok with DHCP implementations, causing DHCP servers to hand out IPs that are currently in use. (The DHCP server, if a lease is expired will attempt to ping an IP to determine if it's truely not in use, and if it recieves no response takes the IP out of the reserved pool, and thus can assign it to a new requestor. a bad implementation, but yet another point where something relies on the protocol and stealth has broken that. Of course, the client isn't renewing it's lease because it's firweall is incorrectly configured, another PEBKAC)
quote:
Specifically, spell out PEBKAC, most of the people reading this thread don't know that acronym.
Problem Encountered Between Keyboard And Chair = User Error

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

jvmorris

MVM

said by nevertheless:
. . . . Back in the day the implementors had no reason to design the protocol with security in mind, ...
Yes, we were all geeks then and we had no reason to assume that anyone other than geeks would ever use the technology. Geeks are 'white hats' (hackers, if you will, in certain circumstances), not 'black hats' or 'gray hats' (crackers, skiddies, and the clueless, if you will).
quote:
but I've yet to see a real argument to support the idea that not responding to proper queries provides any benefit to security. I can't honestly say that I've gone looking for them, so if there is one, please someone present it!
Yes! That's exactly what I'm trolling for here.
quote:
There are changes to TCP/IP behavior that are necessary and are acceptable compromises--I can understand tarpitting DoSes (deliberately slowing down responses to certain kinds of suspect traffic) and such, but stealth just doesn't add any functionality other than Beavis & Butthead going "heheheheh...Cool!". (Again, my opinion)
Oops, bit my tongue! No (seriously), that's sort of my question in this thread. Does it really do anything worthwhile to break the TCP/IP protocol by stealthing one's system?
quote:
.... It certainly does. Stealth port 113 on your own box, then connect to an FTP server that tries to do an auth lookup on your IP. You're going to wait 30 seconds. It's perfectly OK for a machine to attempt an auth lookup, and if you don't want someone doing it, just close the port and the remote side will report failure, and continue on it's day. SMTP is similar.
Well, that's a well-stated issue. However, I've long since removed the global Port 113 authorization for "Any Application" on my box. All of the Port 113 PERMITs that I retain are application-specific. Unfortunately, I'm not logging them (for FTP apps or anything else, for that matter), so I really have no idea as to which applications may (occasionally) make use of this functionality. Specifically, I have no idea as to what remote IP addresses may rely upon this functionality in my situation. I'd probably have to invoke logging on at least half a dozen rules in order to just find out and, even then, the results would probably be dependent on which remote IP addresses I happened to query.
quote:
I thought I did!
Well, yes and no. I think you probably did in terms that an ISP provider would understand, but not necessarily in terms that the average end-user frequenting the DSLR Security Forum would understand.
quote:
Parts of the protocol were designed for testing and troubleshooting. Most users are aware of ICMP's ping functionality, which will echo back a response to determine if a host is alive, and how long it took to get the response. A host that does not participate in this type of request (stealthed) is not only lying, but will falsely show a negative result to a troubleshooter (or a network audit system).
I understand your response above, but 'stealthing' TCP/UDP ports (as opposed to blocking ICMP responses) are two entirely different issues. What I'm saying is that some of the problems you are encountering are not necessarily related to 'stealthing' as used by the typical ISP subscriber.
quote:
On several networks this particular behaviour has been seen to wreak havok with DHCP implementations, causing DHCP servers to hand out IPs that are currently in use.
Acknowledged.
quote:
(The DHCP server, if a lease is expired will attempt to ping an IP to determine if it's truely not in use, and if it recieves no response takes the IP out of the reserved pool, and thus can assign it to a new requestor. a bad implementation, but yet another point where something relies on the protocol and stealth has broken that.
Interesting. I had never considered that consequence.
quote:
Of course, the client isn't renewing it's lease because its firewall is incorrectly configured, another PEBKAC)
Yes, I've encountered this behavior. I use a dial-up connection and frequently stay online for extended periods, but I've seen more than a few instances in which I've eventually surpassed the 'lease expiration' date/time.
quote:
quote:
Specifically, spell out PEBKAC, most of the people reading this thread don't know that acronym.
Problem Encountered Between Keyboard And Chair = User Error

Okay, now the other guys know what the acronym means!
Sentinel
Premium Member
join:2001-02-07
Florida

Sentinel to nevertheless

Premium Member

to nevertheless
said by nevertheless:
quote:
Specifically, spell out PEBKAC, most of the people reading this thread don't know that acronym.
Problem Encountered Between Keyboard And Chair = User Error

I usually call that an IO error IO = Idiot Operator.

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

R2 to jvmorris

MVM

to jvmorris
said by jvmorris:
I understand your response above, but 'stealthing' TCP/UDP ports (as opposed to blocking ICMP responses)...
Can you define "Stealthing" for a UDP port?

[text was edited by author 2002-06-06 18:43:18]

SYNACK
Just Firewall It
Mod
join:2001-03-05
Venice, CA

SYNACK

Mod

This is usually the suppression of a ICMP(3,3) response. However, UDP is not connection based, so even an open port might not respond. Example: you are running a syslog server on UDP/514. This is a potential DoS vulnerability, because somebody could just flood you with GBytes of irrelevant entries. For the attacker, an ICMP(3,3) means closed. No response can mean open or stealth, you pick!

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

R2

MVM

said by SYNACK:
However, UDP is not connection based, so even an open port might not respond.
Well, even an open port might not know it is not responding!:)
quote:

No response can mean open or stealth, you pick!
Exactly my point...:)

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:
Can you define "Stealthing" for a UDP port? . . . .
Hell, R2, I can't really define stealthing for anything! (You've given the best definition I've seen to date.) I used to pester Steve Gibson for a definition of stealthing; I never got a response. Indeed, as far as I can tell, it may well mean dramatically different things to different proponents!
dave
Premium Member
join:2000-05-04
not in ohio

dave

Premium Member

said by jvmorris:
I used to pester Steve Gibson for a definition of stealthing; I never got a response.
That's because he's stealthed, silly.

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

dja to jvmorris

Premium Member

to jvmorris

Re: Closed vs Stealthed Ports

With 'stealthed' ports (ZAF) I get anywhere between 500 and 3000 alerts per day. With 'closed', I get less than 50.

OzarkMan$
join:2000-12-22
Ozark Mtns.

OzarkMan$ to nevertheless

Member

to nevertheless
said by nevertheless:
A simple mistyped IP will cause me up to 30 seconds of waiting, where it normally would cause me a few milliseconds.
Oh well....perhaps one should be more attentive to the addy they type

I reckon this is similar to caller ID for me. If you call my home mistakenly, your wait time is likely to be as long as you care for it to be. Similar to Stealth....if I do not want to answer I do not pick up the connection.

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

jvmorris to dave

MVM

to dave

Re: Stealth, Traffic Clutter, and delayed response

said by dave:
said by jvmorris:
I used to pester Steve Gibson for a definition of stealthing; I never got a response.
That's because he's stealthed, silly.
Oh, man, that's too heavy for me!
jvmorris

jvmorris to dja

MVM

to dja

Re: Closed vs Stealthed Ports

said by dja:
With 'stealthed' ports (ZAF) I get anywhere between 500 and 3000 alerts per day. With 'closed', I get less than 50.
Now that's what I was interested in hearing. I had a subjective impression that the number of logged (and unsolicited) inbound probes I was seeing was higher when I was running stealthed than when I subsequently started running unstealthed. However, to run a true 'controlled experiment' to ascertain this would be a bit prohibitive in terms of time and effort and would necessitate the use of resources that I don't have readily available.

Thank you. (And would ya please quit changing your sig? It must have taken me 30 seconds to figure out who you were! )

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

R2

MVM

Is this because the lack of an answer causes the scanner to keep trying to probe the port?

I am not sure that causing more probes is any less secure, but it certainly adds to the Internet garbage...

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

jvmorris to OzarkMan$

MVM

to OzarkMan$
said by OzarkMan:
. . . . Oh well....perhaps one should be more attentive to the addy they type

I reckon this is similar to caller ID for me. If you call my home mistakenly, your wait time is likely to be as long as you care for it to be. Similar to Stealth....if I do not want to answer I do not pick up the connection.
This prompts another "Yes, well, but ..." response from me. You see, we tend (and I know I tend to do this myself) to treat the Internet as point-to-point communications and often neglect the infrastructure in between which is also being saddled with this unnecessary traffic. True (at least for normal situations), this is hardly likely to 'overwhelm' the Internet or even selected subnets, but there have been situations (Code Red II comes to mind, in particular) in which specific subnets have essentially been rendered non-functional. Consequently, we may well not be doing ourselves (or other users of our subnets) any favors when we choose to run 'stealthed'. (And, again, this is a query on my part, not an assertion of established fact.)

SYNACK
Just Firewall It
Mod
join:2001-03-05
Venice, CA

SYNACK to dja

Mod

to dja
The concept of stealth had to be invented to allow remote detection/verification of the presence of a firewall by online self-scanning tools. It is a self-serving stance by firewall promoters and is NOT the best stance in day-to-day operations because it breaks certain useful mechanisms of the protocol (many examples have been mentioned by others).

In the long run, these shortcoming need to be addressed to design a better, low-impact firewall. I intentionally have my ZyWALL 10 set to closed instead of stealth. (As mentioned before, this is my definition of a stealth firewall, the RST response hides the actual presence of the firewall. ).

The 1214 problem has been mentioned, where stealth causes never-ending probing. Maybe a stealth firewall should once-in-a-while send a RST if a certain number of probes have occurred to the same port. Firewalls need more intelligence to deal with nuisance traffic they cause.

Another serious issue is with NAT routers. Some people like to define a default server, then run a stealth firewall on that LAN target. Each little probe creates a lingering entry in the NAT table that stays until the NAT timeout for half-open connections expires, plugging up the NAT table. If the firewall would respond with closed, the outgoing RST reply would clear the NAT entry immediately, freeing valuable resources.

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

dja to jvmorris

Premium Member

to jvmorris
said by jvmorris:
(And would ya please quit changing your sig? It must have taken me 30 seconds to figure out who you were! )

Sorry! I took off the 'shley' part and just left the 'dja' (Damien James Ashley), because everyone thought I was a 'female disc-jockey. (I even got an 'IM' from some guy hitting on me)

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:
Is this because the lack of an answer causes the scanner to keep trying to probe the port?

I am not sure that causing more probes is any less secure, but it certainly adds to the Internet garbage...
R2,

Again, I suspect that Steve Friedl or SYNACK could provide a more definitive answer than I can. But, it seems to me that the situation is implementation-specific (for both malicious apps like worms and semi-authentic apps like file sharing programs such as KaZaA). I can envision at least three scenarios (and I think we've seen all three in the past twelve months). • There is no explicit coding in the calling app. If you run 'stealthed', it will probe three times; if you run 'closed', it's more likely to call only once (assuming TCP/IP defaults are used) and then give up if your port is 'closed', but not 'stealthed'.• If the app (malicious or benign) is explicitly coded to continually call against non-responding IP addresses (presumably in the hope that something will eventually turn up on what is likely to be a dynamically assigned IP address available from a dialup ISP), then the process can run ad infinitum or until such time as some prescribed 'check count' is exceeded. KaZaA seems to do this, as did the early versions of Code Red (which apparently had a cut-off count for specific IP addresses). • If the app (malicious or benign) is explicitly coded to continually call against IP addresses responding as closed, then the process can run ad infinitum or until such time as some prescribed 'check count' is exceeded. It looks like SQLSnake worked this way, but I'm not an authoritative source on this exploit. And, no, it's not inherently any more insecure than anything else; it just clogs the arteries, so to speak.

garp123
Premium Member
join:2001-12-06
Duncan, OK

garp123 to jvmorris

Premium Member

to jvmorris
I personally think this whole "stealth" thing is taken wayyy too seriously.
After all, I leave my IP at every website I visit.
It's not too difficult to determine that my computer exists.
If my firewall blocks any unauthorized access, in or out, then it's doing exactly what I want it to do, no matter how many "stealth" tests I flunk.

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

jvmorris to SYNACK

MVM

to SYNACK
SYNACK,
First, I want to say thank you for showing up before I started banging on your door with IMs. I suspect you probably know far more (and far more authoritatively) about this subject than I do.
said by SYNACK:
The concept of stealth had to be invented to allow remote detection/verification of the presence of a firewall by online self-scanning tools. It is a self-serving stance by firewall promoters and is NOT the best stance in day-to-day operations because it breaks certain useful mechanisms of the protocol (many examples have been mentioned by others).

In the long run, these shortcoming need to be addressed to design a better, low-impact firewall. I intentionally have my ZyWALL 10 set to closed instead of stealth. (As mentioned before, this is my definition of a stealth firewall, the RST response hides the actual presence of the firewall. ).
I really need to take some time and figure all this out, but this sounds very much like one of the options that
R2 originally proposed. The "neat" part of R2's 'solution' (at least to me) was that the bad guys would be in instant hell in terms of being able to further diagnose just what they had encountered. Right now, it's a no-brainer as far as 'stealth' is concerned.
quote:
. . . . Another serious issue is with NAT routers. Some people like to define a default server, then run a stealth firewall on that LAN target. Each little probe creates a lingering entry in the NAT table that stays until the NAT timeout for half-open connections expires, plugging up the NAT table. If the firewall would respond with closed, the outgoing RST reply would clear the NAT entry immediately, freeing valuable resources.
Another good point. Thank you.
jvmorris

jvmorris to dja

MVM

to dja
said by dja:
. . . . Sorry! I took off the 'shley' part and just left the 'dja' (Damien James Ashley), because everyone thought I was a 'female disc-jockey. (I even got an 'IM' from some guy hitting on me)
Ya know, you really know how to make us old geezers feel totally out of it, dontcha? (Who the f*** is this female DJ named DJAshley? And what's she doing this weekend? )
jvmorris

jvmorris to garp123

MVM

to garp123
said by garp123:
I personally think this whole "stealth" thing is taken wayyy too seriously.
After all, I leave my IP at every website I visit.
GASP!! Oh, GARP, tell me it ain't so, buddy! You actually surf without using an anonymizer!!??
quote:
It's not too difficult to determine that my computer exists. . . .
True, indeed, what's amazing is how many people obsessed with 'stealthing' don't realize that they're giving out their (current) IP address every time they access a website, simply in order to obtain a response.

thegrinch8
join:2001-08-27
Westminster, CA

thegrinch8 to jvmorris

Member

to jvmorris
You all make great points, so I'm going to add another idea.
Odds?

Yes I believe that closed is actually better due to odds!
You ask why? Well I believe the average port prober that gets a confirmed closed port rather then anything else will move on to an easier target. Odds are they will!

just my 2 cents...

garp123
Premium Member
join:2001-12-06
Duncan, OK

garp123 to jvmorris

Premium Member

to jvmorris
said by jvmorris:
.... what's amazing is how many people obsessed with 'stealthing' don't realize that they're giving out their (current) IP address every time they access a website, simply in order to obtain a response.

My point exactly.
A firewall should block any unauthorized traffic, inbound or outbound.
I don't give a poop whether or not my computer is "stealthed", since I'm not invisible as I actually use the thing.
Sentinel
Premium Member
join:2001-02-07
Florida

Sentinel to thegrinch8

Premium Member

to thegrinch8
But if a port is stealth it is still closed. And not only that, it most likely closed due to a firewall, is it not? A closed port is the same but just could be closed due to not being open.

I guess what I am trying to say is, if I were a hacker and I saw a stealth port it would not tempt me any more than if I saw a closed port. As a matter of fact if I saw a stealth port it would likely deter me more since it is probably stealth due to a firewall. Whereas a user who has no firewall is likely to have closed ports.

I would probably pass on both the stealth and closed ports and try to find something open, but if I were to choose between trying to hack a closed port or a stealth port I would try the closed one thinking that the stealth one was probably stealth due to a firewall which I would not want to come up against. Does any of this make any sense?
dave
Premium Member
join:2000-05-04
not in ohio

dave to jvmorris

Premium Member

to jvmorris
quote:
I would probably pass on both the stealth and closed ports and try to find something open, but if I were to choose between trying to hack a closed port or a stealth port I would try the closed one thinking that the stealth one was probably stealth due to a firewall which I would not want to come up against.
A 'closed port' is closed for one of two reasons:

1) The firewall is refusing to forward messages for that port.

2) There is nothing with the port open.

OK, so you could hack the firewall in case 1 (it's the same as the stealth-by-firewall case).

In case 2, there's literally nothing to hack. There's no program there to be the target of your hacking.

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

jvmorris to thegrinch8

MVM

to thegrinch8
said by thegrinch:
. . . . Yes I believe that closed is actually better due to odds!
You ask why? Well I believe the average port prober that gets a confirmed closed port rather then anything else will move on to an easier target. Odds are they will!
Ya know, I'm starting to get jealous here! I take an entire screen to express an idea and one of you comes along and wraps the whole concept up in two lines!

Yep, agreed. If I were scanning (maliciously) and hit a definitely closed port, I'd pack it in and forget about that IP address myself because there's apparently some sort of protection there. And, to me, protection implies logging. True, I couldn't tell if it's a NAT, or a firewall, or an IDS but I would not further probe that IP address. Conversely, if I got a 'stealthed' (i.e., no response) result from a particular IP address, I might well continue to scan it on future Internet scans with the expectation that something would eventually turn up.

As you say, it's all really a question of odds -- for me (as a scanner) and for them (as a potential protected site).