October 2002 - Test - lists.nanog.org

wcom
by Ian A Finlay 03 Oct '02

03 Oct '02

I know, I know, don't believe everything you read... ;-) http://www.msnbc.com/news/816663.asp?0dm=C15MT "Struggling WorldCom Inc., one of the major backbone providers of networks that route traffic over the Internet, suffered a major commercial Internet outage beginning at 8 a.m. EDT on Thursday, according to a company that monitors Internet performance." Article goes on to state the reason was a "software glitch". FWIW, Ian

1 0

Re: Security Practices question
by Barb Dijker 03 Oct '02

03 Oct '02

>There is no secure accountability, by default, with sudo either. The >sudo log is trivially bypassed, at least in every instance I've ever >encountered it being used, even when those who installed it claimed it >was "secure". Sudo accountability is only as secure as the programs which you allow the user to run via sudo. At least with sudo you have control over allowed commands and logging per command. With uid=0 accounts you have neither. In any case with someone having root, they can circumvent controls. The point is with uid=0 accounts there are no controls to circumvent. >The biggest problem with sudo is that it often makes it a heck of a lot >easier for an attacker with minimal access to gain increased privileges How is that?? An attacker needs to not only access the system as a sudo-capable user, but also know their password (have cracked it). With additional uid=0 accounts, you've added passwords to root which betters the odds for cracking uid=0 as much as sudo-capable accounts do. At least with sudo, they have to first figure out who might have full sudo access. You won't find that in /etc/password like you find uid=0. > Oddly only by >forcing admins to login directly via a trusted path as root can you >avoid many of those risks Any time you force someone to login via a trusted path, as root or a regular user (for sudo/su), you avoid auth/acct risks. This is not a feature only of logging in as uid=0. Trusted paths are essential in any security scheme. >, and if that's the approach you take then use >of multiple UID==0 accounts is the only way to achieve (regain?) at >least minimal accountability (i.e. the same amount that can be achieved >with 'su', assuming one has a decently secure logging system, or >physically secure host with a good and complete securemode >implementation and append-only log files, etc.). Your statement seems to make the assumption that a login via a uid=0 account is somehow better authenticated than a normal user login (who can then su/sudo) and thus better then sudo or su. A login is a login. It's only as good as the trusted path regardless of uid. If you have a secure logging system, your sudo log can be just as secure as login entries. In fact sudo and su logs are easier to secure than login because sudo and su use syslog and login does not. It seems in your definition of "accountability," you only need to know who logged in when. That's all your getting, if you believe your "trusted path." With sudo, even if you don't believe the sudo logs, you still get at least who logged in when, but much more as well. >their managers must not trust the sudo log any more than they would >really trust any logbook, even on written in indellible pen on >sequentially numbered pages in a hard-bound volume. But at least it is something. The login logging is equally suspect (can readily be modified) and contains insufficient information to account for activities after login. Try to figure out who unplugged a computer in a controlled access machine room. You can only make guesstimates by correlating the time of the event with the time stamps on the door access logs. What if the logs show two people in the room at the same time and they both claim ignorance? Accounting only for the login event is pretty useless. ...Barb

1 0

Re: Security Practices question
by Scott Francis 03 Oct '02

03 Oct '02

On Wed, Oct 02, 2002 at 04:06:00PM -0400, woods(a)weird.com said: > [ On Wednesday, October 2, 2002 at 11:47:12 (-0700), Scott Francis wrote: ] > > Subject: Re: Security Practices question > > > > Absolutely so - which is why no account should have multiple equally valid > > passwords, which is what multiple accounts sharing a uid equates to. > > Hold on a minute. You've taken this entirely out proportion for any > reasonable real-world scenario! that last should have been qualified s/no account should/the root account should not/ > It's _NOT_ that bad. Not anywhere near. > > The only real risk with having multiple superuser (UID == 0) accounts is > when the system has some form of vulnerability which makes it reasonable > for an attacker to guess the password. Now normally on any decently > modern system the group of potential attackers who could even begin such > an attack is limited strictly to those who are already members of the > "wheel" group, and all of those people should already have the real root > password anyway. grr. Please read Barb's post about exactly why multiple aliases for the UID 0 account is a Bad Idea. It's not really about opening potential security vulnerabilities as much as it is about bad (lazy) administration. > The risks that a wheel-group member will execute a trojan of some sort > that will help an attacker gain increased privileges are much higher > than any of the risks directly associated with multiple UID==0 accounts! Rubbish. There are no risks associated with members of gid 0 that are not also associated with accounts having UID 0 - and multiple accounts with UID 0 brings in a host of other issues and problems. > Different UID==0 accounts can have different home directories, and with > careful implementation of certain tools the benefits of this mechanism > also vastly outweigh the risks of having multiple UID==0 accounts. bah. There is _nothing_ one could reasonably hope to accomplish by creating multiple accounts with UID 0 that could not be accomplished at least as easily, and vastly more safely, using sudo. (before anybody uses it as a defense, yes, there are a (very) few systems out there that sudo will not run on. That's not the debate here.) > Even just the benefit of being able to appease multiple human superusers > with the abillity to specify different shells for their superuser > account can be enough of a benefit to oughtweigh the risks (though of > course with a small amount of training in the proper use of 'su', there > really isn't any need to specify different default shells in the first > place). su isn't even needed. USE SUDO. I cannot believe that there are so many otherwise clueful people out there that apparently are unfamiliar with the fine-grained control and flexibility that this tool gives the admin (multiple shells, multiple environments, etc. etc. etc.) > You didn't give one solid example of a real-world threat or > vulnerability for having multiple superuser (UID == 0) accounts. Not > one. If you're going to say something is so bad that nobody should ever > do it regardless then you'd better have some damned good solid threat > analysis and risk assessment to back up your claim! Trying to avoid yelling here. PLEASE go read Barb's excellent post on EXACTLY why multiple UID 0 accounts are a problem. She details multiple real risks and problems associated with this practice. I didn't list them because I thought it would surely not be too much to ask for those posting to the thread to READ the thread first, from the beginning. It's not that long. > The only thing you really said that stands up to analysis is your > repeated assertion that multiple accounts with the same UID are, from > the system's perspective, simply multiple ways to authenticate access to > the same underlying system ID and thus to grant exactly the same > authorisations. That is 100% true. What this really means, especially > if the UID in question is zero(0), is that ultimately all activities > that take place on the system are done with that unified UID and so > there's no way to hold separate human users accountable for their > actions. However in the case of UID==0 that's more or less true of 'su' > even with just one "root" account. You have to trust superusers 101%, I never advocated using su. *sigh* Use sudo. > regardless of how they authenticate to the system. In turn they, if > there's more than one of them, must each be held equally responsible for > any and all damage done by any superuser. If nobody confesses you can Yes, there is trust that must be given along with superuser privs. The level of trust required can be MUCH LOWER using sudo, ACLs, or some other system. As opposed to just giving $admin or $user a blank check to do whatever they please. There was an excellent talk on exactly why the UNIX permissions scheme is archaic and needs to be replaced at ToorCon last weekend <http://www.toorcon.org>, but this is getting off-topic (even for this thread). > point fingers just as easily with 'login' logs as you can with 'su' > logs, but in the end you cannot prove anything with those logs alone if > its UID==0 (unless the logging is done securely in such a way that > UID==0 cannot modify it). The finger pointing suggested by the logs > _MUST_ be corroberated with an external verifiable alibi (or hopefully > multiples!) (which, BTW, is essentially what any secure logging system > is, and it doesn't matter if 'login' or 'su' generates the audit trail). USE SUDO. Most people, even those with a legitimate need for superuser privileges, do not really need the ability to do EVERYTHING on the system as UID 0. Sure, it takes a bit more effort to setup, but I don't think anybody could argue that the gains in control, logging, security and authentication/authorization are not worth it. >> Use sudo, use ssh keys from a central admin host, use ACLs - use whatever you >> like, but please don't create multiple aliases for an account and think it's >> anything but an invitation to disaster. > > Sudo is a far worse solution, with a far higher false sense of security, > than multiple UID==0 accounts, unless maybe you're using it purely and > only for convenience and documentation purposes amongst a group of > mutually trusting users who already each know the "real" root password > anyway. Can you back up that statement in /any/ way? What exactly are your reasons why sudo is a worse solution (or even a bad idea)? -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui

9 11

Hunting for bogus BGP announcement for 204.106.93.155
by Michael.Dillon＠radianz.com 03 Oct '02

03 Oct '02

For the last two days, between approximately 7pm to 2am Eastern time, a spammer hijacked a piece of our address space, presumably by announcing some size of aggregate containing the IP address 204.106.93.155. During the time that the spammer had connectivity using this bogus announcement, they originated many spam messages for a porn website. Possibly, they also provided connectivity for the porn website during that time. And they probably also announced various other netblocks which you may be able to deduce by studying the emails posted to nanas here <http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=1032174896.54.41…> If anyone has some idle time this evening, and you happen to successfully traceroute to 204.106.93.155 then I would appreciate seeing a copy of that traceroute as well as a BGP dump with all of the routes announced by the AS containing this netblock. At the current time we are not announcing the netblock containing this address but even if we were, the address is currently unassigned, i.e. a portscan would show it not in use, and therefore the hijacker could still successfully announce a longer prefix than us to use our address space. If you are not filtering your inbound BGP sessions, then this spammer could be your customer. Or maybe this spammer is abusing the hospitality of your local Internet exchange. I was originally alerted to this spam by a half dozen messages from spamcop and I've asked the spamcop folks to collect a traceroute as soon as they identify the spam so that we have a better chance of tracking down the rogue ISP/XP (or sloppy ISP/XP) that is letting these spammer announce bogus routes. ------------------------------------------------------- Michael Dillon

4 3

Re: IPv4 country of origin
by Michael.Dillon＠radianz.com 03 Oct '02

03 Oct '02

>One of my clients is a large computer security software >company. According to them, it's not just crypto export rules that are >the concern, but also the ITAR countries (N. Korea, Lybia, Cuba, ...). As >well they are concerned about liabilities in countries like France where >it is illegal to import crypto so they want to restrict people from France >too. You're trying to solve the wrong problem. Since you have a legal requirement that would be violated by sending stuff to a bad place, you should only send it to a known good place. Therefore, instead of trying to identify the bad places to block them, you should be trying to identify the good places that should be allowed access. If someone from a good place can't get in, then give them a web page to register a complaint and check it out manually if you think it is worth your while. Michael Dillon

1 0

RE: IPv4 country of origin
by Peter Salus 03 Oct '02

03 Oct '02

Ralph, You and alex exchanged: >On Thu, 3 Oct 2002, alex(a)yuriev.com wrote: > >> > > Is there a more accurate method to determine the country of origin for an >> > > IP than the methods I've described above? >> >> Yes, at least three companies have databases of pretty much all /24s and >> above mapped up to a zip code. > >So far I've been referred to 3 commercial services, and all (including >NetGeo/Ixia) fail on the example I gave (194.196.100.86). > >- -Ralph As near as we can tell, 194.196.100.86 is near Eisenhuettenstadt, Brandenburg, Deustschland. Is this good enough? Peter ----------------------------------------------------------- Peter H. Salus Chief Knowledge Officer, Matrix NetSystems Ste. 300 5001 Plaza on the Lake Austin, TX 78746 +1 512 697-0613 -----------------------------------------------------------

1 0

Re: IPv4 country of origin
by Ralph Doncaster 03 Oct '02

03 Oct '02

That's basically all Netscape & Microsoft were doing when they had to restrict 128-bit SSL. They threw in the requirement to enter your address & phone number, but they had no way of telling if you were entering your address, or the one you got from doing a four11.com lookup of John Smith in Plano, Tx. I block anonymizer & some other proxies, as well as AOL. So I guess you're saying there's not much better than what I'm already doing? The only info I have on the client is what I can get from a TCP connection. -Ralph On Wed, 2 Oct 2002, Rick Ernst wrote: > "Good luck"? > > Have you thought about folks using tunneling and proxies? IP-based > authorization is a very weak and inaccurate/insecure method... > > On Wed, 2 Oct 2002, Ralph Doncaster wrote: > > :> > :>I would like to restrict access from certain countries to content on my > :>network (for security and legal reasons). > :> > :>So far the best algorithm I've been able to come up with is a combination > :>of reverse DNS and APNIC/ARIN/RIPE whois queries. I've written a perl > :>cgi that checks reverse DNS first, and if there is no gtld country code > :>for the reverse mapping, does a whois query and parses the response for > :>the address. > :> > :>The problem I have is that the country for the company that owns the IP > :>block is sometimes not the country the IP block is used in. For example > :>sungold22.de.ibm.com 194.196.100.86 > :>Whois parsing indicates a country of UK, but from the reverse DNS a person > :>can see that it is Germany. I've built the pattern of cc.ibm.com into my > :>cgi, but I'm sure there are other blocks that I'm incorrectly identifying. > :> > :>I've looked at RADB entries, as well as origin AS for various IP blocks, > :>and neither source looks any better than whois. > :> > :>Is there a more accurate method to determine the country of origin for an > :>IP than the methods I've described above? > :> > :>-Ralph > :> > :> > >

2 2

Dont you love it when FC updates are better than NOC status report?
by alex＠yuriev.com 03 Oct '02

03 Oct '02

This is an automatic email from Fuckedcompany.com. A new rumor has been submitted on October 3, 2002 9:37AM that matches your keyword "Worldcom". Huge Worldcom Outages WorldCom http://www.uunet.com UUnet is having a massive network outage. You can't even get through to tech support -- they just have a tape repeating "Worldcom is experiencing network outages in multiple locations throughout the United States". Shit, I can't route through NYC

1 0

Re: UUNET Routing issues
by Patrick_McAllister＠WASHGAS.COM 03 Oct '02

03 Oct '02

Not sure why the two different numbers...the one I gave you is the one we got.... Manolo Hernandez To: Patrick_McAllister(a)WASHGAS.COM <manolo@dialto cc: Nanog <nanog(a)merit.edu>, owner-nanog(a)merit.edu ne.com> Subject: Re: UUNET Routing issues 10/03/2002 10:04 AM Thats no the number I got I got 651751. On Thu, 2002-10-03 at 10:05, Patrick_McAllister(a)WASHGAS.COM wrote: > > > UUnet is currently experiencing outages throughout the US. Master ticket > number is 651744. No estimate on repair. > > > > > Manolo > Hernandez To: Nanog <nanog(a)merit.edu> > <manolo@dialto cc: > ne.com> Subject: UUNET Routing issues > Sent by: > owner-nanog@me > rit.edu > > > 10/03/2002 > 09:54 AM > > > > > > > > Anyone know the cause of todays routing problem at UUNET? It looks like > an IBGP loop but I could be wrong. > -- > Manolo Hernandez - Network Administrator > Dialtone Internet - Extremely Fast Linux Web Servers > phone://954-581-0097 fax://954-581-7629 > mailto:manolo@dialtone.com http://www.dialtone.com > "The only source of knowledge is experience." - A. Einstein > > > > > > -- Manolo Hernandez - Network Administrator Dialtone Internet - Extremely Fast Linux Web Servers phone://954-581-0097 fax://954-581-7629 mailto:manolo@dialtone.com http://www.dialtone.com "The only source of knowledge is experience." - A. Einstein

2 1

Re: UUNET Routing issues
by Patrick_McAllister＠WASHGAS.COM 03 Oct '02

03 Oct '02

UUnet is currently experiencing outages throughout the US. Master ticket number is 651744. No estimate on repair. Manolo Hernandez To: Nanog <nanog(a)merit.edu> <manolo@dialto cc: ne.com> Subject: UUNET Routing issues Sent by: owner-nanog@me rit.edu 10/03/2002 09:54 AM Anyone know the cause of todays routing problem at UUNET? It looks like an IBGP loop but I could be wrong. -- Manolo Hernandez - Network Administrator Dialtone Internet - Extremely Fast Linux Web Servers phone://954-581-0097 fax://954-581-7629 mailto:manolo@dialtone.com http://www.dialtone.com "The only source of knowledge is experience." - A. Einstein

2 1