I may be in the minority here, but I do see a real value in "security by obscurity" as part of a layered defense. I think it has been drummed into us for so long as being bad or worthless that many of us believe it.
You certainly do not want to rely on it as your primary defense. True simply changing the default SSH port or the Administrator name will not in itself stop a determined attacker but it will frustrate a lot of default automated attacks that are just looking for low hanging fruit. If you are not part of a targeted attack that may just be enough to get them to leave you alone. Sometimes your security just needs to be a little bit better than the next person's. :) Jody -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael Douglas Sent: Thursday, October 08, 2009 11:46 PM To: PaulDotCom Security Weekly Mailing List Subject: Re: [Pauldotcom] Drop or rst? <sarcasm> Also if you drop packets instead of sending the RST, you're saving power. Since I get all the trade rags, I know green data centers are all the rage. Every electron not sent down the wire is one less polar bear that has to tread water. Dropping packets saves Mother Earth! </sarcasm> Dropping is so much better because while you don't want to do the "security by obscurity" thing, you certainly don't want to make things easier for the bad guys. As others have said giving RSTs makes it crystal clear what systems are around, and what ports are open. If you do have to go the RST route for troubleshooting, see if you can enable RST response for only specific IPs or ranges. If that doesn't or can't fly (and on internet facing systems you might not want to enable RST even for a little while - though western civilization likely wouldn't end if you had to for a while), you can always tune nmap to assume a port is closed faster Try using the --host-timeout option! (one of the least used sadly) It takes arguments like so: 300000 or 300s or 5m. In your case, you'll want to use miliseconds (Hint: no letter after the time value) To get the "right" value, you'll need to do testing on how quickly an open port responds and then give it some extra time -- i give anywhere from 25% - 50% more time... ex: I know open port respond on a system respond on average around 130 milliseconds I might give nmap the following: --host-timeout 195 WARNING: setting your --host-timeout too low could result in nmap claiming a port is closed when it isn't. So you want to be on a low jitter, repeatable latency network link when doing this sort of stuff. For further ways to tune your nmap experience, you're likely not going to find a better writeup than here: http://nmap.org/book/man-performance.html Sorry to thread jack this a bit into arcane nmap stuffs, but hey, nmap is fun! Best of luck! - Mick On Thu, Oct 8, 2009 at 3:42 PM, Norman Rach <[email protected]> wrote: > Thanks everyone for your input. I'll add this to the agenda at our next > meeting as discussion points. > > Cheers! > NR > > ________________________________ > From: [email protected] > To: [email protected] > Subject: Drop or rst? > Date: Wed, 7 Oct 2009 09:39:07 -0700 > > Hi Everyone, > > I'm currently in a discussion about our current ruleset for iptables. > Whether to be RFC compliant and issue a RST to those scanning/connecting to > undesired ports or to drop the packet completely. By sending a rst back to > the host aren't we letting the srcIP know that the traffic > successfully arrived to the host without being intercepted by a network > appliance (i.e. IDS/IPS, firewall, etc)? > > As far as I can tell this seems to be more of a discussion on one's own > security posture preference. Any feedback is appreciated. > > Cheers! > NR > > ________________________________ > Hotmail: Powerful Free email with security by Microsoft. Get it now. > ________________________________ > Hotmail: Trusted email with Microsofts powerful SPAM protection. Sign up > now. > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com > _______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.421 / Virus Database: 270.14.8/2423 - Release Date: 10/08/09 18:33:00 _______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
