Firewall (Something I would like to see)

[MakoFusion]

It would be nice if firewalls logged whenever a packet is ignored instead of blocked.

Online scans that tests firewalls usually show three settings on any given scanned port.

Port is Open
Port is Closed
Port is Stealthed

The firewall accepted, blocked, or ignored the test packets sent. On my current firewall it shows everything as blocked or accepted. Is there any firewall which logs when a packet has been ignored? I think future releases of firewalls should show exactly what it did with the packet sent for inbound traffic instead of combining block to mean block and ignored.

If I set my Zone Alarm to Medium security and run Steve Gibson's port tester it shows all my ports are closed.
Zone Alarm records blocked for those packets.
If I set my Zone Alarm to High security and run this same test it shows all my ports are stealthed.
Again Zone Alarm records these packets blocked.
See where I'm going with this?

[root]

Check out Outpost version 2 and see what you think of the logging.
http://agnitum.com/download/

It is still being debugged for some people having some issues with it, but I believe it works well for most. It uses the MMC snap in for logging and is quite extensive.

[JacK]

-{ Quote: " quoting: MakoFusion link=board=23;threadid=10710;start=0#msg69556 date=1056590530]
It would be nice if firewalls logged whenever a packet is ignored instead of blocked.

Online scans that tests firewalls usually show three settings on any given scanned port.

Port is Open
Port is Closed
Port is Stealthed

The firewall accepted, blocked, or ignored the test packets sent. On my current firewall it shows everything as blocked or accepted. Is there any firewall which logs when a packet has been ignored? I think future releases of firewalls should show exactly what it did with the packet sent for inbound traffic instead of combining block to mean block and ignored.

" }-

Hello,

Blocked = stealth = neglected, dropped = NO explicit respons from the firewall
Closed = deny = explicit respons from the firewall

Rgds,

[Phant0m]

Actually response from the System not a response from the Firewall unless you in reference to old Software like NukeNabber and perhaps PortWatchers… ;)

[gkweb]

I disagree Jacks,

Open = port open and response from it

Closed = port closed (no app listening on it) and response from it

Blocked = port closed or open, but firewall drop the SYN packet. But the port could be visible by sending it a TCP packet with special flags (such as ACK) the port respond whit a packet (RST flag), so the port is blocked but visible by other ways.

Stealth = the port is open or closed, but the firewall drop all kind of traffic toward it, not only SYN (connection), so, the port never respond to any traffic.

"Blocked" not equal to "Stealth"

regards,

gkweb.

[MakoFusion]

Yeah something like this...

June 26, 2003
xxx.xxx.xxx.xxx / TCP / Incoming / Connected
xxx.xxx.xxx.xxx / UPD / Incoming / Closed
xxx.xxx.xxx.xxx / UDP / Incoming / Blocked
xxx.xxx.xxx.xxx / UDP / Incoming / Dropped (Stealth)

[Phant0m]

Specifically in Reference to web-scans STEALTH & BLOCK concepts are one of the same. And even though I don’t agree with a lot of these web-scans giving the STEALTH status when done half-open (TCP SYN) Scans, I won’t start get technical so less knowledgeable folks gets highly confused and frustrated… ;)

[gkweb]

no, it's different.

i can block ports on my linux firewall without make them stealth, but believe what you want.
In addition, you definition are wrong, "closed = port exists..." all ports exist, from 1 to 65535, some are assigned to program listening, other not.
A blocked port can be open but blocked by firewall, it's not "twist", it's detail, but nothing to add, i'm wrong of course...

[LowWaterMark]

One of the problems trying to precisely clarify these points is that different firewalls use slightly different terminology for these things. I've seen terms like: block, drop, reject and deny and they don't always do the exact same thing in these different firewalls. What's important is knowing the specific syntax and termonology required on a particular firewall to get it to do exactly what you want from a results perspective.

[gkweb]

a block port can respond, but i will not try to explain how and why, and i will not try to explain what you can do with iptables on linux, it's a powerfull tool which by far is better that only block and stealth, you want to believe website ? believe what you want, me i will return here next week.

I'm start to be ...... up.

[Dan Perez]

Yeah, I agree with LWM that there is differing interpretations by various vendors on what their implementation of "stealth" but if you are looking at any non-vendor-specific definition it equates to no packet return for unallowed traffic. RFCs specify that if a host recieves an ACK without any prefatory SYN then the target host should send a FIN so any so-called stealth implementation should suppress the FIN in these instances. Likewise, a FIN without previous traffic is frequently reponded to by a FIN and thus should also be suppressed by a "stealth" implementation.

If you do a search for "stealth vs blocked" you will find many discussions of this. You may want to go through the nmap manpage for a good summary

http://www.insecure.org/nmap/data/nmap_manpage.html

Dan

[Dan Perez]

phantom''

"Block" implementations are almost *never* the same as stealth implementations alng the lines outlined in my previous post, but, again it depends on the FW vendor

[JacK]

-{ Quote: " quoting: Phant0m`` link=board=23;threadid=10710;start=0#msg69618 date=1056624883]
Actually response from the System not a response from the Firewall unless you in reference to old Software like NukeNabber and perhaps PortWatchers? ;)
" }-
Hi Phant0m,

You are right of course ;) No respons from the System due to the FW rules.

Due to my bad English : I meant allowed by the FW or through the FW.

Sorry

[Phant0m]

Hey Jack

Naa I know what you meant, I was just teasing :)

[JacK]

-{ Quote: " quoting: gkweb link=board=23;threadid=10710;start=0#msg69723 date=1056658462]
no, it's different.

i can block ports on my linux firewall without make them stealth, but believe what you want.
In addition, you definition are wrong, "closed = port exists..." all ports exist, from 1 to 65535, some are assigned to program listening, other not.
A blocked port can be open but blocked by firewall, it's not "twist", it's detail, but nothing to add, i'm wrong of course...
" }-
Hello gkweb,

A slight misunderstanding here : not so far ago, Windows FWs did not allowed to be in stealth mode just because they did not permit to drop packets but only forcefully deny.
LINUX FW allows it from the beginning.

You cannot on a LINUX box block a port (drop the inbound packets) and give a respons CLOSED when a probe on the port is done from the outside.
All ports exists from 0 to 65535 What Phanth0m meant is not that the port exists or not but that you know it exists as you get the answer CLOSED and you don't know it exists when it's BLOCKED as you get no answer proving the adress in existing
(enfin you may know it as a non respons is also a kind of respons ;)) if you know the IP is valid.

Yes, as you say, your are wrong ;)

Rgds,

[gkweb]

@ JAck

-{ Quote: "You cannot on a LINUX box block a port (drop the inbound packets) and give a respons CLOSED when a probe on the port is done from the outside.
" }-

I'm sorry but you can...

## RULE 1 : STEALTH PORT 21 (FTP)##
iptables -A INPUT -i ppp0 -p tcp --syn --dport 21 -j DROP

http://perso.wanadoo.fr/jugesoftware/test1.jpg


## RULE 2 : CLOSED PORT 21 (FTP)##
iptables -A INPUT -i ppp0 -p tcp --syn --dport 21 -j REJECT --reject-with tcp-reset

http://perso.wanadoo.fr/jugesoftware/test2.jpg



This rules will DROP the packet and then send the closed answer.
Why iptables allow us to do this ? because there is cases where if we just DROP the packet, a system services (like NFS, share daemon on linux if i remember right) could crash on outgoing packet DROP.

So, linux allow us to do BLOCKED ports, or STEALTH port.

So i'm not wrong...

gkweb.

[JacK]

-{ Quote: " quoting: gkweb link=board=23;threadid=10710;start=15#msg70228 date=1056841695]
@ JAck

-{ Quote: "You cannot on a LINUX box block a port (drop the inbound packets) and give a respons CLOSED when a probe on the port is done from the outside.
" }-

I'm sorry but you can...

## RULE 1 : STEALTH PORT 21 (FTP)##
iptables -A INPUT -i ppp0 -p tcp --syn --dport 21 -j DROP

http://perso.wanadoo.fr/jugesoftware/test1.jpg


## RULE 2 : CLOSED PORT 21 (FTP)##
iptables -A INPUT -i ppp0 -p tcp --syn --dport 21 -j REJECT --reject-with tcp-reset

http://perso.wanadoo.fr/jugesoftware/test2.jpg



This rules will DROP the packet and then send the closed answer.
Why iptables allow us to do this ? because there is cases where if we just DROP the packet, a system services (like NFS, share daemon on linux if i remember right) could crash on outgoing packet DROP.

So, linux allow us to do BLOCKED ports, or STEALTH port.

So i'm not wrong...

gkweb.
" }-

Hello gkweb,
I don't quite catch your point ?

What I see from your pics : it allows to appear blocked (= stealth) if you drop the packets or closed if you reject the packet .

As I told you : if you rule is drop you get an answer STEALTH (Blocked)
If you rule is reject you get an answer CLOSED
But you don't get an answer STEALTH when you rule is reject.

I often swich from BLOCKED to CLOSED purposely to give an answer when I inherit an IP from P2P user for instance to stop hammering on the dedicated P2P ports.

Rgds,

[gkweb]

that you say don't make that i show wrong.

may be you missed a point :

from start i say that STEALTH different of BLOCKED
and for me (BLOCKED = CLOSED)!= STEALTH

may be anyone here use his own words, and obviously it couldn't lead to anything good.

so with
(BLOCKED = CLOSED) != STEALTH

+

my pics

i'm not wrong, the two state STEALTH and UNSTEALTH (but both blocked) are different states, that we can even use on linux machine.

gkweb.

[Phant0m]

I don’t know of many Software Firewalls for Windows which provides unstealthed packet capabilities, and I can’t much say I care as I surely don’t see any benefits in this. Making yourself visible rather then stealth just provides a vulnerability to malicious activity…

[gkweb]

The fact that you want it or doesn't want it doesn't change that the two state are different, that is the only unique point that i wanted to say.

After, usefull or not, each have his point of view. Like said on symantec website, it's not a security hole to be visible, at worst, ports have to be closed, you are right on this point.

Me i prefer to be stealth, but it's just a security preference ;)

regards,

gkweb.

[gkweb]

@Phant0m

i don't talk to you about that websites think, but about real different state (that some confused!)

Open
Closed
Stealth

and that Closed != Stealth
and (to Jack) that a Closed port can be done on Linux.

After that, sites can say what they want. Notice that use the word "Block" is confusing, because in both CLOSED and STEALTH packets are blocked, or if you prefer the connection is blocked.
This is why i don't use "Block" as a state to avoid misunderstanding.

After you said that _for this websites scan_ this is sometimes the same, it's true. But me FROM START i put all my effort to said that STEALTH and UNSTEALTH (but blocked) are two different state, different than OPEN of course.

I think that considering BLOCKED ports while testing is a mistake, because as i said, in STEALTH and CLOSED conenctions are blocked.

regards,

gkweb.

[gkweb]

there is too much between JACK, ME, and YOU talking about :

OPEN
BLOCKED
CLOSED
STEALTH
DROP
REJECT

the only difference is that me i explain why i use words and not other.
and about you, where i said you were wrong ???
I essentialy replied to JAck posts (as you can see about linux).

regards,

gkweb.

EDIT : if you are annoying because i said to you that STEALTH != BLOCKED, see below my definition (BLOCKED = CLOSED != STEALTH).
Now you understand why i prefer to speak symantec talking : CLosed and Stealth, or at worst my own : stealth or unstealth (but blocked).

[CrazyM]

Hi Phant0m``

-{ Quote: " quoting: Phant0m`` link=board=23;threadid=10710;start=15#msg70243 date=1056845830]I don’t know of many Software Firewalls for Windows which provides packet DROP capabilities, and I can’t much say I care as I surely don’t see any benefits in this." }-

I am not aware of any Windows software firewalls either that provide the level functionality as demonstrated by gkweb's example using iptables. However, having that functionality and control over the firewall would be beneficial. To get this type of control now for Windows users means using a hardware firewall. This level of control may not be something everyone would want, but it is something I would like to see.

-{ Quote: "Making yourself visible rather then stealth just provides a vulnerability to malicious activity…" }-

Stealth may be your preference, but having the ability to configure a software firewall for stealth or closed would provide better functionality and the choice. Stealth or closed = secure/no access.

Regards,

CrazyM

[JacK]

-{ Quote: " quoting: gkweb link=board=23;threadid=10710;start=15#msg70247 date=1056847056]
After you said that _for this websites scan_ this is sometimes the same, it's true. But me FROM START i put all my effort to said that STEALTH and UNSTEALTH (but blocked) are two different state, different than OPEN of course.

I think that considering BLOCKED ports while testing is a mistake, because as i said, in STEALTH and CLOSED conenctions are blocked.

regards,

gkweb.

" }-

@ gkweb,

Of course the connections are technically blocked in both states ;)

It just a bit confusing terminology from different scanners.

In the beginning of online scans, the only respons you got was Blocked (when stealth or closed) and open. (There are still some using this).

St. Gibson introduced "stealth"and closed. Most online scanners now use this terms, some like Sygates I think use the word Blocked instead of stealth. (rhetorically incorrect but not my fault ;)) You have other interesting possibilities on LINUX, redirect some incoming packets somewhere else for instance.

@ Phant0m,

As to know whether stealth or closed is more secure, it's an old discussion : they are partisans for both.
ASFM, réponse de Normand, sometime better, sometime worse to be stealth : depends on circumstances

Being stealth you will escape ports scan on a IP range by scriptkiddies for instance but you will give valuable information to a hacker which already knows your IP.

Rgds,

[Phant0m]

For those who knows an Machine exists on IP and Machines stealthed, the information that should be going through an Hacker or Hax0r’s mind is this person is Firewalled, they going to possibly need to spend quite a bit of time and efforts. If this Machine runs servers or the Software Firewall that’s not properly configured then you can expect it to possibly be a disadvantage. No difference as your being specifically targeted and your Firewall generates unstealthed packets, the Hacker or Hax0r who wants to revenge or get thrills are going to thorough Scan you anyways.

And they finally come to the conclusion you’re not penetrable then you going to have to expect Flood Attacks, and if your Software Firewall is spending time generating unstealthed packets, responding back wasting valuable System Resources not to mention the valuable bandwidth in the process then that’s totally not what I consider beneficial…

[CrazyM]

Hi MakoFusion

-{ Quote: " quoting: MakoFusion link=board=23;threadid=10710;start=0#msg69635 date=1056629284]
Yeah something like this...

June 26, 2003
xxx.xxx.xxx.xxx / TCP / Incoming / Connected
xxx.xxx.xxx.xxx / UPD / Incoming / Closed
xxx.xxx.xxx.xxx / UDP / Incoming / Blocked
xxx.xxx.xxx.xxx / UDP / Incoming / Dropped (Stealth)
" }-

As you can see from some of the discussion the context in which these terms are used can mean different things to different people. Also noted is that terms will vary between software firewall vendors and testing sites.

Some firewall logs will make no reference to action taken and at the other end of the spectrum you have something like the current version of NIS/NPF where you will see the terms Blocked, Dropped and Stealth in the different logs. Knowing how your firewall is configured and how it responds to unsolicited traffic is how most will interpret what ever caption is used in the log.

There are not many traditional software firewalls left, and as they evolve to include things like IDS, you are seeing multiple logs and the possibility of more terminology being introduced. The likelihood of uniformity between vendors is probably not that great.

If you are sticking with ZA and it is something you would like to see, you could alway fire off a note to them with your suggestion.

Regards,

CrazyM

[JacK]

-{ Quote: " quoting: Phant0m`` link=board=23;threadid=10710;start=30#msg70262 date=1056853027]
And they finally come to the conclusion you?re not penetrable then you going to have to expect Flood Attacks, and if your Software Firewall is spending time DROPPING packets, responding back wasting valuable System Resources not to mention the valuable bandwidth in the process then that?s totally not what I consider beneficial?

" }-

Hi Phant0m,

When it can be beneficial answering CLOSED is when you inherit an IP where formerly ran a server, PCAnywhere, a P2P, etc... : as long as you are stealth no way for other machines to know the service is no more available at this IP and they go on sending packet to you. Once they know the service is over, they stop sending to you.

Rgds,

[Phant0m]

I dont agree ;)

[gkweb]

You are right Jack, it's sometimes needed to say closed instead of stealth (P2P yea ;) )

But i know at least one case where to be stealth is very annoying for the hacker, even if it know your IP and that you have a firewall : Nmap scanner.
It will take more than one hour, sometimes 2 hours, when it wouldn't take more than only 10/15mn ;D
Because of the timeout, Nmap wait for responses.

So have the possibility to use these features on a personal firewall could be usefull i think, just with a small checkboxe 'stealth' checked or not (let's use only one word! ;D )
Of course it's to firewall vendors to do that it have to do, because a closed port return his associated closed answer, that is not always TCP RST, but to the end user, this should be user friendly with just the checkbox

regards,

gkweb.

[Phant0m]

-{ Quote: " as long as you are stealth no way for other machines to know the service is no more available at this IP and they go on sending packet to you. " }-
When you inherit IP that was formerly running Services, and you are STEALTH the other Machines will know the service is no longer available when they cannot connect to it, period!

-{ Quote: " Once they know the service is over, they stop sending to you. " }-
Do you sit there constantly re-loading a 400Page?


Sorry i disagree that it's useful in any manner... :P

[JacK]

-{ Quote: " quoting: Phant0m`` link=board=23;threadid=10710;start=30#msg70342 date=1056884285]
-{ Quote: " as long as you are stealth no way for other machines to know the service is no more available at this IP and they go on sending packet to you. " }-
When you inherit IP that was formerly running Services, and you are STEALTH the other Machines will know the service is no longer available when they cannot connect to it, period!
No, it will goes on trying to connect it , especially the P2Ps. The service may be temporary unavailable or just a time out for some raison, the app running on the remote machine has no way to now it till it gets a CLOSED answer

-{ Quote: " Once they know the service is over, they stop sending to you. " }-
Do you sit there constantly re-loading a 400Page?
I was not only speaking about a webserver, a lot of applications go on sending packets stupidly as long as they don't get an answer. You may easily verify it in your FW logs

Sorry i disagree that it's useful in any manner... :P
That's your right ;)
" }-

Rgds,

[JacK]

-{ Quote: " quoting: gkweb link=board=23;threadid=10710;start=30#msg70339 date=1056883713]
You are right Jack, it's sometimes needed to say closed instead of stealth (P2P yea ;) )

But i know at least one case where to be stealth is very annoying for the hacker, even if it know your IP and that you have a firewall : Nmap scanner.
It will take more than one hour, sometimes 2 hours, when it wouldn't take more than only 10/15mn ;D
Because of the timeout, Nmap wait for responses.

So have the possibility to use these features on a personal firewall could be usefull i think, just with a small checkboxe 'stealth' checked or not (let's use only one word! ;D )
Of course it's to firewall vendors to do that it have to do, because a closed port return his associated closed answer, that is not always TCP RST, but to the end user, this should be user friendly with just the checkbox

regards,

gkweb.
" }-

Hi gkweb,

Unfortunately I don't know any Windows FW with this checkbox on a port basis. It's all or nothing and you need to go in advanced settings or modify the rule each time or have different config files saved and switch according to your needs, not just one click ;(

Rgds,

[Phant0m]

Key word "Time Out"

[Phant0m]

IRC for an Example; you connect to the IRC server and your ISP disconnects you, do you think you stay known permanently? No server Times your Out the same way as “Direct Connect” times you out from the hubs & that’s including the hubs server List and likewise for any p2p servers.

Yes I do agree that Clients will make Connection attempts simultaneously for about few tries if the Client doesn’t receive a response of some sort and then “Times Out”. When this occurs first thing arises through average heads is the server no longer exists, so constantly attempting to re-connect would be effortless and time consuming for the most part…

So I still don’t see the benefits with Software Firewall vendors implementing unstealthed capabilities… I only see major disadvantages on;

#1. System
#2. Bandwidth

Usages…

You want to know why most prefers seeking for “Closed” Ports on Firewalled users. Because it's the next best thing to "Open" ports when in Reference to Flood Attacks, because the unstealthed responses will lead to the user’s destruction much earlier in the process then that who is properly Firewalled… I’ve been around many Hackers many Hax0rs and just plain numb headed folks for many years who all I considered friends. I know what they think, I know what they do, and I know there capabilities. ;)

[gkweb]

@Phant0m
-{ Quote: "I know what they think, I know what they do, and I know there capabilities. " }-

you're not alone!

and as i said stealth it the worst for hackers, but it exist a very few cases where stealth instead of just closed make the system crashing!
I don't know any example on windows, but a least on Linux i know two (if it's not crashes at least it's system instability) with NFS sharing and X Window, both are about outbound attempt that you have to closed and not drop.

So close a port could be in very few cases absolutly needed.

Now, about inbound attack, and all other legitimate traffic, it's true that we can stealth all without system errors, and with the max security for a home user (i don't talk about firm...)

I think that both Jack and Phant0m are true ;)

regards,

gkweb.

[Phant0m]

Finally! We agree that packet Firewalls implementing unstealthed capabilities for Inbounds are unbeneficial!
However I see benefits in this technology upon Outbound Connection Attempts, as long as we are in understanding…

[JacK]

-{ Quote: " quoting: Phant0m`` link=board=23;threadid=10710;start=30#msg70359 date=1056890031]
IRC for an Example; you connect to the IRC server and your ISP disconnects you, do you think you stay known permanently? No server Times your Out the same way as ?Direct Connect? times you out from the hubs & that?s including the hubs server List and likewise for any p2p servers.
" }-

Hi Phant0m,

I am in stealth mode and the same IP for about 30 hours and don't run Edonkey/Emule. In my firewall log : 7 Inbound connections on :4662 from the same IP the last half hour. Other probes on the same port from different IPs earlier and even from the same with an interval of some hours.

That tends to prove they go on sending packets to my IP because they don't know I don't run Edonkey. If I answer CLOSED for some minuts, no more probes on this P2P port.

Same with Kazaa when I inherit a former Kazaa user IP.

Of course most of the time I am in stealth mode, just Closed for a short time to stop hammering from P2P and back to stealth.

As for pagers, I don't experience anything for I always run them through proxysocks which I often change ;)

Rgds,

[Phant0m]

Hmmm well that’s one crappy p2p service then, can someone confirm that this Edonkey/Emule server doesn’t Time-Out it’s users after the users experienced some type of Disconnection anomaly?

As for Kazaa I definitely know it’s servers Times-Out users who experiences some type of Disconnection anomaly.

Again! I see no benefits in having Software Firewalls generate unstealth capabilities for Inbound Connection attempts; I only see major disadvantages…

[gkweb]

From that i read on eMule forum, other P2P client stops hammering you between 20-30min.
No more details.
I supposed that it is in the case where the port is closed.

(pls use closed instead of drop, because drop on itself is stealth, closed isn't stealth, pls :-\)

So, if the port is stealth instead of closed, it will take longer for they stop asking you sources, how many longer i don't know.
This about P2P discussion.

Now about "CLOSED feature" on personal firewall :
there is a way to have this CLOSED port capabilitie :)
If the port is really unused, P2P client down for instance, you can simply temporarly accept traffic toward the port which will say itself that it is closed ;)
This way is less secured, of course !

regards,

gkweb.

[gkweb]

???

I studied network at school, i do it on hobbies too, i do only this, so when you say what you say, it's a little bit exagerated!
However i can do mistakes of course, but say what in this case.

In addition what you are saying to me is sensless.
If a packet that reach a closed port (without any firewall) would be dropped, this would meaning that without firewall by default all closed port are stealth !! i want to know which OS you have !

Of course may be you are playing with words or reading documentation without thinking where they said the packet is dropped... the packet is dropped, if you want, AND a closed answer is send, it's not me that don't know what he is saying, it's you.

If you do symantec test without firewall, all port tested but without any services up and running on your side will have the state CLOSED, because the port send a closed answer, they won't be STEALTH.

gkweb.

[gkweb]

i agree, that doesn't prevent the TCP/Ip stack to do his job :

Nmap documentation :
-{ Quote: "-sF -sX -sN
Stealth FIN, Xmas Tree, or Null scan modes: There
are times when even SYN scanning isn't clandestine
enough. Some firewalls and packet filters watch for
SYNs to restricted ports, and programs like Synlog*
ger and Courtney are available to detect these
scans. These advanced scans, on the other hand, may
be able to pass through unmolested." }-

and the most important :

-{ Quote: "
The idea is that closed ports are required to reply
to your probe packet with an RST, while open ports
must ignore the packets in question (see RFC 793 pp
64)" }-

That's what i said about closed ports, nothing more.

gkweb.

[gkweb]

other example :

-{ Quote: "
-sS TCP SYN scan: This technique is often referred to
as "half-open" scanning, [...] A RST is indicative of a non-lis*
tener. [...]
" }-

about classical connection attempt.

gkweb.

[gkweb]

glad to know your award, you don't know mine! and i prefer don't write it because i'm not here to hurt you, but to have constructive answer.

and where in what you are saying you give me wrong ?
all that i said is that a not firewalled port closed return a closed answer, i didn't said anything else.

After that you said that the packet is dropped, again confusing because for some people including me a dropped packet is a firewall feature, but of course in network reality, the OS drop the packet (that i said on my last post!) AND return closed answer, it's not me that said this to you, it's a network functionality !
(use on some Nmap scan).
So just say that the packet is Dropped mean that the port is stealth, even without firewall, that is wrong.

gkweb.

[MakoFusion]

You 2 are being so silly.

[Phant0m]

I apologize MakoFusion.

[gkweb]

ok.

Phant0m don't want to see network basis, and in addition make me say things that i never said (that can ideed be considered as silly).
That i say is true, that firewall vendors say it's true, but say one thing _partially_ make it wrong, if you only talking about dropping (wo! like firewall vendors said!!) but don't say the follow (no follow if firewalled and stealth, but closed response if port closed and unfirewalled) that's wrong, and you play on words to laugh at me.

So i ended here with all what i said, it's a sume up, silly sume up if i believe MakoFusion :


1 - STEALTH and UNSTEALTH (CLOSED) are two different state
2 - a not firewalled closed port answer a closed reponse


I said this, nothing less, nothing more.

Now, you want to play on words, to make me said amazing things, to make me appears like a kid that have zero knowledge, it has nothing to do with network, it's a silly behaviour like said MakoFusion.

So, i finally fed up, and i repeat what i said :


1 - STEALTH and UNSTEALTH (CLOSED) are two different state
2 - a not firewalled closed port answer a closed reponse


Now i go away from this board, thanks to all constructive posts, and not thanks to people who can't be wrong.

[innocent bystander]

"Do you know any of today’s Software Firewall which provides this Feature now?"
_

VisNetic.

[Phant0m]

Ohhh yea, LOL obviously i know that one does...

;)

[Paul Wilders]

Gents,

The both of you started off in a friendly way. There's no need at all to agree; actually agreeing to disagree, or coming up with arguments seems a nice and solid way to have a fine discussion. This can be done the way you both started off - in a friendly way, with mutual respect :)

regards.

paul

[Phant0m]

There is no need to agree to disagree; I totally agree with gkweb that using the term Dropped packets isn’t the most appropriate to use under such circumstances. ;)

[Phant0m]

With respect for MakoFusion I cleaned up abit of my threads, once again I apologize for any inconveniences we (gkweb and I) had put you and others through… :'(

[CrazyM]

Hi Phant0m``

-{ Quote: " quoting: Phant0m`` link=board=23;threadid=10710;start=45#msg70500 date=1056929531]With respect for MakoFusion I cleaned up abit of my threads, once again I apologize for any inconveniences we (gkweb and I) had put you and others through… :'( " }-

While things strayed a little, the discussion demonstrated there will be different interpretations of what terminology is used.

As for the stealth vs. closed debate, the only consensus will be that different users will likely always agree to disagree.

Regards,

CrazyM

[Phant0m]

Hey...

Agreeing to disagree is quite overrated… :-\

[Dan Perez]

lol

-{ Quote: "Agreeing to disagree is quite overrated? " }-

So is "winning" an argument. ;D

[Phant0m]

I thought i agreed with gkweb?

Did i not agree with gkweb?

[CrazyM]

Hi Phant0m``

I think everyone agreed or disagreed with each other at one point or another ::). Perhaps it's best to leave it for now.

Regards,

CrazyM

[Phant0m]

I didn't agree to disagree, scroll up...

[LowWaterMark]

Well, in any case, I think this thread has made all of its points - on more than one occasion.

:: sticking a fork in it ::

Yep, it's done. Thanks everyone for your contributions. ;)