Actually the number of potential attackers isn't much lower and I wasn't talking about accidental file deletion and forgetting to revoke network access to ex-employees. Here is a real life example from my life:
I was going to school at the college in Lethbridge. They had the same problem, external servers in the DMZ and the firewall were all fine but internal systems were not. You want to know how long it took me to get the root password on their mail server (Staff, faculty and students)? They were running a version of DIGITAL Unix that hadn't been patched in 3 years. They were not using shadow passwords and also were running anonymous ftp internally with anonymous access to / ftp <mail server IP> get /etc/passwd exit In 3 hours on a AMD K6/2 450, I had the root password and around 15000 other passwords for staff and students. Those problems are fixed now and I wound up getting a job in their IT department afterwords too. My point is though, they are lucky I found the problem first... not everyone would have made them aware of it and not abused that knowledge. Trevor > Fair enough, but the number of potential attackers is much lower. Most > things called internal attacks shouldn't be. > > Disgruntled ex-employees whose network access hasn't been revoked. > Accidental moving/deleting of files. > Executives having access to things they don't need "because they're the > boss" deleting stuff. > Etc. > > These are labelled attacks, but they aren't. > > Kev. > > > ----- Original Message ----- > From: "Trevor Lauder" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, December 02, 2002 1:13 PM > Subject: Re: (clug-talk) Linux Work > > >> It's just as important to patch internal boxes if not more important. >> 80 percent of network attacks come from the inside, a firewall and >> patched external boxes do you no good if someone takes it down from >> the inside. >> >> Trevor >> >> > To which I again point at the Mandrake 9 install thread. >> > >> > Neither system is perfect period. >> > >> > Back to the platform standardization issue, I only have 1 platform >> to test across. Compaq deskpro EVO 1.7 w/ 512 Megs of RAM. Other >> boxes are non-production, or whatever. >> > >> > Further, I generally do not need to immediately apply patches. >> Sure, if Apache has some major issue come out, then I'll patch it on >> external facing boxes. But I can wait a while before patching a >> BIND >> > vulnerability on a box that runs internally only. Others can find >> problems for me, thanks... >> > >> > Kev. >> > ----- Original Message ----- >> > From: "Jesse Kline" <[EMAIL PROTECTED]> >> > To: <[EMAIL PROTECTED]> >> > Sent: Monday, December 02, 2002 11:54 AM >> > Subject: Re: (clug-talk) Linux Work >> > >> > >> >> Quoting Kevin Anderson <[EMAIL PROTECTED]>: >> >> >> >> > Would you install something onto a production box without testing >> it >> > first? >> >> > I test everything before it goes into production. Therefore, >> >> actually emerging the app doesn't worry me, because I know it will >> compile correctly, >> >> > and install in my environment. I've already done it in test. >> >> >> >> There is a difference between you testing a package for a couple >> hours, >> > and >> >> having it tested by a distributor. Before a version of Red >> > Hat/MDK/whatever >> >> comes out, the packages are tested by the author, in the lab, in >> alpha >> > tests, in >> >> beta tests, etc. Then once the distro. has his the market it is >> tested by thousands of other people. I love having a system with >> the latest and >> > greatest >> >> software but there are drawbacks. Just because a new version is >> released >> > doesn't >> >> mean that it has less bugs than the old version. It could have a >> new bug >> > that >> >> you missed, and then fucks up your server. Where as someone using >> Red Hat >> > 7.3 or >> >> 8.0 still gets the security updates but also has the security of >> knowing >> > that >> >> their packages have been tested by thousands of people, and have a >> better >> > chance >> >> of working properly than something that was released yesterday and >> is >> > running in >> >> your production environment today. >> >> >> >> Jesse
