Port 113?

But that's not true. Something is there - it is just not replying. And since your stealthness depends, among other things, on the infrastructure you are connected to you have to take also that into consideration. Just to take my own machine as an example, it is childs play for someone out there to figure out of if I'm really not there or if I'm there but just "stealthed".

It can slow down a port scan - but since a bad guy can do numerous scans in parrallel I don't think the effect of that is really significant.

I also wonder what the -P0 option of the nmap utility is for.

Others look at that as a prompt rejection like "there is nothing here for you - move on". Who is right?

He may well know it's there. But anyway, how do you get through a closed port? And if that is possible, why is there a difference to it being stealthed?

And how do we know what "the bad guys" are thinking after all? Maybe it's a bigger challenge to get into the stealthed one?

/B. Nice

Very simple: Blindly send out 4 SYNs simutaneosly and only react to replies. They don't care if they receive an answer after the first SYN (hardly possible), they don't care if they receive a TCP-RST or an ICMP UNREACHABLE or ADMINISTRATIVELY_PROHIBITED, they don't hold any big state so they don't care for no replies at all...

Oh, and you won't slow down port scan for the very same reason.

Why? Please substantiate.

Yours, VB.

Yes.

The opposite is true. There is something at this address, because if there would be nothing, then the router before would send ICMP host unreachable.

Yours, VB.

Hello B. Nice and all.

I disagree fundamentally with Mr. Gottschalk's recommendation to use what amounts to "Default Allow" firewall policies.

Mr. Gottschalk wrote "You should never "stealth" any port until you have explicit reason to do so." This is an example of a "Default Allow" policy.

I believe in using "Default Drop" policies for all of my firewalls. As far as I am aware using INBOUND and OUTBOUND Default Drop policies are the Most Secure default firewall configurations. One has to know what traffic they wish to allow , and add deliberate and specific firewall-rules to allow it. It's a very educational process , because you cannot use any facet of the Internet until you know exactly which protocols and/or (TCP/UDP) ports you wish to use.

Imagine a door-lock for a house or an apartment , under what would be similar to a "Default Allow" policy , everyone would be able to unlock your door EXCEPT those persons whom you have specifically listed and barred from entry. Who would wish to have to list the 6-Billion odd people extant on the planet just to be able to prevent their entry? Under a similar scenario with a "Default Drop" policy ALL (those 6-Billion+) are denied entry UNLESS they have been specifically added to a list to be given entry (to be given a key lets say).

Mr. Gottschalk's recommendation to the original poster was to allow the traffic to and from the poster's computer to the extent that his ports would be "unstealthed". Later Mr. Gottschalk mentioned that:

"I've got a box that runs Windows from time to time. By default it would only react to ICMP codes 0,3,4,5,8,11,12,17 and 18. I configured it to not react to code 5, 17 or 18. The other ones aren't dangerous in any way. ..."

Maybe I missed it somewhere , but I don't recall Mr. Gottschalk warning the original poster that (perhaps especially under Windows environments) ICMP codes 5 , 17 , and 18 are dangerous. Did he make it clear to the original poster?

With Default Allow all is allowed (unless you know exactly what you wish to Disallow and then add the appropriate firewall-rule).

My advice wouldn't have left the original poster open to problems related to ICMP codes 5 , 17 , and 18.

Perhaps today there are dangers using ICMP codes 3 , 8 , and 12?

Perhaps tomorrow there will be attacks using 0 , 4 , 8 , and 11?

Things change constantly , new attacks are formulated constantly.

I'm quite content using a Default Drop stance.

My advice (again) is to do similarly , add rules to allow the traffic you absolutely must have , then add other traffic when and only when you FULLY UNDERSTAND what you are allowing. To do otherwise you truly must be an expert , and I mean having the ability to know of all possible attacks that are available instantly (and being able to change your firewall configurations instantly). I personally feel that having a secure firewall is NOT possible using defaults that blindly allow traffic.

Perhaps Mr. Gottschalk or some others are even more omnipotent than they could imagine. One would have to be to be able to track and respond to varying attack-methodologies second-by-second. Does anyone know what the dangerous ICMP codes are for today? Some find philately or numismatic-pursuits to be more relaxing hobbies. To each his (or her) own.

N.B. I assume that any who actually have a need to use ICMP or TCP RST or anything else will take the time and perhaps the Great Effort to be able to use these things securely. I elect not to use them. Some things can be Mastered. Some other things are perhaps best Not to master (nor to use). Cost-benefit and risk-reward analyses are your friends.

P.S. RE: Volker Birk (x2)

1) Many ISP's disable or curtail ICMP in their routers. If you are near to such routers (as I believe I am) there will be no forthcoming ICMP Host Unreachable messages. Even for those routers that do give these messages , would-be attackers would have no idea whether you were a home PC or some networked refrigerator or toaster. OS-fingerprinting relies on being able to receive packets (probably preferably TCP SYN packets) from potential targets , I choose not to emit ANY packet to anywhere without a valid reason.

2) Substantiate which? I advocate a Default Drop firewall stance. Those using Default Drop policies will be "stealthed" by default , they will be emitting packets only according to the specific firewall-rules that they write , rather than to anyone or anything on the planet that wishes to scan or probe them.

You and some others advocate sending packets out to anyone for no articulated security or other advantage. It is always less secure to allow traffic blindly. It is indeed bizarre to allow traffic for absolutely no advantage or reason.

My systems and my Internet connection are highly-stable. I can leave my machines on and my connection up for days at a time with nothing but a steady and reliable exchange of data. Perhaps any performance-degradation when not allowing certain types of traffic is idiosyncratic to your particular equipment or configuration.

I am a home user , but a number of reports both here and elsewhere seem to indicate that many larger networks also do not require that which you and others are advocating.

It is not. There is no security gain by this "stealthing" nonsense at all, and there is no security loss by not doing so.

Maybe you really should try to learn. Perhaps it would be a good idea for you to read the RFCs about IP, ICMP and TCP first.

Yes. Just try to understand what you're doing or recommending, _afterwards_ do or recommend, please.

Please, *PLEAZE* read the corresponding RFCs now and try to understand. Afterwards it will be very clear for you, which ICMP messages you want to let through at all events. Beside that "stealthing" also requires to violate TCP and not only ICMP, of course.

Just try to understand. Believe me, it's not too hard, you don't need to be "omnipotent" or something like that, and you really will learn interesting and useful things.

Yours, VB.

I didn't claim such a thing.

No, absolutely wrong. There's a big difference between "allow" and "reject

--with tcp-reset".

Are you twisting something? There's a difference between default action and default policy. The default policy should be "drop", whereas the default action for TCP and UDP should be a "reject".

ipfw add 65533 check state ipfw add 65535 allow tcp from me to any setup,frag keep-state ipfw add 65535 allow tcp from any to any related,etablished keep-state ipfw add 65534 reject tcp,udp from any to any ipfw add 65535 deny ip from any to any

They're not really dangerous. However, they might omit unexpected behaviour.

What I made clear is that blocking every ICMP is both needless and stupid.

Mine neither.

No.

Unlikely. And still you're ignoring that those are NEEEDED for proper functionality, so you should explicitly allow them, probably with a rate limit.

Exactly. Allow ICMP codes 0, 3, 4, 8, 11 and 12.

Yes, there have been extensive discussions.

And now you're doing the same nonsense. One should disallow all ICMP expect the ones you want/need. Just like the TCP/IP stack of any partitially sane operating system already does. Hey, not even Windows is so stupid to allow ICMP router discovery unless you explicitly activate it.

Yes, and that's a problem. Happily, my ISP is sane and does properly send ICMP error messages.

We've already discussed the advantages on doing it in a standard-conformant way. Yes, even advantages for yourself.

Well, it's my fault that I didn't properly migrate my kill file.

I don't know if you work in the business or not so I will tell you what is actually done by my company which has several hundred Checkpoint firewalls, and Juniper IPS devices and multiple DS3 links to the Internet.

We silently DROP all packets where there is not a server listening on that port. There are no ICMPs sent back or any resets. Regardless of if it violates any RFCs or not, if there is no server on a port, nothing at all is sent back. We run our own edge routers, we don't trust our service providers to do this. We have our own class A block and several class B blocks. If you have a class A block, you have been around for a bit.

This is how every person I know who works at any large company has configured their sites. By large I am talking billion dollar size company. I have had all the Checkpoint training classes, Juniper Netscreen classes and Secure Computing Sidewinder G2 classes. This is how they all teach you to configure the firewalls, drop anything not matching a policy, NEVER use reset.

I don't want to argue about if it's correct or not, it's what is done and taught.

We've done the same method for a decade and it's worked perfectly for our clients.

Some people don't get into the real world much, if you linger long enough in this group you will learn who they are.

So I have gathered. My impression is that some here give out advice without actually working in the field. It's not my intent to get involved in some flame war, been there already and it's better to just forget it. I just had to say however that to silently drop packets is the industry standard and has been for the 10 years I have been doing commercial firewall work.

Indeed!

Now consider this: If you controlled the router in front of a host and had a way (i.e. IPTables (and the likes)) to make the router send an "ICMP Host Unreachable" message on behalf of the host that it is protecting, it will be much harder to determine if the host is really there or not.

I would think that it would be very easy to configure the edge firewalling router to watch for "ICMP Host Unreachable" messages from specific hosts and SNAT the packet appear to be from the firewalling router its self. This would allow the protected host to manage it's own firewall yet still have the "ICMP Host Unreachable" messages appear as if they were from the router.

Or at least this is what I think. Any thought's / opinions?

Grant. . . .

Do consider that people that can program firewalls(perhaps some here can) , and really know how they work. Those people will have a different , and more technically correct understanding than people whose experience of firewalls are $800 appliances. Those people won't have to go on "courses".

I think it's important to have both perspectives. But to say to a technical geek expert 'you don't know, you're not a "professional", because you're not 'in the industry' of setting up fireawlls for businesses, is just stupid.

Many people that teach and are not in the field have problems with this statement: There is the right way, the wrong way, and the way it really works.

Many people that don't have experience in multiple cases only see a small scope of situations, or actually never see more than a couple situations. Some of those people are ignorant enough to believe that their scope and what they read is the definitive word in how it should always be.

Many people that have built solutions in the real world, that have proven to work, without a failure, without a breach, that keep corporations all over the world up and running, feel they know it all.

There are a few people, and mostly a minority, that have enough experience, have enough QA/Development time, have experienced many solutions and products/platforms, that they get tired of the kiddies claiming that they know the only right answer to everything.

I've seen hundreds of installations were a "technical" type setup a firewall, you can pick the firewall platform/appliance, where they just went by some training or document they found on the web, where there were so many holes that it might as well not have been installed. I've seen security instructors give bad information and methodology to students. I've seen instructors to the one really bad example "We're going to do it this way in class so that I can show you how it works, but you should never do this in a clients network" - and then the kids go out and all they remember is how it was done in class.

I have the impression that there are people in here that claim a lot of things, that like to appear as authorities by spouting what the RFC's suggest, that say nothing except their way is the right way, but, I also get the idea that those same people have either never been in the real world or are so far removed from it that the scope of what is real and what they know is very small.

You can take what I've written and throw it away, but it won't change the fact that you can do many things, even things that the RFC's would rather you not do, and life will still go on, your network will still work, your client won't experience any problems, and your designs will be safe.

An expert is only an expert if his peers believe he's an expert. Any expert that believes he's an expert is only fooling himself.

I agree, that was very well put.. The other guy also provided some advantages of the industry guy over the only technical guy. As if that was all that counted. I was just showing that the technical guy hasm any advatnages over the industry guy.

Ideally you want both. But typically the best technical or best industry guy is going to be weighted to one side.

I did see a thread involving you where somebody mentioned an application that would fail. It would be worth me searching through the archives if your posts were still there. Is there any way that I can read your old posts? Any searchable archive? preferably free.

I don't see the definition as "Technical" as the field guy is normally technical to the max, but a field guy may be green, as the same is true with your technical guy.

What I like to break them do into is:

1) People that have real experience in a LOT of real world solutions and a lot of technical background. 2) People that have limited real world/none experience but have a lot of technical training. 3) People that believe they are #1, are not really #2, and just can't cut it in either group.

I never hire the #2 or #3 types, I only hire people with lots of real world experience and good technical backgrounds, people that are book/limited scope are worthless when it comes to the real world.

LOL, this is Usenet, you can search for anything you want and I don't have anything to say about it.

ok

You misunderstood what I was asking.

To put it differently, what I meant was, suppose you make a good contribution to a thread, if I want to see that contribution, to search for the thread and see your contributions as well as those of others, Is there any searchable archive (preferably free) that'll contain your posts?

I use something called "X-No-archive: yes" in almost every post, have for years, and under every nickname I've used since the early 80's.

So, unless you find an archive or a usenet web mirror that ignores XNA, you won't see my direct posts archived.

Google has taken over the archiving of Usenet, but they honor XNA requests.

Just to add a few points for clarification.

I tend to be very conservative when I configure things for security , as I mentioned previously I am not an expert. An "expert" might conceivably be more vulnerable to attack in using something complex that a non-expert might have DISABLED.

I tend to define many things very literally , to me a "Default Drop" policy is ONLY a firewall stance that allows no packets to travel in either direction unless specific rules have been added to specifically allow packets to pass. To me a "Default Deny" policy (that would include sending TCP RST packets) is another form of Default Allow policy. Though by definition only a Default Allow policy allows complete connections to be formed by default , Default Deny policies allow PACKETS to travel in either direction by default and I personally view these as being "lesser" Default Allow policies.

To have any computer "unstealthed" one needs to be using a firewall that is allowing packets to move in and out in what I personally consider to be an unsafe fashion.

I admit I do need to spend a great deal of time researching many Internet protocols. It is possible that I might find some compelling reasons to use TCP RST and ICMP , but I don't believe I will find that any such possibilities would increase my level of security.

I value my privacy and security highly , I fervently believe that allowing the likes of TCP RST and ICMP will only act to undermine my online privacy and security.

I also believe that using ICMP will leave my systems open to future and as yet unknown attacks. As I have not used ICMP and have perfectly stable and responsive systems I see absolutely no reason to make myself vulnerable to the plethora of ICMP-based attacks. I do not use ICMP , thus I am not vulnerable to most attack-forms that utilize it.

I prefer to keep things as simple as is possible. I use two firewalls at present and in addition to STRICTLY LITERAL Default Drop policies , my firewall-rules are highly-specific to the packets they allow. Very Strict.

Though Mr. Gottschalk may very well be an expert on say ICMP , I believe his decision to use ICMP will make his systems more vulnerable to ICMP attacks (including new attack-methodologies in the future). More vulnerable than my own systems are that are "stealthed".

Stealthing is a good thing , it can help to protect your privacy and your security. I'm not saying that there is security through obscurity , but with adequate and tangible computer defenses in place , I see the tool of "stealthing" to be useful.

If anyone is curious I use OpenBSD's PF firewall and also the Linux Netfilter firewall. Neither have ever failed me. I prefer OpenBSD's PF as I am more used to it , I find it to be more configurable , and it seems to be quite a bit more sophisticated (perhaps more so than I require).

I do value the comments of Mr. Gottschalk and many others , should I ever decide to use TCP RST and ICMP for some non-security-related reason , their posts and the RFC's may very well come in handy. If I were not a home computer-user , if I actually wished to allow connections originating from the Internet to my systems , I might configure things differently. Possibly.

We block all ICMP and have never had a problem with inbound connections for services we provide.