Re: oof. panix sidelined by incompetence... again.
On Sun, Jan 22, 2006 at 10:33:04AM -0800, william(at)elan.net wrote: > > Can there be a confirmation of this? I see no such MOTD at > http://www.panix.com/panix/help/Announcements/ I don't know how realtime that is ... but Panix (including their web site) was unreachable from several points earlier. It's back now. > and my connection to panix is fine and route I see is 166.84.0.0/17 > with origin in 2033. I also checked at routeviews.org and similarly > all their peers see origin in in 2033. Is there some other route > that has been hijacked then or has it now ben resolved? As noted in the MOTD posting, Panix is announcing more specifics. 166.84/16 is what they would normally accounce (and they are still announcing that), 166.84.0/17 and 166.84.128/17 are there to overcome the /16 Con Ed is advertising. As of the now (according to Panix; I haven't independantly verified it), Verio is (at Panix's request) rejecting the route from ConEd, and Panix's upstreams are accepting the /17s, so connectivity should be OK from everywhere except possibly ConEd. -- Brett
Re: GoDaddy.com shuts down entire data center?
uOn Mon, Jan 16, 2006 at 10:20:23AM -0500, Martin Hannigan wrote: > > As you dig deeper into his site you find out that he does this > often for the recorded calls. He's got quite a few to AT&T and MCI > stored. There's enough there that GoDaddy ought to inquire as to > the legality of him taping their call without consent. I don't > think the fact that GoDaddy stated they may record is protection > for both, but IANAL. Federal law prohibits private recording of phone calls in the absence of consent from at least one party to the call. Since the caller in this case presumably consented to the recording he was doing, no federal law was broken. Whether or not GoDaddy's "we may record" statement constitutes consent is irrelevant because their consent is not required. Most state laws are similar to the federal law. Some states, though, require the consent of all the parties to the call. It's not clear what law applies on interstate calls between states with dissimilar laws. In particular, if the caller is in a one-party state and GoDaddy is in an all parties state, then he is potentially violating the law in the all-parties state. Any attempt to prosecute such violation would likely be challanged on the grounds that it was an interstate call so only federal law applies (that is, that the existance of the federal law automatically preempts state law on any interstate call), or on the grounds that there isn't sufficient relationship to GoDaddy's state to allow that state to prosecute the caller. (Put another way, the argument would be that State X is not entitled to regulate what individuals in State Y do with their own phones in State Y, even when they are calling people in state X.) And, of course, if an all-party law were held to apply to this case, then he could argue that he consented and GoDaddy's "we might record this call" constituted consent for him to record it. In short, if he and GoDaddy are both in the same state, and it's an all-parties state, he probably broke the law (unless he successfulyl argues that GoDaddy effectively consented.) If he and GoDaddy are both in one-party states, he's fine. Anything else, and it's unclear. If his state is one-party, he's probably safe. If his state is all-parties, then it's harder to say, although federal preemption is certainly a reasonable argument to make. http://www.rcfp.org/taping/ seems to have good information. -- Brett
Re: Cisco, haven't we learned anything? (technician reset)
On Thu, Jan 12, 2006 at 10:53:32AM -0600, Rob Thomas wrote: > > Hi, Matthew. > > ] Cisco Router and Security Device Manager (SDM) is installed on this device. > ] This feature requires the one-time use of the username "cisco" > ] with the password "cisco". > > Interesting. Is it limited to one-time use? Are the network login > services (SSH, telnet, et al.) prevented from using this login and > password? No. No. (It's nothing special -- it doesn't do anything you couldn't configure manually on a pre-SDM device if you wanted.) -- Brett
Re: Cisco IOS Exploit Cover Up
On Thu, Jul 28, 2005 at 07:03:31AM -0700, Eric Rescorla wrote: > > Can you or someone else who was there or has some details describe > what the actual result is and what the fix was? Based on what I've > been reading, it sounds like Lynn's result was a method for exploiting > arbitrary new vulnerabilities. Are you saying that this method can't > be used in future IOS revs? As nearly as I can tell from reports (I wasn't there), he (1) talked about a general way to exploit a buffer overflow to cause arbitrary code execution (this would apply to buffer overflows generally, but would be completely useless if you didn't know of a buffer overflow to exploit), and (2) demonstrated his technique using a previosuly known buffer overflow vulnerability which Cisco has already patched. So Cisco is correct in saying that he didn't identifiy any new vulnerabilities, and Cisco is also correct in saying that the vulnerability he used in his presentation to demonstrate his technique has been patched. However, the same technique will be useful on the next buffer overflow vulnerability to be discovered. -- Brett
Re: OT: Banc of America Article
On Wed, Jan 29, 2003 at 10:35:37AM -0800, Al Rowland wrote: > > The PIN is on your card, likely encrypted, We're off-topic now, so I won't go into detail, but the PIN is sometimes on the card and sometimes not. There are different ways of doing it. (If the sampling of cards in my wallet is representative, then mostly, the PINs aren't on the card anymore (I still have one card that has the PIN on the card).) -- Brett
Re: As-Path filtering based on ranges, not regex
On Fri, Jan 17, 2003 at 12:10:59PM -0500, Andy Johnson wrote: > > Vincent, > > I'm fairly certain it can match a range, just as you yourself posted you > could do. There is no difference between using a range to find 0-9, than > there is finding 64512-65535. There is in regular expressions. >So your line would look something like this: > > ip as-path access-list 150 permit _[64512-65535]$ [0123] is a one-character regular expression matching the digit 0, 1, 2, or 3. [3-5] is a one-character regular expression matching 3, 4, or 5. [64512-65535] is a one-character regular expression matching 1,2,3,4,5 or 6. (It's way more complex than it needs to be, of course. You've got 6 listed in there twice; five is listed 4 times and also included in the 2-6 range, and so on.) So your expression above is going to match paths ending with AS 1, 2, 3, 4, 5, or 6. -- Brett
Re: Even the New York Times withholds the address
On Tue, Nov 19, 2002 at 08:37:33AM -0500, Johannes Ullrich wrote: > > How about using water power for backup? Store a big tank of water on the > top floor and use a water turbine to generate power in an emergency... > Wonder how much water it would take... but for sure this would do well > in case of fire. Have you done the math? Let's say it's a 100 meter high building. A kilogram of water 100 meters off the ground has: 1kg * 100m * 9.8m/s^2 = 9800 J of energy. Let's say we want to be able to run for one day without power. So 9800J is enough to provide 9800J/(24*3600)s = 0.113W for a day. So, roughly speaking, you need 10 kilograms of water for every watt. One milliliter of water weighs one gram. So that 10 kilograms is 1ml, or 1cm^3, or .01m^3. One cubic meter, then weighs 1000kg, and, thus, can provide about 100W (for a day). Now, figure out how many kw you need to run a telecom hotel, and you'll know just how large your tank needs to be (and how much weight the building structure is going to have to support). Even if you assume 100% efficiency, the tank is still going to me, um, rather largish. -- Brett
Re: ICANN Targets DDoS Attacks
On Tue, Oct 29, 2002 at 09:05:40PM -0500, Jared Mauch wrote:
>
> Please discontinue imagination. You obviously don't understand how
> traceroute works by sending udp packets and getting icmp ttl expired
> messages back which are not icmp {echo,echo-reply}. Come back when you do
> understand how it works. /sigh
Addressing just the issue of how traceroute works, I'll point out that
(a) Most or all flavors of traceroute distributed by Microsoft use ICMP
ECHO instead of UDP for the outbound packets (the old issue of some
stacks not sending ICMP errors in response to any ICMP being not much
of an issue these days, Microsoft's non-traditional method works almost
as good as the traditional UDP method), and (b) A Microsoft traceroute
is what most customers will be using.
FWIW, I don't think rate limiting ICMP is likely to have a negative
impact. I also don't think it's a good idea, though -- it might help
to identify or prevent some problems in the short term, but in the long
run, it's a race we can't win -- if everyone limits ICMP, people will
launch DDos attacks with, say, packets to 80/tcp -- rate limiting that
is more problematic. ICMP rate limiting isn't anywhere near a big
enough win, from my perspective, to justify adding complexity to the
network, and having to remember, when troubleshooting strange problems,
that ICMP is no longer forwarded just like any other packet.
-- Brett
