Slashdot Mirror
The Twenty Most Critical Internet Security Holes
Ant writes: "A little over a year ago, the SANS Institute and the
National Infrastructure Protection Center (NIPC)
released a document summarizing the Ten Most
Critical Internet Security Vulnerabilities. Thousands of
organizations used that list to prioritize their efforts so
they could close the most dangerous holes first. This
new list, released on October 1, 2001, updates and
expands the Top Ten list. With this new release, we
have increased the list to the Top Twenty
vulnerabilities, and we have segmented it into three
categories: General Vulnerabilities, Windows
Vulnerabilities, and Unix Vulnerabilities."
id add
21. Hiring admin's with no clue about security
"G" stands for "general holes"
"W" stands for "Windows holes"
"U" stands for "Unix holes"
G1 - Default installs of operating systems and applications
G2 - Accounts with No Passwords or Weak Passwords
G3 - Non-existent or Incomplete Backups
G4 - Large number of open ports
G5 - Not filtering packets for correct incoming and outgoing addresses
G6 - Non-existent or incomplete logging
G7 - Vulnerable CGI Programs
W1 - Unicode Vulnerability (Web Server Folder Traversal)
W2 - ISAPI Extension Buffer Overflows
W3 - IIS RDS exploit (Microsoft Remote Data Services)
W4 - NETBIOS - unprotected Windows networking shares
W5 - Information leakage via null session connections
W6 - Weak hashing in SAM (LM hash)
U1 - Buffer Overflows in RPC Services
U2 - Sendmail Vulnerabilities
U3 - Bind Weaknesses
U4 - R Commands (rlogin, rsh, rcp)
U5 - LPD (remote print protocol daemon)
U6 - sadmind and mountd
U7 - Default SNMP Strings
MadCow
I used to have a sig, but I set it free and it never came back.
Google Link:: www.sans.org/top20.htm+
http://www.google.com/search/?q=cache:dbJlh35mihk
Click here
This is really important, to think what the machine is really supposed to do.
It has been said a thousand time already, but disable all services, daemons etc, and start only those needed for the particular things this machine do.
This is the first and foremost security measure, and sadly it seems, one of the most overlooked.
Maybe not on UNIX machines, where SNMP is generally turned off by default - but on Cisco devices where it is enabled by default with the common SNMP names . . .
SNMP on cisco devices is weak because of the default community string names (public, private and secret). To add to the situation, the secret string will allow you to bring interfaces up and down at will, all without a trace of intrusion in the logs. While the big guys like ATT and Wcom may fix these using default config files, may universities and smaller carriers dont even know it exists.
http://support.microsoft.com/support/kb/articles/Q 303/2/15.ASP
... in programs (setting aside administration issues such as passwords)
1. string.h
2. sprintf
3. system
4. char buff[255];
5. snprintf(buf,len,user_input);
Let's face it, C's string handling is the biggest cause of security problems on the Internet. Static strings are evil. Too bad there is no standard way to handle them in C.
Equally negligent are broadband vendors that give away connection hardware, but can't be bothered to include a firewall or software that will check for open ports. These vendors won't make the simplest effort to insure the product they are selling is secure, yet will not take the responsibility when their service dies due to DOS attacks. These DOS attacks are largely possible because of the massive number of wide-open computers created by their broadband connections.
This is not a rant; this is a statement of reality. Vendors can not, and should not, expect the consumer to be skilled enough to provide adequate levels of security. This is why houses and cars come with locks. Sometimes consumers lock themselves out, but that is a minor inconvenience. As an extreme example, many shoes now have Velcro, and most cars, at least in the U.S., have automatic transmissions.
No stream of security patches, warnings, and news items will solve the problem. The consumer is not skilled enough to keep up. Until the default configuration is secure, until vendors are forced to take monetary consequences for their defective products, and until the consumer is trained to suffer the imposed inconveniences, we will continue to see the same sort of problems.
- DDOS attacks, etc. that use your machine to do the dirty work,
- Net worms which may be propagated from an insecure machine
- back doors: perhaps you will do something useful, valuable, or important on your computer in the future, only to get clobbered or ripped off by whoever's bug installed the backdoor, not to mention the loss of your time to recover your valuable work (if you even can) or to reinstall and reformat.
- remote keyboard monitors... first time you use your credit card to make an online purchase, and bam, script kiddie has your cc # and can attempt to use it or sell it to even less scrupulous folks,
- and my personal favorite reason: to make it less worth the script kiddies time to try to take down yours, mine, and everybody else's machines for kicks and giggles. Think about the bragging rights between "hey my new ultra-virus took down four machines, or "hey, my new ultra-virus took down 200,000 machines..."
But let me offer a different perspective. What if the security holes in your machine allowed big gov't, or someone else to snoop on what you were doing online all the time? Would you think about closing the security holes in your machine then?Course, if those four machines were the front end machines for M$, that might be worth a brag or two ;-)
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
It is extremely difficult to maintain local security on UNIX systems if you and your users are using quite a few tools. For example, GNU Emacs 20 still has temporary file races (really old advisory), and a lot of your favorite tools, too. Such problems disappear only very, very slowly.
Of course, there seems to be a way out of this dilemma: don't install anything on your server except the server software itself. Put each service (HTTP, SMTP, NNTP) on separate machines, and interactive users onto another. Unfortunately, after you've done this, you are facing a remarkable farm of servers, each requiring maintenance, which is not always acceptable.
As a result, if you have limited capacities (and who doesn't?), you are better off when you focus most of your energy on securing against attacks over the network, as long as you can trust your local users. Relying on the security features of a typical UNIX system to confine a security breach to a certain account is not a good idea, at least at the moment.
A year and a half old advisory, and sites still refuse to fix it. http://www.cert.org/advisories/CA-2000-02.html
Some of you will remember the problems with Hotmail relating to cross site scripting. Newsflash, it affects your site too!
-- these are only opinions and they might not be mine.
MY_NET=1.2.3.4/5
INT_DEV=eth0
EXT_DEV=eth1
# 1. Any packet coming into your network must not have a source address of your internal network
ipchains -A forward -i $EXT_DEV -j DENY -s $MY_NET
# 2. Any packet coming into your network must have a destination address of your internal network
ipchains -A forward -i $EXT_DEV -j DENY -d ! $MY_NET
# 3. Any packet leaving your network must have a source address of your internal network
ipchains -A forward -i $INT_DEV -j DENY -s ! $MY_NET
# 4. Any packet leaving your network must not have a destination address of your internal network.
ipchains -A forward -i $INT_DEV -j DENY -d ! $MY_NET
# 5. Any packet coming into your network or leaving your network must not have a source or destination address of a private address or an address listed in RFC1918 reserved space. These include 10.x.x.x/8, 172.16.x.x/12 or 192.168.x.x/16 and the loopback network 127.0.0.0/8.
ipchains -A forward -i $EXT_DEV -j DENY -s 10.0.0.0/8
ipchains -A forward -i $EXT_DEV -j DENY -s 172.16.0.0/12
ipchains -A forward -i $EXT_DEV -j DENY -s 192.168.0.0/16
ipchains -A forward -j DENY -d 10.0.0.0/8
ipchains -A forward -j DENY -d 172.16.0.0/12
ipchains -A forward -j DENY -d 192.168.0.0/16
### REMOVE the next 3 rules for masquerading systems
ipchains -A forward -i $INT_DEV -j DENY -s 10.0.0.0/8
ipchains -A forward -i $INT_DEV -j DENY -s 172.16.0.0/12
ipchains -A forward -i $INT_DEV -j DENY -s 192.168.0.0/16
# 6. Block any source routed packets or any packets with the IP options field set.
# This is done at the kernel level under Linux, and is usually set by default.