Slashdot Mirror

WinXP EULA: "shouldn't be ever used as a webserver or fileserver"

Damned good idea

Opaserv

network.vbs

There were some others I found before, but I'm not finding them now, probably need to refine my search, but I don't have the time atm.

Here's some more reading material...

911, etc.

port scan

I spent some time reading up on how buffer overflows were used for exploits on this port, UDP packets, and so on. I'm not convinced this is innocent activity, particularly since I do have a firewall configured and don't see any outgoing traffic.

Learning about attacks is an ongoing thing for me and until I have all the facts, or enough of them, I'm leaving it my firewall to keep intruders out. I have seen bursts, usually on weekends when I assume more infected computers have been turned on and the worms are active. At various times I've had as many as 100 hits within 2-3 minutes.

Since I have no current reason for anyone on the internet to access my system, I believe a complete lockdown is a good position to start with. If I put it on a high-speed connection, with fixed IP and fire up services, then I'll allow ports as necessary.

It's been nearly six months since the SANS/FBI "Top 20" Internet vulnerabilities list was updated. Looks like it's time for another update as the sendmail section contains the following line:

Sendmail has not had a 'high' severity vulnerability in more two years

Is this latest considered 'high' vulnerability? If you have never read this report, I highly recommend it for both Unix and MS system admins.

Green cards scam's, credit card fraud, theft on many levels would be wiped out.

Having a central repository of all citizens with their biometric data may be a problem, but thats another story

"Even if you read "3-4" to mean 5 orders of magnitude, that means that the factoring cost is reduced by a factor of 100,000. In other words, a 1024-bit key will only be as safe, after this cost-reduction, as a 1007-bit key is today for the same amount of money."

You didn't read the primer we linked to :)

An increase in 3 bits in symmetric keys corresponds to an increase of about 160 bits at this size of asymmetric key. As I understand it (and this is probably an oversimplification), this is because while you can pick any symmetric key you want, your choice of asymmetric key is limited to prime numbers.

So a change of 4 orders of magnitude in cost-effectiveness would be about the same as shaving 13 bits off a symmetric key. But if the table credited to Lenstra and Verheul is correct, that would correspond to reducing a 1028-bit asymmetric key's effectiveness to 488 bits.

I think.

I didn't see anyone mention any of the sans training or any of the GIAC certs. I attended the sans conference in SF last December. I was very impressed with the level of depth in the training and the level of knowledge all the instructors have.

on March 7th/8th, SANS is having another 'IDNET'
event. The target boxes are preconfigured with
known vulnerabilities for this even. It is part
of the vendor expo at SANS 2003 in San Diego.

usually, there are some nice prices and admission is free or cheap ($10-20).
details

Read about it here, including a nice set of pros and cons here

I'm reading this book now. Surprisingly, it isn't so much about technology and security. Instead, it is more about understanding humans. Despite the sterotype that geeks have for being socially incompetent, to be a truly good hacker using social engineering, you have to be good socially. Maybe not great, but pretty good. And, you need to know the right language and the right people to communicate with. Mitnik does a great job with this stuff and I am really enjoying the book. (However, I'm not so sure his tactics will work as well as they did a few years ago.)

Here are some pretty good resources for learning more about social engineering:

Social Engineering: What is it, why is so little said about it and what can be done?

Social Engineering Fundamentals, Part I: Hacker Tactics

Social Engineering: The Human Side Of Hacking

The majority of the successful attacks on operating systems come from only a few software vulnerabilities ...

While the list is (appropriately) in OS-neutral and scripting language-neutral terms, the way to correct these problems is specific to the OS, webserver and scripting langauge you are using. So the next question is: what are the resources for addressing these issues, specifically, for particular OSes, webservers and languages?

For those taking the MS approach (and flame it if you want, but IIS isn't about to stop being the #2 web server overnight, so it might as well be done as securely as possible), I can recommend the following two guides from SANS:

Securing Internet Information Server

and

Windows 2000/XP Scripting For Security

These are listed as "course books" on their site, but they stand alone as guides for those who already have some background and knowledge. And if you don't have much background and knowledge, SANS courses are very good. (In fact, just about everything at the SANS website is valuable for the IT professional who wants to know more about security -- which ought to be all of us.)

So, stop just posting that these 10 problems are old news, and post the resources you use (or learned from) to avoid these problems yourself on your platform of choice, so the many (majority?) still making these mistakes can learn to avoid them too.

While the list is (appropriately) in OS-neutral and scripting language-neutral terms, the way to correct these problems is specific to the OS, webserver and scripting langauge you are using. So the next question is: what are the resources for addressing these issues, specifically, for particular OSes, webservers and languages?

For those taking the MS approach (and flame it if you want, but IIS isn't about to stop being the #2 web server overnight, so it might as well be done as securely as possible), I can recommend the following two guides from SANS:

Securing Internet Information Server

and

Windows 2000/XP Scripting For Security

These are listed as "course books" on their site, but they stand alone as guides for those who already have some background and knowledge. And if you don't have much background and knowledge, SANS courses are very good. (In fact, just about everything at the SANS website is valuable for the IT professional who wants to know more about security -- which ought to be all of us.)

So, stop just posting that these 10 problems are old news, and post the resources you use (or learned from) to avoid these problems yourself on your platform of choice, so the many (majority?) still making these mistakes can learn to avoid them too.

While the list is (appropriately) in OS-neutral and scripting language-neutral terms, the way to correct these problems is specific to the OS, webserver and scripting langauge you are using. So the next question is: what are the resources for addressing these issues, specifically, for particular OSes, webservers and languages?

For those taking the MS approach (and flame it if you want, but IIS isn't about to stop being the #2 web server overnight, so it might as well be done as securely as possible), I can recommend the following two guides from SANS:

Securing Internet Information Server

and

Windows 2000/XP Scripting For Security

These are listed as "course books" on their site, but they stand alone as guides for those who already have some background and knowledge. And if you don't have much background and knowledge, SANS courses are very good. (In fact, just about everything at the SANS website is valuable for the IT professional who wants to know more about security -- which ought to be all of us.)

So, stop just posting that these 10 problems are old news, and post the resources you use (or learned from) to avoid these problems yourself on your platform of choice, so the many (majority?) still making these mistakes can learn to avoid them too.

• June 2, 2000 - E-Commerce Times - 'Top 10 List' Reveals Internet Security Flaws"
• October 21, 2001 - Tech TV - FBI Releases List of Top 20 Computer Risks
• Monday, September 30, 2002 - PCWorld/Yahoo - List of Top 20 Software Flaws Due
• October 17, 2002 - SANS/FBI - The Twenty Most Critical Internet Security Vulnerabilities

Remote OS detection via TCP/IP StackF ingerPrinting

TCP/IP Stack Fingerprinting Principles

Graphing Randomness in TCP Initial Sequence Numbers

Security Problems in the TCP/IP Protocol Suite

System Fingerprinting With Nmap

Remote OS detection via TCP/IP Stack FingerPrinting

If you don't have the $100k to sign up for
Symantec, check out DShield.org and The Internet Storm Center to get it all for free, including the pretty pictures for the boss.

Phrack is perhaps a good example of the line between black hat and white hat "hackers" being blurry. The articles are informative and well-written, and by intelligent people, not your typical 14 yr old cracker on ecstasy who launches DDOS attacks from haX0r'd machines. I've done a compilers course, but still found a lot to learn about compilers from a phrack article on buffer overflows. Also check out the essays at SANS .

> CIPE

I have skimmed over CIPE.php So.. if I am reading this correctly, this would allow a lightweight VPN over an arbitrary public AP? (getting hung up over the "how is routing handled?" part)

There's plenty of information avaiable on how to tighten a Solaris install. Start with a checklist like this and customize it for your needs. I don't think its four hours of work though.

BTW, I do hope you know about Sun Freeware to pick up freeware for Solaris.

get a free account to the SANS Reading Room; they have whitepapers galore and a few more applied guides, including some on nessus and snort, iirc. with a good theoretical background, you should be able to proceed to use documentation for each product you choose in a mostly referential manner.

The guy is asking a question here!

You will find most of what you want to know at the SANS Reading Room site. This is an invaluable resource for your line of work.

SANS briefly used an obnoxious password scheme to access this archive, but this has been - thankfully - removed.

Specific to your needs is a "waiver" style document, to be signed by the technical and management authorities resposible for the network you are testing. It defines the behaviors to expect from a consultant and the expectation of impact by the client. A good example, by GIAC candidate Nancy Simpson, is provided here: PENETRATION TEST SAMPLE RULES OF BEHAVIOR .

This is in the Reading Room, under the section Penetration Testing.

You can adapt some of this to your needs - keeping a Lawyer on retainer is a bit steep for a single, independant contractor these days, with contracts like provebial hen's teeth. Insurance isn't probably a bad idea though.

The guy is asking a question here!

You will find most of what you want to know at the SANS Reading Room site. This is an invaluable resource for your line of work.

SANS briefly used an obnoxious password scheme to access this archive, but this has been - thankfully - removed.

Specific to your needs is a "waiver" style document, to be signed by the technical and management authorities resposible for the network you are testing. It defines the behaviors to expect from a consultant and the expectation of impact by the client. A good example, by GIAC candidate Nancy Simpson, is provided here: PENETRATION TEST SAMPLE RULES OF BEHAVIOR .

This is in the Reading Room, under the section Penetration Testing.

You can adapt some of this to your needs - keeping a Lawyer on retainer is a bit steep for a single, independant contractor these days, with contracts like provebial hen's teeth. Insurance isn't probably a bad idea though.

The guy is asking a question here!

You will find most of what you want to know at the SANS Reading Room site. This is an invaluable resource for your line of work.

SANS briefly used an obnoxious password scheme to access this archive, but this has been - thankfully - removed.

Specific to your needs is a "waiver" style document, to be signed by the technical and management authorities resposible for the network you are testing. It defines the behaviors to expect from a consultant and the expectation of impact by the client. A good example, by GIAC candidate Nancy Simpson, is provided here: PENETRATION TEST SAMPLE RULES OF BEHAVIOR .

This is in the Reading Room, under the section Penetration Testing.

You can adapt some of this to your needs - keeping a Lawyer on retainer is a bit steep for a single, independant contractor these days, with contracts like provebial hen's teeth. Insurance isn't probably a bad idea though.

And here is the list of vulnerabilities that they are talking about.

The register points to the 2002-09-27 SANS/FBI top 20 most critical internet security vulnerabilities. 2000's top vulnerability, BIND weaknesses, dropped to Unix number 3 last year, and number 9 this year.

They left Outlook and it's derivatives off the Windows list. Nevermind the root VBS cause

This worm, and others which have followed it, took advantage of Windows Scripting Host (WSH), which permits any text file with a ".vbs" extension to be executed as a Visual Basic script. With WSH enabled, a typical worm propagates by including a VBScript as the contents of another file and executes when that file is viewed or in some cases previewed.

I have to disagree with their evaluation of item W10, Windows Scripting Host. They're essentially blaming it for improper use by mail clients (I never heard of anything other than Outlook or Outlook Express having problems with .vbs scripts run through WSH -- Word macros, while VB, are not VBScript, and don't go through WSH. IE embeds vbscript and jscript, again not through WSH, so while I guess you could download a .vbs, you'd have to be a moron to tell it to run automatically). Sure, they do include the line, "While administrators should always keep applications like browsers, mail clients and productivity suites patched and updated, patching these applications to eliminate their susceptibility to a particular worm is an incomplete (and no better than reactive) solution to the risks posed by scripting," but that's paramount to suggesting all scripting is bad. Would it be bash's fault if mutt auto-ran .sh extensions? Or would it be perl's fault if mutt did the same thing with .pl extensions? No, it wouldn't, so to fault WSH for Outlook/OE problems is pretty ludicrous.

WSH is a very useful tool when used properly, just as bash or perl are very useful when used properly. Misuse by one or several applications does not mean the tool itself is at fault. A better thing to blame would be running as administrator (in NT-based Windows systems) full-time, rather than as a non-admin user. Again, this is directly parallel to running as root 24/7 in a unix system. You wouldn't do it there, so why do it in Windows? (Win9x is dead, let it rest in peace.)

#8 is listed here.

If you are using IE, your computer is vunerable to numerous security breaches.

If this is installed on EVERY Windows computer by default, I believe that this should be rated higher than those vunerabilities in applications that are only installed by default on SOME Windows versions (IIS).

What happened here is that the submitter read or heard something about a wireless honeypot being used to trap wardriving/walking etc. activity, and thought that the term just meant a free access point. He's confused.

It isn't true. See Intrusion Detection FAQ

You might want to take the one-day class on securing Windows 2000 currently being run in various cities by the SANS Institute or you won't have to worry about having secure remote access to your server(s) -- someone else will.

It won't help to have the best encryption in the world securing your front door to a system that has 120 vulnerabilities in the default install!

It's true that the Bush Administration has made some amazingly stupid blunders. However, this is not one of them and the large volume of ignorant, knee-jerk remarks being made in this thread is proof to me that slashdotters are just as capable of mindless FUD as our favorite corporate punching bag.

I'm a security professional who happens to know three of the people in the White House office of cybersecurity. All three have a great deal more clue than anyone posting on this forum realizes. Judging from the maturity level of the posts I've seen here, I think it's safe to say that these gentlemen were securing computers when most of you were running around in diapers.

Let's deal with some facts here. Please.

The default install of Windoze 2000 contains at least 120 known vulnerabilities [source: SANS Institute].

Many of us security professionals have had to deal with Neanderthal bosses unwilling to allocate to us the time and/or people to properly secure our connected systems.

So the best minds among us some in industry, some in academia and some in Government have been working for the last couple of years or so on a consensus standard that defines minimum-acceptable and best-practices levels of security for various operating systems (FWIW, the Unix document was finished a long time ago). And yes, some of those best minds are working for the US military, the FBI and the NSA.

With this standard in hand, and a tool to quickly and easily evaluate our systems, many of us believe that we now have something we can take to clueless bosses and say, THIS is the standard! Are we going to meet it, or not?

Those of us in the security community believe that the US government is the best vehicle for publishing and communicating these standards. For one thing, Government agencies have been dragging their feet at complying with Congress' demands that they secure their systems, citing (among other things) the lack of a standard for secure configuration.

But there is another, even more serious issue: millions of clueless Americans connecting home PCs to the Internet through high-bandwidth connections, oblivious to the collective danger that millions of potential DDOS zombies pose to the nation's critical infrastructure. I mentioned this to Dick Clarke (White House Chief of Cybersecurity) last month in a meeting with him, and I for one am damned glad to see that he's doing something about it. He's basically taken the Windows 2000 security consensus document and vulnerability scanner (which are finally ready) and taken it to the masses.

Let's face it, we have people out there who couldn't get a clue if they were standing in a field of clues during clue mating season wearing clue musk, but if the President of the United States tells them they need to secure their home computers to make America safe, then they'll By God do it!

The idiotic anti-government paranoia I've seen expressed in response to this is, frankly, highly inappropriate. Some of you need to grow up and learn not to piss in the village's well.

Of the stuff posted so far I'd say the best advice is subscribe to bugtraq read hacking exposed and the cryptogram news letter. plus.. SANS have shitloads of pretty decent stuff in thier reading room rr.sans.org Old issues of phrack contain really informative stuff like aleph1's 'smashing the stack for fun and profit' And Bruce Schneiers book 'secerts and lies' is quite good in a broad overview kind of way.

Serveral of the "security agencies" in Canada offer courses which are fairly strong overviews. The RCMP technical security branch offers a number of workshops for free. I have taken the 4 day IT security officer and 1 day malacious code course and both were very good overviews.

The Communications Security Establishement (Canada's NSA) offers a number of courses quite cheap. This is a good place to start and often provide a wealth of resources for additional learning. I would look into whether the same exist in your country...

SANS reading room boasts 1300 research papers. Here are some other places for reading off the top of my head:

@Stake
phrack
antionline
securityfocus

There are tons more if you look

Sig, Shmig...who needs one

I'm in Guyana, South America so the cost of the conferences with airfares etc is way outside the budget.

I agree that the literature is a good starting point - the reading room at SANS is a mighty fine
resource.
When I'm ready (read "can do no more without expert help") I'll look into courses/conferences.

Doesn't matter. A black hat will ignore the sticky note and just use the default or backdoor BIOS password.

In the computer security field, you have to jump through all sorts of hoops to preserve evidence if you want to prosecute a break in. Usually you have to pull the disk from the machine (without altering it) and lock it away. Trying to figure out what happened is a good way to make the crime unprosecutable. Shouldn't there be a similar requirement for this type of evidence gathering? Or do we just trust whoever answers the phone at some ISP to copy the correct files and correlate them with the correct users and never make a mistake. Here is one link, although not exactly what I was looking for.

Pardon me, but as, for example this document, and multiple others state. Fingerprint ID has a false positive identification rate just under one percent. And gross biometric accuracy of 1:500.

Simple mathematics applied, when the store gets some success, and it's customer base exceeds 500 or let's say even thousand - you are likely to always match someone else's fingerprint.

Sincerely, fingerprints were not made for shopping. :))

Wrong... The DoD using Lotus Notes and Exchange. Both are approved for use in the official Defense Message System. The Army has chosen Lotus Notes, while the Air Force uses Exchange. Not sure about the Navy.

The first step (really!) is to get a security policy in place. This really doesn't have to be anything special-- but it does need the buy-in of ALL groups affected (sysadmins, developers, marketing, sales, executives, etc.) That's really the only hard part.

Probably the quickest way to get started is to head to the SANS security policy project and adapt their sample policies to your company. This is one of those rare cases where it's more important to get something in than it is to get it right the first time. Policies can be changed fairly easily-- but you don't want to go to all the trouble to implement a secure environment only to have someone on the inside fighting you every step of the way.

Now the fun part-- actually securing your systems. Here are some pointers on places to start:

1) Review the SANS "top 10" security vulnerabilities and make sure they're covered.

2) Review Lance Spitz's excellent collection of host security information and make sure to follow his recommendations.

3) Make sure your firewall rules are set up with the security best practice of "minimum access to get the job done". Far too many firewalls allow traffic they shouldn't.

4) Get NMAP, a network mapper, port scanner, and OS identifier and run it from the Internet to your exposed (i.e. DMZ) hosts. Also run it from your exposed hosts to your internal network to validate that only the traffic that should get in can get in. (The traffic allowed back in from your DMZ should be very little, preferably none.) If you find anything that is inconsistent with what you think should be happening, check your firewall rules again.

5) Grab a copy of the Nessus security scanner and run it against your newly secured systems. If it finds anything, read the description of the problem and see if it's something you can fix. You can bet that everything you find here will also show up on your "security audit" since most "audits" are just someone running a tool like this and then feeding the output to the consultants to make it all pretty for management.

6) You should have most of the obvious, widespread holes plugged by now. This would be a good time to get some sysadmins out to some classes. Verisign has a number of excellent general Internet security classes. I'm sure there are lots of other good places, too. I was pleased with Verisign because of their Internet focus. Too many security classes only concentrate on host security and neglect network security.

7) Get the application developers at your site to read and follow Dave Wheeler's writing secure programs guidelines. This is a lower priority than OS/network security since these holes are likely to be specific to your site only. Only a determined hacker is likely to find and exploit them-- however exploiting application bugs/holes can severely disrupt your business. What happens when an electronic data interchange transaction gets bogus data inserted? How far will that bogus information make it in before it's detected? In the worst case these bugs could result in people getting free products/subscriptions, stealing credit card info, or destroying data inside your systems.

8) Now it's time to get that audit. They will be able to tell you what you missed in the previous 7 steps. Why wait so long? Most places will keep looking until they find something to report. If you do this too soon, the subtle security problems will be lost in the noise of all the obvious problems the previous 7 steps would have fixed. If you do this last, only the "hard" problems are left for them to find.

Remember above all that this is an ongoing process. Keep current on your patches, and repeat all the above steps regularly to keep all the bad guys away.

The first step (really!) is to get a security policy in place. This really doesn't have to be anything special-- but it does need the buy-in of ALL groups affected (sysadmins, developers, marketing, sales, executives, etc.) That's really the only hard part.

Probably the quickest way to get started is to head to the SANS security policy project and adapt their sample policies to your company. This is one of those rare cases where it's more important to get something in than it is to get it right the first time. Policies can be changed fairly easily-- but you don't want to go to all the trouble to implement a secure environment only to have someone on the inside fighting you every step of the way.

Now the fun part-- actually securing your systems. Here are some pointers on places to start:

1) Review the SANS "top 10" security vulnerabilities and make sure they're covered.

2) Review Lance Spitz's excellent collection of host security information and make sure to follow his recommendations.

3) Make sure your firewall rules are set up with the security best practice of "minimum access to get the job done". Far too many firewalls allow traffic they shouldn't.

4) Get NMAP, a network mapper, port scanner, and OS identifier and run it from the Internet to your exposed (i.e. DMZ) hosts. Also run it from your exposed hosts to your internal network to validate that only the traffic that should get in can get in. (The traffic allowed back in from your DMZ should be very little, preferably none.) If you find anything that is inconsistent with what you think should be happening, check your firewall rules again.

5) Grab a copy of the Nessus security scanner and run it against your newly secured systems. If it finds anything, read the description of the problem and see if it's something you can fix. You can bet that everything you find here will also show up on your "security audit" since most "audits" are just someone running a tool like this and then feeding the output to the consultants to make it all pretty for management.

6) You should have most of the obvious, widespread holes plugged by now. This would be a good time to get some sysadmins out to some classes. Verisign has a number of excellent general Internet security classes. I'm sure there are lots of other good places, too. I was pleased with Verisign because of their Internet focus. Too many security classes only concentrate on host security and neglect network security.

7) Get the application developers at your site to read and follow Dave Wheeler's writing secure programs guidelines. This is a lower priority than OS/network security since these holes are likely to be specific to your site only. Only a determined hacker is likely to find and exploit them-- however exploiting application bugs/holes can severely disrupt your business. What happens when an electronic data interchange transaction gets bogus data inserted? How far will that bogus information make it in before it's detected? In the worst case these bugs could result in people getting free products/subscriptions, stealing credit card info, or destroying data inside your systems.

8) Now it's time to get that audit. They will be able to tell you what you missed in the previous 7 steps. Why wait so long? Most places will keep looking until they find something to report. If you do this too soon, the subtle security problems will be lost in the noise of all the obvious problems the previous 7 steps would have fixed. If you do this last, only the "hard" problems are left for them to find.

Remember above all that this is an ongoing process. Keep current on your patches, and repeat all the above steps regularly to keep all the bad guys away.

External audits are good because they bring in experts who focus on finding vulnerabilities in your network. These experts will come armed with a variety of vulnerability assessment tools to perform their audit. The only problem is that it will almost always happen less frequently than vulnerabilities are discovered, so this should only be 1 part of the overall solution.

You should adopt this practice internally, because if the tools are set up to check for vulnerabilities, you can be much more proactive about finding them than simply by scheduling consultants to come every few weeks, months, year. There are a variety of tools available, both freely and commercially.

A good tool will be updated frequently, check a lot of bugs, including the most critical (SANS Top 20, BugTraq, CERT.

Free Tools
SATAN -- Security Administrator Tool for Analyzing Networks
SAINT -- Security Administrator's Integrated Network Tool -- based on SATAN, GNU
SARA -- Security Auditor's Research Assistant -- similar to SATAN/SAINT check the Freshmeat page
NESSUS -- another free tool

Commercial Tools
ISS has a variety of tools avaiable depending on your needs
NeXpose -- try the free demo, great ui, demo only lets you assess 1 IP at a time though :( Here is a review
A Networking Computing article on Vulnerability Assessment tools. Reviews many of the major vendors (so I won't list them all). Includes some of the free tools.
Here is another overview of security tools to get you started.

Telnet isn't evil if it's tunneled through an encrypted VPN connection which is a breeze to setup in Windows.

Telnet is still evil even with a VPN tunnel.Suppose I break into your box, and wish to get more passwords. I install a sniffer on your box. I get more passwords, since the telnet connection is _not_ protected by the VPN when the packets hit the interface of the box you are connecting to, or leave the box you are connecting from. This may also work if i break into a different box on the same network - note that a switch (as opposed to a hub) will not necessarily prevent me from getting packets bound for other boxes - see SANS for more info Telnet is bad - whether you're running a *nix or a Windows*. You have to remember that a potential attacker may be local.

Military-grade encryption has its weaknesses, too. Especially considering it uses "only" 80-bit keys. And ooh dose pesky cwackews!

Do I have to post this again to remind you zealots that *nix is not the ultimate in security?

NetSol insane? Maybe just concerned with security. But don't let hard numbers fool you, just go ahead and believe what Linux zealots tell you.

>Or compromise the servers where you get your .debs.
>...
>Obviously nobody would have installed (and be updating) a package called "rootkit," but the scripts could be piggybacked on any security update.

First, it doesn't have to be installed through the updates to the server. It's probably actually easier to find some misconfig'd server or vulnerable daemon out there, establish remote access, and install the rootkit from ther. But you do have a point and that's why I just subscribe to bugtraq, etc. and never trust things like the .deb/.rpm updates.

Second, why worry about a rootkit when the underlying problem is how they get IN before the rootkit. I would definitely reccomend looking at securing-debian-howtofor those of you who are unsure of your debian security.

If the only problem were a rootkit changing binaries and installing a backdoor, then all an admin has to do is put a firewall in front of the server and control all the ports so that any unsolicited traffic from getting to the "unknown" daemon listening on port xyz plus stop ALL unsolicited tcp/udp/icmp traffic from leaving the server unless a handshake was completed. Most stateful pcket filters can do this. If your real paranoid, put an IDS (ie: snort www.snort.org) between the server and the outside to look for irregular activity. Worried about one of your services? Find a Proxy to inspect the connections. Worried about corrupt binaries? Install an integrity checker (ie:tripwire. www.tripwire.org)

Obviously, securing a server will require much more than this. Check out Sans.org. But AT A MINIMUM, the above should have been in place already. Hope that helps at least somebody out there.

How feasible would it be for someone to take a computer and have it do nothing but pattern-matching through all the source code in a typical Linux distribution, looking specifically for problem areas like these?

For longer answer, read this:

• Secure Programming: Buffer Overflow by David Wheeler
• Smashing The Stack For Fun And Profit by Aleph One
• Buffer Overruns, whats the real story? by Lefty
• Finding and exploiting programs with buffer overflows by Prym
• Stack Smashing Security Vulnerabilities by Nathan Smith
• Buffer Overflows by The FreeBSD Documentation Project
• Linux/ix86 buffer overflows by Willy Tarreau
• SunOS 4.1/Sparc buffer overflows by Willy Tarreau
• The Tao of Windows Buffer Overflow
• Buffer Overflows: Why, How and Prevention by Nicole LaRock Decker

http://news.com.com/2100-1001-835602.html

To mitigate this vulnerability OULU (the guys that found this a year ago) has some good links at http://www.ee.oulu.fi/research/ouspg/protos/testin g/c06/snmpv1/

Securing SNMP on Solaris
http://ist.uwaterloo.ca/security/howto/2000-10-04/
Securing SNMP in Windows
http://www.sans.org/infosecFAQ/incident/SNMP.htm
Securing your Cisco Router when using SNMP
http://www.sans.org/infosecFAQ/netdevices/router.h tm
SNMP - simple management tool for hackers?
http://www.nwfusion.com/newsletters/sec/1004sec1.h tml
Windows 2000, SNMP and Security
http://www.securityfocus.com/focus/microsoft/2k/sn mp.html