
Due Diligence? 226
ekr writes "The OpenSSL remote buffer overflows discovered at the end of July got
a lot of press here on /. But how many people actually fixed their
machines? I decided to study this question, and the results are kind of
depressing. Two weeks after the release of the bug, over two thirds of
the servers I sampled were still vulnerable. Even two weeks after
the
Slapper worm was announced, a third of the total servers
were vulnerable. The paper can be found here in
PDF
or
Postscript."
It's not just laziness... (Score:5, Insightful)
Re:It's not just laziness... (Score:5, Insightful)
Bottom line? Improve your security while you still have the rights to do it yourself.
Re: (Score:2)
Re:It's not just laziness... (Score:2)
There are tons of recent examples of computers accidentally storing critical info and records out in the open, much less secured by a barrier like OpenSSL.
Re: (Score:2)
Re:It's not just laziness... (Score:2, Insightful)
Re:It's not just laziness... (Score:2, Insightful)
Re:It's not just laziness... (Score:2)
By gaining access to many hosts on the net an attacker may launch distributed attacks against specific targets.
Imagine if sombody took down all top level DNS servers in such an attack. Today internet is part of the information infrastructure government and press use to communicate with the citizens. And if that information channel is at risk, governments will act.
Re: (Score:2)
Re:It's not just laziness... (Score:2)
Read as: it doesn't negatively affect the bonuses of the company execs or the board.
Re:It's not just laziness... (Score:2)
What I will say is that more distributions and operating systems should implement systems like apt, and vendors should keep up with patches as well as the Debian security team does. It really shouldn't be a big effort on any administrator's part. (Though that doesn't absolve administrators from having to be mindful of security issues.)
this is why... (Score:5, Funny)
Re:this is why... (Score:2, Interesting)
I'm starting to wonder if installing linux 0.99 wouldn't be such a bad idea.....
I wiped my OpenBSD boxes, reinstalled, patched (Score:3, Interesting)
I had some angst with RedHat boxes, though. The update mechanism didn't change the reported version number of OpenSSH. Annoying.
Re:I wiped my OpenBSD boxes, reinstalled, patched (Score:3)
Re:I wiped my OpenBSD boxes, reinstalled, patched (Score:2)
I think openbsd is wonderful and I buy their swag to support them. I've offered to mirror, but I think they might have enough.
Securing OpenSSL (Score:5, Interesting)
All of this points to the fact that there is a fundamental flaw in the way that the Open Source community is securing their software. Putting MD5 signatures on the same server that the software is available from isn't even close to secure - Dave Aitel of Immunity Security keeps hammering on this point in BugTraq. And we're going to see even more of this 'Upgrade Fear' as more and more distributions get trojaned - Slash is probably next on the list.
We need to look at existing, successful solutions to this problem (like Windows Update) and catch up. Now.
Re:Securing OpenSSL (Score:4, Informative)
Any decent distribution will do this work for you. That's what they're for after all. My Debian box was updated no more than 24 hours after I read about the problem, requiring nothing more that an apt-get update on my part.
Re:Securing OpenSSL (Score:4, Interesting)
Re:Securing OpenSSL (Score:2)
(...)
The key needs to be stored with a trusted entity like Verisign, which is how Windows Update and other commercial-grade updating systems ensure the integrity of their packages.
I find this a weak argument. A man in the middle attack would only get slightly harder if they put keys and packages on different (trusted) servers. Their just harder to fake than one server systems, but by monitoring regular patterns between all servers and a client you'd be able to assemble the right phony proxy (or whatever the cracker's using.)
Re:Securing OpenSSL (Score:2)
In other words no one place is trusted with the entire verification, one source or path might get compromised, but all of them simultaneously would take quite the effort. And perhaps if the keyholders were on a freenet sort of arrangement?
Re:Securing OpenSSL (Score:4, Informative)
No, but they have been cracked before:. html [attrition.org]
http://www.attrition.org/security/commentary/ms16
It doesn't take a whole lot of imagination to come up with some very scary scenarios of what could have been put there instead of "Hacked by Chinese!" After all, how many people visiting Windows Update are running versions of IE without known run-arbitrary-code security holes?
Re:Securing OpenSSL (Score:2)
"Trusted"? ROFLMAO.
Re:Securing OpenSSL (Score:3, Insightful)
0) How are you sure it hasn't already been trojaned?
1) Verisign just _claims_ to say the entity is who they claim they are, not that the entity is trustworthy.
2) Verisign screw up - certs issued to wrong people see Microsoft Security Bulletin MS01-017.
3) Microsoft screw up- there was an issue where the wrong types of certs could be used as CA certs. [Microsoft Security Bulletin MS02-050]
4) Network Solutions is part of Verisign. NS is not known to be very security conscious. If someone screwed both the certs and the DNS most people wouldn't notice.
5) Windows Update could become a trojan itself- make sure you read the EULA. e.g. one day you might see stuff like:
"You acknowledge and agree that Microsoft may automatically check the version of the OS Product and/or its components that you are utilizing and may provide upgrades or fixes to the OS Product that will be automatically downloaded to your computer"
And how sure are we that it will do it correctly?
Also note that Microsoft has recently said that they may break some apps.
So if windows update automatically downloads stuff which breaks some of your apps, it starts getting hard to distinguish it from a trojan.
--
I'm not saying Open Source is more trustworthy either. Most software isn't secure. Most Open Source software isn't secure. Most were never designed with security in mind - look at PHP - many of the features that make PHP PHP are actually bad for security. Look at ISC's range of software, see the history and the design/architecture of the software.
Unfortunately there are only very few who can program securely, and C just makes things worse - even fewer of the few can program securely in C.
Decent Distributions (Score:2)
If only we could all use decent distributions...
I'm sitting here on my beautiful, instantly up-to-date Debian box with a terminal open to a Solaris production server. Now I'm sure there's some way to get the binary distribution of Apache to install, but I'm not sure I'll be able to actually figure it out in less time then it would take me to configure and compile the source. Of course who knows how long that will take if I have to hunt down the Solaris packages for all those "useless" tools like a C compiler that aren't installed by default.
Yes, my 31337 h4x0r friends, this is one box that won't ever be secure until I convince the boss that SPARCs should be running Linux.
Re:Securing OpenSSL (Score:4, Interesting)
Sure something else might come along that can, but as you point out, if you're running a server that's been up a year, changing things is never comfortable, and if you know slapper isn't going to infect you, there's much less motivation.
Re:Securing OpenSSL (Score:3, Insightful)
That's exactly what the Blackhats of the world wanted to hear. Of course, they can use the exploit on you, log in, download their BINARY rootkits that don't need a compiler, and use your bandwidth to rape innocent sites like Slashdot with DoS attacks. After deleting your logs, they'll install a sniffer to see what other systems they can compromise using your NIC's visibility, and finally they'll deface your web site and pipe
Have fun!
It's really a damned shame you don't have a way of getting a securely signed OpenSSL update. While Debian has signature and key checking, it's all on a single point of failure server. You really need a trusted key that comes with the install media, but so far the only O/S which supports this is Windows. People who use Free software don't get install media and are pretty much up the creek...
Re:Securing OpenSSL (Score:3, Informative)
Re:Securing OpenSSL (Score:5, Insightful)
False. From the HLUG website [hlug.org] (the group that discovered the trojan):
Thanks to Antioffline.com for hosting us, and Gentoo's Portage system for catching the trojaned files via checksums.
Putting MD5 signatures on the same server that the software is available from isn't even close to secure
This is true though.
False (Score:3, Redundant)
Gentoo had the OLD checksums, which is the reason it was caught. Everyone who checked the new checksums got owned. The Gentoo suspicions were confirmed by checking the Google cache.
Gentoo basically caught this because they were so far behind the curve that they still had the old distribution. While it's a great argument not to use Gentoo, this kind of security-through-being-behind accident is not a security process, nor is it repeatable, nor should it be considered a success of the checksum system.
Re:False (Score:3, Informative)
Re:False (Score:2, Informative)
No right-minded packaging system would have merged in the MD5 changes from the site on blind faith without at least giving the old and new files a cursory diff. The only people that were fooled by the weak strategy of modifying the server's MD5sum file are people who used the equally weak strategy of downloading it at the same time as the file. Everybody with a reasonable checksum-checking build system is safe.
Re:Securing OpenSSL (Score:2, Interesting)
But that secret string is as good as the security of the server it exists in.
I have higher degree of trust for the gpg key that comes on the RedHat CD's from official RedHat boxes. Nothing against other distro's, RedHat is just an example.
narbey
Re:Securing OpenSSL (Score:2)
Haven't figured out what to do about mirrors yet.
Servers should disable themselves... (Score:2, Interesting)
It should warn the admin before it turns the server off, of course, but a broken unmaintained server is always better than a hacked server.
Re:Servers should disable themselves... (Score:3, Interesting)
Other than that, it's a good idea...
Re:Servers should disable themselves... (Score:2)
Re:Servers should disable themselves... (Score:2)
I didn't update the version of OpenSSH on a few of my boxes when the last advisory came out. I wasn't using a vulerable configuration (CHAP disabled) so I didn't really see it as an immediate danger.
Stuff like auto updates also has issues for the same reason. I can't think of an easy replacement for a resposible admin.
Re:Servers should disable themselves... (Score:2)
And BTW, dont forget that not only the owner of the server is harmed when a hacker compromises a server and starts a distributed DOS attacks...
And then the updater gets hacked (Score:2)
Not really a good idea... an equivilient to *gasp* "windows update" for terminal would be nice (RH8 has one, if you pay for or try RHN), where it automatically gives you a list of updates available and allows you to pick them in a dselect-style (debian) format, or something similar.
Re:And then the updater gets hacked (Score:2)
Shutting the server down is only the last resort, when the sysadmin does not react.
The most important advantage is, that the admin knows a) that there is a bug that affects a server he is responsible for and b) he gets a complete list of all affected machines.
Missing Correlation (Score:2, Insightful)
We Fixed Ours (Score:2, Interesting)
Should have upgraded (Score:5, Informative)
When to Patch (Score:5, Interesting)
WireX Communications, Inc. http://wirex.com [wirex.com]
and
Adam Shostack
Informed Security http://www.informedsecurity.com [informedsecurity.com]
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. [wirex.com]
Immunix: [immunix.org] Security Hardened Linux Distribution
Available for purchase [wirex.com]
Downstream Liability (Score:5, Informative)
In the same vein, readers might be interested in a presentation we did at RSA 2002; the topic was Downstream Liability for Attack Relay and Amplification [cert.org]
(A two-page summary is available here [whitewolfsecurity.com].)
We described a scenario in which an intruder compromised a system, used it as a jumping-off point, and subsequently caused damages to an individual. The paper focuses on the legal side of things; IANAL but the other two authors - Tim Rosenberg, J.D. and Ron Plesco, J.D. - are.
I also state my opinion, which is that "...patches should be installed no later than ten (10) calendar days after release of the patch by the vendor". Discuss.
Re:When to Patch (Score:2, Interesting)
Interestingly, if you look at the curves of people's behavior, you can see that the algorithm they're apparently following is pretty different from the one you recommend. Namely, people who are going to upgrade do so pretty much right away (mostly within 10-14 days of the stimulus that seems to have forced them to upgrade). The second interesting observation is that a substantial number of people seem to wait for a vulnerability to be released before they upgrade. One question that would be interesting to ask in the context of best practices would be how long on average vulnerabilities circulate before they are announced.
MS way (Score:2, Insightful)
It's not a bad idea after all, too bad you can't trust MS on anything (They use a good idea bundled with a bad one and a EULA that grants them too much)
The problem is they don't. (Score:2)
If you are a MS server admin you are always double checking TechNet and the other available sources because the delay between the patch on TechNet and the WindowsUpdate (critical area) can be as long as 3 weeks sometimes. Now that's sorry as can be. Lockdown tool is a joke.
Damn MCSEs (Score:5, Funny)
wait, did you say Linux?
Re:Damn MCSEs (Score:2, Interesting)
Re:Damn MCSEs (Score:2)
Due diligence. (Score:5, Informative)
This is too easy, folks. Subscribe to your distro's update announcement list, read your mail daily, and apply the relevant patches promptly.
It's really not that hard. A typical update for me is:
The window (Score:2)
However, some people take vacations, or go on project, or the such. Some people even sleep, and a window of vulnerability of only a few hours can create a serious problem. Your advice is perfect for those situations which need it the least - where the system is regularly serviced by a nearly-constantly-available administrator. This by no means covers all situations.
Re:The window (Score:2)
Re:The window (Score:2)
Re:The window (Score:3, Informative)
up2date runs with gpg signatures on all packages
and it checks all dependencies. And, since the packages are built by a company trying to guarantee you can run oracle on your box rather than a couple of dudes in a basement, the packages and their dependencies are correct and current.
--mandi
Re:The window (Score:3, Informative)
We have a cron job at 4am that mirrors the RH update directories (only downloads changes) and then emails us if there are changes. Then we install and test them on a test non-production server to verify first, then install on the production boxes, plus we already have the update(s) on a local box so 'rpm -Fvh ftp://localupdateserver/whatever.rpm' goes really fast (especially when you have a couple dozen boxes to maintain).
Re:The window (Score:2)
Re:Due diligence. (Score:2)
You forgot:
2.5. rpm --checksig whatever.rpm
YES. DO IT.
Run right out and get nessus. (Score:5, Informative)
It'll scan your machiens for known vulnerabilities and give you pointers on how to go about taking care of any that it finds. It's also got built-in updating to pull in the latest exploits.
The clients are even getting pretty spiffy these days, and the project has matured very rapidly.
Have we grown complacent? (Score:5, Insightful)
All of these years of rock solid security has made us complacent. We have to remember that, while Linux and OSS may be inherently secure, and Linux's modular design works as a fail safe against complete failure, we are still just as vulnerable if we don't remain vigilant.
Re:Have we grown complacent? (Score:4, Insightful)
I think this is a complete fallacy. Most default Linux installations, when left alone on a cable/DSL connection, have been hackable for years now. I can remember when I installed RedHat 6.2 on my gateway machine without having time to do the updates, and before midnight that night the box had been hacked.
I think that a lot of Linux users don't even realize when they've been hacked, either. Even the automated scan-and-exploit tools these days are becoming quite good at getting themselves installed on a system quietly. Unless you watch your logs on a daily basis, you often have no idea what is actually going on with your system.
FreeBSD binary updates (Score:2, Informative)
# pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/A ll/openssl-0.9.6g.tgz
Binaries installed -- no compilation required!
Weird misconception (Score:5, Insightful)
However, I read a stat somewhere that said that a large majority of security breaches could have been prevented by merely keeping up with patches. Therefore my philosphy is to create a patch schedule. And because I'm on Solaris things like OpenSSL are 3rd party to the OS, therefore I upgrade immediately. I rebuilt my solaris RPMs of OpenSSL that day and had it deployed to all my machines. Other things like GnuPG, IPFilter, OpenSSH, apache, sendmail, etc... they all need to be upgraded ASAP.
So all you Slashdot readers who posted that you have nothing to do but read Slashdot in that downsizing article [slashdot.org], get off your butts and start patching. That should keep you busy full time.
Re:Weird misconception (Score:5, Insightful)
Have your machines patch themselves. (Score:5, Informative)
We're all doomed... (Score:2)
I'm tempted to think that what's needed is a bunch of vigilantes who go accross the net and wipe any machine that's still vulnerable to any given bug after a while - but even this is not a solution, as some exploits/rootkits, after cracking a machine, install the fix to 'close the door behind them'.
Re:We're all doomed... (Score:2)
So we'll innovate and develop protocols and mechanisms which are resistent to DDOS attacks, and counter-worms that attack the malicious code and clean it out.
It isn't doomsday, its just another bump in the upgrade cycle.
Two words (Score:4, Insightful)
For the part-time server admin, who doesn't have time to read up on the latest patches, recompile all applications and their libraries from source, work out dependencies etc., the work of the debian security team is invaluable.
apt-get update
apt-get upgrade
Now, I know that this relies on the hard work of others; all I can say is, "thanks, I really appreciate it."
Disclaimer:
This post is not meant to be debian propaganda --- no doubt other venders are doing a good job too. The point is that this is the kind of problem that a package system solves, and solves well. (As long as there is a trusted source)
It's simple really (Score:3, Interesting)
rpm -Uvh
or
make
make install
(If I see these simplistic answers one more time I will puke)
Other things are seen as more important than security by the people that employ the sysadmins.
You can either
A) piss people off by not fixing their problems, argue with them about how some mysterious security shit is more important, waste valuable time, maybe get the patch done and avoid getting hacked. For this you're not rewarded, you're seen as inefficient - you didn't get some dipshit's email to work or something (and this dipshit may control your life in the organization).
B) Fix dipshit's email, do whatever else people think is imporant. Don't waste time making your case. Do mention that you should be working on this mysterious security patch thing no one wants to hear about though... Get hacked - holy SHIT everyone knows that's a bad thing, no more "can I please reboot your machine" no more questions at all, you get to take that piece of shit computer and wipe it clean, upgrade everything, piece of cake. Then for the next few days no one bitches that you are patching stuff all over the building - they WANT you too so they don't get screwed like the poor schlub that got hacked. End result of not be "Duly Diligent"? You are a hero, everyone knows you work way too hard, etc etc.
The age old problem for sysadmins - if you are truly good people think you don't do anything, stuff just works.
I have ten years experience at this, I manage sysadmins at my organization now. I spend a lot of time trying to cheerlead for the important work they do. Still we often have these kinds of problems. I've found it does work to sometimes just put a smile on your face and say "what, me worry?" and let some things break. Raises follow.
Fuck people, fuck them all.
Ah, a little sysadmin recovery makes me feel so much happier.
And no, none of us read your stupid email. Your lives are boring, face it!
-A Grouchy Young Man
It's not as bad as it looks, guys (Score:5, Informative)
Many webservers reporting themselves as "Apache 1.3.22" are in fact RedHat RPM based distros using the Apache RPM with the latest patches applied. (that fix the vulnerabilities mentioned)
Doing a simple "Head" WILL NOT pick up on this detail. To be really sure, you have to run exploit code, and that gets you into all kinds of sticky legal issues.
A while back, I wrote a quick script that did much as described in this article, only I went one step further and shot an email to whoever whois reported as the administrative contact.
I got alot of angry calls that morning, and I quickly stopped. I'd guess that of those sites that I figured were vulnerable, at least 8 of 10 were not.
Re:It's not as bad as it looks, guys (Score:4, Informative)
As described in the paper, I directly checked for the vulnerability. This allowed me to determine when implementations had been patched rather than upgraded.
Re:It's not as bad as it looks, guys (Score:4, Interesting)
so, if you're running a service scanner across your network, and it gets an OpenSSH_3.1 signature, that doesn't mean that that particular machine is vulnerable, it means the vendor decided that putting a new version on there compromised the stability of other software on the system.
So, if you're going to look for vulnerabilities on your network, make sure your scanner looks for the vulnerability, not a version number on the software. (and therefore don't use SARA as your scanner... "blah.blah.blah.blah may be vulnerable to the bend-server-over-the-table but we're not sure, so click this link...." UGH!)
--mandi
Re:It's not as bad as it looks, guys (Score:2)
It certainly seems to be the case that RedHat prefers to backport security fixes to the version of an application or library that they are already distritubuting, rather than upgrading their distribution to a new version. They are very conservative about maintaining backward compatibility within a major version.
The only exception I can think of to this is that their updates to RedHat Linux 6.2 now install bind9 rather than a patched bind8; I suspect that this may be either because of ISC's broken patch distribution procedures, or because they've moved to bind9 on their newer major versions and can't justify the work in maintaining bind8.
Sorry, but this is no shock (Score:2)
What's funny is that people spend so much time dealing with TCO issues comparing Windows vs Linux, when these little security snafus cost huge amounts of time. Especially for smaller operations who build their machines from scratch, rather than periodically roll up their own images and then patch sets against them, the time lost having to rebuild a set of machines wrecked by such issues could cost tens of thousands of dollars.
Companies, remember that, when you are presented with the extra cost of a security professional. Pay up front, or pay in aggravation later. Nothing beats having a pro-active advocate for security within your organization, if you have any significant IT assets.
Other configs "blacklisting" vulnerable versions (Score:4, Interesting)
Lots of admins are probably thinking, "well, I don't run a HTTPS service, so I won't bother with this yet." But if many months later they decide to run such a service, they may forget that they should get an updated version.
Pine, however, is something that lots of admins who don't run "servers" do upgrade with each release and it does make use of openssl. So this would be a place to catch such systems.
So you're the asshole ... (Score:2, Funny)
Click 'Install' (Score:3, Interesting)
By default, users only have to click one button (the default button) to keep their Mac-flavored BSD secure.
And they don't have to subscribe to mailing lists or be security geeks. They could be your mom and still get it right.
Not trying to rip on your mom.
I don't even know her!
No, seriously. That wasn't me, that time at the Quaker Steak n Lube!
Re:Click 'Install' (Score:2)
Obligatory reply. (Score:2)
I'm surprised you didn't get that one yet
methodology in paper is flawed (Score:3, Insightful)
Or the lack of certs in OpenSSL so no one checks. (Score:4, Informative)
If you can see https://www.amazone.com, your browser is badly broken. amazone.com points to amazon.fr - but you should match the cert to the DNS.
Opera on the Zaurus was also vulnerable. Apple doesn't install any certificates in their OS X or Darwin OpenSSL directory.
One thing that happened between SSLeay (the original project) and OpenSSL is that the certificate chains were NOT installed by default, so everyone had a library, but no way of checking certificates since you require root certificates to check the site certificate. A second thing, probably worse is that the old default was to return an error if the certificate couldn't be validated. Now the default is TO GIVE NO ERROR IF THE CERTIFICATE CANNOT BE CHECKED. It would be better to give an error that would have to be overridden, which would cause developers to have to take a look and to actively disable security.
Curl was the only one that included any checking, but it required manually installing certs and specifying an option to turn it on. It would SILENTLY connect to SSL sites without security.
Mozilla was fine, and Konqueror fixed any problem it had, but the Opensource community should be embarrassed since the rest of the browsers security was not just flawed like IE, but DISABLED without any notice to this effect or NONEXISTENT.
gah (Score:3, Funny)
If you're depressed by that, you might want to see a psychiatrist. I mean, you shouldn't have that kind of reaction to such a minor issue.
Why we keep getting these bugs (Score:2)
There are other bugs out there - a popular attack is to try to abuse dotdots in path names, which there's more excuse for forgetting to check, and there are things like race conditions that are genuinely hard to check for (e.g. what happens when somebody's ripping up your temp files while your program is running), though checking return codes on system calls and doing something appropriate about failures is a good start.
Suggestions? (Score:2)
I personally dislike C - programming securely in C feels like clearing a minefield inch by inch.
So any suggestions?
Haven't seen docs on programming securely in Lisp. Many Lisp coders like to mix data and code, that seems scary, but I'm very very new to Lisp so is that safe? There's little out there to suggest it is or isn't.
Forth seems to have about the same problems as C - buffer overflows. Data-code mixing (but a Forth coder said a solution is to keep dictionaries separate).
Many of the other languages are more high level, very useful and recommended for certain apps, but not suitable for the low level system programming area.
The languages have to be able to hook to C apps very easily.
Sysadmins need to pursue intrusion attempts (Score:3, Interesting)
The system admin wasn't pursuing these reports. I asked why.
His response - "Well, those are attempts to exploit a Windows server, and this is a Linux box, so they don't matter."
I made the counterpoint "If one of your system was infected, wouldn't you want to be told about it?"
If every systems admin would take the time to track down the Code Red attempts on their systems, and notify the responsible parties whereever possible, then a lot of the unpatched systems would be shut down (if not by their administrators, then by the ISP supplying connectivity).
I just don't understand an admin with an attitude like that.
Re:Sysadmins need to pursue intrusion attempts (Score:2)
Yes, I would. But how many of these reports did your sysadmin get? Probably quite a few, daily. What would his manager say if he spent most of his time helping other people administer their systems instead of doing his job? If it's an occasional occurrence, you can help, but the infections are endemic, and helping a few is unlikely to change anything, as there are thousands of new virus cultures sold every day...
Re:Vulnerability Check (Score:5, Informative)
Well if you'd read the PDF instead of skimming it, you would have seen this:
Thus, we can simply connect to the HTTPS server and issue a HEAD request. The server responds with an HTTP header containing the Server: field and hence the answer we desire:
Server: Apache/1.3.26 (Unix) mod_ssl/2.8.10 OpenSSL/0.9.6
They then went on to verify that SSLv2 is not disabled, but they mention later in the paper that on only 10 hosts was this done.
Theoretically you could change the response to report the more recent version which would make this check innacurate, but why would anyone bother doing that? Far easier to just upgrade OpenSSL.
Re:Vulnerability Check (Score:4, Interesting)
Re:Vulnerability Check - An easy way (Score:2)
One easy way I discovered to do this, assuming you've got the curl library installed, is to issue this from the command line:
curl -I [your_url__or_hostname_here]
Probably old hat to most of this group, but it proved an easy way to check several servers quickly. It's also handy if you want to make sure that your changes to Apache's httpd.conf (for ServerTokens and ServerSignature) actually "took".
Re:Vulnerability Check (Score:2)
I sure as hell can't think of any.
In fact I am going to go over my system here and make damn sure that I stop any such foolishness...
Re:Vulnerability Check (Score:2)
Re:Vulnerability Check (Score:2)
as soon as I get this pineapple up my ass I'll be on it!
Re:Vulnerability Check (Score:2)
Server: Apache/1.3.26
Set ServerTokens [apacheref.com] to "min" in httpd.conf. Why tell anybody anything you have no use in their knowing? Sure, there are other ways they can test your vulnerability. But some of them will look here first, and just go elsewhere if you're not baiting them with what they're looking for.
Re:Vulnerability Check (Score:4, Interesting)
Re:Vulnerability Check (Score:2)
Actually I did really _read_ the parts you quoted. My question was more about laws. Doesn't probing if it is vulnerable (i.e. actually "playing the attack") count as attacking?
THIS was what I was asking. But thanks for beeing so friendly and trying to allege me I am a stupid cocksucker.
Cheers.
Re:Vulnerability Check (Score:2)
One also tends to sleep well at night afterwards.
Re:Gentoo! (Score:3, Funny)
Re:SSH open on the internet (Score:3, Funny)
Granted SSH does use OpenSSL too but, this isn't about exposing SSH to the internet. It's about OpenSSL your trusted port 443.