RE: Popular trouble ticket management system for IP NOC
Hi all, Thanks for all your kindly reply. I'm currently evaluating HP Service Desk, and CA Unicenter service desk. Remedy seems have no Chinese contact. RT seems too non-commercial :-) thanks! Yu Ning |-Original Message- |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On |Behalf Of jeffrey.arnold |Sent: Thursday, September 19, 2002 3:19 PM |To: Yu Ning |Cc: [EMAIL PROTECTED] |Subject: Re: Popular trouble ticket management system for IP NOC | | | |On Thu, 19 Sep 2002, Yu Ning wrote: | |:: Have any idea of the current popular trouble ticket system |for the NOC ? |:: The system used to accept, dispatch, close, store and search trouble |:: ticket or customer case ? It's pretty much a NOC work flow system, |:: but more focused on IP NOC. |:: | |Definitely check the archives, this comes up often: | |http://www.merit.edu/mail.archives/nanog/ | |I've seen everything from $100 pc's running RT to multimillion |dollar distributed remedy installs used successfully. I |personally use RT 1.0, and like it. RT is available at: |http://www.bestpractical.com | |-jba |__ | [[EMAIL PROTECTED]] :: |analogue.networks.nyc :: http://analogue.net |
Re: selective prepends (RE: Cogent service)
> > > Date: Sun, 22 Sep 2002 23:16:20 -0400 (EDT) > > From: jlewis > > > > Speaking of special...having played around a little with the > > BGP communities supported by C&W and Sprint, I'm wondering > > which other big transit providers (it seems almost a waste to > > say Tier 1 anymore) support community strings that will let you > > (the customer) cause them to selectively prepend route > > announcements to their peers. > > 1239, 3356, 3549, 3561 5511 supports that kind of traffic engineering as well. Our communities are publicly available: http://www.ripe.net/perl/whois?AS5511 Best Regards, German
Re: Pricing model for transit services
On Mon, Sep 23, 2002 at 05:28:15PM -0400, Joe Abley wrote: > > I think the problem is not that there are multiple definitions of > how to calculate the 95th percentile of a sample population, but > that different peoples' sample populations are constructed in > different ways. > > I have seen billing based on: > > max(95th(to_cust), 95th(from_cust)) > 95th(max(to_cust, from_cust)) > 95th(to_cust + from_cust) > 95th(to_cust) There are really two things we're talking about, the mathmatical function for "95th percentile", which is quite simply take the highest sample after removing the top 5% of samples, and the "95th percentile billing system", which can only be defined as max(95th(to), 95th(from)). Anything else is a varient which may or may not be useful as a billing metric, but it is NOT "the 95th percentile billing system", it is "a billing system which happens to use the 95th percentile function". > I would be interested to find out how many customers of services > billed by "95th percentile" do their own measurements and compare > them with the bill. I suspect the number is not large. I suspect most customers don't even fully understand 95th percentile. I still see many people thinking its the average after the 5% is removed, infact if you're a good you can convince sales people at "some major ISPs" to write it that way in the contract. > Maybe that's why most providers don't find it necessary to spell > out exactly what calculations they are doing in order to arrive at > a monthly figure with a dollar sign in front of it. The stories I've heard from the few people who do their own measurements for billing confirmation usually involve some significant over (or sometimes under) billing. As they put it, "We get a bill for 750Mbit, we send them the money for the 670Mbit we actually used, and they're happy." -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
RE: Cogent service
This was a totally bogus reason from the very beginning. Given that real backbones carry no prefixes longer than 24 bits the "long" lookup in Last numbers I saw put 701 at over 100k prefixes in the /25-/32 range. The more correct statement is backbones carry no external prefixes longer then /24. The point is there can be a HUGE number of internal prefixes that can make a difference. I will admit 701 route bloat, is not a typical example.
Re: Security Practices question
On Sun, Sep 22, 2002 at 03:22:11PM -0700, [EMAIL PROTECTED] said: > > I have question for the security community on NANOG. > > What is your learned opinion of having host accounts > (unix machines) with UID/GID of 0:0 > > otherwords > > > jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh > > > The argument is that way you don't hav to give out the root password, > you can just nuke a users UID=0 equiv account when the leave and not > have to change the real root account. This is a really /really/ REALLY bad idea. I had nightmare issues dealing with a network formerly run by a 'sysadmin' who thought every user that might need to do something as root should have a uidzero account. I seriously cannot think of ANY scenario, no matter how improbable, in which what you're suggesting would be a good idea (or even defensible). > Now, don't flame me over the question, but provide valid pro's or con's > for this practice from your experience. Names on accounts are strictly an abstraction to make interacting with the system easier for us dumb humans. In reality, there is only one UID 0, no matter how many copies of it you make. This means there is NO difference between giving out the root password to everybody, and giving everybody UID 0 accounts. None. As far as the system is concerned, the two are one and the same. > thank you. > > the reason I'm asking is important. Even were it not, I'd still urge you - please do not consider this a valid option. > john brown -- -= Scott Francis || darkuncle (at) darkuncle (dot) net =- GPG key CB33CCA7 has been revoked; I am now 5537F527 illum oportet crescere me autem minui msg05570/pgp0.pgp Description: PGP signature
Re: Pricing model for transit services
On Mon, Sep 23, 2002 at 04:07:47PM -0400, Richard A Steenbergen wrote: > On Mon, Sep 23, 2002 at 12:50:17PM -0700, Lane Patterson wrote: > > > And there are at least 4 ways of computing 95th percentile, though I'm sure > > there've already been threads on this. > > There is only one way, anyone else is computing "something else" that they > just happen to bill with. But this sounds like a subject for the NANOG > FAQ. :) I think the problem is not that there are multiple definitions of how to calculate the 95th percentile of a sample population, but that different peoples' sample populations are constructed in different ways. I have seen billing based on: max(95th(to_cust), 95th(from_cust)) 95th(max(to_cust, from_cust)) 95th(to_cust + from_cust) 95th(to_cust) all referred to by different people as "95th percentile billing". There are also many different ways of obtaining values for "to_cust" and "from_cust", just to keep things interesting. I would be interested to find out how many customers of services billed by "95th percentile" do their own measurements and compare them with the bill. I suspect the number is not large. Maybe that's why most providers don't find it necessary to spell out exactly what calculations they are doing in order to arrive at a monthly figure with a dollar sign in front of it. Joe
Re: Wireless insecurity at NANOG meetings
On Mon, 23 Sep 2002, Huopio Kauto wrote: > How about just plainly blocking the most obvious holes, that is > telnet and POP? If someone wants a direct telnet connection to a > route server or something similar - open a hole with a web-based tool? > Ok, then you say all unencrypted www traffic with plain username/pw.. > SSH'ing everything back to home base is quite useful :) Configure hogwash (an evil snort hack which RSTs connections that match snort IDS rules) and create rules for unencrypted pop login, telnet login, web login things. That way you don't disturb encrypted versions on the same port numbers.. .. such for-you-own-good could be done by anyone on the wire vigilante style, not that anyone would endorse that (you're likely to screw up the rules and fry the network) ..
Re: Wireless insecurity at NANOG meetings
How about just plainly blocking the most obvious holes, that is telnet and POP? If someone wants a direct telnet connection to a route server or something similar - open a hole with a web-based tool? Ok, then you say all unencrypted www traffic with plain username/pw.. SSH'ing everything back to home base is quite useful :) --Kauto
RE: Cogent service
On Sun, 22 Sep 2002 23:16:20 -0400 (EDT), [EMAIL PROTECTED] wrote: >What are these 'special needs' people keep mentioning? What special needs >might you have of your transit providers? It's hard to generally categorize special needs because they're special. I can give you an example of a special need, but it hardly typifies all the special needs. One example of a special need would be a case where you get a 100Mbps connection from a transit provider and you don't use BGP. They normally assign two IPs, one to each end of the link. You want to connect the link to a switch and number two routers inside the link using HSRP for which router they send your traffic to. Another case might be where you get 2 100Mbps links and you want both failover and load sharing. You might want them to allow a setup where each of the two links goes to two routers (through switches) such that either router can use either link under normal conditions. This way you're protected against failure of either router, either link, and under normal conditions can get the full use of both. This may require configuration changes on their end (such as the subnet mask of the block the link is numbered with.) What I think you don't realize is how precisely Cogent specifies everything. Anything other than exactly their default configuration is a special need they won't do. DS
Re: Pricing model for transit services
On Mon, 23 Sep 2002, Richard A Steenbergen wrote: > > On Mon, Sep 23, 2002 at 12:50:17PM -0700, Lane Patterson wrote: > > > Also, some large ISP's have a policy that you must buy the whole pipe > > unmetered if your commit is >50% pipe speed. > > Never heard that one, but conversly most ISPs have a minimum commit for I have, but not 50%.. usually around 75% and the way I've seen it is you pay for the 75% and that gets you the full pipe unmetered. ie the extra 25% is FOC but its not really that usable anyhow as you know.. Steve > "big expensive ports". For example, 1 meg commits on FastE ports are > usually fine because almost nobody still has ports that are only 10Mbit > Ethernet. But noone in their right mind will give GigE ports to 10Mbit > committers, for potential abuse reasons and port cost reasons at the very > least. > > > And there are at least 4 ways of computing 95th percentile, though I'm sure > > there've already been threads on this. > > There is only one way, anyone else is computing "something else" that they > just happen to bill with. But this sounds like a subject for the NANOG > FAQ. :) > >
Re: Pricing model for transit services
On Mon, Sep 23, 2002 at 12:50:17PM -0700, Lane Patterson wrote: > Also, some large ISP's have a policy that you must buy the whole pipe > unmetered if your commit is >50% pipe speed. Never heard that one, but conversly most ISPs have a minimum commit for "big expensive ports". For example, 1 meg commits on FastE ports are usually fine because almost nobody still has ports that are only 10Mbit Ethernet. But noone in their right mind will give GigE ports to 10Mbit committers, for potential abuse reasons and port cost reasons at the very least. > And there are at least 4 ways of computing 95th percentile, though I'm sure > there've already been threads on this. There is only one way, anyone else is computing "something else" that they just happen to bill with. But this sounds like a subject for the NANOG FAQ. :) -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: Pricing model for transit services
On Mon, Sep 23, 2002 at 11:26:22AM -0400, Alex Rubenstein <[EMAIL PROTECTED]> wrote: > > > > > - flat fee for a L Mbps link > > Also known as 'fractional' or 'tiered.' $x for y mb/s, and it is > rate-limited. > > > > - volume based, y $ per Mbps (95% quantile) for a L Mbps link > > - burstable, flat fee for x Mbps on a L Mbps and z $ per Mbps above x > > These two are essentially the same. You do have three variations of > usage-based, however: > > a) vth percentile: $x per y zzzbits/sec, with a t committment. > Occasionally, any usage over t has a different price. In my somewhat limited experience, "t" commitment is usually at least 10% of wire speed. Though if transit is coming off low-cost LAN ports in data center environments, sales folks will probably approve lower commits if pressured. Also, some large ISP's have a policy that you must buy the whole pipe unmetered if your commit is >50% pipe speed. And there are at least 4 ways of computing 95th percentile, though I'm sure there've already been threads on this. Cheers, -Lane > > b) 'Average usage', which is is the same as A, but using an averaging > measurement system, rather than a percentile system (50th percentile is > NOT the same as, or even relevant to, average). > > c) counting bytes: $x per y bytes. > > > -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- > --Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- >
RatHole: Wireless insecurity at NANOG meetings
"That [WEB] will give people a false sense of security." IMHO those 'people' are a group that is a subset of folk that will do 'unwise' things no matter what level of scurity is in place. Move along, nothing to see here... Internet != secure, period. Best regards, _ Alan Rowland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Chris Adams Sent: Sunday, September 22, 2002 11:51 PM To: [EMAIL PROTECTED] Subject: Re: Wireless insecurity at NANOG meetings On Sunday, Sep 22, 2002, at 15:41 US/Pacific, William Allen Simpson wrote: > I will agree that the security in WEP is almost useless, and have > personally campaigned to change it for years. But, it is still the > only Access Control widely available. So, it should be used, in > addition to the better methods. That will give people a false sense of security. Wouldn't it be better to use an approach like NetReg to give every user a warning when they first connect to the network? That doesn't require any arcane software config and would give an accurate indication of how secure the network is. Chris
Re: Wireless insecurity at NANOG meetings
On Sunday, Sep 22, 2002, at 15:41 US/Pacific, William Allen Simpson wrote: > I will agree that the security in WEP is almost useless, and have > personally campaigned to change it for years. But, it is still the > only > Access Control widely available. So, it should be used, in addition to > the better methods. That will give people a false sense of security. Wouldn't it be better to use an approach like NetReg to give every user a warning when they first connect to the network? That doesn't require any arcane software config and would give an accurate indication of how secure the network is. Chris
Re: Wireless insecurity at NANOG meetings
On Sun, 22 Sep 2002, Iljitsch van Beijnum wrote: > > On Sun, 22 Sep 2002, Richard A Steenbergen wrote: > > > On Sun, Sep 22, 2002 at 01:11:07PM +0200, Iljitsch van Beijnum wrote: > > > > There are also people ssh'ing to personal and corporate machines from > > > > the terminal room where the root password is given out or easily > > > > available. > > > > Are you saying people shouldn't SSH? > > > I've seen far too many people get into trouble because they have some > > flawed thinking that "ssh == always secure", even against compromises of > > one of the endpoints. If root is available, a reasonable person should > > ASSUME that some bored individual (like Bandy Rush) has taken 30 seconds > > and recompiled the ssh binaries with a password logger. When we hosted nanog 16 we made the effort to periodically compare the md5 sums of the binaries on the terminal room machines to a reference source. I wouldn't personally place a greate deal of trust in machines that aren't in ones possession but we try. > Excellent point. Fortunately, this doesn't apply to running SSH from your > laptop over the wireless network. > -- -- Joel Jaeggli Academic User Services [EMAIL PROTECTED] --PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary"
Re: Wireless insecurity at NANOG meetings
On 07:19 AM 9/23/02, Steven M. Bellovin wrote: >>I can't say without a sniffer, but I'd bet that most NANOG participants are >>doing the same: SSH or IPsec VPN's back to home (wherever that is). > >Experience doesn't support this, I fear. How many passwords were >captured last time? Passwords to *what*? Not all passwords need to be kept secret. When I login to read slashdot, I don't much care if someone sniffs the username and password. Just because a password was captured doesn't mean that knowing the username/password gives you access to anything special. Going back to that lock and door analogy, it's like when you have a latch on the front gate. It's there to keep the gate from swinging in the breeze, to keep dogs and kids who are playing on the street from aimlessly wandering into your front garden, etc. It's no big deal if other people can figure out how to work the latch and get into my yard. There are some things I keep behind latched gates. Other things are kept behind a locked door with a simple doorknob lock (easily picked or forced). Other things are behind a door with a deadbolt lock. Other things are behind a combination padlock. Some things are in a safety deposit box in the bank vault. We don't need to keep all valuable things in the safety deposit box, and we don't need to lock down the WLAN at NANOG as if it were access to a bank's intranet. jc
Re: Security Practices question
Hi John, Haven't seen you in a while. I hope all is well. Maybe I'll make it to a nanog or arin meeting again one of these days. As these are unix security questions and I've been a principle reviewer of the bible on unix sysadmin (by Ms. Nemeth et al)... At 03:22 PM 9/22/02 -0700, John M. Brown wrote: >What is your learned opinion of having host accounts >(unix machines) with UID/GID of 0:0 Learned opinion is, it is considered a back door. Period. It's bad enough having to have one login like that. On all the machines I manage, the (one) uid 0 account is never used. Period. In fact my staff don't routinely even know the root password. If root ever logs in, it is considered a breach. There is no need for it and I've yet to have anyone convince me otherwise in 15 years of doing this. The only time one needs to login as root is in single user mode when the system won't boot otherwise. For that, the root password is written in a sealed location known to all who need to know. If the seal is broken (meaning it was used), the password is changed. The problems are specifically: 1) Accountability. You don't know who is creating files and running processes. The best you might get are timestamps and source IP on things like wtmp and su logs for gross comparisons. That's not good enough in most cases. 2) How do you know that all programs protecting the "root" account always do so by UID rather than username? That is unless you view the code yourself or test all such mechanisms. E.g., sshd or login that prevents the root account (usually by default) from being logged into directly from the network interface. How about su where you are supposed to be a member or group 0 before you can suid to root? What about home grown code? It would be nice to think everyone was a good little programmer, but you don't know until you actually test every one of those protective mechanisms. 3) There can be unusual and unexpected behaviors. Some may be benign and confusing, others a problem. For example, all the files will appear as owned by "root" in 'ls' regardless of which of the uid=0 users created them (file ownership is stored by uid). See accountability above. Worse yet, your root files may appear as owned by jmbrown_r. It all depends on how your system reads the passwd database as to which name "wins." What home directory is used when a program needs to reference the users' home directory?? You better test this on your rmuser/userdel program, otherwise you may delete your real root home directory when you delete the other users. 4) Have you ever renamed the root account to something else and left it uid 0? Some of us have been unfortunate enough to have this happen by mistake (by someone who shouldn't have had root access). You would be surprised at what it breaks. Try this first. The bottom line is that the behavior is OS dependent. For example, I just tried this on BSDI and Linux. The BSDI box was pretty well-behaved by maintaining the proper (original) USER environment after su (even su -). On the linux box, once logged in or su'd the account was 100% indistinguishable from root in all respects. However, su without the - option left some original env vars, but not important ones. Using the 'passwd' command changed the password on the root named account, not the user that logged in on Linux, but not BSDI. However, the BSDI box showed jmbrown_r as the user for all root files using 'ls', the Linux box didn't. The behavior between the two OS was completely inconsistent. In sum, alternate uid=0 accounts are not necessary, problematic, and have OS dependent behavior. So if you are forced into providing them, you should first test each OS on which you are forced to do this. And test thoroughly. >The argument is that way you don't hav to give out the root password, >you can just nuke a users UID=0 equiv account when the leave and not >have to change the real root account. Specious. The counter argument is that you actually HAVE given out the "root" password. The definition of the "root" account is any account with uid=0. The username is not used for determining unix permission levels - which is of course the whole reason you want uid=0. All you've done is associated multiple passwords with _the_ only root account. That just makes it easier to crack. You've also made it possible for many people to change the "root" user password without them even realizing it. That will be fun when your system is toasted and you have no clue what the root password is. Single-user mode won't accept jmbrown_r's password. If the users to whom you've given such accounts are naive enough to believe that argument, that they don't have the "root" password, they may also be naive enough to share it with their buddies. There is often an argument that goes something like sudo doesn't fully change all of the user attributes, and that's not enough
Re: Pricing model for transit services
> - flat fee for a L Mbps link Also known as 'fractional' or 'tiered.' $x for y mb/s, and it is rate-limited. > - volume based, y $ per Mbps (95% quantile) for a L Mbps link > - burstable, flat fee for x Mbps on a L Mbps and z $ per Mbps above x These two are essentially the same. You do have three variations of usage-based, however: a) vth percentile: $x per y zzzbits/sec, with a t committment. Occasionally, any usage over t has a different price. b) 'Average usage', which is is the same as A, but using an averaging measurement system, rather than a percentile system (50th percentile is NOT the same as, or even relevant to, average). c) counting bytes: $x per y bytes. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: Wireless insecurity at NANOG meetings
> > > 10-15 minutes. None of the doors of that class is in your house. Why do you > > > have a door on your house? > > > > It keeps honest people honest, and opportunists from taking advantage of > > easy opportunity. > > Thank you. Why is it different from putting even rudimentary security in > place on the wireless LAN? I think it does exactly the same thing... And... I just opened up the wireless network at the local convention center for a convention. Placards at the entrance advertise it's presence, and that it is not secure. Reccomendations include NOT using plain POP e-mail.. etc..
Re: Wireless insecurity at NANOG meetings
On Mon, 23 Sep 2002 14:52:41 +0100 Simon Lockhart <[EMAIL PROTECTED]> wrote: > Someone sat in the hotel lobby with a powerful laptop isn't going to > cause > anyone to look twice, at a NANOG conference. ok, i think we need to talk about the actual threats at a nanog conference. 1) some otherwise harmless person gets free internet access for a couple of days. BFD. 2) some hacker uses free, untraceable access to do something nasty. hmmm. 3) some attendee gets hacked because they have security problems with their laptop. sounds like a personal problem to me. 4) some spammer parks nearby and sends out a lot of spam. so block port 25 outbound, don't offer mail servers, anyone who wants to send email can bloody well tunnel back to their home systems using ssh or ipsec. are there others i've missed? do we really care about anything other than 2, as the others have remedies or are else apparently unimportant? turning up WEP would keep the riffraff out. is that actually necessary or important? richard -- Richard Welty [EMAIL PROTECTED] Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security
Re: Wireless insecurity at NANOG meetings
In message <006a01c2630a$19725020$[EMAIL PROTECTED]>, "Stephen Sprunk" wr
ites:
>
>I can't say without a sniffer, but I'd bet that most NANOG participants are
>doing the same: SSH or IPsec VPN's back to home (wherever that is).
Experience doesn't support this, I fear. How many passwords were
captured last time?
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
Re: Wireless insecurity at NANOG meetings
Actually, from a legal standpoint, you put locks on the door same reason as u would on the wireless. Otherwise an invitation could be implied. It's hard for someone to argue that they were invited if they had to use breakin tools. Otherwise I dont think anyone would have a case, public area, public use lan If I was walking through a hotel and found an open LAN I would assume it was there for a perk of the hotel. I still dont see the problem with either side of this discussion. If we had a minor amount of security, I think the nanog goers could easily figure it out. If not, a little friendly assistance from the person sitting next to you and you might just have made a friend. Payoff with a simple beer later would suffice. Actually I believe it was Bill Woodcock that sent me mac drivers back in 1997 for the wireless. I may still owe him a beer though. dave At 9:04 -0500 9/23/02, Stephen Sprunk wrote: >Thus spake "Sean Donelan" <[EMAIL PROTECTED]> >> The wireless networks at NANOG meetings never follow what the security >> professionals say are mandatory, essential security practices. The NANOG >> wireless network doesn't use any authentication, enables broadcast SSID, >> has a trivial to guess SSID, doesn't use WEP, doesn't have any perimeter >> firewalls, etc, etc, etc. At the last NANOG meeting IIRC over 400 >> stations were active on the network. > >There is no useful security mechanism that can be applied to NANOG wireless. > >WEP assumes a black-and-white security model, just like most VPNs: >if a user is >on the "inside", they're fully trusted. This is somewhat reasonable in the >corporate world, where all of the users are employees who are responsible to a >common entity, but it has no application to NANOG or other public events where >none of the users are responsible to the operator, much less have >any trust for >each other. There is no sense giving people the illusion of security here. > >Many corporations are going to open access-points "outside" their firewall and >requiring per-user VPNs to access any data-center resources. This is the >simplest (and cheapest) solution to deploy and offers security folks the best >options for AAA besides. > >I can't say without a sniffer, but I'd bet that most NANOG participants are >doing the same: SSH or IPsec VPN's back to home (wherever that is). >Anyone who >isn't is begging to be hacked, WEP or not. Anyone interested in hacking NANOG >attendees' networks is likely a NANOG attendee himself. Caveat attendor. > >S -- David Diaz [EMAIL PROTECTED] [Email] [EMAIL PROTECTED] [Pager] Smotons (Smart Photons) trump dumb photons
Re: Wireless insecurity at NANOG meetings
Thus spake "Sean Donelan" <[EMAIL PROTECTED]> > The wireless networks at NANOG meetings never follow what the security > professionals say are mandatory, essential security practices. The NANOG > wireless network doesn't use any authentication, enables broadcast SSID, > has a trivial to guess SSID, doesn't use WEP, doesn't have any perimeter > firewalls, etc, etc, etc. At the last NANOG meeting IIRC over 400 > stations were active on the network. There is no useful security mechanism that can be applied to NANOG wireless. WEP assumes a black-and-white security model, just like most VPNs: if a user is on the "inside", they're fully trusted. This is somewhat reasonable in the corporate world, where all of the users are employees who are responsible to a common entity, but it has no application to NANOG or other public events where none of the users are responsible to the operator, much less have any trust for each other. There is no sense giving people the illusion of security here. Many corporations are going to open access-points "outside" their firewall and requiring per-user VPNs to access any data-center resources. This is the simplest (and cheapest) solution to deploy and offers security folks the best options for AAA besides. I can't say without a sniffer, but I'd bet that most NANOG participants are doing the same: SSH or IPsec VPN's back to home (wherever that is). Anyone who isn't is begging to be hacked, WEP or not. Anyone interested in hacking NANOG attendees' networks is likely a NANOG attendee himself. Caveat attendor. S
Re: Wireless insecurity at NANOG meetings
> Someone stood at your front door with lock picking tools for more than a > couple of minutes is going to arouse suspicion, and hopefully cause someone > to call the police. > > Someone sat in the hotel lobby with a powerful laptop isn't going to cause > anyone to look twice, at a NANOG conference. Neither would someone standing in front of your door with lockpicks on a busy streeet. You would be amazed how small those tools are. The point of the post was that knowledge of the limitations of tools that we use to protect access does not justify not using those tools at all. Alex
Re: Wireless insecurity at NANOG meetings
> > 10-15 minutes. None of the doors of that class is in your house. Why do you > > have a door on your house? > > It keeps honest people honest, and opportunists from taking advantage of > easy opportunity. Thank you. Why is it different from putting even rudimentary security in place on the wireless LAN? ALex
Re: Wireless insecurity at NANOG meetings
> > Rubbish. > > > > There are only two or three types of locks that cannot be picked from the > > outside by a lockpicker within 10-15 minutes. None of those locks is on your > > outside door. Why do you bother to lock your house? > > > But in the case of public WLAN, who is the one that you´re trying to keep > out? That is not the point that was responded to [1]. > You don´t give the keys to your house to 500 people so your analogy > sucks. Again that was not the point that was responded to. In a case of public wireless LAN or any other public line you by *definition* do not care about protecting public. Can someone please explain to me why (apart from relative ease of mounting those attacks) do we care about attacks mounted via wireless LANs more than attacks mounted over any other medium? Alex [1] The point that the original poster made was that since the WEP is rather trivial to break, one should not use WEP at all.
Re: Wireless insecurity at NANOG meetings
> 10-15 minutes. None of the doors of that class is in your house. Why do you > have a door on your house? It keeps honest people honest, and opportunists from taking advantage of easy opportunity.
Re: Wireless insecurity at NANOG meetings
On Mon Sep 23, 2002 at 09:47:06AM -0400, [EMAIL PROTECTED] wrote: > There are only two or three types of locks that cannot be picked from the > outside by a lockpicker within 10-15 minutes. None of those locks is on your > outside door. Why do you bother to lock your house? Someone stood at your front door with lock picking tools for more than a couple of minutes is going to arouse suspicion, and hopefully cause someone to call the police. Someone sat in the hotel lobby with a powerful laptop isn't going to cause anyone to look twice, at a NANOG conference. Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services| Email: [EMAIL PROTECTED] Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/
Re: Wireless insecurity at NANOG meetings
> > Rubbish. > > There are only two or three types of locks that cannot be picked from the > outside by a lockpicker within 10-15 minutes. None of those locks is on your > outside door. Why do you bother to lock your house? > But in the case of public WLAN, who is the one that you´re trying to keep out? You don´t give the keys to your house to 500 people so your analogy sucks. Pete
Re: Wireless insecurity at NANOG meetings
> > At 06:41 PM 9/22/2002 -0400, William Allen Simpson wrote: > >... But, it is still the only > >Access Control widely available. So, it should be used, in addition to > >the better methods. > > Using a supposed security mechanism that is known to be essentially useless > does nothing but lull people into a false sense of security. Rubbish. There are only two or three types of locks that cannot be picked from the outside by a lockpicker within 10-15 minutes. None of those locks is on your outside door. Why do you bother to lock your house? There is only one class of door designs that cannot be broken through in 10-15 minutes. None of the doors of that class is in your house. Why do you have a door on your house? Alex
Pricing model for transit services
Hello, We are working on a research project on interdomain traffic engineering and would like to quantitatively evaluate interdomain traffic engineering solutions in a realistic way. We have a BGP simulator that allows us to simulate networks with a few hundreds of AS and are adding several mechanisms to this simulator. To complement the simulator, we are looking for realistic cost models of transit services. Since we do not buy transit services, we have some difficulties finding this information. For the moment, our cost models are the following : - flat fee for a L Mbps link - volume based, y $ per Mbps (95% quantile) for a L Mbps link - burstable, flat fee for x Mbps on a L Mbps and z $ per Mbps above x We would like to know whether these three cost models accurately reflect the current pricing schemes of transit services and what are the most popular ones ? If you know other pricing schemes that should be taken into account, we would appreciate to have additional information. I heard of destination-based pricing schemes, but do not have enough details on them and don't know whether they are frequently used. You can either answer directly to us ([EMAIL PROTECTED] and [EMAIL PROTECTED]) and we will summarize or directly to the list. Thanks a lot for your help, Olivier Bonaventure --- http://www.infonet.fundp.ac.be
Re: Wireless insecurity at NANOG meetings
In message <[EMAIL PROTECTED]>, Sean
Donelan writes:
>
>On Sun, 22 Sep 2002, Randy Bush wrote:
>> - the users need to be told how to operate more safely, use
>> end-to-end authentication and privacy, etc. it's a matter of
>> education. and the education will stand them in good stead
>> when they use 802.11 at starbucks, airports, etc. we do this
>> at ietf, but it is not allowed at nanog.
>
>Sunday afternoon is full of tutorials on lots of different subjects.
>Has anyone volunteed to conduct a Sunday tutorial on wireless security
>for users of "public" wireless networks?
>
>Although I think it is a mistake to think a wireless network security
>is different than using any other network you don't control. Most
>wireless security tutorials tend to concentrate on "securing" the
>wireless network instead of how to communicate over an untrusted
>network.
>
Precisely -- and it's precisely why I'm not a big fan of "wireless
security" as a discipline: my threat model for the wired network has
never been any different than for wireless...
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
Re: Security Practices question
On September 22, 2002 07:41 pm, Ryan Fox wrote: > On Sun, 2002-09-22 at 18:22, John M. Brown wrote: > > What is your learned opinion of having host accounts > > (unix machines) with UID/GID of 0:0 > > > > jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh > > The biggest argument I have against creating accounts with uid 0, is > that even as an admin, I appriciate not always having admin privs. I suspect that the "_r" in the login means that there is a regular jmbrown in the system as well. I must admit that I do this too. I only do it for people I trust completely and only when there are two or, rarely, three people with root. That way if you see a change and you didn't do it you generally know who did. Also you get slightly better logging on some commands that log the user name rather than the UID. Of course, sudo is still better for all of this overall. -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
Re: Wireless insecurity at NANOG meetings
In message <[EMAIL PROTECTED]>, Sean
Donelan writes:
>
>On Sat, 21 Sep 2002, Martin J. Levy wrote:
>> >I agre security is sadly lacking, but it is probably impossible to
>> >implement in a conference environment.
>>
>> Look this is a very simple issue. Sean's first post really pointed out
>> that it's "bad form" for a set of operators to run an insecure network.
>> I would believe that it's "good form" to at least try. It was stated
>> that the network was not run by the "operators". OK, I accept that, but
>> it's run by people with great (actually fantastic) connections to real
>> operators (ie: us).
>
>I feel like a Rorschach Test.
>
>Is the Nanog confernce network really insecure for its purpose?
>
This is the real question -- what are you trying to protect?
Apart from its (many) other problems, WEP is useful for protecting
a single hop at layer 2. It does not protect against attacks at higher
layers. (That's true of virtually all security mechanisms, I might add
-- and I say "virtually" because I don't really trust my reasoning at
at an hour when I really should be asleep, but I think that "all" is
correct.) Apart from the problem of attacks from the Internet --
surely we don't want NANOG to run a firewall for us -- there are easy
attacks that can bypass WEP. For example, someone could use
ARP-spoofing to launch an active attack on even non-sensitive Web
traffic. Btw -- that has happened on the wireless network at at least
two conferences I've been to in the last few years. And no, these
weren't black hat or grey hat conferences.
If it weren't for the cryptanalytic attack on RC4 -- the one attack on
WEP that wasn't foreseeable -- and if it had been done properly in
other respects (i.e, if it had per-user keying, key management, and no
"IV" collisions), WEP could provide access control. We could even
imagine an AES-based WEP with key management, etc. -- and *all* it
would buy us is access control.
Is that worth it for NANOG? Again, what are you trying to protect? Is
access to the conference net a resource that needs to be protected?
Maybe it is, if you're concerned about drive-by spammers.
But there's another resource, and that's the reputation of NANOG, or at
least of its members, as folk who know how to run a network. Wide-open
802.11 networks are often a bad idea, precisely because access is a
resource that needs to be protected. Beyond that, there's sometimes a
"good neighbor" issue -- you don't want to accidentally attract
folks who want to be on some local net of their own. Maybe a closed
net is reasonable for that purpose -- but that's about it.
If you want to protect yourself, make sure that your software is fully
patched, you expose as few services as possible to the outside, and
that you don't send anything unencrypted if it's at all sensitive if
intercepted or modified. Beyond that, make sure that you're lucky,
because new holes can be found at any time.
Note, btw, that I didn't say "do that at conferences", or "do that for
802.11 hosts"
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
Re: Wireless insecurity at NANOG meetings
> On Sun, 22 Sep 2002, William Allen Simpson wrote: > > > Sorry, any security requires a *SECRET*. The only thing security really requires is *trust*. Secret keys won't do any good if the platform is compromised. Elaborate protections are useless if people who are allowed access are untruthworthy. No matter what you do it always boils down to trustworthiness of the physical implementations and people. Technological tricks simply modify the communication space by shifting vulnerable points around. This is often useful, but by no means can eliminate the need for inherently trusted devices and people at the end points. --vadim PS. As a side note - the "shocking" discovery that ObL's guys didn't really use steganography and other modern tricks much and still have world-wide network which is very hard to compromise or penetrate (all those montains of cool high-tech gagetry NSA has, notwithstanding) is a good illustration: they rely on the "first principle" of building trusted systems - i.e. building the network of personal loyalties and face-to-face communications, instead of fooling with techno fixes. PPS. I'm really really amazed at how people can consider any opaque system truthworthy. Most computer users naively trust their secrets to effectively every one of thousands of Microsoft engineers who can easily plant trapdoors. The same goes for trusting Intel. How hard it is for a CPU designer to plant an obscure bug causing switch to a privileged mode? It is hard _not_ to create trapdoors like that by mistake, even in much simpler designs (check the 30-year old report on Multics security).
