- Test - lists.nanog.org

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

03 Oct '02

>I was assuming a more complex configuration than the wide-open one >advocated by Barb, which seems to add little to no security benefit. > >I'm sorry I wasn't clear on this point; of course pushing out a single >file to n machines shouldn't be a problem. Of course. And a complex sudoers setup can be in a single sudoers file distributed to thousands of hosts. The sudoers syntax allows for as much or as little complexity as suits your needs. ...Barb

1 0

Re: Security Practices question
by Michael Lamoureux 03 Oct '02

03 Oct '02

"eddy" == E B Dreger <eddy+public+spam(a)noc.everquick.net> writes: jm> Date: Wed, 2 Oct 2002 17:48:16 -0700 (PDT) jm> From: just me jm> In an environment where every sysadmin is interchangable, and any jm> one of them can be woken up at 3am to fix the random problem of jm> the day, you tell me how to manage 'sudoers' on 4000 machines. eddy> krb5/ksu Well, no. That's an excellent answer to someone else's question, but krdist would be a better answer to his question. ;-) But the real answer is: The same way you maintain everything else on the same 4000 machines. I assume if you're running 4000 machines you have some cookie-cutter secured baseline OS load that gets installed on them all when they're loaded, and then something like home-grown perl scripts wrapped around rdist or rsync, or a specific tool for the purpose like cfengine or synctree to push out changes and keep them all under control. I would assume that the sudoers file could be pushed out with the same mechanism. Or am I missing some implied complexity in your situation? If the implication is that you have 4000 one-off machines, I retract my next statement. ;-) BTW, I really envy "just me". I have yet to work anywhere where every [insert position here] is actually interchangable. Must be nice. IMHO, Michael

2 1

RE: wcom
by Mike Damm 03 Oct '02

03 Oct '02

IMO, quite possibly a 'who'. >From http://www1.worldcom.com/us/tools/maintmsg/: During the normal operations window on Thursday, October 3rd, 2002, WorldCom will be performing maintenance in the following cities: DOMESTIC: Atlanta, GA(ATAN, ATL1, ATL3, ATL4, ATL5); Boston, MA(BOS1, BOS6); Buffalo, NY(BUF1); Chicago, IL(CHI1, CHI2, CHI6); Cleveland, OH(CLE1); Washington, DC(DCA1, DCA6, DCA8, WASD); Denver, CO(DEN4); Detroit, MI(DET1); Dallas, TX(DFW7, DFW9); Newark, NJ(EWR1, EWR3); Kernersville, NC(GSO1); Houston, TX(HOU4, HOU7, HSN); Ashburn, VA(IAD6); Indianapolis, IN(IND6); Kansas City, MO(KCY1, KCY4); Los Angeles, CA(LAX1, LAX2, LAX4, LAX9); Miami, FL(MIA1); New York, NY(NYC1, NYC3, NYC9); Palo Alto, CA(PAO1); Philadelphia, PA(PHL1); Phoenix, AZ(PHX2); Pittsburgh, PA(PIT1); Sacramento, CA(SAC1); Santa Clara, CA(SCL1); Seattle, WA(SEA1, SEA4); San Francisco, CA(SFO1); San Jose, CA(SJC1, SJC5); Salt Lake City, UT(SLT1, SLT4); Saint Louis, MO(STL2); Vienna, VA(TCO1) --- Michael Damm, MIS Department, Irwin Research & Development V: 509.457.5080 x298 F: 509.577.0301 E: miked(a)irwinresearch.com -----Original Message----- From: Jim Popovitch [mailto:jimpop@rocketship.com] Sent: Thursday, October 03, 2002 12:54 PM To: Randy Bush Cc: nanog(a)merit.edu Subject: RE: wcom > -----Original Message----- > From: Randy Bush > Sent: Thursday, October 03, 2002 3:47 PM > > more measurement sans insight or analysis. sadly a popular > sport, though neither operations or research. > > what *caused* the outage? > Outages like that are more likely to to be caused by a "who" rather than a "what". ;) -Jim P.

1 0

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