Yes, you can. Read RFC 793.
Yes, you can. Read RFC 793.
Sure "listening" is a well defined state for certain socket implementations, but you said "without having your computer listen on any port", not "without having any sockets in listening state." As you did not use technical vocabulary, the readers are entitled to interpret your remark in a more general sense of "listening" that includes the processing of returning packets.
We were responding to what you actually wrote, not to a narrower meaning that you might perhaps have intended.
In my experience, in general discussion groups, it is best to respond to what the person actually wrote: to presume a specialized interpretation is to "put words in people's mouths".
If you make an ambiguous statement, it is poor manners to denegrade those who interpret the statement in ways you did not expect. For example, you could have skipped the insults and simply said something like, "I intended 'listening' in the sense of the specific socket state
If you reread the discussion about the security aspect, you'll notice that exactly only the socket "listening" is relevant.
But you're ignoring context. Again: There is no useful meaning of blocking wanted connections initiated from the protected host.
Since you obviously have sufficient technical background I take it you were deliberately misunderstanding what either the OP and I had written.
This is not a general discussion group, and from the context it was pretty clear that the OP meant sockets in the state LISTEN.
My statement was much less ambiguous than you try to make it look. Established connections do not "listen on a port". Period.
Just like you could have skipped being a smartass. You were asking for it, so what are you complaining about?
cu
59cobalt
Don't waste your time. These guys are professional critics. That's what they do. They have staying power that any normal individual is way too busy to compete with.
-Frank
At least "these guys" know what they are talking about.
But I understand You are too busy to care about facts.
/B. Nice
We have no reason to expect that the original poster is using a POSIX compatible sockets -- for example it would be extremely reasonable to suppose that the original poster might be using Microsoft Windows XP.
If you follow this further into Microsoft's Windows Services For UNIX (SFU), you find that you only get IEEE 1003.1 compatibility promises for programs developed with the Internix SDK; similarily the earlier Windows POSIX subsystem only applied to programs specifically built for that subsystem:
The SFU download page indicates,
Note: The product will not install on Windows 9x or Windows XP Home Edition.
If you recheck you will find that the original poster did not specify TCP/IP.
Name another common network protocol with ports, wiseguy.
cu
59cobalt
I've been reading this newsgroup for several years, and it sure looks like a general discussion group to me. comp.security.firewalls is about akin to rec.autos.misc -- occasional detailed and helpful technical foreys, but much unfocused discussions about who's toy is better and about who can peel rubber faster.
If this were a technical newsgroup, I would expect a graceful "That's not what I meant, but my wording could have been a little tighter" (except from Vernon, who never has a need to directly
-say- "You don't know what you're talking about" ;-) )
It is only in general discussion groups that I expect to see people immediately jumping to phrases such as "shut the f*ck up".
Oh noes, no POSIX for Windows !!!11 Now does this make a bind() and listen() work any different?
Beside that, WinSrv03 R2 has got the POSIX subsystem back.
So, what else could you conclude to be consistent with the terms "firewall" and "port", especially in comp.security.firewalls?
IPX, even though they're commonly calling it sessions. :-) Now still it doesn't make any difference.
And it's only trolls that I expect to purposedly misinterpret other people's statements and go nitpicking about them.
*plonk*cu
59cobalt
You seem to forget that this was initiated by someone ridiculing the original poster with plain wrong statements.
I don't understand why You did'nt start by reacting to that.
Protocol 17.
-Russ.
And now better inform yourself what's commonly referred as TCP/IP protocol stack.
No, this subthread was started with someone making a gentle -humourous- response to the original poster -- a response that was valid within the scope of the original poster's actual words, even if it was perhaps not what the original poster had intended.
The ridiculing was of the person who made the humourous response (Frank), and of me when I supported him.
Correction: In general, YES.
Although those are good points, they don't address the other 200-ish IP protocols that do not have ports.
In particular, although one might not have any SOCK_DGRAM or SOCK_STREAM sockets in LISTEN state, one might still be completely vulnerable to The Ping Of Death, or to IP fragmentation attacks, or exploits of, say, PPTP (which is based upon GRE).
Huh, wonderful. I guess you usually just speak 3 of them.
Hello? This is year 2006.
PPTP is f***ed up anyway and no firewall could help with that.
You must not spend time in comp.lang.c . Statements made in comp.lang.c are routinely reinterpreted away from the "obvious" meaning, and then nitpicked. The purpose there is not to troll, but rather to develop precision and deepen understanding. It is quite common in comp.lang.c that a loosely-written statement is an indicator that a technical detail has been overlooked (or was not known), and the exploration of those technical details often ends up requiring a noticably different model of what is -really- happening.
For example, comp.lang.c has been debating for weeks over the exact meaning of the C statement x = (x=5,11); the understanding of which requires almost Talumdic analysis.
("In the Talmudic method of text study, the starting point is the principle that any text that is deemed worthy of serious study must be assumed to have been written with such care and precision that every term,expression, generalization or exception is significant not so much for what it states as for what it implies." [...] "Now this method of text interpretation is sometimes derogatorily referred to as Talmudic quibbling or pilpul. In truth, it is nothing but the application of the scientific method to the study of texts."
PPPoE on a DSL line: uses GRE (IP Protocol 47) to encapsulate all user traffic.
ESP (IP protocol 50): used by my IPSec connection to work to encrypt and encapsulate payloads
AH (IP protocol 51): used by my IPSec connection to work to provide authentication services
ICMP (IP protocol 1): numerous uses
And of course my systems use ARP as well.
As best I can tell, you did not really pay attention to what the original poster actually wrote. *ALL* we know about the original poster's system is that the original poster has a computer, and that the original poster's computer is running at least one networking protocol that uses "ports" that might (in some sense or other) be "listened" to.
We were not given ANY information about the kind of computer or the operating system version or what patches have been applied. In order to answer the question accurately, we must assume that the original poster might be running unpatched Windows 95, or might be using something akin to Controller Area Network (CAN).
Do people actually run old systems? Yes: my desktop at work and at home are (non-PC) models that were built in 1995.
Are fragmentation attacks still a problem in 2006? Yes: May 9, 2006, Cisco advised of a firewall security bypass based upon fragmentation. It isn't a DoS attack and doesn't kill the firewall, but if fragmentation approaches are still presenting problems to mature products, you can be pretty sure that IP-level fragmentation attacks are still a security risk that need to be actively considered.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.