| View previous topic :: View next topic |
| Author |
Message |
bluesky
Apprentice
Joined: 14 Aug 2002
Posts: 230
Location: USA
|
 Posted: Fri Jan 17, 2003 7:09 pm Post subject: DROP or REJECT |
 |
|
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. 
_________________
bluesky
"free as the wind"
Last edited by bluesky on Fri Jan 17, 2003 7:30 pm; edited 1 time in total |
|
| Back to top |
|
 |
rtn
Guru
Joined: 15 Nov 2002
Posts: 427
|
| Posted: Fri Jan 17, 2003 7:26 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
bluesky
Apprentice
Joined: 14 Aug 2002
Posts: 230
Location: USA
|
| Posted: Fri Jan 17, 2003 8:04 pm Post subject: re: DROP or REJECT |
|
|
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
least in that respect) indistinguishable from unfiltered, unbound ports.
If you want your port filtering to be very obvious, then use DROP instead. |
| 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.
If the client receives no response, he's likely to just keep flooding more
packets at the port (particularly for UDP).
Sure, REJECT results in you sending a response you wouldn't otherwise send
(nominally using more bandwidth), but it also cuts off further incoming
traffic (saving bandwidth, and reducing filter load). |
_________________
bluesky
"free as the wind" |
|
| Back to top |
|
|
nikai
Apprentice
Joined: 02 Oct 2002
Posts: 270
Location: Kitzbühel, Austria
|
| Posted: Fri Jan 17, 2003 8:42 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
kaladis
n00b
Joined: 12 Jan 2003
Posts: 4
Location: Germany
|
| Posted: Fri Jan 17, 2003 9:07 pm Post subject: |
|
|
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.
_________________
Error 666: Repeated reboots failed to solve problem
Login Lanstation Corp Sysadmin - www.login-lanstation.de |
|
| Back to top |
|
|
rtn
Guru
Joined: 15 Nov 2002
Posts: 427
|
| Posted: Fri Jan 17, 2003 9:27 pm Post subject: |
|
|
| 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 |
|
| Back to top |
|
|
bluesky
Apprentice
Joined: 14 Aug 2002
Posts: 230
Location: USA
|
| Posted: Fri Jan 17, 2003 11:09 pm Post subject: re: drop vs reject |
|
|
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
"free as the wind" |
|
| Back to top |
|
|
bluesky
Apprentice
Joined: 14 Aug 2002
Posts: 230
Location: USA
|
| Posted: Sun Jan 19, 2003 3:04 pm Post subject: What is stealth? |
|
|
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.
_________________
bluesky
"free as the wind" |
|
| Back to top |
|
|
kaladis
n00b
Joined: 12 Jan 2003
Posts: 4
Location: Germany
|
| Posted: Sun Jan 19, 2003 3:25 pm Post subject: |
|
|
*coughs* gibson *coughs* bullshit *coughs*
_________________
Error 666: Repeated reboots failed to solve problem
Login Lanstation Corp Sysadmin - www.login-lanstation.de |
|
| Back to top |
|
|
bluesky
Apprentice
Joined: 14 Aug 2002
Posts: 230
Location: USA
|
| Posted: Sun Jan 19, 2003 5:44 pm Post subject: re: finding the fact |
|
|
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. 
_________________
bluesky
"free as the wind" |
|
| Back to top |
|
|
474
l33t
Joined: 19 Apr 2002
Posts: 714
|
| Posted: Sun Jan 19, 2003 7:14 pm Post subject: |
|
|
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 ... |
|
| Back to top |
|
|
Xor
Tux's lil' helper
Joined: 07 Jul 2002
Posts: 144
|
| Posted: Tue Jan 21, 2003 11:05 am Post subject: |
|
|
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 
| Quote: | | The spoofed argument does not apply |
agreed, drope'em
security through obsucurity - I don't like it.... I like bullet proof security
gives you sometimes real troubles with dns and mta's.... just to name a few
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.
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....
- 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
Just my 2p
regards |
|
| Back to top |
|
|
474
l33t
Joined: 19 Apr 2002
Posts: 714
|
| Posted: Wed Jan 22, 2003 7:35 pm Post subject: |
|
|
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.
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. |
|
| Back to top |
|
|
Xor
Tux's lil' helper
Joined: 07 Jul 2002
Posts: 144
|
| Posted: Wed Jan 22, 2003 9:55 pm Post subject: |
|
|
| 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 >)
| 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....
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"....
as said, drop all spoofed packages - you are not wrong
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.
H323 - you owe me a dinner (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 (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
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
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.
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 - 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
| 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...
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 |
|
| Back to top |
|
|
474
l33t
Joined: 19 Apr 2002
Posts: 714
|
| Posted: Fri Jan 24, 2003 6:37 pm Post subject: |
|
|
Hmm, I guess I did over-react a bit. 
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 ... |
|
| Back to top |
|
|
Crg
Guru
Joined: 29 May 2002
Posts: 345
Location: London
|
| Posted: Thu Jul 24, 2003 12:49 pm Post subject: Re: What is stealth? |
|
|
| 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... |
|
| Back to top |
|
|
erik_swanson
Retired Dev
Joined: 02 Feb 2003
Posts: 123
Location: Corvallis, OR USA
|
| Posted: Thu Jul 24, 2003 4:31 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
Xor
Tux's lil' helper
Joined: 07 Jul 2002
Posts: 144
|
| Posted: Thu Jul 24, 2003 5:10 pm Post subject: |
|
|
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] |
|
| Back to top |
|
|
madchaz
l33t
Joined: 01 Jul 2003
Posts: 995
Location: Quebec, Canada
|
| Posted: Fri Jul 25, 2003 2:56 pm Post subject: |
|
|
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.
_________________
Someone asked me once if I suffered from mental illness. I told him I enjoyed every second of it. |
|
| Back to top |
|
|
Xor
Tux's lil' helper
Joined: 07 Jul 2002
Posts: 144
|
| Posted: Mon Jul 28, 2003 12:33 pm Post subject: |
|
|
| 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.
/rant
Last edited by Xor on Wed Jul 30, 2003 3:27 pm; edited 1 time in total |
|
| Back to top |
|
|
puddpunk
l33t
Joined: 20 Jul 2002
Posts: 681
Location: New Zealand
|
| Posted: Mon Jul 28, 2003 8:27 pm Post subject: |
|
|
| You sure know how to make friends around here, dont you |
|
| Back to top |
|
|
uzik
Apprentice
Joined: 17 Apr 2003
Posts: 257
|
| Posted: Mon Jul 28, 2003 10:57 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
nikai
Apprentice
Joined: 02 Oct 2002
Posts: 270
Location: Kitzbühel, Austria
|
| Posted: Tue Jul 29, 2003 9:59 am Post subject: |
|
|
| 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
then switches to DROP thereafter. |
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
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. |
|
| Back to top |
|
|
uzik
Apprentice
Joined: 17 Apr 2003
Posts: 257
|
| Posted: Tue Jul 29, 2003 12:15 pm Post subject: |
|
|
I thought about the spoofed IP's but didn't think about them spoofing
me. You're pretty devious! |
|
| Back to top |
|
|
SpinDizzy
n00b
Joined: 28 May 2003
Posts: 63
Location: Moss Vale, Australia
|
| Posted: Wed Jul 30, 2003 3:00 pm Post subject: |
|
|
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... |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
