On Wed, 13 Jan 1999, Linux Mailing Lists wrote: > Doesn't sound very good to send the configuration of your machine over the > internet by email. What if someone gets it and use that information to > know the vulnerabilities of your server? Using your service he would know: > > * Which Software you have installed in your server > * Which patches you have applied (and what's more interesting, which > patches you *haven't* applied) In my experience there is always a patch that have not been applied ;-) I have not applied prtdiag patches on some of my machines, even though they are listed as recommended. Why? prtdiag is useless on SS10 or SS20, and only seems to apply to newer boxes. However there is a reason why some patches are not made recommended and shipped with the default jumbo cluster. I recall the embarrassing moment of installing a stand-alone kernel patch and having the system panic on boot-up, as a SS10 was not exactly an E10000 server for which the patch was designed. patchdiag was claiming that I absolutely have to install it to bring my systems up to date, though. This /is/ a part of the problem - there are so many hardware configurations and so many different patches that any automated service will have problems figuring out if you should (or should not) patch something. What if I have SENA installed? What if I have some bits of other uncommon hardware in the box as well? Will patches work together OK? Ultimately it seems to me that hardware in the box have to be consulted too (and not just the software packages installed. I can recompile and install the latest and greatest sendmail on my own, without updating the pkg list, and then have it overwritten by the next "Official Sun Sendmail Security Patch", which will look as a newer package, but in fact be older software) before the patches are installed, and I hope that the next version of patchdiag will be asking for the output of prtconf before making a descission what patches should or should not be installed on an given machine. After all, why do I need to patch something that is not used by the system in a first place, like PPP modem support, while new drivers for hardware which I /do/ have do not get installed by default? Guess the idea is that all the tools for keeping the system up to date are great, but they are not a substitution to a clear head and reading of the patch descriptions too. Automated, one size fits all updates just do not cut it, unless you have 50 (or more) of identical machines, with identical software on them all running the same OS revision. But how realistic is this, and if it is, are you sure that your users (whom we all learn to love) have not installed something on their own, and not running their own services on unpriveledged ports? > * The OS version, platform, etc... Such things can be pretty closely guessed with other freely available tools, like Fyodor's nmap (which will not be able to distinguish between SunOS 5.6 and SunOS 5.7, but will tell you if the remote system is Solaris 2.5.x). There are still few good alternatives to well configured firewall/proxy or bastion host as the entry point into your network. > * Your server's name > Mmmmmmm... Just the information someone would need to hack your system :) It seems to that this is not that easy even with this info. Yes, I have seen Solaris boxes that bleed services all over the local LAN, and for which this is generally true. But from my experience any more or less competent admin would close most of the gaping remote root holes just by installing the lates jumbo patch right after the system's installation, commenting a bunch of lines out in /etc/inetd.conf, and installing ssh, in which case the information is only useful for local exploits (but in which case you can run most of those tools by hand yourself) or for DoS. The idea seems to be that the less ports are open, the better it is for the system and for admin's peace of mind. > What about making public the program you use, to run it locally? > > (showrev -p ; pkginfo -l)|yourniceprog > I haven't tried the above mentioned service for above mentioned reasons, but from the information requested, this seems awfully like a perl wrapper for Sun's own patchdiag script with the -p option and showrev and pkginfo outputs fed to it in the proper way. If that is the case, there might be different copyright problems with making this script accessible to people without Sun support contract. However if that is the case, server name means nothing at all to the script (as it should only use it for cosmetic reasons) and anything can (and should) be plugged in in the right place. I have to admit that the above paragraph is pure speculation, though, and I would be interested to see how the original poster have implemented this service. > Greetings, > > Sergio > > PS: Who knows who is really receiving your information at > pdiagat_private ;) ;-) You never know indeed. And one can only trust so far in this world.... //Stany -- +-----------------------------------------------------------------------------+ | Stanislav N. Vardomskiy - Procurator Odiosus Ex Infernis[TM] | | This message is brought to you by letters jey, ow, el and tee. | | Jolt! For all the sugar and twice the caffeine. | +-----------------------------------------------------------------------------+
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:28:57 PDT