how-to block ads
|
|
Uniqs:
44833 |
Share Topic
 |
 |
|
|
|
| reply to jvmorris
Re: Closed vs Stealthed Ports said by jvmorris:
Didn't want you to take my comments above the wrong way.
No problem. I wonder why all the testing sites make such a big deal about stealth, then? Is that just marketing and hype, or do the testing sites really think that stealth is better? I include, of course, Symantec's Security Check, from the makers of your beloved NIS -- they seem to value stealth, because you cannot get a good score from their security check unless you're stealthed.  | | |
|
 jvmorrisI Am The Man Who Was Not There.Premium,MVM
join:2001-04-03
Reston, VA | reply to OzarkMan$
Hey, any chance we can have the old avatar back? I really liked it!  said by OzarkMan:
. . . .Sure it's true Joseph since I base my thinking on the same facts R2 shared in his initial post. I also agree with the premise that Stealth is over-rated. In fact with my surfing habits, download management, I'm quite content for now . . .
Darn! We both agree with R2!  But you make an additional point above that may also be coloring my own perception, now that you bring it up. I suspect that your and my surfing habits and management procedures are not too dissimilar and that would influence my own personal experience.
quote:
. . . . BUT am always concerned about the traffic that I don't know about.
But this brings us to Steve Friedl's comment in Randy's thread about the Port 1214 probes (and MeeToo brings up essentially the same issue directly after you posted). Let me pick up on MeeToo's comments in a direct response to his posting.
--
Regards, Joseph V. Morris | |
 R2R NotPremium,MVM
join:2000-09-18
Long Beach, CA
kudos:1 | 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...:( | |
 MeeToo7You Too?Premium
join:2000-10-18
Ardmore, PA | reply to Randy Bell
said by Randy Bell:
I wonder why all the testing sites make such a big deal about stealth, then? Is that just marketing and hype, or do the testing sites really think that stealth is better?
My rule of thumb is to assume first a business into making money will use hype and catchy words. Then I look into their claims on unbiased sites, such as university research sites, professional discussion sites etc. DSLR is an unbiased site, and although not everyone is professional, enough are that we can get good answers and links to further our research.
I think most for-profit sites don't really think "stealth" (a catchy word for non-responding ports) is better, but will lead you to think it is IF their products has stealthing options. I would imagine the developers themselves know better, but marketting department have to put in their selling hype to sell their products.
Just like the "New and improved!" catch phrase used on every supermarket products these days. When you find out what's improved, many times it's just the box that poors better, or the product that smells better or has a nicer color. Is it really improved? No, but it sells better.
--
Help find a cure, join Team Helix | |
jvmorrisI Am The Man Who Was Not There.Premium,MVM
join:2001-04-03
Reston, VA | reply to MeeToo7
Now, we're beginning to peel the lemon (or is it an artichoke?)! said by MeeToo:
As the hackers in the link TimeOut posted demonstrate, they are not as interested in getting past through a firewall as they are going around it, by means of other executable programs.
I'd modify your statement above a bit, however: Hackers primarily rely on getting through a firewall using a PERMITTED communication (to either a client or server application) or by going around it (by using a parallel stack or WinSock, for example).
There are times when we (by which I mean us) don't do a really good job of explaining to novices exactly what a particular firewall does and what it doesn't do -- at least as the term 'firewall' is traditionally used. By failing to make these points clear, there's a false sense of security that a firewall (and especially a personal software firewall) can potentially evoke in the uninitiated.
A lot of novices, for example, don't understand that when you run a web browser (a client application), you have to allow responses to your requests for information. And a lot of browsers will accept inputs that could be malicious in their intent. The 'traditional' firewall doesn't inspect the response before accepting it -- you asked for it; you're going to get it, is the way the firewall looks at it. You'd need a full-capability IDS or stateful packet inspection firewall to do this and I have yet to see a single personal software firewall that really does this. (In the first place, it would raise havoc with throughput, and we've already got people complaining about the throughput constraints of even the most rudimentary packet inspection techniques that are typically provided by such firewalls using HTTP proxy servers.) The situation gets even worse for those end-users who insist on running a web server (a server application)--especially if it violates their ISP's ToS/AUP. (Which, of course, is why some ISPs scan their subscribers for such proscribed servers.) Hell, most novices don't yet understand the difference between a client app and a server app; they think you're asking them whether they're running an NT/2K/XP server box on the Internet! (And I could run a web server on this poor, pitiful Win 98 SE box that I'm using at the moment.)
In these instances, one is forced to rely on one of several options other than a 'traditional' firewall. • One relies on inbuilt security features of the internet-enabled application • One relies on 'sandboxing' memory-resident applications like Tiny Trojan Trap (as gwion emphasizes repeatedly), or • One relies on other security-related utilities, as you note below.
But let's get back to the subject at hand. It seems to me that many of the 'arguments' for stealthing are fallacious in the sense that they are comparing the benefits of stealthing (which really doesn't require a firewall at all, but the proponents don't typically tell you that) with the alternative of running with no Internet Security at all! They're (often) not really comparing running a secured firewall (all ports under firewall control and closed unless expressly permitted) with running a secured firewall that also allows stealthing. (Which, of course, is what I'm asking about.) Instead, these arguments tend to compare running a stealth-capable firewall against running no Internet Security utilities whatsoever.
quote:
. . . . So IMO, showing ports closed through firewall instead of stealthing them is less trouble in the long run, and just as secure (or more to the point, insecure, as there's no such thing as completely secure).
Agreed again. Indeed, your comment is inherently true on Windows 9x/ME boxes. And tweaking a Win NT/2K/XP system to even approach C2 security specs is likely to make the box unusable for the average end-user.
quote:
But with either case of stealth or closed ports, one needs to apply other security measures and habits, such as using AV and updating them regularly, applying patches regularly, and securing browsers and other internet access apps out of their defaults. One should not get the false sense of security with being stealth and thinking one is invisible, which might lead to lax security habits and implementations. . . .
Also agreed. We need to constantly remind people that even the most secure firewall available on the market is only one component of the arsenal upon which they should rely in order to secure their systems against subversion and damage.
Good points, thank you.
--
Regards, Joseph V. Morris | |
jvmorrisI Am The Man Who Was Not There.Premium,MVM
join:2001-04-03
Reston, VA | reply to R2
said by R2:
I think that despite our disagreements, we essentially agree.:)
R2,
Oh, I don't think we're having disagreements or arguments as I read the thread so far. I think we're simply discussing differing experiences and perspectives. Perhaps I'm wrong, but I believe Steve Friedl (who posted subsequent to your post to which I'm responding here) is the first individual to post in this thread who's likely to be familiar with explicitly (and knowingly) running server apps on the Internet at large. The rest of us are more likely end-users running client apps like web browsers, e-mail readers and news readers.
quote:
. . . .If a hacker is using some automated scanner to pick up addresses and the scanner is designed to ignore 'stealthed' responses, then perhaps it is a good thing. Otherwise I am not sure it buys you much 'protection'.
Well, I would prefer to characterize the people to whom you are referring above as 'crackers' rather than 'hackers', but that's mostly due to my own personal experiences with people that view the term 'hacker' as a mark of distinction.
. . . .
--
Regards, Joseph V. Morris | |
| reply to jvmorris
One of my issues with 'stealth' is that it's damaging to proper network functionality.
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.
Apart from annoying user timeouts, by blocking out the pieces of the protocol that were specifically designed to facilitate proper network functionality and testing, they're making reliable testing of the network impossible.
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. (IMO)
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.
Anyway, thst's my 2 cents.
--
Some people think I'm an idiot. I disagree, but idiocy is subjective--so they may well be right. With this in mind, take everything I post with a grain of salt, eh? | |
jvmorrisI Am The Man Who Was Not There.Premium,MVM
join:2001-04-03
Reston, VA | reply to Steve
said by Steve:
.... Steve Gibson?
Arrrggghhh! Steve, do you have any conception as to how difficult I found it to compose my original posting without mentioning Steve Gibson?
As far as I know, you are correct: Steve Gibson was the first individual to use the term 'stealth'.
--
Regards, Joseph V. Morris | |
 Time Out$Premium
join:2002-04-28
North Myrtle Beach, SC | reply to nevertheless
nevertheless..so glad someone brought that into this discussion...instead of you always on the "other side" getting beat up. You have my vote today. | |
jvmorrisI Am The Man Who Was Not There.Premium,MVM
join:2001-04-03
Reston, VA | reply to Randy Bell
said by Randy Bell:
. . . .Is that just marketing and hype, or do the testing sites really think that stealth is better? I include, of course, Symantec's Security Check, from the makers of your beloved NIS -- they seem to value stealth, because you cannot get a good score from their security check unless you're stealthed.
A question I can answer (but I'm not going to get specific, so there's no point in pressing me on the subject)! Every member of Symantec's NIS/NPF development team with whom I've ever corresponded considered 'stealth' as nothing more than marketing hype. Indeed, I detected a certain bitterness in some of the responses that I've had via e-mail. 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.
--
Regards, Joseph V. Morris | |
jvmorrisI Am The Man Who Was Not There.Premium,MVM
join:2001-04-03
Reston, VA | reply to R2
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.
--
Regards, Joseph V. Morris | |
MeeToo7You Too?Premium
join:2000-10-18
Ardmore, PA | reply 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
--
Help find a cure, join Team Helix | |
jvmorrisI Am The Man Who Was Not There.Premium,MVM
join:2001-04-03
Reston, VA | reply 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.
--
Regards, Joseph V. Morris | |
jvmorrisI Am The Man Who Was Not There.Premium,MVM
join:2001-04-03
Reston, VA | reply 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.
--
Regards, Joseph V. Morris | |
| reply 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/incidents/200···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
--
Some people think I'm an idiot. I disagree, but idiocy is subjective--so they may well be right. With this in mind, take everything I post with a grain of salt, eh? | |
jvmorrisI Am The Man Who Was Not There.Premium,MVM
join:2001-04-03
Reston, VA | 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!
--
Regards, Joseph V. Morris | |
 SentinelPremium
join:2001-02-07
Florida
kudos:1 | reply 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.
--
AL | |
R2R NotPremium,MVM
join:2000-09-18
Long Beach, CA
kudos:1
| reply 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] | |
 SYNACKJust Firewall ItPremium,Mod
join:2001-03-05
Venice, CA
Networking
Virtual Private Ne..
Netgear
ZyXEL
| 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!
--
Where is the world is LA/OC ? | |
R2R NotPremium,MVM
join:2000-09-18
Long Beach, CA
kudos:1 | 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...:) | |
|
