Port function and scanning

That doesn't matter, since I doubt that you're competent enough to recognize a serious compromise.

However, the real reason is that K9 has a certain reputation. Beside being utterly useless.

Well, this is exactly the contrary of reputation. Anyway, Keir is known to dispute a lot of shit posted there (BTW, this stuff is NOT Usenet).

Now either this irony bites so hard that I fail to recognize it, or you're a total fool.

Dear Sebastian,

It is your messages I would be inclined to distrust most. My reasons are:

First of all your composition is faulty. One never knows who you are addressing or just what you are saying.

Secondly you rely upon personal insults and other offensive ways to display contempt for everything, particularly corporations, and you do not exempt individuals from your gall either.

Thirdly, you never come up with anything remotely useful, but limit yourself to declare almost everything which somebody else thinks is of value as worthless.

I think the best use for your diatribes is to read them for entertain- ment rather than for serious consideration.

GR.

Dear Ansgar-59cobalt- Wiechers,

Great suggestion to read the source code to remove doubts but not very practical. Consider the time it takes, the different kinds of computer languages and versions, the subroutines involved!

It is best to offer practical suggestions!

GR.

Which part of "then you have to trust the author" did you fail to understand? You don't have any other option.

cu

Dear Volker,

Thank you for your very practical suggestion regarding the netstat commands. I am already using them but I do not understand the impli- cations.

The netstat command offers seven arguments. These are: -a, -e, -n, -p proto, -r, -s, interval. Of these [-a] offers to "display all connections and listening ports". Sounds great for what I want to do. The way I understand the sentence in quotes is, that it reports the state of the system at the moment netstat -a is executed. Do the ports reported include all potentially open ports are just the ones cur- rently open? If the answer to this question is yes, it does not tell me all I need to know about the security of my system. I think that nmap tells queries all ports and determines their state..

I would appreciate a clarification of this issue...

Thank you

GR.

Hm? A reply typically addressed the quoted statement, what else?

What the...? I have never been insulting to anyone (except when very obviously for obvious reasons). Are you twisting this with honesty and directness? Consider that it's not wrong to tell someone that he's doing something very stupid.

Well, if you want useful advice, then ASK. So far typical questions are limited to "how do I make this crap not do anything crappy" or even worse "how do I make that crap do something stupid". The first step is to tell you that it's crap. The next step would be understanding what the real problem is, and then offering an appropriate solution.

Be honest: Your problem are not TCP/IP ports.

Which is utterly stupid, because they're very serious advice.

Oh, and could you please stop your stupid bottom full-quoting? Also, why does it seem that you're abusing Outlook Express as a newsreader?

"NoSpam" wrote in news:6GQfi.684$w2.586@trnddc01:

NoSpam, For quiet some time, I didn't even know if Sebastian G. existed anymore. He's been in my killfile for quite some time. That's the best suggestion that I can give you. Your assessment of him is dead on.

Currently listening, connected, closing, etc.

You have to understand the different states a port can be in:

Listening or not listening (and some in between, but only temporarily). What some firewalls call stealthed or filtered is something external to the interface. E.g.: Paketfilters (hence the name!) are an additional layer like a sieve in front of a system.

IFF the system is correctly configured and IFF the listening applications have no bugs, then you do not need a firewall.

IFF the listening application has security relevant bugs, a filter will not help, btw, if you expose the application to the net. If you want to tackle that, you need ALG. Some of the "security" suites include such a thing for example for pop (receiving mail). Proxies or reverse proxies are ALG also.

Summary: "stealthing" a port just tells me, that there is something interesting.

If I want to close a port, I stop the application listening on the port. I use an external firewall to my windows systems. On Unix systems I usually do not need an additional firewall (but I am a couple of years behind the state of art here, I see a lot of Linux-distros incorporating "personal firewalls").

Have you had time to skim through "Firewalls and Internet Security: Repelling the Wily Hacker". It is really easy to understand and ou just need a couple of introductor pages.

Cheers, Jens

There is no such thing like "potentially open ports".

A port is no door, no gate and no harbour. It's just a maintenance number. To be clear, it's a 16bit ID.

One calls a port "open", if this maintanence number is used by a process. One calls it "closed", if no process uses this number at this point of time.

With the netstat utility you can view all local processes and what ports they have open.

nmap is a port scanner. You can send network packets to network interfaces with it, which implement parts of traffic of common network protocols of the TCP/IP network protocol family. nmap does this waiting for replied packets. Then a heuristic is implemented to determine, wether a process on a remote machine is using the port on a network interface or not.

The port concept is used by different network protocols. A port scanner usually is used for TCP traffic, because there is an algorithm to determine wether there is a process "listening" on the "port" (using a socket or an XTI connection into the kernel with this maintenance number). Port scanners are more seldomly used for UDP, because there is no algorithm for this case for UDP. Sometimes it's used combined with implementing higher level protocols for that case, because for some protocols which are based on UDP there are algorithms or at least good heuristics.

ICMP by contrast has no port concept at all. And any port scanning system, which claims to implement "ICMP port scanning", is nonsense (like the Symantec trash).

Yours, VB.

There is. no reply -> open or filtered ICMP Destination Unreachable :: Port Unreachable -> closed UDP reply -> definitely open

ICMP has message codes and subcodes, which are essentially similar to ports. Still using the term "port" is, of course, wrong.

Wrong. No reply: open or closed.

From RC 792: | The Internet Protocol is not designed to be absolutely reliable. The | purpose of these control messages is to provide feedback about | problems in the communication environment, not to make IP reliable. | There are still no guarantees that a datagram will be delivered or a | control message will be returned.

No, they aren't. ICMP is a messaging protocol using IP packets, and the message codes have nothing to do with a port concept.

Yours, VB.

The Nmap documenation and the real world systems' behaviour tell something different.

Is that your argument of a misguided quote? Taking packet loss into account, you couldn't differ between open, closed or filtered even for a TCP-SYN.

They aren't used directly for multiplexing, however this is done by providing a part of the initial IP packet - which tells the host to which packet the reply belongs.

That may be your view.

I fear, you just don't understand.

Strange view.

I cannot see any argument in your posting which persists.

Yours, VB.

Same for you. So once again: If an RFC-conformant TCP/IP stack receives an UDP packet, it is supposed to reply with an ICMP Destination Unreachable with subcode Port Unreachable. Your quote is absolutely unrelated to this point, maybe you should rather cite RFC 768?

Dear Volker,

Thank you for your straightforward explanation of ports in your message of Tuesday, June26, 2007 11.40 AM. It was of great help.

In the meantime I have ordered the new edition of Cheswick's book "Firewalls and Internet Security" and I should shortly know more about the subject.

Regarding the subsequent exchange of messages between you and Sebastian I am sorry to say, that I had to disregard them all. I con- sider Sebastian to be an uninformed and uninforming contributor.

Thank you GR.

Well now, I wouldn't go that far. The dude maybe rude & crude but most certainly *not* uninformed and may I add quite entertaining :)

Yup, Seb's our resident 'Mr Angry', though I believe I have spotted one or two polite and helpful postings by him in the past. I love seeing postings along the line of 'What's a good PFW', and waiting for his predictable response!

Jim Ford

Jim Ford wrote in news:o5xgi.7537$_ snipped-for-privacy@newsfe2-gui.ntli.net:

I almost think that some regulars on this list post PFW questions using a different identity, just to trip his trigger. He needs to hide where he keeps his goat tied.