# DROP or REJECT

## bluesky

I run a iptables stateful firewall box  and di a little experimenting with DROP /REJECT.  The results were obtained from various popular test sites such as dslreports, pcflank, grc.com, sygate.com.

1. When  I used  DROP as below, all test sides showed "stealthed ports" :

 *Quote:*   

>  iptables -A INPUT -p TCP -i  eth0 -j DROP 

 

2.  When I use  REJECT , all test sides showed "closed ports":

 *Quote:*   

>  iptables -A INPUT -p TCP -i eth0 -j REJECT --reject-with tcp-reset

 

According to Daniel Robbins in his  ibm paper on stateful firewall, the second rule is far better than the first.  But general opinion favored "stealthed ports" over "closed ports".  

As a newbie in iptables, I am awaiting your experienced opinions.  Thanks.    :Sad: 

----------

## rtn

I tend to use REJECT over DROP.  REJECT is more "polite" in that it sends a

message back to the source (which is configurable) saying that port/service

is unavailable.  DROP just drops the packets, and the source never gets a 

reply, which most applications will show as Filtered instead of Unavailable.

--rtn

----------

## bluesky

I  scanned some mailinglist archives and the issue seemed controversial. I will quoted here a couple of opinions that favored REJECT.  My stand on this issued  is still undecisive:

 *Quote:*   

> RFC behavior is that unbound TCP ports return resets on connections, and 
> 
> unbound UDP ports return ICMP port unreachable.  If you want to make your 
> 
> firewall less obtrusive, then do that.  Your filtered ports will then be (at 
> ...

 

 *Quote:*   

> Depending upon the client, sending resets is actually more efficient.
> 
> If the client receives an ICMP port unreachable, she will give up and move 
> 
> on to the next UDP port.  Ditto for reset and TCP ports.
> ...

 

----------

## nikai

 *rtn wrote:*   

> REJECT is more "polite" in that it sends a message back to the source (which is configurable) saying that port/service is unavailable.

 

Exactly, that's why I'm using REJECT as well.

The only problem I heard of is that someone could use the "unreachable" answers to remotely attack someone else. I was told it was a good idea to add a rate limit to prevent that.

----------

## kaladis

And since we all wouldn't be online without the RFCs, we should tend to behave according to the RFC. Ie, Reject the packets. Everything else has already been said.

----------

## rtn

 *nikai wrote:*   

>  *rtn wrote:*   REJECT is more "polite" in that it sends a message back to the source (which is configurable) saying that port/service is unavailable. 
> 
> Exactly, that's why I'm using REJECT as well.
> 
> The only problem I heard of is that someone could use the "unreachable" answers to remotely attack someone else. I was told it was a good idea to add a rate limit to prevent that.

 

That's true, and I'd meant to include that but got sidetracked.  Spoofed

source packets can result in ghosted DoS attacks - I personally saw it happen

often at my old job with their EFnet IRC servers....

--rtn

----------

## bluesky

I found a pretty good paper on this subject "drop vs reject" :

http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

So far, it seemed to me that  the two sides used different arguments.  The REJECT camp  tried to explain the "why reject is better than drop".  The DROP camp  favors its cause around the word "stealth" and around  the popularity of the test sides(grc.com, pcflank, sygate, dslreports...).  

At this point, being no iptables expert, I am not sure  which side is more correct. But either way,  it is still acceptable.  So, I really am not too worry about it  but if there is a better explaination either way,  I will be glad to hear it.

----------

## bluesky

I looked at the "definition" of stealth at grc.com(gibson) from the "nano probe" tests:

 *Quote:*   

> There is NO EVIDENCE WHATSOEVER that a port (or even any computer) exists at this IP address!

 

It seems to make sense if you don't run any service(webserver...)  and it explains the effect of DROP.  However,  if there is any service running , the proble will revealed them as closed and the usefulness of DROP ceases to exist.

----------

## kaladis

*coughs* gibson *coughs* bullshit *coughs*

----------

## bluesky

When I posted this same topic at dslreports, all responses were pro DROP( for stealth).  Here, so far all responses have been  pro REJECT.   Unless we discuss  the topic  with facts we will not go anywhere.   :Smile: 

----------

## kerframil

I generally favour the "DROP" approach. If my firewall receives a request to connect to a sevice that I do not offer, then it is (a) by definition, unauthorised or unwanted (b) junk or accidental traffic - there's far too much of this going around the Net due to poor stack implementations and software (Windows NT is quite appalling in this regard). I personally, do not wish to waste my time responding to either.

The spoofed argument does not apply if you have set up a proper ruleset. You should automatically drop any incoming traffic with a source IP matching a private range subnet (regardless of whether it is TCP/UDP/ICMP or where it was destined) - and these rules should be way up high before anything else gets considered. That way, you don't have to check for spoofed packets in any subsequent rules.

I can appreciate the argument that issuing a TCP RST back to an unwanted connection attempt can be seen as a kind of "shut up" response but for me, the obfuscation of not responding and not bothering to waste my bandwith dealing with and clogging the Internet with yet more pointless traffic takes precedence. By responding you make it easier for someone to put a load on your firewall just by hammering you with SYN packets, to the detriment of yourself and your users.

As for the argument that if you have any availabe services then you can't achieve full stealth anyway - true, but it's not the whole point. Not every unwanted access attempt is necessarily a script kiddie scanning every available port and looking for a way in, and such people might just probe commonly open ports. Script kiddies aren't really that clever - and they just want an easy target, IMO. Assuming such a scenario, you can conceivably appear to be invisible just by running your services on non-standard ports.

The only acception is that I send a RST on incoming IDENT/AUTH requests because it makes FTP a lot quicker - which is worth it for me. You can also run a fake identd daemon which will just respond with random IDs - which may be even more efficient.

Of course, there are valid counter-arguments - including the faking of services and open ports to make your machine look like something it is not. But for me, I'm more concerned with making sure the firewall itself is secure, that the services exposed are secure and that the whole thing is efficient.

I use OpenBSD for all of this, which confuses the hell out of nmap anyway (it is hopeless at identifying anything worthwhile about the host itself).

Just my two pence anyway ...  :Smile: 

----------

## Xor

I'd like to join....

 *Quote:*   

> I generally favour the "DROP"

 

but I do not agree in general terms

 *Quote:*   

> by definition, unauthorised or unwanted

 

maybe unwanted but not unauthorized!

 *Quote:*   

> accidental traffic

 

well, those guys are the loosers in your scenario....

 *Quote:*   

>  there's far too much of this going around the Net

 

agreed, but that's no reason to violate RFCs nor to fight it that way, as almost every mother says: be always polite and behaIve  :Wink: 

 *Quote:*   

> The spoofed argument does not apply

 

agreed, drope'em

 *Quote:*   

> the obfuscation

 

security through obsucurity - I don't like it.... I like bullet proof security

 *Quote:*   

> not responding

 

gives you sometimes real troubles with dns and mta's.... just to name a few

 *Quote:*   

> waste my bandwith

 

well, if I count all the "code red" "nimda" "dynamic dns updates" I don't care about a few ICMP packages....

 *Quote:*   

> load on your firewall

 

poor firewall if it can't handle thos extra ICMP traffic

 *Quote:*   

> hammering you with SYN packets

 

well, if someone wan't to DOS or DDOS you, you are anyway out of luck - so what's the point? if that's happening you can go to your next upstream and determin the source... that's all - todays computers don't get as fast out of resources as your bandwith or routers do.

 *Quote:*   

> stealth

 

it's the same argument like "OS Fingerprinting" - hey the whole world should know I USE OPENBSD - so if you want wast your time try to breack it... but you'll have surely more luck the next door.... so if I send the "adm prohibited ICMP" message in return it's almost the same. The guy should know, that he's playing with a well configured firewall by well trained personel - "go hack someones zonealaram or whatever but go away" is the message.

 *Quote:*   

> The only acception

 

oh, only ftp? there are a lot of other services.... what about mta's? httpd's? - you see...

 *Quote:*   

>  fake identd daemon

 

more code that can be exploited - great!

 *Quote:*   

>  firewall itself is secure

 

good - but don't forget the purpose of it - you wan't a secure network.... 

 *Quote:*   

> I use OpenBSD

  - well mine says clearly "OpenBSD 3.0 upwards with "scrub all" feature enabled - I see no harm in it.

take nature - a cheetah never attacks a strong elephant, only the weak or old... so be strong and up-to date  :Wink: 

Just my 2p

regards

----------

## kerframil

OK - I never thought I'd read something so abrasive in these forums. I'm sorry you so vehemently find everything I said disagreeable, but as I said that is my 2 pence and the general tone of the response ensures that I am sticking by it. As your reply shows mild signs of one-upmanship and remarks which seem to be contrived to contradict almost everything I could possibly have said (seeing as it is littered with quotes from myself interspersed with almost purely the negative or oh-so-slight deragatory), I believe this warrants a reply:

 *Quote:*   

> maybe unwanted but not unauthorized!

 

I'm not quite sure how you worked that one out. It seems simple enough to me. I have a few open ports, 25, 443 and a couple more. Someone fires a TCP packet with the SYN flag at my private system _not_ targeted to any of those legitimate ports running legitimate services. That, to me, is unauthorised. I don't authorise anyone to connect to services on a private host which don't even exist, let alone stipulating about those that do.

 *Quote:*   

> well, those guys are the loosers in your scenario.... 

 

I disagree. Everyone's a loser. Every router through which this traffic must pass. The overall Net bandwidth which is lessened by this kind of junk traffic. Think I'm being pedantic? There's a lot of this traffic going around and it adds up. I'm a loser because if I followed your example and rigorously honoured every unwanted TCP connection with a RST packet then I would be sending out yet more traffic (consuming my rather limited upstream bandwidth on my not amazingly fast cable modem), sending unneeded traffic through my ISP and again back over the Internet. The slight CPU time incurred, the slight less time I am able to provide for servicing my users. And maybe not so slight if someone hits me with a DoS attack. Even in light of your remarks on DoS, I'm not responding to traffic I don't want. It's my host and I put it on the Net for my purposes. It's put on the Net for the benefit of my users not anyone else - and there's nothing wrong with that.

Theo de Raadt has apparently implemented an anti-spam SMTP proxy recently which is deliberately very expensive for anyone initiating a connection who happens to be on the SPEWS list. Aside from the arguments about the validity of the list, is Theo wrong to think that it should be the spammers who get the cost and not the would-be recipient of the spam? One can only assume that, presumably like me, he didn't listen to his mother either.

 *Quote:*   

> agreed, but that's no reason to violate RFCs nor to fight it that way, as almost every mother says: be always polite and behaIve

 

I am not misbehaving. The initiater of the traffic is the misbehaver and the bad Net citizen. Your analogy is equivalent to answering the doorbell dogmatically every time a prankster were to ring it, even if they were doing it every 10 seconds ad infinitum, and to claim that not to answer them is cheating the etiquette of citizenship.

BTW, if I do not intend to run any external services and wish only to provide Internet access to my internal users, thus attaining full "stealth" (so to speak) is that a heinous act of criminal disregard of RFCs? I think not. To me it's just common sense, and these recommendations do seem to be widespread, as I will re-iterate.

 *Quote:*   

> agreed, drope'em

 

Wrong. I was, that is. The example rules I was talking about would only defend against spoofed packets that would potentially target a host on your internal subnet. If you do not "DROP" packets which have a spoofed source IP (a valid public IP) then you are potentially rendering other people to a DoS attack from your host. There may be other ways around it (yes, quite possibly things I don't know about), but I still consider it to be a significant factor.

 *Quote:*   

> gives you sometimes real troubles with dns and mta's.... just to name a few

 

Can you elaborate on these troubles, because I have been using the same basic firewall template in various setups for many years - and my setups have consistently run (apparently to end-users) flawlessly. If someone tries to connect to my port 25, they get a response from my MTA. If an internal host of mine tries to connect to a foreign MTA, the stateful inspection enables all traffic required to support a legitimate (yes, RFC-compliant) connection for the whole duration of the connection right up until the point at which it is closed. Just as it does an inbound SMTP transaction with my MTA, in fact. Same with DNS. If my internal host sends a UDP request to a foreign DNS server on port 53, then my firewall will realise the responding UDP packet containing the answer is logically "partnered" with the request that initiated the response, and it flows in no problem. BUT, if someone tries to connect to me on port 53 and the firewall sees that it is a fresh request (i.e. someone acting as if I'm running a DNS server) then it will drop it and rightly so. I don't run a public DNS server, and there is no law that says I have to. So you have completely lost me there. There is nothing non-compliant about the way other people must conduct their connections with me, or vice-versa.

The reason I enabled an RST on the AUTH port is because I just happened to notice that many FTP servers respond to an intial data control connection on port 21 with an packet sent right back at you on that port. If you don't respond, they don't seem to like it very much and FTP logins are extremely slow. By enabling RST (or REJECT, if you prefer) I let them know that I can't accept that connection and they seem to deal with it. FTP is a very strange protocol, if you can name me any other typical protocol that I might use which is characterised similarly then by all means be my guest - does SMTP behave like that, does HTTP? No.

 *Quote:*   

> more code that can be exploited - great!

 

Look, this isn't a contest. I don't actually run it myself - I was just sharing that because I thought the whole FTP-triggering-a-fresh-incoming-IDENTD thing was quite interesting and the identd thing seems like a decent way of dealing with it ... dare I say compliant and polite! If it is not to your taste, then don't run it - but don't just blindly criticise. With that kind of approach, I wonder how you even dare power on your computer at all. Among other things, I set up firewalls for a living (not nearly getting enough time to work on them, frankly) and I've worked with a few. I am not an old-school hacker with experience dating back to the ARPAnet implementation, but I am not an idiot and am quite capable of deciding what code I am prepared to take a risk with and that which I am not on my networks, thank you - and I didn't mention it as a prescription - just for the sake of sharing information. If you have tried the fake identd and found a bug, why not send a patch to the author instead of smirking. I have not tried it.

 *Quote:*   

> good - but don't forget the purpose of it - you wan't a secure network....

 

Thank you for reminding me of that. See my last sentence.

 *Quote:*   

> well mine says clearly "OpenBSD 3.0 upwards with "scrub all" feature enabled - I see no harm in it.

 

I'm not sure exactly what you mean, but I think you mean that you have probed my firewall to see what you could get. If what you say is the case, then I thank you for correcting me and I will investigate it. I don't get much time allocated on maintenance and while I like to think I know my rule set inside out, I don't get to do enough testing seeing as I have to balance a multiplicity of duties without a team, on not much pay. If it turns out to be true, then I hope you enjoy what apparently seems to be a victory to you. I'll just take it as a helpful hint.

I'll round off by saying that I took over supporting a commercial implementation of CheckPoint Firewall at one point. The initial setup had been performed by some excellent engineers from one of their subsidiaries. They did not favour the "REJECT" approach (they were also the source of the IDENTD trick which inspired me investigate the FTP issue further). As far as I can tell, most people steeped in the BSD way (and I do not claim to be an outstanding member of the cognoscenti) advocate the DROP (or block) approach, including the official OpenBSD pf guide and Brendon Conoboy's excellent IPF documentation. I agree with them, I'm sticking to that and I hope you can find it in yourself to accept other people might have contrasting opinions with yourself.

Had your reponse not been so acidic, I would not have bothered to re-iterate any of my opinions, which are perhaps just that, opinions. Rather I would have been inclined to discuss your views further. But as it stands, I'm peeved. I refuse to take part in discussion which is going to degenerate to this level of pseudo-macho "knowledge" posturing and will not be watching this thread any further in any shape or form. Yes, I put my opinions strongly (as I usually do) but do not believe I did or will imply incompetence in others just because they disagree - that I have no time for. Maybe I'm just reading this the wrong way, but I was looking for mature debate, not a nature lesson and a reminder that I should listen have listened to my mother (conspicuously, the only two things you chose to put a "smiley" against). And to round it off my echoing my "2p" quote which seems to me to be nothing short of mockery. Doubtless you are smart and perhaps a more experienced Linux person than I am, but right now I care not a jot - and frankly don't even feel like contributing a single word to the forums anymore. Good day.

----------

## Xor

 *Quote:*   

> OK - I never thought I'd read something so abrasive in these forums. 

 

well, that must me bad english - I appologize - it's nothing personal... it's my opinion (my 2c)

 *Quote:*   

> omeone fires a TCP packet with the SYN flag at my private system

 

well, it's quite simple: has it a privat or public IP-Address - I guess the word "public" is per definition not private.... If you want that I don't see it, than rule it out.... or do you leaf your home with doors unlocked?

 *Quote:*   

>  There's a lot of this traffic going around and it adds up

 

agreed - as someone said the sum if intelligence on earth is always the same, but the population is growing... more and more people enter the net and no _bs_ about netiquette or RFCs and as someone pointed out: the only reason you are able to connect to the Internet are this very RFCs and other Standards - so if you participate in the Net obey those rules.

SPAM: who sends SPAM? folks that don't know Nettiquette.... they get punished - but in ignoring the RFCs you fall in the same category: you work for your own pleasure and give a damn about others - that do SPAMers... and in my opinion - RFC ingorants.

 *Quote:*   

> anti-spam SMTP proxy 

 

unfortunately I'm not yet aware of this feature - but I have no problem if I can integrate RBLs into PF > :Smile: )

 *Quote:*   

> answering the doorbell dogmatically

 

I never open the door when someone rings, and I don't answer phone-calls when I don't know the number. But if someone of this marketers in the shopping mal ask me If I want to have the newest fastest... "No Thankyou" - I don't just walk by if I wouldn't see him.

But that are IRL examples which don't can be compared to an RFC.... best known in IRL is a "code of honor" but how does life with one anyway....

 *Quote:*   

> full "stealth"

 

a firewall (in routed mode) is more than a router - but still a router - and a router must (by RFC) be responsive to some ICMP traffic. if you want stealth you have to bridge the firewall.

sorry, but I don't understand what you mean with "external services" in conjunction with "stealth"....

 *Quote:*   

> Wrong. I was,

 

as said, drop all spoofed packages - you are not wrong  :Smile: 

to make a DOS effective, you as a "blackhat" have to get hosts which say produce 2 byte of traffic for every 1 byte you send.... the bigger the difference the better.... I don't know what the difference is between the smallest possible UDP package and an ICMP unreachable by heart, but you might have a point here - and limiting ICMP traffic to say 10% of you total bandwith is surely a good idea (udp 30%)

 *Quote:*   

> Can you elaborate on these troubles

 

older sendmails and ftp agents as do irc servers (and others possibly) do an idend or finger connection in return if you connect to them.... some httpd servers too do fancy stuff... so connections slow down. I see it own eyes - I can't tell why there are servers still usings this by logic, but it happens. and you statefull inspection doesn't help here.

 *Quote:*   

> right up until the point at which it is closed

 

you do know that Netfilter currently has a problem to deliver some "ACK FIN" and "PSH FIN" packages.... I belive it's a problem of old linux-kernels on a foreign host... but yet they didn't find out. so this surely is not as it should be, but it happens (well OpenBSD is better... it can also handle ipv6 statefull) - anyhow, was just FYI

 *Quote:*   

> UDP request to a foreign DNS 

 

there is no hostility meant in this sentence - but you know that DNS also happens over TCP... especially older RedHats... (glibc related?)

 *Quote:*   

> I don't run a public DNS server

 

so just behave as you wouldn't - just help to make the network a little bit more transparent if you don't run the service, deliver the correct respond as defined per RFC: "No Thank you"

 *Quote:*   

> The reason I enabled an RST on the AUTH port is because I just happened to notice that many FTP 

 

if you would follow the RFC, you wouldn't have to trouble which services may do such things.

 *Quote:*   

> FTP is a very strange protocol

 

as stupid one if you ask me - as is h323... but my opinion - I like statefull firewalling.... others don't.

 *Quote:*   

> my guest

 

H323 - you owe me a dinner  :Wink:  (sorry, I don't drink beer....)

it's pain to firewall - opens variuos ports... >30000 and some in the 5xxx range...

irc does auth bachwards (I know, said earlier, but just to make it complete in this section)

 *Quote:*   

> are I say compliant and polite! 

 

I see... we make progress  :Smile:  (no offense, please)

 *Quote:*   

> but don't just blindly criticise

 

it's no blind (or is it... if I write rubbish because I'm blind, say it - name the RFC  :Wink: 

the problem with every service is, that you deliver "code" that is executable - preferably this fake ident runs not chrooted and as root - and it is possible a daemon with little user-base - which is pro and con. anyhow, the less services you run, the lesser is the chance of a break-in.

surely, it's a "philosophy" which is not shared by all - but how often do you intend to watch out for an update of your "pseudo ident service"? once service more to maintain.... 

 *Quote:*   

> With that kind of approach, I wonder how you even dare power on your computer at all. Among other things, I set up firewalls for a living (not nearly getting enough time to work on them, frankly) and I've worked with a few. I am not an old-school hacker with experience dating back to the ARPAnet implementation, but I am not an idiot and am quite capable of deciding what code I am prepared to take a risk with and that which I am not on my networks, thank you - and I didn't mention it as a prescription - just for the sake of sharing information. If you have tried the fake identd and found a bug, why not send a patch to the author instead of smirking. I have not tried it. 

 

I guess, that's the payback for my not intended personal directed hostility - well, I can dig it  :Smile: 

you do use ssh? you do use openssl? - code used by thousends.... and yet - bugs survived over years - to make the correct statement: it's not relevant how many sevices you run, it's relevant how many bugs they have and how well they are configured and used. the chance of running into a "problem" with 20 services is just a little bit higher than running 5.

FYI: apache is now chrooted in openbsd - quite cool, I just what application this will break.... 

 *Quote:*   

> Thank you for reminding me

 

maybe *I* phreased a few sentances to personal, but I meant it technical - all your firewall is nonsense if your webserver has funny perl scripts - I don't think you are stupid, and I think you well aware of it.... I just wan't to make a point - to explain myself.

 *Quote:*   

> my firewall 

 

well, I guessed this sentence could be missinterpreted - but I  didn't - I don't have the wish to track your IP - and don't even know if I would be able  :Smile:  - No it's *my* firewall at home, which I mean.

 *Quote:*   

> I don't get much time allocated on maintenance

 

yet we have different approches for handling unwated traffic, we still suffer the same and aim for the same.... I don't dare to say that... but it make's us somekind member of the same brotherhood  :Smile: 

 *Quote:*   

> I don't get to do enough testing seeing as I have to balance a multiplicity of duties without a team, on not much pay

 

well - I share that too, except we are here 2 technicians and 1 salesmen.... My aim is just to improve where I can, in my network at home, in business, and people have enough understanding worth to share my thoughts - which you are as you proof understanding - as I hope to proof myseld of some understanding to admited to get some usefull thoughs of other minds - maybe I didn't responded in a well formed tounge - but to bring up some fire... it's also nettiquette to take everything so "hostile" - you just can't tell how I would have to spoke the words I have written... but you allready know...

 *Quote:*   

> victory

 

is the day, everone uses opensource, has error-free dns, well configured MTAs and of course firewalls right configured - I don't have any benefit it probing, hacking or bringing business down for no purpose. I don't allow hotmail to mail me because of their license - but as long as micosoft.com behaves to RFC they can mail me....

 *Quote:*   

> Yes, I put my opinions strongly

 

well. as I read, you will never read this - but that's just the fault I made it - and as I expiriced it's the only way, "be self aware"

 *Quote:*   

> "knowledge" posturing

 

wasn't my intend - but it seems I did.... I appologize for that.

 *Quote:*   

> I did or will imply incompetence in others just because they disagree - that I have no time for. Maybe I'm just reading this the wrong way

 

you surely did take it the wrong way - I surely wouldn't use that word for someone.

 *Quote:*   

> mother (conspicuously, the only two things you chose to put a "smiley" against)

 

they were jokes - and yes, I should make more use of those smileyies....

it seems like I messed it up and you are not going to read it anyway, so I'll keep this post-mortem short.

I would have enjoyed a "mature debate" - but it seems I failed, maybe it's me (too) that should read the Nettiquette once more.... at least I know one exists - while many don't - and it's my daily business to get troubles just because people don't read manuals, rfcs and man pages - if the would I would get halfe the phone calls and emails and certainly more time for maintenace - but like other started to drop unwanted traffic insted of reject (the polite way) I forgot manners to respond in correct manners and fall into the same category as those firewalls - if not the very communication of the internet would be at stake (yes dramatic - but possible if you like a can explain) and the looss (really?) of a member in this forum (which might be one of the more knowldegle ones I meet here) I would say it's a funny coinsidance, but in this case it's a sad one.

best regards

xor

----------

## kerframil

Hmm, I guess I did over-react a bit.   :Confused: 

Obviously I was considerably angry and what seemed to me to be a picky deconstruction of my post and it resulted in my breathing fire and brimstone all over the place, which I realise isn't necessarily the best way to respond.

After a few days, I think it's safe to say I've cooled down about it. I'll try not to do it again ...   :Smile: 

----------

## Crg

 *bluesky wrote:*   

> I looked at the "definition" of stealth at grc.com(gibson) from the "nano probe" tests:
> 
>  *Quote:*   There is NO EVIDENCE WHATSOEVER that a port (or even any computer) exists at this IP address! 
> 
> It seems to make sense if you don't run any service(webserver...)  and it explains the effect of DROP.  However,  if there is any service running , the proble will revealed them as closed and the usefulness of DROP ceases to exist.

 

Not if you use the recent match in a nice way...

----------

## erik_swanson

Facts)

1. DROP breaks things (IDENT,FINGER...)

2. DROPping everything cannot completely hide the existence of your computer

3. DROP goes against the RFCs

My opinions)

1. Obscurity is not security

2. It's better (and easier!) to not break things in the first place then to set exceptions

I use REJECT.

----------

## Xor

One small token to think about it

pinging a host that does not exist says:

--($:~)-- ping 212.25.4.27

PING 212.25.4.27 (212.25.4.27) 56(84) bytes of data.

From 212.25.27.98 icmp_seq=4 Destination Host Unreachable

Fro--- 212.25.4.27 ping statistics ---

5 packets transmitted, 0 received, +2 errors, 100% packet loss, time 4000ms

m 212.25.27.98 icmp_seq=5 Destination Host Unreachable

pinging a host that blocks icmp says:

--($:~)-- ping www.ibm.com

PING www.ibm.com (129.42.16.99) 56(84) bytes of data.

--- www.ibm.com ping statistics ---

19 packets transmitted, 0 received, 100% packet loss, time 17997ms

it's a difference between "nothing" and "acting as nothing".... 

anyhow, it doesn't matter... or does NIMDA ping you befor it attacks? The "stealth" reason is a joke, nothing more... its like cutting of your legs, you seriously damaging a working system in the hope that a terrorist wont see you just because you are a meter smaller... forgetting that they shoot at everything that moves anyway.[/quote]

----------

## madchaz

My personal opinion

both are good. It's a mather of how you use them. 

the polite way to use it is reject. This is good because it lets the other party know you are actively refusing connections. 

this is proper responce and from legitimate connections will end up saving time, resources and bandwidth. 

This, however, leaves you upen to reflected DOS attacts. Basicaly, it's someone requesting a connection to you with the wrong IP adresse. this then floods the adress that was spoofed. 

Using drop will stop those and waste resources on the attacker. However, so will using a limiter on the reject. 

Personaly, I use drop. I like making the anoying port scaners in my node waste there time. They know port 80 is up but the rest doesn't awnser. 

It's a mather of how you look at it. If you want the easy fast way, use drop. Keeps you from being used in a reflected DOS attack and anoys port scaners. Otherwise, use reject, but for goodness' sake, use a limiter to keep from being used in a reflected DOS, or at least lower the impact of yourself.

----------

## Xor

 *Quote:*   

> 
> 
> This, however, leaves you upen to reflected DOS attacts. Basicaly, it's someone requesting a connection to you with the wrong IP adresse. this then floods the adress that was spoofed. 

 

Reflecting TCP is not very effective to multiply traffic, IMHO it's 1:1. The source of the traffic gets easily noticed. As you may know. the trick is to multiply your traffic.

rant

Anyhow, with drop you do more harm than good, IMHO. and very IMHO folks that block icmp and drop tcp/udp have no clue how networks work and should not be allowed to have a public IP on their NIC. Or said even worse, the Internet was engineerd by smart people but used by idiots.

/rantLast edited by Xor on Wed Jul 30, 2003 3:27 pm; edited 1 time in total

----------

## puddpunk

You sure know how to make friends around here, dont you  :Smile: 

----------

## uzik

If you want to use DROP to protect against reflected DOS attacks

perhaps the thing to do would be to write the IPTABLES rule such

that it does REJECT for the first request from each source IP and

then switches to DROP thereafter. This is polite, unless you're

abusive and keep sending repeated requests. It's not perfect,

but it's a good attempt.

I don't really feel the it's polite and it's in the RFC is a very

valid argument. There are a lot of minimal hardware boxes

with dedicated functionality. It's unreasonable to expect them

to answer queries to every possible port. That allows you

to build modular hardware that can share precious IP

addresses.

It's also unreasonable to expect existing boxes to

keep upgrading by requiring them to give polite

refusals to protocols that weren't invented yet

when the box was installed.

Thus, DROP is my choice for protocols I don't support.

----------

## nikai

 *uzik wrote:*   

> If you want to use DROP to protect against reflected DOS attacks
> 
> perhaps the thing to do would be to write the IPTABLES rule such
> 
> that it does REJECT for the first request from each source IP and
> ...

 

Uhm, AFAIK you can't trust the source IP. It may change with every query.

Or even worse, it may spoof the IP of your dns server  :Wink: 

What I'm using here behind ADSL at home is a rate limit of 1/sec, and burst 5.

My logs tell me that's just fine in most cases. The only time I really get to the drop rule is a selfscan at places like grc.com.

Now you may start throwing stones at me, but that's the best I could figure out until now.

----------

## uzik

I thought about the spoofed IP's but didn't think about them spoofing

me. You're pretty devious!   :Smile: 

----------

## SpinDizzy

99.999% of all traffic my firewall drops is unwanted port scans/attacks, I'm more then happy to drop/tarpit this traffic and see it as doing a good deed by doing what I can to slow this traffic. 

This has nothing to do with stealth, if I wanted to be stealthy, I'd configure my DNS to return 127.0.0.1 to all queries regarding my domain from those IPs not on my whitelist...

----------

## Xor

 *Quote:*   

> I don't really feel the it's polite and it's in the RFC is a very
> 
> valid argument. There are a lot of minimal hardware boxes
> 
> with dedicated functionality.

 

dedicated functionality... hey, I don't talk thei have to be able to do IPSec (at least not with IPv4) but being able to send an ICMP or TCP RST is absiolut fundamental.

 *Quote:*   

> It's unreasonable to expect them
> 
> to answer queries to every possible port. 

 

you don't have really a cliue what you are talking about... I'ms sorry, either you are trolling or have the idea that a linux box runs 65536 deamons just to say "nobody here"

 *Quote:*   

> That allows you
> 
> to build modular hardware that can share precious IP
> 
> addresses. 

  Ah... not answering on 60k ports allows you to bind an additional IP on you interface... please, go read some books.....

 *Quote:*   

> 
> 
> It's also unreasonable to expect existing boxes to
> 
> keep upgrading by requiring them to give polite
> ...

 

The RFC is 20 years old... how old is your box?

 *Quote:*   

> 
> 
> Thus, DROP is my choice for protocols I don't support.
> 
> 

 

yeah, drop the whole IP from you kernel... it seems you really don't understand nor support it

 *Quote:*   

> 
> 
> If you want to use DROP to protect against reflected DOS attacks
> 
> perhaps the thing to do would be to write the IPTABLES rule such
> ...

 

that's fair use... if someone hammers you, than you start dropping...  no stones needed here...

 *Quote:*   

> 
> 
> Or even worse, it may spoof the IP of your dns server 
> 
> 

 

Spoofing is as one self is really nasty... and deserve at drop  :Smile: 

----------

