> Hehehe... you really think so? 90% of the kiddies are brute force > exploiters, who will blindly try whatever exploit they have on hand, till one > succeeds. They wont bother to fingerprint OSs / mailservers etc to try only > relevant exploits.
Au contraire, the cycle is ... use netcraft/queso/nmap/whatever to identify the target's OS, services running etc, find out the respective versions, search for an exploit for that version... Another pattern is to do a sweep across a range of IPs for some service. sshscan for example, does this... It scans for port 22, and if found it checks the version number ... funny that you should say, that you have really looked at it.... I reserve my doubts, really... Thanks for your informed survey report of common cracking patterns. :) > I won't say clueless - but I _will_ say that munging version headers is utter > rubbish. Well, each to his own. :) I hail you, the greatest security expert in the world, but if it is all the same to you, I'd rather patch my servers, install other security measures *and* munge the version headers. If it takes the hacker 5 minutes more of extra effort to identify the version, more power to munging headers. :) > So, filter them out... a little mod_perl (search for Nathan Torkington's > vermicide, for example) takes care of all the nimda crap filling up your > logs. Portsentry / other IDS which dynamically adds nullroutes or iptables > deny rules against cracker IPs is another way to do this. Why not weed them out to begin with ? If I have ftp service running even on a non-advertised server, I will get 5-6 attempts every day for anonymous ftp attempts... if I have disabled anonymous ftp and it deters a couple of script kiddies from thinking I am 100% clueless and they can try stuff... all the better. Portsentry *is* installed and i did recommend that, thank you very much. :) I'd rather have less attempts to begin with, on the server, even though it is completely patched. Ok, I will explain this in far simpler trems which you have hithertho been unable to grasp... Exploits are often released to the underground first and then on the security lists etc. Since we are talking sshscan, I will cite the case of Teso's openssh exploit .... What is your opinion on that ? Point is that you patch the servers *after* the patch are released... what do you do *before* the patches are out ? do you make things easier for the crackers ? Especially if they are running an sweep-scan tool like sshscan which is dependent on just the version number ? Why are you so totally *unable* to grasp what I am saying ? > Yeah. Seen those. Again, the vast majority of crackers - I say this from > a look at all the logs I have with me right now, and it is a LOT of logs - > don't know or care about OS versions, or banners, or whatever. So, it is > pointless to munge them out. *sigh* majority of crackers will use scripts like sshscan etc. which will *depend* on versions... even if the person using them is clueless. Munging banners is not totally useless... > And manage to break several other things while they are at it. Playing with > the ttl values to make a NT machine look like openbsd (or vice versa) is a > stupid waste of time and resources, and severely impacts performance, to > boot. Yes, it does sometimes (I would disagree with the term "severely" though) . And a stateful firewall, or any firewall to boot, will impact performance as a trade-off against security as well. It is just an option that depends on your own particular needs. What is your point ? > An unnecessary, and totally bogus security measure, which engenders a false > sense of security. Kind of like "the emperor's new clothes". Don't directly quote texts. What they meant was to not to rely on modifying headers as the only security measure. Security through obscurity is no security at all, I agree... but it doesn't means you should go on spewing all sorts of helpful info. :) > No... wrong example. What you are saying is "put a cheap brand of lock on > your door, and stamp Godrej Nav Tal on it, or maybe chisel out the lock's > brand name from the lock" *sigh* Trust you to take an analogy too far. :) ... No, what I *am* saying is that put up an iron-bar, chains, padlocks, a security camera, line the door with 2 inches of titanium, get a damned good, think lock *and* chisel out the lock's brand name from the lock. :) I never said to put up a cheap lock... I said get a good lock *and* chicel out the brand name still... Does that finally begins to get through to you ? :) When did I say, you should *not* patch the servers as well ? Stop putting words in my mouth just for the sake of winning an arguement that you are extending pointlessly... > > Did you by any chance, *really* read my mail thoroughly and stumble across a > > technique I referred to, called firewalking ? Search for it on google and > > than tell me your objections... > > I know. I saw that. My objection still stands. And pray thee what it is ? Using firewalk, he *can* get inside the network after discovering what kind of packets are being allowed through. > > --clue-- ... he doesn't *needs* to break into the firewall... go look up the > > OK - so he manages to find out the internal network details by firewalking. > Fat bloody lot of good it does for him, if he can't actually get into that > network. Which he can't, unless he manages to get into that firewall first. *sigh* go and read the full document again please... Firewalking is not that difficult a concept... > However, as the OP (nepali admin's) network is an RFC 1918 network, and > basically unreachable over the 'net, I still don't see your point. I am tired of asking you to read the full document of on firewalking again and again... care to actually go and do it sometime ? :) Regards, Abhi _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ linux-india-help mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/linux-india-help
