Re: ARPANet Co-Founder Predicts An Internet Crisis (slashdot)
On 10/25/07, Paul Vixie [EMAIL PROTECTED] wrote: an economic crisis. Of course, Roberts has an agenda. He's now CEO of Anagran Inc., which makes a technology called flow-based routing that, Roberts claims, will solve all of the world's routing problems in one go. Anyone have any experience with these Anagran flow routers? Are they that much of a departure from traditional routing that it makes a big difference? I haven't done a lot of research into flow-based routing at this point, but it sounds like this would be similar to the MPLS approach, no? How about cost per port versus traditional routers from Cisco or Juniper? It seems that he cites cost as the main point of contention, so are these Anagran routers truly less expensive? -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: Using Mobile Phone email addys for monitoring
On 9/6/07, Rick Kunkel [EMAIL PROTECTED] wrote: Hello folks, It seems especially prevalent when MANY things are sent at once; if, for example, a central piece fails, and dependent pieces suddenly fail as well. I'd probably recommend implementing some sort of parent/child system to reduce the number of messages you receive. Couple that with an acknowledgment syetem to re-page every so often to remind you, and it works out really well. That way you're not overloading the person receiving the alerts, and, especially with SMS, it costs less to send them. Thanks, Rick Kunkel -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: Interesting new dns failures
On 5/20/07, Roger Marquis [EMAIL PROTECTED] wrote: Most of the individual nameservers do not answer queries, the ones that do are open to recursion, and all are hosted in cable/dsl/dial-up address space with correspondingly rfc-illegal reverse zones. Running 'host -at ns' a few times shows the list of nameservers is rotated every few seconds, and occasionally returns server localhost. They're likely not name servers, or at least not all name servers.. I'd venture a guess as to these being part of a Snowshoe spammer network... I've been getting hit by similar domains for a few weeks now.. Blocking seems to be the best way to handle them.. Looks like some of these are running nginx (http://nginx.net/) as a web server... I've seen others with centos installs.. My guess is that the web servers are for management of the spamming software.. Roger Marquis -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: ISP CALEA compliance
On 5/10/07, Jack Bates [EMAIL PROTECTED] wrote: I think what he meant was My DSL has been broke for 3 months now, and I haven't not be able to use it. You can't charge me for something which wasn't working! Question #1 - Did you bother to call our technical support hotline? No? Well then it can hardly be our fault that you're not working. Oh, you did call? (checks support records) .. No, no I don't see that in there.. Please pay the bill. -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: ISP CALEA compliance
On 5/11/07, Brandon Galbraith [EMAIL PROTECTED] wrote: My understanding was data you had needed to be turned over when requested, but CALEA provides no specification/guidance on log retention. Agreed. My understanding, to date, is that the data to be turned over is data collected from the beginning of the CALEA tap. Historical data can be requested, but I'm not aware of any official legal guidelines on retention time. -brandon -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: ISP CALEA compliance
On 5/11/07, Todd Glassey [EMAIL PROTECTED] wrote: Gee Steven, that's what everyone thought prior to a Federal Judge ordering Microsoft to produce seven years of Email... I believe that was because they knew MS *had* that email. Of course, any missing email can probably be tossed together pretty quickly using some fairly simple algorithms, perhaps by using many of the BS generators already on the Internet.. :) That said, if you really don't have 7 years worth of email, then the Federal Judge can order till he's red in the face. TSG/ -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: ISP CALEA compliance
On 5/10/07, Jared Mauch [EMAIL PROTECTED] wrote: If you're not offering VoIP services, your life may be easier as you will only need to intercept the data. Depending on your environment you could do this with something like port-mirroring, or something more advanced. There are a number of folks that offer TTP (Trusted third-provider) services. Verisign comes to mind. But using a TTP doesn't mean you can hide behind them. Compliance is ultimately your (the company that gets the subponea) responsibility. Here's a question that's come up around here. Does a CALEA intercept include hairpining or is it *only* traffic leaving your network? I'm of the opinion that a CALEA intercept request includes every bit of traffic being sent or received by the targeted individual, but there is strong opposition here that thinks only internet-related traffic counts. - Jared (IANAL!) -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: ISP CALEA compliance
On 5/10/07, Patrick Muldoon [EMAIL PROTECTED] wrote: We've been under the impression that is *all* data. So for us, things like PPPoE Sessions, just putting a tap/span port upstream of the aggregation router will not work as you would miss any traffic going from USER A - USER B, if they where on the same aggregation device. Since the Intercept has to be invisible to the parties being tapped, you can't route their traffic back out and then in either, since the tap would change the flow.In that regard, we've been upgrading our older NPE's to newer ones in order to support SII, All the while I keep having something a co-worker said stuck in my head. CALEA - Consultant And Lawyer Enrichment Act :) Agreed.. Now to dig into the legal document to see if this is right.. Anyone have a legal gibberish to english converter? (And no, a lawyer doesn't count) -Patrick -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Bandwidth Augmentation Triggers
Greetings, I'm working on a system to alert when a bandwidth augmentation is needed. I've looked at using both true averages and 95th percentile calculations. I'm wondering what everyone else uses for this purpose? We're talking about anything from a T1 to an OC-12 here. My guess is that the calculation needs to be slightly different based on the transport, but I'm not 100% sure. Thanks, -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons
On 3/2/07, Roland Dobbins [EMAIL PROTECTED] wrote: No one has done the digging required to answer any of these questions, unfortunately. Can you get a valid answer to this based on the existence of BCP38? What I mean is, if your upstream is filtering bogons, you can't get a good read on the amount of bad traffic sourcing from illegal addresses. However, I'm sure it's there. If we stop filtering so-called bad addresses, I'm sure that the attacks from those addresses will increase when it's realized that the filters are gone. I agree with others in that you can't stop looking for old attacks just because they don't happen much anymore. But we can improve the ways we look. uRPF is definitely a dynamic option, but as I understood it, there were issues with using it on multi-homed networks with asynchronous routing. Granted, it has been some time since I've looked at uRPF. I think something like the Cymru bogon route server is great, but I'm not a very trusting person when it comes to something like that. I don't like giving up that level of control. Of course, at some point, I suppose have to trust something... I definitely believe in filtering both bogons and RFC 1918 space, it's just a management issue that has to be dealt with. --- Roland Dobbins [EMAIL PROTECTED] // 408.527.6376 voice -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: Comment spammers chewing blogger bandwidth like crazy
On 1/16/07, Simon Waters [EMAIL PROTECTED] wrote: This is the same issue as the email spam issue. Identify by source, or content. Just as content filters are error prone with email spam, they will be error prone with other types of content. Agreed, but the average end-user has not been subjected to the long, arduous, usually fruitless task of requesting their IP be removed from a DNSBL. So what's the alternative? Popping up a page to allow them to be removed from the list? While this may work, getting an IP removed generally takes days, if not weeks. By that time, any comment they wanted to post would be irrelevant. You could mark that particular comment as moderated and check it by hand, but then the spammers will adapt and go through the motions with every comment, making moderation difficult if not impossible. I think either approach is viable, as long as the poster has an immediate method of redress. (My IP is clean works, and scales, this URL is safe works but doesn't scale, this post is safe is viable). In each case you need to make sure the redress is protected from abuse, so some sort of CAPTCHA is inevitable. Hrm.. captchas have their own set of problems. Accessibility, confusion, etc. Not that they don't work, but if you make the captcha readable enough for humans, then it's inevitable that an OCR program will be able to identify it as well. There has been some progress with alternative captchas that require some thought on the user end, but in the end it becomes frustrating. -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: Comment spammers chewing blogger bandwidth like crazy
On 1/14/07, Gadi Evron [EMAIL PROTECTED] wrote: Your assumption is incorrect. These DNSBLs cover spam sent in email, indeed. Thing is, spam is spam and spammers are spammers. Meaning, they spam in every way they can. How does this make his assumption incorrect? Spam is spam and DNSBLs will likely be very effective when it comes to stopping comment spam. There are, of course, some severe problems with using a DNSBL as a blocklist for comments... I've been working on a new DNSBL for comment/etc. spam for a while, which will be reliable, generally, it doesn't exist yet for public consumption. But there's a major problem here... A DNSBL is a source blocklist. Since the current trend in spam (comment and smtp) is to use botnets, then by blocking the bots, you also block the users who would make meaningful comments. The argument there is that those users don't deserve to comment if they can't keep their computers clean, but let's get real.. Some of this stuff is getting pretty advanced and it's getting tougher for general users to keep their computers clean. I think a far better system is something along the lines of a SURBL with word filtering. I believe that Akismet does something along these lines. There is such a black listing service already, but again, reliability is an issue. Reliability is always an issue with blacklists as they are run as independent entities. There is always someone who has a problem with how an individual blacklist is run... Gadi. -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] http://blog.godshell.com
Re: Quarantine your infected users spreading malware
On 2/23/06, Andy Davidson [EMAIL PROTECTED] wrote: And they don't care ! How is someone else telling them that they need a virus checker going to change anything ? It's not. That's why services such as AOL integrate it with the system.. Granted, the user has to initially accept it, but it's a virtually painless process.. AOL's software does all the work. If a user has to download each individual program, install it, ensure it's updated, etc., then they tend to ignore the use of such a product. Even mostly-automated updates are a burden for them because messages pop up now and then telling them that they're not up to date, warnings about new outbreaks, etc. Most users don't care one way or the other and it's simpler for them to ignore the whole situation. For something like AVG, yes it's free. But, I don't think that includes allowing an ISP to package it up and distribute it as a value-added feature.. Most companies frown on that sort of thing. I believe even Microsoft's EULA forbids distributing SP2 without strict permission. -a -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Quarantine your infected users spreading malware
On 2/21/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Why not just bypass them and go direct to the unwashed masses of end users? Offer them a free windows infection blocker program that imposes the quarantine itself locally on the user's machine. This program would use stealth techniques to hide itself in the user's machine, just like viruses do. And this program would do nothing but register itself with an encoded registry, and listen for an encoded command to activate itself. Rather like a botnet except with the user's consent and with a positive goal. Intruiging concept.. Why bother hiding itself though? Or is the idea to prevent itself from being removed by malware? When the community of bot/worm researchers determines that this machine is infected, they inform the central registry using their own encoded signal. When enough votes have been collected, the registry sends the shutdown signal to the end user, thus triggering the blocker program to quarantine the user. Isn't there a risk of DoS though? What's to prevent someone from spoofing those signals and shutting down other users? Relative precautions would need to be taken, but to be sure, the end-user needs the ability to override the system. Thus leaving us in the same situation as before. Firewall? I don't need no stinking firewall.. :) Unlike antivirus software, the application on the user's computer does not need to detect malware and it needs no database updates. It does only one thing and it relies on the collective intelligence of the anti-malware community. Sure it does.. It doesn't need to remove it, per se, but it will need to know what the infection is so it can give the correct disinfection instructions.. --Michael Dillon -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Quarantine your infected users spreading malware
On 2/21/06, Bill Nash [EMAIL PROTECTED] wrote: If you're talking about a compulsory software solution, why not, as an ISP, go back to authenticated activity? Distribute PPPOE clients mated with common anti-spyware/anti-viral tools. Pull down and update signatures *every time* the user logs in, and again periodically while the user is logged in (for those that never log out). Require these safeguards to be active before they can pass the smallest traffic. Cost prohibitive.. In order to do that you'll need licenses from the AV companies.. The change in traffic flow would necessitate some architecture kung fu, maybe even AOL style, but you'd have the option of selectively picking out reported malicious/infected users (*cough* ThreatNet *cough*) and routing them through packet inspection frameworks on a case by case basis. Quite possibly, you could even automate that and the users would never be the wiser. And then the privacy zealots would be livid.. Silently re-routing traffic like that.. How dare you suggest such a ... wait.. hrm.. The internet basically does this already.. I wonder if the zealots are aware of that.. :) - billn -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Quarantine your infected users spreading malware
On 2/21/06, Bill Nash [EMAIL PROTECTED] wrote: Big deal. You're talking about volume licensing at that point, and offering vendors an opportunity to compete to get on every desktop in your customer base. That's a big stick to negotiate with, especially if you're an Earthlink or AOL. Agreed. And with that, the little guys go away. Yeah, the privacy zealots, of which I'm one, don't have much of a leg to stand on, since as the direct service provider, you'd be directly within AUP/Contractually provided rights to do so, under that particular service model. They can't ding you for being active in your *response* to complaints about malicious activity sourced from your network, and taking the time to verify it. So long as you're keeping their personal information out of the hands of others, they don't have much to bitch about. Agreed, but without publishing the exact procedures, protocols, etc, they can always complain that something might be happening.. Don't get me wrong, I'm just as much for privacy as most of the zealots, but there is a point at which there has to be an acceptable risk. The ISPs win because they've got ready means to tie complaints directly back to an active customer, AND verify the complaint. Consumers win because they've got cheap anti-virus they still don't have to do anything about. The internet wins because ISPs are sharing non-personally identifying information about naughty behaviour and maybe increasing the mean TTL for new Windows machines. In the long term, privacy advocates win because networks have implemented active responses to attacks that routinely lead to identity theft. I wish everyone had this view. Fixing, or at least patching, this problem would help out a lot in the long run. But there's a lot to be done to handle it. An ISP can deal with it themselves or, more often than not, can ignore it. As I was saying before, if there were some sort of standards body that set forth a best practices guide of some sort, that might go a long way. Education for the end-user is key here too. Educate them to understand what precautions are in place at the ISP level, and what they can do to protect themselves. I think it's gotten better in recent years, despite the increase in viral activity. I think the increase is due to better propogation techniques rather then hordes of dumb users. The biggest hole I see in this concept is home routers that do NAT (linksys, linux boxes, etc). While capable of PPPOE, you can't quite mandate the A/V clients. You still have the option of doing packet inspection, which is still better than nothing. Hrm.. Unless some sort of shim was required on the end-user computer.. something transparent that merely identified itself in the background to the central authority and verified signatures and the like.. - billn -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Quarantine your infected users spreading malware
On 2/20/06, Edward W. Ray [EMAIL PROTECTED] wrote: ISPs should not police users, just like auto manufacturers should not police drivers. That is what driver's licenses are for. So the state polices the drivers.. Should the state police the internet as well? And how would that be implemented? The ISP will take the brunt of the operational interference anyways as the police have no other way of stopping those drivers. And when Joe Drivers gets busted and banned, he'll make up a new identity to use at ISP B. I tend to agree with Gadi that we, the ISPs, need to do at least some blocking. I don't see it happening anytime soon though. There's still way too many ops out there who take something like this as a challenge to their ablility to operate a network when in fact, it's the users who are the problem. I'd rather open up everything and allow a user 100% unfiltered access, but most users don't know what to do with that and don't take proper precautions. So, for residential users I think that a reasonable filter should be applied. Block stuff like Netbios. Implement spoofing filters. Do whatever you can to protect the users without impacting their ability to use the internet. For commercial users, offer simple protection, or make sure they know that they will be help responsible for virus activity sourcing from them. Shut down those ports if they become active. I also like the idea of putting infected users in a quarantine. Alert them via an automated process. Give them access to updates, but prevent them from infecting others. I think this is a more than reasonable expectation from end-users. In fact, I'd be more inclined to use an ISP that has safe-guards like this in place. It might even be worth it to put together a best practices guide that lays out the minimum requirements for something like this. (It may even exist.. If so, I'd be interested in reading it if someone would be kind enough to provide a link) Ed Ray Go Go Gadget Flame-Retardent Suit! -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: MLPPP over MPLS
On 2/17/06, Hyunseog Ryu [EMAIL PROTECTED] wrote: Maybe next monday I can ask for detailed info, but I wasn't on the meeting to discuss this in detail. Based on outcome of discussion with Cisco, we decided to go with MLFR instead of MLPPP. Any idea if this issue is just another unfixed bug, or is it something deeper? Hyun -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: McDonalds contact also.
On 1/31/06, Brian Johnson [EMAIL PROTECTED] wrote: I've got a great idea for a new cheeseburger and want someone to give me a contact at McDonalds. I am too lazy to find one myself, and don't care about wasting any of your time. Please reply off-list. offlist Sorry, that idea has already been patented. You'll be hearing from my lawyer. Also, you used a trademarked name without permission on a public list. You'll be hearing from their lawyers too cause I'm tellin! /offlist Brian. -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Compromised machines liable for damage?
On 12/27/05, Owen DeLong [EMAIL PROTECTED] wrote: Look at it another way... If the software is open source, then, there is no requirement for the author to maintain it as any end user has all the tools necessary to develop and deploy a fix. In the case of closed software, liability may be the only tool society has to protect itself from the negligence of the author(s). What is the liability situation for, say, a Model T car if it runs over someone? Can Ford still be held liable if he accident turns out to be caused by a known design flaw in the car? (I don't know the answer, but, I suspect that it would be the same for old software). But can't something similar be said for closed source? You know there's a vulnerability, stop using it... (I'm aware that this is much harder in practice) snip dead horse / In general, if the gross act of stupidity was reasonably foreseeable, the manufacturer has a duty to care to make some attempt to mitigate or prevent the customer from taking such action. That's why toasters all come with warnings about unplugging them before you stick a fork in them. That's why every piece of electronic equipment says No user serviceable parts inside and Warning risk of electric shock. So what if Microsoft put a warning label on all copies of Windows that said something to the tune of Not intended for use without firewall and anti-virus software installed ? :) Isn't the consumer at least partially responsible for reasonable precautions? They feel for the carpenter and the only option they have to help him is to take money from the corporation. I'm all for compassion, but sometimes it's a bit much.. :) Owen I guess, in a nutshell, I'm trying to understand the liability issue... It seems, based on the arguments, that it generally applies to stuff that was received due to some monetary transaction. And that the developer/manufacturer/etc is given a chance to repair the problem, provided that problem does not exist due to gross negligence on the part of the developer/manufacturer/etc ... Does that about sum it up? [From your other mail] SPAM does a lot of actual harm. There are relatively high costs associated with SPAM. Machine time, network bandwidth, and, labor. *nod* I agree.. My point here was that SPAM, when compared to something like a virus, is *generally* less harmful. Granted, SPAM is more of a constant problem rather than a single virus that may attack for a few days before mitigation is possible. I spend a great deal of time tweaking my mail servers to prevent spam.. :) -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Compromised machines liable for damage?
On 12/27/05, Marshall Eubanks [EMAIL PROTECTED] wrote: There was a lot of discussion about this in the music / technology / legal community at the time of the Sony root exploit CD's - which I and others thought fully opened Sony for liability for 2nd party attacks. (I.e., if a hacker uses the Sony root kit to exploit your machine, then Sony is probably liable, regardless of the EULA. They put it in there; they made the attack possible.) IANAL, but I believe that if a vendor has even a partial liability, they can be liable for the whole. But, what constitutes an exploit severe enough to warrant liability of this type? For instance, let's look at some scripts ... formmail is a perfect example. First, there was no real EULA. I'm definitely not a laywer, but I would think that would open up the writer to all sorts of liability... Anyways, the script was, obviously, flawed. Spammers took notice and used that script to spam all over the place. This hurt the hoster of the script, the people who were spammed, and probably the ISPs that wasted the bandwidth carrying the spam. So, should the writer of the script be sued for this? Is he liable for damages? If that's the case, then I'm gonna hang up my programming hat and go hide in a closet somewhere. I'm far from perfect and, while I'm relatively sure there are none, exploitable bugs *might* exist in my software. Or, perhaps, the exploit exists in a library I used. I've written a lot of PHP code, perhaps PHP has the flaw.. Am I still liable, or is PHP now liable? This has scary consequences if it becomes a blanket argument. Alternatively, if the programmer is made aware of the problem and does nothing, then perhaps they should be held accountable. But, then, what happens to old software that is no longer maintained? I suspect that eventually EULA's will prove to be weak reeds, in much the same way that manufacturers may be liable when bad things happen, even if the product is being grossly misused. My intuition says that unfortunately somebody is going to have to die to establish this, as part of a wrongful death suit. With the explosion in VOIP use, this is probably only a matter of time. Personally, I feel that is a person grossly misuses a product and is hurt as a result, they deserve it. Within some acceptable reason, of course. One expects that if you place a cup of coffee in your lap, that you just purchased, I might add, that it may burn you if it spills. Or, if you puncture a can of hair spray near an open fire, you may experience a slight burning sensation a few seconds later. People, use your brains. Next we'll have someone suing craftsman when they chop their leg off because there was no label on the saw that said don't place running saw in lap ... Come on, how stupid can you be? I apparently wouldn't make a good judge because I'd laugh most of these cases right out of the courtroom! Reasonable precaution should be expected of all people. Regards Marshall Eubanks -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Compromised machines liable for damage?
On 12/27/05, JC Dill [EMAIL PROTECTED] wrote: I am not a lawyer, but I believe there is a significant difference in the liability that ensues from knowingly selling a defective product, and from giving something away for free. Matt gave away FormMail for free. When Matt wrote FormMail open relays were common on the internet. His Perl scripts were similar in security and utility to other software at the time. Once it became known how this type of software could be abused, *then* he had an obligation (moral obligation if not strictly legal obligation) to stop distributing the old insecure scripts, which is what he did. And I would agree with this reasoning. If the software is defective, fix it or stop selling it. However, I don't think all software developers have control over the selling of the software after it's sent to the publisher. (I'm by no means intimate with how all this works) So, for instance, if developer A creates product A+, publisher P deals with packaging it up, distributing it, etc. A few months later, developer A goes out of business for some insane reason. Publisher P continues to sell the software in which a security hole is discovered a month later. There's no way for developer A to fix the hole, they don't exist. And publisher P isn't near smart enough to fix it. So they just continue selling it. Life goes on, it eventually falls into the bargain bin where publisher P continues to package it, but in recycled fish wrap instead of the pristine new boxes it used to. So is developer A still liable? Is publisher P liable? Should they be? If you tell someone be careful, that coffee is hot and may burn you most people will equate burn with might cause some temporary pain or perhaps a minor blister and not with I will spend 2 weeks in the hospital with 3rd degree burns and require skin grafts and have over $20k in medical bills. Stella assumed the coffee she was served was served was at a normal hot coffee temperature, hot enough to perhaps hurt a bit if spilled but NOT so hot as to cause severe and disfiguring burns. See: Still, a little common sense... Hot coffee of any type, between the legs, in a moving car? Umm.. even normal coffee still causes a jump of pain. That jump of pain could easily cause a car accident. So who do I sue? McDonalds for selling the coffee? Or the driver who put it between his/her legs? Most people expect that their operating system and browser will work securely, not that it will let intruders steal their data, compromise their privacy, and inflict damage on others. Just as McDonalds was held liable for repeatedly intentionally selling coffee they knew was being served too hot and capable of causing much greater harm than the buyer was aware of, IMHO so should a software company be held liable for repeatedly knowingly selling defective software, especially when that software causes damage to 3rd parties who have not agreed to the EULA. If it's a known issue and the developer continues to ignore it, then yeah, they should probably be held accountable. But, there's still the issue of what is bad and what isn't. Madden 2006 for the PSP reboots when I end a franchise mode game. It destroys the data I just spent 30 minutes generating while playing the game. Is that bad enough that the company should be held liable for it? (Yes, I'm aware they're replacing the discs now. Excellent move on EA's part) There's another form mailer out there that I dealt with, and wrote a large post on Bugtraq about, that continues to allow relaying even after a complete bug report with a fix. Should that developer be held liable for damages? It's just spam, it's not really hurting anyone, is it? Then there's something like Internet Explorer. Any one of the dozens of exploits allows a remote attacker to assume control of the computer ... That's bad.. That's definitely an issue. I could agree that the developer should be held liable for that ... Maden 2006 I had to pay for. IE came with Windows, so I didn't *really* have to pay for it, depending on how you look at it. The form mailer was free on the internet. Does having to pay for it determine if the developer should be liable? What if Linux had a security hole that was reported and never fixed? Should Linus get sued? Wow.. who would you even sue in that instance? Software confuses things a bit I think.. I can agree that an IE bug, unchecked, should be liable. But a form mailer? It was free to begin with, so just move on to something else... I'm not sure I, personally, could get behind holding software companies liable until some standard was set to determine what the expectations were... And setting those standards is the hard part... jc -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Weird DNS issues for domains
On 9/29/05, Matthew Crocker [EMAIL PROTECTED] wrote: I'm hoping someone on the list can help confirm that I'm not going insane. How can you be sure it's not the other way around? You're sane and everyone else is insane? :) Can someone confirm my sanity? My zone of control starts at mtrsd.k12.ma.us I do not have control over k12.ma.us What do you all see for sanderson.mtrsd.k12.ma.us www.sanderson.mtrsd.k12.ma.us. [EMAIL PROTECTED] ~]$ dig mtrsd.k12.ma.us ns ; DiG 9.2.4 mtrsd.k12.ma.us ns ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 23100 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mtrsd.k12.ma.us. IN NS ;; ANSWER SECTION: mtrsd.k12.ma.us.86120 IN NS dns-auth2.crocker.com. mtrsd.k12.ma.us.86120 IN NS dns-auth1.crocker.com. ;; Query time: 3 msec ;; SERVER: 204.10.167.4#53(204.10.167.4) ;; WHEN: Thu Sep 29 10:38:50 2005 ;; MSG SIZE rcvd: 92 [EMAIL PROTECTED] ~]$ dig sanderson.mtrsd.k12.ma.us ns ; DiG 9.2.4 sanderson.mtrsd.k12.ma.us ns ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 28515 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;sanderson.mtrsd.k12.ma.us. IN NS ;; ANSWER SECTION: sanderson.mtrsd.k12.ma.us. 259200 INNS dns-auth2.crocker.com. sanderson.mtrsd.k12.ma.us. 259200 INNS dns-auth1.crocker.com. ;; Query time: 33 msec ;; SERVER: 204.10.167.4#53(204.10.167.4) ;; WHEN: Thu Sep 29 10:39:27 2005 ;; MSG SIZE rcvd: 102 [EMAIL PROTECTED] ~]$ dig www.sanderson.mtrsd.k12.ma.us a ; DiG 9.2.4 www.sanderson.mtrsd.k12.ma.us a ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 28640 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.sanderson.mtrsd.k12.ma.us. IN A ;; ANSWER SECTION: www.sanderson.mtrsd.k12.ma.us. 86400 IN CNAME www.mtrsd.k12.ma.us. www.mtrsd.k12.ma.us.600 IN A 159.250.29.161 ;; Query time: 64 msec ;; SERVER: 204.10.167.4#53(204.10.167.4) ;; WHEN: Thu Sep 29 10:39:33 2005 ;; MSG SIZE rcvd: 81 -- Matthew S. Crocker Vice President Crocker Communications, Inc. Internet Division PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Cisco IOS Exploit Cover Up
On 7/27/05, Jeff Kell [EMAIL PROTECTED] wrote: Cisco's response thus far: http://www.cisco.com/en/US/about/security/intelligence/MySDN_CiscoIOS.html Jeff More fuel on the fire... Cisco and ISS are suing Lynn now... http://news.zdnet.co.uk/internet/security/0,39020375,39211011,00.htm -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Cisco IOS Exploit Cover Up
On 7/28/05, Leo Bicknell [EMAIL PROTECTED] wrote: I am not a lawyer, and so under the current DMCA and other laws it may well be illegal to decompile code. I'm sure all the script kiddies and real hackers out there will be sure to obey the law.. This is the bit of the DMCA I have a huge issue with.. Hackers and others engaging in illegal activities will have no trouble breaking the law and decompiling code looking for exploits. But, if a researcher does it, they get slapped with a lawsuit.. The difference being, the researcher is (usually) doing it to help identify problems and increase security.. There should be some safe harbor here.. That said, it sounds rather like the technical equivilant to Ralph Nader disassembling the Corvair to prove the suspension design was flawed. GM sure didn't like that any more than Cisco likes this incident. To prove a flaw.. This is a great example. Nader wasn't stealing technology, nor was he interested in exploitinig the flaw.. He was proving that it was unsafe, thus providing the vendor with vital information on how it was flawed.. Hopefully the vendor takes that information and fixes the flaw.. I don't know when we decided a program should be a black box welded shut kept from all prying eyes, and that anyone who could run a decompiler was instantly a crimimal. It probably all came about from the crazy decision that software should be licensed, not sold. We'd be in a world of hurt if anyone who figured out how to put a lift kit on his pickup was sued by ford for disassembling the truck and figuring out their propretary internal designs. Why is software special? Good point.. :) What about my house? Can I no longer modify my kitchen at the whim of my wife because I didn't build the house, someone else did? I purchased the home, although it's still mortgaged... So that's even worse.. I don't even really own it.. :) Crap.. anyone know a good lawyer? :) -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: E-Mail authentication fight looming: Microsoft pushing Sender ID
On 7/6/05, Rich Kulawiec [EMAIL PROTECTED] wrote: I grow rather tired of people whining about the spam (and abuse) problem on the one hand...while refusing to take simple, well-known, and proven steps to push the consequences back on those responsible for it. While we may no longer be in a position to remove particularly egregious networks from the Internet, we most certainly are in a position to remove the Internet from them via coordinated group action -- producing an equivalent result. It's the group interaction this requires that is the problem. For instance, as a small ISP, it's hard to make a difference at all if you block someone like, say, comcast or verizon (not pointing fingers, just using examples) ... A small ISP could, conceivably put themselves out of business doing something like that.. Coordinating something like that is difficult to begin with, but if you're on the receiving end, I'm sure there will be lawsuits involved. Regardless of the legality, a lawsuit costs money, money a smaller ISP may not have. Then there's the problem with getting everyone to agree to block someone .. Not everyone is going to agree that company X needs to be blocked. Overall it's a great idea, but I don't think it's practical ... I've stuck to using blocklists and intelligent filtering. I've spent a great deal of time over the past few years developing our system and I think it's doing a fine job at the moment.. :) ---Rsk -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: ATM
On 6/29/05, Petri Helenius [EMAIL PROTECTED] wrote: Maybe the small fact that ATM is fading away and building new networks with technology going away is going to explode your operational cost in a few years time. Business grade IP networks will provide you with equal if not better performance than a dedicated ATM WAN. And being replaced with ? GigE? DPT/RPR? MPLS? ATM is a great technology... Unfortunately, I don't think it was ever fully utilized.. From what I understand, MPLS takes some of the good bits and combines it with traditional routing.. But I don't see a lot of MPLS implementations either... Pete -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: ATM
On 6/29/05, Randy Bush [EMAIL PROTECTED] wrote: indeed! i use them often. remember when you had to go into the bank and wait in a queue for a teller? Hopefully soon to be replaced with RFID machines with voice activated commands.. :) Speaking of which.. It's 2005.. Where's my flying car? randy -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: ATM
On 6/29/05, Christopher L. Morrow [EMAIL PROTECTED] wrote: look to the private networks luke... Seriously, many large private ATM/Frame networks are transitioning to MPLS networks because the ATM or Frame gear is/was/will-be-shortly EOL/EOS from the vendors. The costs to run these networks don't jibe well with the alternatives. I figured MPLS was going to be the answer.. :) Now I must learn, research, implement, and debug! :) Now, start the discussion on: private network and mpls vpn and oops, hey, that runs over the same routers as that bad-old Internet thing with the haxors and such! Heh... :) -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Administration Asks Appeals Court To Compel ISP Searches
On 5/31/05, Fergie (Paul Ferguson) [EMAIL PROTECTED] wrote: Worth knowing how this all falls out, methinks. http://www.securitypipeline.com/163702151 Am I understanding this correctly? Are they trying to get ISP's to release all customer information up front without any sort of legal request? I don't have a problem releasing information asked for in a subpeona, but to turn over an entire customer list without any specific criminal charges having been files is a little much. Please tell me I'm misreading this... - ferg -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Administration Asks Appeals Court To Compel ISP Searches
On 5/31/05, Chris Ranch [EMAIL PROTECTED] wrote: Looks like they want us to turn over customer info without the subpoena, but simply with a phone call (or whatever) from an investigator. I would hope that would be just for specific accounts, and not the entire customer list. In any event, now we're going to have to at least confirm the investigator's identity, whereas currently the sub carries sufficient authority. Ugh.. Ok, so it's a Hi, I'm an FBI Agent. Gimme info on Joe Blow and Mary Jane and I'm supposed to jump and give out that info... No questions asked... I'm not so opposed to the don't tell anyone part. When we receive a subpeona for a criminal case (as opposed to a civil case), the subpeona usually states that the subpeona and information being requested can't be discussed by anyone. Whereas a civil case allows us to tell the customer if we want to. My problem would be the handing over of information to what is essentially an unknown party.. That wonderful law would allow a terrorist or other crook to impersonate an investigator and gather information.. I don't think you meant to say 'without any specific criminal charges having been filed', as subpoena'd evidence leads to charges. Well, the few instances I've had to deal with this, the subpeona was for a specific case, so I would guess from that information that charges had been filed... I'm not a lawyer and I don't even pretend to understand fully how the whole system works, so I'm probably wrong.. :) Chris Ranch Affinity Internet, Inc. -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Administration Asks Appeals Court To Compel ISP Searches
On 5/31/05, Chris Ranch [EMAIL PROTECTED] wrote: I just reread the article, and realized I got it wrong. There is some paperwork: The ruling came in a lawsuit by the American Civil Liberties Union and an Internet access firm that received a national security letter (NSL) from the FBI demanding records. So, the NSL isn't judge or grand jury authorized, just the FBI investigator. Yeah, I guess I missed that too.. I wonder what an NSL looks like... Here's some info on them tho : http://www.selfstorage.org/pdf/WhatisNationalSecurityLetter.pdf Do you double-check sups back to the signing judge? Does anyone? We generally call to verify the authenticity... And we ususally wind up calling to inform them that they've given insufficient information, or asked for something we can't provide... It's fun when you get one that requests the IP address of the user and all they give you is a screen name. *sigh* Chris Affinity Internet, Inc. -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: VoIP operators given 120-day deadline to implement E911 services
On 5/19/05, Bruce Pinsky [EMAIL PROTECTED] wrote: That last part ought to be interesting to try and implement in 120 days: ...must provide the emergency operator with the customer's callback number and location, regardless of whether the call is being made from the customer's home or elsewhere. I'm not sure how VoIP operators are going to accomplish this.. The ugly method would be requiring the user to put in their location information when the VoIP device first goes online, but I'm not sure that's even remotely practical... I know you can sometimes get generalized location information from an IP, but nowhere near what's needed for 911 operations.. Any insight on how this is going to be handled? So what's the local 911 center I should be routed to when I'm at the Cebu Phillipines airport and making a VoIP call? Where should I be routed when I'm making a VoIP call while wardriving? - -- = bep -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
On 4/18/05, Daniel Golding [EMAIL PROTECTED] wrote: Aside from individual OS behavior, doesn't this seem like very bad advice? I think this is more of a question of who to trust. Caching, in general, isn't a bad thing provided that TTL's are adhered to. If the poisoning attack were to inject a huge TTL value, then that would compromise that cache. (Note, I am no expert on dns poisoning, so I'm not sure if the TTL is attackable) However, on the flip side, if nothing is ever cached, then I would expect a huge amount of bandwidth to be eaten up by DNS queries. I think a seasoned op knows when to use caching and when to not use caching, but the everyday Joe User has no idea what caching is. If they see a technical article telling them to turn off caching because it will help stop phishing attacks (which they know are bad because everyone says so), then they may try to follow that advice. Aside from the I broke my computer syndrome, I expect they'll be very disappointed when their internet access becomes visibly slower because everything requires a new lookup... Is it possible to prevent poisoning attacks? Is it beneficial, or even possible, to prevent TTL's from being an excessively high value? -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Jonathan Yarden @ TechRepublic: Disable DNS caching on workstations
On 4/18/05, Mikael Abrahamsson [EMAIL PROTECTED] wrote: It would be very interesting in seeing the difference in DNS traffic for a domain if it sets TTL to let's say 600 seconds or 86400 seconds. This could perhaps be used as a metric in trying to figure out the impact of capping the TTL? Anyone know if anyone did this on a large domain and have some data to share? Our first foray into DNS was using a DNS server that defaulted to 86400 for new entries.. Not being seasoned, we left this alone.. Unfortunately, I don't have any hard data from that dark time in our past.. Windows 2000 DNS seems to set the ttl to 3600, which is a tad on the low side, I think... At least for mostly-static domains, anyways. But I believe the reasoning there was that they depended heavily on dynamic dns.. If one had to repeate the cache poisoning every 10 minutes I guess life would be much harder than if you had to do it once every day? I dunno.. how hard is it to poison a cache? :) -- Mikael Abrahamssonemail: [EMAIL PROTECTED] -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Memory leak cause of Comcast DNS problems
On 4/18/05, Florian Weimer [EMAIL PROTECTED] wrote: Maybe the leak wasn't in the DNS service, but some other software component which company policy required on each server (think of Tivoli, antivirus software, or CSA). Who knows? The possiblities are endless. There was, at one time, a fairly serious memory leak in Cisco CNR... I believe I saw a post indicating that CNR was possibly in use? -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Why do so few mail providers support Port 587?
On Tue, 1 Mar 2005 09:18:19 -0500, Nils Ketelsen [EMAIL PROTECTED] wrote: Okay, the main difference seems to be: 1. People here trust, that mailservers on port 587 will have better configurations than mailservers on port 25 have today. I do not share this positive attitude. I think you're right here.. There are a number of us who will endeavor to do it the right way, and then there are others who will either not have the technical know-how, or just plain don't care.. 2. Port 587 Mailservers only make sense, when other Providers block port 25. My point is: If my ISP blocks any outgoing port, he is no longer an ISP I will buy service from. Therefore I do not need a 587-Mailserver, as I do not use any ISP with Port 25-Blocking for connecting my sites or users. For a commercial service, I agree. Commercial users are deemed more intelligent and should have the capability to set up services in a more secure manner. Residential users, however, are the general problem. Your average Joe User has no idea how email works other than merely clicking the send button and having the email appear magically at the other end. Most users don't have spyware or virus checkers either. All of this leads to a large group of general users who can be exploited and abused at-will. As an ISP, I find it necessary to block certain ports. I block port 25 outbound from my residential customers to prevent direct-to-mx spamming. Currently they can only use port 25 on my mailserver, but that will eventually change to only port 587 and port 25 will be completely blocked. I also block netbios and other similar services which were never intended as WAN protocols in the first place. And I haven't had a single complaint from any of my residential customers. I'm fairly confident that they're mostly unaware of these blocks even though they were announced in advance.. I agree. Just as I said: If the ISP blocks (and I do not care which port he blocks), then it's time to go and look for another ISP. If I buy Internet I do not want a provider that decides for me which parts of it I am allowed to use today and which I am not. You would be one of the smarter Joe Users who can handle the day-to-day nasties on the internet. Unfortunately, you're the minority... I wouldn't mind having an alternate service, with no change in pricing, that would allow users like you to have the freedom they want. In fact, if I had any demand for it at all, I'd set something up in a heartbeat. Wehret den Anfaengen is the german saying, I currently cannot find a good translation for. Nils -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Why do so few mail providers support Port 587?
On Fri, 25 Feb 2005 11:17:35 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: That's being a bit disingenuous. The discussion here hasn't been to open up port 587 to relay for all comers, but rather to open it up for authenticated use only. If spammers start using it, then it's a result of either poor authentication security or an understaffed abuse department. I'll agree with you on one thing, though -- the whole business of port 587 is a bit silly overall...why can't the same authentication schemes being bandied about for 587 be applied to 25, thus negating the need for another port just for mail injection? Port 587 is intended for authenticated mail relaying only. While you can set up authenticated relaying only on port 25, you still have to deal with spammers sending mail directly to your users on port 25. Blocking port 25 outbound from dynamic ips (dialups, dsl, cable, etc) helps a little bit .. But then you need an alternate port for relaying. I think using port 587 for authorized relaying and port 25 for normal smtp services works out well. I can't think of a valid reason to ever block port 587, and I can't see how spammers will use port 587 for spamming, unless they have a username/password for relaying.. Andrew -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Why do so few mail providers support Port 587?
On Tue, 15 Feb 2005 21:50:23 -0500, Daniel Golding [EMAIL PROTECTED] wrote: Thor, 587 running SMTP auth (and relaying for authenticated users) and port 25 for local (non relay) delivery without authentication should be the default on all servers. Agreed! At the very least you get the benefit of an electronic trail to follow if one of your users *is* spamming.. :) If you only relay mail from authenticated users, drop (not bounce) any mail destined for a non-existant account, and use reasonable spam blocking and tagging, you should be able to reduce spam to a slow trickle.. It's working here, thus far... And I don't have authentication fully implemented yet. :) -- Daniel Golding Network and Telecommunications Strategies Burton Group -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Time to check the rate limits on your mail servers
On Thu, 03 Feb 2005 17:54:28 +0200, Gadi Evron [EMAIL PROTECTED] wrote: Still, please tell me, how is not blocking un-used or un-necessary ports a bad thing? It is a defensive measure much like you'd add barricades before an attack. Agreed. And depending on your service, there are different ports worth blocking. For residential users, I can't see a reason to not block something like Netbios. And blocking port 25 effectively prevents zombies from spamming. Unfortunately, it also blocks legitimate users from being able to use SMTP AUTH on a remote server.. They now evolved, and are using user-credentials and ISP-servers. This evolution means that their capabilities are severely decreased, at least potentially. Has this been confirmed? Does this new worm, in fact, use SMTP AUTH where necessary? Will it also check the port that the user's computer is set to send mail on? So, for instance, if SMTP AUTH is required, and the mail submission port is being used rather than standard port 25, will the worm detect all this? The nice part about SMTP AUTH, though, is that there is at least a direct link to the user sending the spam. This means, of course, that ISP's will need to police their users a little better.. :) It means ISP's will have to re-think their strategies, just like AOL did. It also means it's once small step to victory for us. We are a long way from it, and please - not everybody blocks port 25 so current-day worms are more than efficient still. So I guess users will have to stop clicking that Save Password button... That is, until the worm records the keystrokes when the password is entered... *sigh* Gadi. -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Time to check the rate limits on your mail servers
On Thu, 03 Feb 2005 12:26:55 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Thu, 03 Feb 2005 12:16:41 EST, Jason Frisvold said: Agreed. And depending on your service, there are different ports worth blocking. For residential users, I can't see a reason to not block something like Netbios. And blocking port 25 effectively prevents zombies from spamming. Unfortunately, it also blocks legitimate users from being able to use SMTP AUTH on a remote server.. There's a *reason* why RFC2476 specifies port 587 I assume you're referring to the ability to block port 25 if 587 is used for submission. This is great in theory, but if this were the case, then the Trojan authors would merely alter their Trojan to use port 587. Unfortunately, I don't think there's an easy answer to the spam problem. Sure, we can educate and block. But at the end of the day, the spammers will just find another way to worm those messages into the network. Some of these guys are making boatloads of money, and I hardly think they're willing to throw in the towel if they hit a bump in the road... On the flipside, those of us working as admins and trying to stop the flow of spam are making next to nothing.. *sigh* -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: New Virus in the wild
On Tue, 18 Jan 2005 08:58:32 -0500, Nils Ketelsen [EMAIL PROTECTED] wrote: McAfee knows about this Virus since last week, but decided it was not worth an update of their regular patterns. Thank you for this policy of slow updates, I will see that I get a vendor that acts in time, I guess. Might I suggest ClamAV? http://www.clamav.com ClamAV, while being open source, seems to have an incredibly fast response time to new virii. I've seen new virii caught by Clam 8-10 hours before the big vendors catch them. I understand the need to have a vendor supported product, but having clamav in the mix helps tremendously... And there's a windows version as well (albeit, by another developer) ... http://www.clamwin.net Nils -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: ATM SVC rerouting time
On Tue, 30 Nov 2004 16:30:47 -0500 (EST), Paul Khavkine [EMAIL PROTECTED] wrote: In a situation where a link fails and the VC needs to be rerouted. The VC path has allready been setup. In the network I work with, SVC re-routes are near instantaneous... If I break a link on purpose, I'm hard pressed to type in the command fast enough to see if the svc is back up and it's already re-routed... 4-6 switches should be the same.. What kind of switches are we talking about here? Thanx Paul -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
IRR Registration
Greetings, We just received our first ARIN allocation and I'm going through the motions to make sure we do everything right. Aside from dealing with DNS, BGP, and rwhois (which is a nightmare to set up), it was highly recommended that we register with an IRR. After looking a bit, I'm wondering which IRR I should be registering with ... It looks like ARIN has an IRR, but it's not something I can register with. The 2 specifically mentioned were raddb and altdb ... altdb obviously looks good because it's free... So .. is there a recommended registry to register with? Is it better to register with more than one? Am I staring a religious argument in the face here? Also, as an aside, does anyone have a checklist of sorts describing best practices for new allocations? Maybe something describing all the steps taken after a new allocation is assigned? Thanks! -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: Name resolution in the .MIL domain
On Fri, 19 Nov 2004 15:58:03 -0500 (EST), Scott McGrath [EMAIL PROTECTED] wrote: Several of our researchers have pointed out that sites in the .MIL TLD are unreachable. Did a nslookup and got a interesting result SNIP Back to the subject at hand is anyone else seeing the same issue with the .MIL domain Looks ok here : [EMAIL PROTECTED] ~]$ host www.army.mil www.army.mil has address 140.183.234.10 [EMAIL PROTECTED] ~]$ host www.navy.mil www.navy.mil is an alias for WWW.NAVY.M7Z.NET. WWW.NAVY.M7Z.NET has address 64.156.240.36 WWW.NAVY.M7Z.NET has address 64.156.240.43 Thanks in advance - Scott -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
RE: Important IPv6 Policy Issue -- Your Input Requested
-Original Message- From: Eric Gauthier [mailto:[EMAIL PROTECTED] Subject: Re: Important IPv6 Policy Issue -- Your Input Requested Hello, I must admint, I'm really not up on the more subtle aspects of v6 addressing nor have I read the drafts you posted, but I've never Nor have I ... I'm just starting to look at IPv6 now This seems like a good discussion to jump in on though. :) understood why we needed a new set of RFC1918-like IPv6 space. Wouldn't 0::10.0.0.0/104, 0::192.168.0.0/112, and 0::172.16.0.0/116 (or whatever the appropriate masks would be) all function as v6 addresses with exactly the same properties at the current RFC1918 space? If the existing RFC1918 space will exist in IPv6 as described above, that can, presumably, be used in the same way existing 1918 space is. For instance, as non-routable loopback addresses for routers, switches, etc. Correct? Or is IPv6 NAT batter suited for this in the future? Eric :) -- Jason Frisvold Penteledata
RE: Network Monitoring System - Recommendations?
-Original Message- From: Charlie Khanna - NextWeb [mailto:[EMAIL PROTECTED] Subject: Network Monitoring System - Recommendations? Hi - I was interested in finding out what software applications other ISPs are using for network monitoring? For example: 1) Overall network health - uptime reports 2) Backup router config automatically 3) Bandwidth reporting (or integration with an MRTG-type app) 4) SNMP trap support (BGP/OSPF session drops - emails out) 5) Database back end (port info into or over to other apps) I've been using Argus - http://argus.tcp4me.com I've found this program more and more useful as time goes on... This should fit in with every point except #5. But, of course, the data has to be stored somewhere, so it should be fairly trivial to either write a parser, or modify the source to use a database. At any rate, I really like this program, it works wonderfully. I'm just looking for something well rounded for a small ISP. I've heard about OpenNMS and other apps but I'd like to get everyone's feedback. Thanks! -Charlie
RE: Loss of Telnet Capability to 6509
Do you have ACL's restricting access to the vty's? I've seen instances where telnet ports get locked up because of port scanning and/or attacks... -- Jason Frisvold Penteledata -Original Message- From: Richard J. Sears [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 2:54 PM To: Nanog Subject: Loss of Telnet Capability to 6509 We posted this to cisco-nsp but someone suggested posting it here as well... We have a 6509 running a SUP720 in IOS only mode (no cat os). At around 4am this morning, we lost our ability to telnet to the router. Running a tcpdump shows that the router never responds to the telnet request. All functions and interfaces on the router seem fine (bgp, etherchannel, ibgp, vtp, hsrp) and I can console into the sup with no problems at all, we just cannot telnet into it. The CPU is at around 6%. I have checked all access lists on the router, none were added/removed or modified on line vty that would cause this problem. All logging appears normal. We are running Version 12.2(17a)SX3. Anyone have a similar problem or know how to check or restart the telnet process on the router without a reload...? ** Richard J. Sears Vice President American Digital Network [EMAIL PROTECTED] http://www.adnc.com 858.576.4272 - Phone 858.427.2401 - Fax INOC-DBA - 6130 I fly because it releases my mind from the tyranny of petty things . . Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching.
RE: IT security people sleep well
On Mon, 2004-06-07 at 23:06, Edward B. Dreger wrote: Dynamic linking might be cheating. Static linking might be pessimistic. Probably best to compare BSD crunchgen images with and without ssh/sshd. (2MB total for statically-linked ssh and sshd as I compile it.) Ooops.. forgot that bit :) You haven't lived life to its fullest until you need to load a boot image remotely via YModem. ;) Been there, Done that.. Is there a T-Shirt? :) Eddy -- Jason H. Frisvold PenTeleData signature.asc Description: This is a digitally signed message part
RE: IT security people sleep well
-Original Message-
From: Edward B. Dreger [mailto:[EMAIL PROTECTED]
Correct. One must shell out more money for a bigger feature set
to obtain SSH. I don't recall specifics off the top of my head,
and don't have a javascript-cable machine handy to use Feature
Navigator[*], but certain { feature sets | trains } only support
SSHv1.
I don't see why they can't roll it into every ios that runs on a router
capable of ssh. Ssh and sshd on my linux system barely break 500k
compiled... And there's a TON of functionality in there that isn't
required on a router. It would seem that you could get ssh put into
these code trains in under 500k ...
Personally, I like having a little wiggle room in the flash ... Putting
an image on there that occupies the entire flash is a bad thing...
[*] Quick gripe: Did anyone at Cisco ever consider that people
might like to use Feature Navigator without javascript?
What's next? Mandatory Flash Player?
I concur.. Mandatory Javascript sucks... Esp when Mozilla and Firefox
have problems viewing the pages... Cisco's site became decidedly
un-useful when they switched it over to this new design...
Eddy
Jason Frisvold
Penteledata
RE: IT security people sleep well
-Original Message- From: Robert Boyle [mailto:[EMAIL PROTECTED] Agreed. I really truly don't see the problem with plaintext telnet management of routers. We have access-lists on vty 0 15 specifying which networks can even connect. We can't connect except for from a trusted internal management network and I control all the routers and circuits in the path. If someone is in the middle of one of my circuits doing some type of dump of the data to disk, they are probably the NSA or CIA, and I've got much bigger problems. Can someone please provide a situation Yeah, that would be a concern... :) where doing this can lead to compromise or any type of problem at all? I just don't see Do you trust every person you work with? Are your internal networks completely segmented (including the ethernet switches?) Here, they are not. And as much as it's been pointed out, they continue to leave everyone in the company on the same segment. Our security guy proved this point by hijacking a switch, convincing it that the traffic had to pass through his computer, and sniffed a TON of traffic ... All within a few minutes, without anyone knowing until he showed it... Through this, he was able to grab a number of passwords all through telnet sessions. Unless you can completely trust everyone in your internal network, ACL's aren't always enough... it. However, I see people having unpatched servers running without proper ACLs every day and this is rarely discussed and as Stephen Sprunk points out, lot of people here on nanog don't apply bogon filters or even source filter their customers - and this doesn't require a feature set upgrade to IOS. (All of which we do, btw) So I'm still not convinced that SSL on routers is needed. Nice, sure, but needed? no. Please convince me otherwise if you feel this is such a hugely pressing need or at least explain your position. I've been converted into the secure it if you can, ensure it's not important if you can't way of thinking ... I would very much like to change our ACL's to only allow telnet from our server farm (which is SSH *ONLY*), thus allowing a little bit of security ... This would at least bring us into the if someone's listening, it's gotta be the NSA or CIA class of security... :) R Jason Frisvold Penteledata
RE: IT security people sleep well
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] OK.. Say you can get it into the code train for 200K. What do you do with all those routers that have only 100K or 125K of space left in the flash (if that), and the flash is NOT going to get any bigger without massive abuse of a soldering iron because not all the needed address lines are brought out to the flash chip (a fine tactic dating back decades - I remember seeing a 16K ROM nailed to the top quarter of the 64K address space, and only 14 address lines brought to the chip - it was nailed to the top 16K by feeding A14 and A15 to an AND gate which fed the 'Chip Select' pin...) Agreed, but what are those routers used for these days? We use those routers for management (old 2511's) ... Any existing 2500's in the core network (yes, I'm ashamed to say some still exist) are ensured to have the max memory they can get ... Again, this is purely theoretical for me as management here has not deemed it appropriate to deploy ssh ... But, if ssh were added to all IOS's, it would greatly reduce the number of routers that could *not* include SSH due to flash limitations... I can say that in other networks that I consult for, I try to ensure ssh is available, as well as acl's and other security techniques... :) Jaosn Frisvold Penteledata
BGP - Newbie Documentation
All, Does anyone have some really good in-depth reading material on BGP for beginners? I've been handed the reigns of BGP administration for our network, but I would still consider myself very much a newbie to this... Some decent how-to's and accepted standards would be great... Thanks! -- Jason H. Frisvold PenTeleData signature.asc Description: This is a digitally signed message part
Re: BGP - Newbie Documentation [apology]
On Mon, 2004-05-24 at 14:53, Jason Frisvold wrote: All, Does anyone have some really good in-depth reading material on BGP for beginners? I've been handed the reigns of BGP administration for our network, but I would still consider myself very much a newbie to this... Some decent how-to's and accepted standards would be great... My apologies.. I should have read the FAQ... I'll be over here in the corner shooting myself in the foot if anyone needs me... Thanks! -- Jason H. Frisvold PenTeleData signature.asc Description: This is a digitally signed message part
RE: GSR, 7600, Juniper M?, oh my!
-Original Message- From: Alex Rubenstein [mailto:[EMAIL PROTECTED] On the 7500, you have RSPs and VIPs; the former performing routing protocol work, vty's, RIB's, etc., the latter doing actually packet forwarding. While this sounds great on paper, our experience has us shying away from dCEF and looking for something bigger and better... dCEF pushed the RSP processor down to about 5%, but pushed up the VIP processors to about 90-95%... VIP-Slot0sh proc c CPU utilization for five seconds: 13%/12%; one minute: 14%; five minutes: 15% I wish we could get our routers to do this... Obviously, we run dCEF, which puts the VIP's in the position of forwarding everything on their own, as evidenced by the CPU measurements. But each VIP is responsible for it's own traffic, so if a particular VIP runs most of the traffic, it has much higher CPU usage... In our case, we have a router loaded with VIP 4-50's and Enhanced ATM OC-3 adapters... Originally, we had a single OC-3 running about 120-130 Megs constant and the VIP CPU was at 90-95% To combat this, we had to put in additional OC-3 cards with additional VIPs and distribute the load... Still, high CPU is a problem .. For instance : CPU utilization for five seconds: 63%/63%; one minute: 63%; five minutes: 65% 30 second input rate 78227000 bits/sec, 17858 packets/sec 30 second output rate 47944000 bits/sec, 12778 packets/sec It seems to me that we should be able to do sooo much better... *sigh* OC-12 adapters are an option, but they are rather expensive ... However, to answer your question, even a modestly configured 7507 with RSP4, and VIP2-50's will be substantially more capable than a 7206-NPE300. Things may change on the NPE-400 or G1, but I have no direct experience with that. The G1 processors, so far, have proven to be wonderful... We only have experience with them running in the 7200 uBR chassis, but they've shown a huge reduction in CPU utilization... PS. Regards to stability; we have SUBSTANTIAL improvements in IOS stability, especially in 12.3.5a mainline. Heh.. *old* Cisco code scares me enough... Bleeding edge is simply terrifying... *sigh* -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- Jason Frisvold Backbone Engineering Supervisor Penteledata
RE: GSR, 7600, Juniper M?, oh my!
Ours dropped about 70% ... And it's been steady ever since.. we've added a large number of modems since that time as well... Look into 'no cable-arp' as well ... Basically, it prevents arp broadcasts and that also had a major impact on the cpu utilization of our CMTS's.. Jason Frisvold Backbone Engineering Supervisor Penteledata -Original Message- From: Tarko Tikan [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 2:55 PM To: [EMAIL PROTECTED] Subject: Re: GSR, 7600, Juniper M?, oh my! hello! The G1 processors, so far, have proven to be wonderful... We only have experience with them running in the 7200 uBR chassis, but they've shown a huge reduction in CPU utilization... what is huge reduction for you? we upgraded from npe-400 to npe-g1 on ubr7200 and processor usage decreased 20-30%. And we are pushing about 100Mbps traffic from GigE to cable and about 20-30Mbps from cable to GigE. -- tarko
Re: cef/process switching problem
Not sure on the MC3810 (never used one), but I know that many of the other Cisco routers didn't do CEF on ethernet until later revisions of code... There are other factors that kick it out of CEF as well.. I believe ACL's and Route Maps are 2 of them.. On Tue, 2003-09-09 at 11:07, Austad, Jay wrote: I've got a cisco MC3810 with a bunch of DSL customers on it. CEF is enabled, but when I do a show int stat, I see that almost 100% of the outbound packets on the ethernet interface are process switched, and not being matched in the route cache. The Input looks just fine, and the other interfaces are borderline (usually 50% hit rate on the cache or a little less). CPU is sitting pretty high on this box during the day, and I have strong suspicions that this is why. :) I can't seem to find any info on why this would be happening or how to figure out what's going on. Anyone have any suggestions? -jay -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Re: Cable Wireless, Verio and/or Level 3 port blocking?
On Mon, 2003-09-08 at 14:56, William Devine, II wrote: Can anyone from these three carriers tell me if you're doing port blocking on the Windows file/print ports (135-139, 445 593) ? A client of ours (in the US), against our recommendation, still wants to connect to their Exchange server in the UK without a VPN. We're not blocking their IP#'s from anything but somewhere in between it's getting blocked. We use CW directly and Verio/Level3 through a peer. Can they set up a gre tunnel? I did this for a site to site active directory setup and it worked out great... :) Thanks! william -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Cisco Service Provider code - Any good?
All, It was requested that I post this email to the Nanog list as the person in question does not have posting ability... :) Hello All, We're currently looking into migrating our Cisco 72xx and 75xx routers to Service Provider IOS and I was wondering if anyone has had any good luck with a certain version? We've seen that 12.0(25)S1 seems to be an ok version but I have also heard some gripes about it. The PAs that we run in most of the units are the following: ATM-OC3-MM ATM-OC12-MM FastE GigE The IOS would also have to support RFC-1483 connections (Preferrably RBE), BGP, IS-IS and any other basic services of the such. Thanks in advance -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Re: Why do you use Netflow
On Tue, 2003-08-19 at 16:12, Jack Bates wrote: Number one use for netflow, scan detections. I detect most users infected with a virus before remote networks can auto-gen a report. I also detect mail being sent from various customer machines. High volume traffic flags me so I can investigate if it's spam or not. Cool.. I never thought of using it for this... I can tell you (well, I won't without a court order, but I could) the username, or customer name (if static), of every worm infected user on my network at any given point in time. 50+ inactive flows for an IP address is definite worm sign. If you want to be more specific, do sequential scan checks on the flow data. Has been very useful in dealing with Blaster. Worm Sign... Dune... Cool :) We used ip accounting the other night to detect and disable a large number of worm infected users that took out the router completely.. I think net flow would have been too much overhead at the time... Once we were down to a more manageable number of infected users, we used netflow to pinpoint them immediately... (Note, we don't leave netflow on all the time) Netflow is particularly useful when utilizing NAT, as it's much easier to collected netflow data than translation tables. On a cold, boring day, you can setup aggregates and generate cute little statistics for all sorts of things, and I hear it's useful in some scenarios. Sounds like fun... I wish I had slow boring days... *grin* -Jack -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
The impending DDoS storm
All, What is everyone doing, if anything, to prevent the apparent upcoming DDoS attack against Microsoft? From what I've been reading, and what I've been told, August 16th is the apparent start date... We're looking for some solution to prevent wasting our network resources transporting this traffic, but at the same time trying to allow legitimate through... So, is anyone planning on doing anything? Thanks, -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
RE: The impending DDoS storm
On Wed, 2003-08-13 at 10:14, Ingevaldson, Dan (ISS Atlanta) wrote: It might be somewhat tricky to block TCP/80 going to windowsupdate.com. I agree... but then, who needs updates anyways.. *grin* Regards, === Daniel Ingevaldson Engineering Manager, X-Force RD [EMAIL PROTECTED] 404-236-3160 Internet Security Systems, Inc. The Power to Protect http://www.iss.net === -Original Message- From: Stephen J. Wilcox [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 10:38 AM To: Jason Frisvold Cc: [EMAIL PROTECTED] Subject: Re: The impending DDoS storm On Wed, 13 Aug 2003, Jason Frisvold wrote: All, What is everyone doing, if anything, to prevent the apparent upcoming DDoS attack against Microsoft? From what I've been reading, and what I've been told, August 16th is the apparent start date... We're looking for some solution to prevent wasting our network resources transporting this traffic, but at the same time trying to allow legitimate through... So, is anyone planning on doing anything? See previous discussion on filtering... Other than that experience says if these things turn out to be big enough to cause an issue then they quickly burn themselves out anyway Steve -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
RE: The impending DDoS storm
On Wed, 2003-08-13 at 10:55, Ingevaldson, Dan (ISS Atlanta) wrote: More info: -Opens a raw socket and spoofs its source address It *appears* to us through current testing that the source address spoofed is always within the class of the current subnet... So, a spoofing filter that denies all but the local subnet may only be partially affective.. -Randomizes its source port, but destination is always TCP/80 -Does one DNS lookup on windowsupdate.com and then uses the IP returned -The window size is always 16384 (this might be useful) It also looks like there is no throttling at all.. it abuses as much bandwidth as it possibly can... Regards, === Daniel Ingevaldson Engineering Manager, X-Force RD [EMAIL PROTECTED] 404-236-3160 Internet Security Systems, Inc. The Power to Protect http://www.iss.net === -Original Message- From: Jason Frisvold [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 10:50 AM To: Ingevaldson, Dan (ISS Atlanta) Cc: Stephen J. Wilcox; [EMAIL PROTECTED] Subject: RE: The impending DDoS storm On Wed, 2003-08-13 at 10:14, Ingevaldson, Dan (ISS Atlanta) wrote: It might be somewhat tricky to block TCP/80 going to windowsupdate.com. I agree... but then, who needs updates anyways.. *grin* Regards, === Daniel Ingevaldson Engineering Manager, X-Force RD [EMAIL PROTECTED] 404-236-3160 Internet Security Systems, Inc. The Power to Protect http://www.iss.net === -Original Message- From: Stephen J. Wilcox [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2003 10:38 AM To: Jason Frisvold Cc: [EMAIL PROTECTED] Subject: Re: The impending DDoS storm On Wed, 13 Aug 2003, Jason Frisvold wrote: All, What is everyone doing, if anything, to prevent the apparent upcoming DDoS attack against Microsoft? From what I've been reading, and what I've been told, August 16th is the apparent start date... We're looking for some solution to prevent wasting our network resources transporting this traffic, but at the same time trying to allow legitimate through... So, is anyone planning on doing anything? See previous discussion on filtering... Other than that experience says if these things turn out to be big enough to cause an issue then they quickly burn themselves out anyway Steve -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Microsoft.com attack?
Anyone aware of an attack on www.microsoft.com? I had a customer machine that was attacking it, looks like either a bug in Microsoft's SP4 (coincidentally this started the day after this was installed) or there's some new(?) worm of some sort causing this ?? Thanks! -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
RE: Microsoft.com attack?
On Fri, 2003-08-01 at 22:16, Matt Ploessel wrote: http://www.microsoft.com/homepage/features/2003/denialofservice.htm Cool... thanks for the info... Hopefully I'll be able to gather any information I can from our infected machine here and forward it on to the proper authorities... Anyone got a contact for the good guys ?? :) Thanks! -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Certified - RHCE # 807302349405893 MySQL Core Certified - ID# 205982910 --- Something mysterious is formed, born in the silent void. Waiting alone and unmoving, it is at once still and yet in constant motion. It is the source of all programs. I do not know its name, so I will call it the Tao of Programming.
Cisco Vulnerability (updated?)
Apparently protocol 103 does not need to have a ttl of 0 or 1 when it hits the interface in order to cause the DoS ... Cisco has updated their advisory to reflect this (Version 1.9 now).. Just wanted to alert everyone... This makes the thought of some sort of virus causing this even more realistic.. no need to check ttl's, just fire away with protocol 103... Yikes... -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Re: Cisco vulnerability and dangerous filtering techniques
On Tue, 2003-07-22 at 09:54, [EMAIL PROTECTED] wrote: I'm going to go out on a limb and say that at least 30% of Ciscos are installed in places that would, if hit with this, have NO CLUE why their router needs to be power cycled every 30 mins. Not only the clueless, but how about those of us who deploy older routers sometime in the future with legitimate uses? What happens when we forget that this bug exists? Now we have to go through the process of adding a don't forget the IPV4 Cisco Bug clause to our procedures.. -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Re: Cisco vulnerability and dangerous filtering techniques
In our case we use some older routers as managment devices... Not critical to the core unless there is some larger outage... Those devices are old enough that they can't handle a newer rev of code... ACL's are the only answer there.. Luckily they have very little traffic even under heavy use, so ACL's don't hurt as much, but still something we need to be aware of.. On Tue, 2003-07-22 at 13:58, Allan Liska wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22 Jul 2003, Jason Frisvold wrote: Not only the clueless, but how about those of us who deploy older routers sometime in the future with legitimate uses? What happens when we forget that this bug exists? Now we have to go through the process of adding a don't forget the IPV4 Cisco Bug clause to our procedures.. You don't need to add that clause as long as you maintain a set of baseline configurations. If you deploy all routers with the same code, or as close to it as possible, then you don't have to remember individual security alerts, because as you update the code on your existing routers, you should be creating a new baseline that should be installed on all newly deployed routers. allan - -- Allan Liska [EMAIL PROTECTED] http://www.allan.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/HXtTvfQS9KzHT6ARAo+1AJ0WYoveQOYum6Fjqt2BgphxAIw2tACfRRTo pyJ71GMRlVYpltvuUrWsLLo= =hFp+ -END PGP SIGNATURE- -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Cisco Vulnerability Testing Results
Hi all, First post.. I hope this is ok ... We tested the Cisco vulnerability and I wanted to share our results with you ... The attack code we used is the same code that was posted to the Full Disclosure list. Compiled on a Redhat Linux 6.2 machine. Testing scenario is this : Linux Machine (10.0.0.2/24) Cisco 2514 Ethernet0 (10.0.0.1/24) is in from the attacker Ethernet1 (192.168.0.1/24) is output to the 2501 Cisco 2501 Ethernet0 (192.168.0.2/24) is in from the 2514 First attack was to the 2514, ran the program as thus : ./sc 192.168.0.1 1 This produced unexpected results. Cisco indicated that the vulnerability was on the interface specified in the packets. However, after running this, it was actually the INPUT interface that the input queue increased on. In our test, this was Ethernet0, not Ethernet1 as expected. Next attach was to the 2501 : ./sc 192.168.0.2 2 This produced expected results. Input queue did increase on the 2501. Next we tried a pass-through attack : ./sc 192.168.0.2 0 ./sc 192.168.0.2 1 No interfaces on either Cisco were affected. It seems that pass-through attacks are not possible. The attack *must* terminate on an IP on one of the router interfaces. An additional test to both routers using a high TTL value was also run. No interfaces were affected. This is in-line with Cisco's posting. Code was then upgraded on the 2514 to 12.0.27 (non-vulnerable) .. Tests were run again. This time, the 2514 was not affected by any tests. The 2501 was still vulnerable. I will be testing ACL's in a moment, but I wanted to get these results out and see if they were on-par with any testing anyone else has done. -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
SC Signature and HPING Signature
For those interested, these are the packet dumps of all 4 protocols
using HPing and the release ShadowChode exploit.
I'm told you can create the necessary IDS filters from this.. we're
working on this now as well... :) I'm not an IDS expert, so I don't
have the know-how to do this... yet.. :)
-Forwarded Message-
From: Keith Pachulski
Output below is from both the SC code and hping performing the same as
SC. Feel free to develop your signatures from it.
SC Exploit
11:59:59.014190 79.111.123.116 dhcp9-1.noc.corp.ptd.net: swipe 181
0x 4500 00c9 bf25 0235 fe3b 4f6f 7b74E%...5.;Oo{t
0x0010 ccba 6301 0001 0203 0405 0607 0809 0a0b..c.
0x0020 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b
0x0030 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b.!#$%'()*+
0x0040 2c2d 2e2f 3031 3233 3435 3637 3839 3a3b,-./0123456789:;
0x0050 3c3d 3e3f 4041 4243 4445 4647 4849 4a4b=[EMAIL PROTECTED]
0x0060 4c4d 4e4f 5051 5253 5455 5657 5859 5a5bLMNOPQRSTUVWXYZ[
0x0070 5c5d 5e5f 6061 6263 6465 6667 6869 6a6b\]^_`abcdefghijk
0x0080 6c6d 6e6f 7071 7273 7475 7677 7879 7a7blmnopqrstuvwxyz{
0x0090 7c7d 7e7f 8081 8283 8485 8687 8889 8a8b|}~.
0x00a0 8c8d 8e8f 9091 9293 9495 9697 9899 9a9b
0x00b0 9c9d 9e9f a0a1 a2a3 a4a5 a6a7 a8a9 aaab
0x00c0 acad aeaf b0b1 b2b3 b4 .
11:59:59.014402 dhcp9-1.noc.corp.ptd.net 79.111.123.116: icmp:
dhcp9-1.noc.corp.ptd.net protocol 53 unreachable [tos 0xc0]
0x 45c0 00e5 80f8 4001 fdc0 ccba 6301[EMAIL PROTECTED]
0x0010 4f6f 7b74 0302 df39 4500 00c9Oo{t...9E...
0x0020 bf25 0235 fe3b 4f6f 7b74 ccba 6301.%...5.;Oo{t..c.
0x0030 0001 0203 0405 0607 0809 0a0b 0c0d 0e0f
0x0040 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0050 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f.!#$%'()*+,-./
0x0060 3031 3233 3435 3637 3839 3a3b 3c3d 3e3f0123456789:;=?
0x0070 4041 4243 4445 4647 4849 4a4b 4c4d 4e4f@ABCDEFGHIJKLMNO
0x0080 5051 5253 5455 5657 5859 5a5b 5c5d 5e5fPQRSTUVWXYZ[\]^_
0x0090 6061 6263 6465 6667 6869 6a6b 6c6d 6e6f`abcdefghijklmno
0x00a0 7071 7273 7475 7677 7879 7a7b 7c7d 7e7fpqrstuvwxyz{|}~.
0x00b0 8081 8283 8485 8687 8889 8a8b 8c8d 8e8f
0x00c0 9091 9293 9495 9697 9899 9a9b 9c9d 9e9f
0x00d0 a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf
0x00e0 b0b1 b2b3 b4 .
11:59:59.014380 36.71.143.53 dhcp9-1.noc.corp.ptd.net: mobile: []
(bad checksum 515)
0x 4500 00c9 fefc 0237 d5c9 2447 8f35E7..$G.5
0x0010 ccba 6301 0001 0203 0405 0607 0809 0a0b..c.
0x0020 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b
0x0030 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b.!#$%'()*+
0x0040 2c2d 2e2f 3031 3233 3435 3637 3839 3a3b,-./0123456789:;
0x0050 3c3d 3e3f 4041 4243 4445 4647 4849 4a4b=[EMAIL PROTECTED]
0x0060 4c4d 4e4f 5051 5253 5455 5657 5859 5a5bLMNOPQRSTUVWXYZ[
0x0070 5c5d 5e5f 6061 6263 6465 6667 6869 6a6b\]^_`abcdefghijk
0x0080 6c6d 6e6f 7071 7273 7475 7677 7879 7a7blmnopqrstuvwxyz{
0x0090 7c7d 7e7f 8081 8283 8485 8687 8889 8a8b|}~.
0x00a0 8c8d 8e8f 9091 9293 9495 9697 9899 9a9b
0x00b0 9c9d 9e9f a0a1 a2a3 a4a5 a6a7 a8a9 aaab
0x00c0 acad aeaf b0b1 b2b3 b4 .
11:59:59.014603 dhcp9-1.noc.corp.ptd.net 36.71.143.53: icmp:
dhcp9-1.noc.corp.ptd.net protocol 55 unreachable [tos 0xc0]
0x 45c0 00e5 5815 4001 3e0b ccba 6301[EMAIL PROTECTED]...c.
0x0010 2447 8f35 0302 df39 4500 00c9$G.5...9E...
0x0020 fefc 0237 d5c9 2447 8f35 ccba 6301.7..$G.5..c.
0x0030 0001 0203 0405 0607 0809 0a0b 0c0d 0e0f
0x0040 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0050 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f.!#$%'()*+,-./
0x0060 3031 3233 3435 3637 3839 3a3b 3c3d 3e3f0123456789:;=?
0x0070 4041 4243 4445 4647 4849 4a4b 4c4d 4e4f@ABCDEFGHIJKLMNO
0x0080 5051 5253 5455 5657 5859 5a5b 5c5d 5e5fPQRSTUVWXYZ[\]^_
0x0090 6061 6263 6465 6667 6869 6a6b 6c6d 6e6f`abcdefghijklmno
0x00a0 7071 7273 7475 7677 7879 7a7b 7c7d 7e7fpqrstuvwxyz{|}~.
0x00b0 8081 8283 8485 8687 8889 8a8b 8c8d 8e8f
0x00c0 9091 9293 9495 9697 9899 9a9b 9c9d 9e9f
0x00d0 a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf
0x00e0 b0b1 b2b3 b4 .
11:59:59.014572 57.21.62.14 dhcp9-1.noc.corp.ptd.net: nd
Re: Cisco Vulnerability Testing Results
Just a quick credit email.. :) I wanna make sure credit is given to the 2 guys who helped with this testing.. Keith Pachulski and Chrus Kruslicky .. both from PTD.. :) On Fri, 2003-07-18 at 11:34, Jason Frisvold wrote: Ok, update to my testing : On Fri, 2003-07-18 at 10:48, Jason Frisvold wrote: Hi all, First post.. I hope this is ok ... We tested the Cisco vulnerability and I wanted to share our results with you ... SNIP Testing scenario is this : Linux Machine (10.0.0.2/24) Cisco 2514 Ethernet0 (10.0.0.1/24) is in from the attacker Ethernet1 (192.168.0.1/24) is output to the 2501 Cisco 2501 Ethernet0 (192.168.0.2/24) is in from the 2514 SNIP Firstly, HPing (www.hping.org) can craft the packets required for this attack very simply... I won't post the exact command string, but it's not that hard to figure out... And with HPing, you can easily take down an interface in under a second. Now, on to ACL testing... 3 ACL tests just to make sure we had everything correct ... We first tried the any any ACL that Cisco recommends : access-list 101 deny 53 any any access-list 101 deny 55 any any access-list 101 deny 77 any any access-list 101 deny 103 any any access-list 101 permit ip any any This produced expected results. When placed on the interface, it prevented the router from being attacked. Next, we tried an ACL with just the interface IP in it : access-list 101 deny 53 any host 10.0.0.1 access-list 101 deny 55 any host 10.0.0.1 access-list 101 deny 77 any host 10.0.0.1 access-list 101 deny 103 any host 10.0.0.1 access-list 101 permit ip any any We applied this to the Ethernet0 interface on the 2514. Attacks to that IP were prevented as expected. Attacks through to the 2501 were not blocked, again as expected. And finally, attacks to the ethernet1 interface on the 2514, which passes through the ethernet0 interface, still caused the ethernet0 interface to be attacked. And the last test was an ACL containing all of the IP's on the router: access-list 101 deny 53 any host 10.0.0.1 access-list 101 deny 55 any host 10.0.0.1 access-list 101 deny 77 any host 10.0.0.1 access-list 101 deny 103 any host 10.0.0.1 access-list 101 deny 53 any host 192.168.0.1 access-list 101 deny 55 any host 192.168.0.1 access-list 101 deny 77 any host 192.168.0.1 access-list 101 deny 103 any host 192.168.0.1 access-list 101 permit ip any any This blocked all attacks on the 2514 while still allowing attacks through to the 2501.. This is as expected. Also, another note. Loopback interfaces, while not vulnerable themselves, make it much easier to completely take out routers.. (We're assuming that the device is still vulnerable) If the attacker has the loopback of the router, they can run an attack at that interface. Every input interface will be attacked in succession. As each interface goes down and the traffic re-routed, the next interface will fall under attack. Just be sure to add the loopback IP as part of the ACL ... :) -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Re: Patching for Cisco vulnerability
On Fri, 2003-07-18 at 14:29, Irwin Lazar wrote: Just out of curiosity, are folks just applying the Cisco patch or do you go through some sort of testing/validation process to ensure that the patch doesn't cause any other problems? Given typical change management procedures how long is taking you to get clearance to apply the patch? I think a lot of providers are doing the minimum testing required (upgrade, does it boot? can I ping?) and then rolling it out... I guess it's more of an implicit trust type deal rather than having routers running with an increased load because of ACL's and still having the possibility of a vulnerable router because something was overlooked.. Going forward, if you go the ACL route, every time you add a new interface you need to be sure to either apply the any any acl to it, or add the new ip's to the big block by ip acl ... I'm trying here to gauge the length of time before this vulnerability is closed out. I don't think it will ever truly go away.. there are lots of older routers that won't be able to support the newer code, albeit small routers like the 2500's, but they'll exist.. irwin -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Re: Patching for Cisco vulnerability
On Fri, 2003-07-18 at 15:37, Stephen J. Wilcox wrote: I don't think it will ever truly go away.. there are lots of older routers that won't be able to support the newer code, albeit small routers like the 2500's, but they'll exist.. Yes I have some old routers (2500s) for which no code exists which is patched and small enough to sit in the flash/memory... acl acl ! And given the low processing power of those routers, acl's hurt ... :( Steve -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
