Re: Kiss-o'-death packets?
I would agree that for some application protocols this would be useful++. Letting layer 7 generate layer 3 responses though is, imvho, a bad idea (tm) from an architectural perspective. Beyond that, in Linux (and I would imagine a few other OSes) ICMP is in-kernel, which lowers the practicability of implementation right out of the gate. I am sure you probably thought of this, but what happens if I spoof an ICMP Go Away? Keeping things like this within the protocol that takes care of authorization (of transmissions) is a logical choice, I would think. Paul - Original Message - From: "Sean Donelan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, October 06, 2003 2:11 AM Subject: Kiss-o'-death packets? > > On Mon, 6 Oct 2003 [EMAIL PROTECTED] wrote: > > My favorite: > > > > "ntp-1.vt.edu is portscanning me very slowly with source port 123" > > > > The really sad ones are the ones who 3 days earlier dropped me a note to tell > > me they'll using our NTP server. > > Due to the propensity of people to configure NTP in various annoying ways, > and then failing to respond to requests to fix their systems, the NTP > developers added a new command packet to the protocol. > > To help reduce the level of spurious network traffic due to obsolete > configuration files, a special control message called the kiss-o'-death > packet has been implemented. If enabled and a packet is denied service > or exceeds the client limits, a compliant server will send this message > to the client. A compliant client will cease further transmission and > send a message to the system log. See the Authentication Options page > for further information. > > Should other protocols include the same feature? If someone sends you > a Dynamic DNS update, could the protocol include a kiss-o'-death packet > to tell clients to go away? If someone keeps probing your HTTP server, > should HTTP include a kiss-o'-death packet to tell clients to go away? > If someone connects to your SMTP server, should SMTP include a > kiss-o'-death packet to tell clients to go away. > > Or is this such a widely needed feature, should we try to include it > in a base protocol such as IP/ICMP? > > In a large number of these cases, its not malicious, its misconfigured. > A host could respond to a connection with an ICMP Go Away packet. Even if > the end-host doesn't comply, an edge device or firewall using ICMP > snooping could detect the Go Away packet and change its configuration. > By pushing the control out to the edges, we avoid overloading the core > with one-to-one configuration changes. Using a four-way handshake, its > possible to protect against most types of spoofing and denial of service > even without encryption or keys distribution. > > If you think the root servers are attacking you, Ok. Send a Go Away > packet, and you won't get any more packets from the root server. Why > would you do this? I don't know, but that's your choice. It would get > the ISP out of the business of deciding what should be considered network > abuse, and what isn't. After the user stops shooting himself in the > foot (or runs out of toes), maybe he'll fix the broken auto-firewall > software which thinks everyone is attacking him. > > At NANOG in Chicago, if anyone would like to discuss it further let > me know. >
Re: Security v. Privacy (was Re: Is there anything that actually gets users to fix their computers?)
Sean Donelan wrote: The difference being campus machines are null routed rather than disconnected, and they are not reconnected until checked and clean. And once again, the question: how do you know the machines have been checked and cleaned before they are reconnected? Do you take the customers word, or do you perform some other check yourself? If it's in the campus we take their word for it the first time (local/dept IT personnel only). Dialups/externals we take their word for it the first time. Second time for campus machines they are usually checked over by a member of the ITS security team. Second time for dialups/externals again take their word for it, however warn strongly about the 3rd time. Third time externals/dialups don't connect with us again. Campus machines - I have yet to have this happen. Network security is high priority here and it doesn't matter what machine is compromised, they are all disconnected in one way or another, and yet we still have to nuke machines occasionally because of suspicious (DDoS/scanning etc) traffic. Seems like a re-active policy. Why don't you check the computers before they start exhibiting suspicious behavior, such as when they are first connected to the network? Waiting until after the computer is compromised is too late. Already doing this... except we are also actively scanning (new policy) all computers connected periodically. It has taken a lng time to get the train of thought that scanning is a good thing. (FYI using Nessus) Should commercial service providers have the same policy when new customers connect to the network? That is still reactive here, but I see no real reason why it shouldn't be. Or is it considered a bad thing to warn customers about vulnerabilities in their computers in advance. Instead waiting until after your receive a complaint about something exploiting those vulnerabilities before taking action? Personally I feel there are 3 problems 1/ Some people are already security concious and will give you merry hell over security scans (filling logs, false positives etc) 2/ Some poeple consider it an invasion of privacy - personally I'd tell these people to go else where if it was upto me. 3/ People install software after installing the machines and getting them connected. / Mat
Kiss-o'-death packets?
On Mon, 6 Oct 2003 [EMAIL PROTECTED] wrote: > My favorite: > > "ntp-1.vt.edu is portscanning me very slowly with source port 123" > > The really sad ones are the ones who 3 days earlier dropped me a note to tell > me they'll using our NTP server. Due to the propensity of people to configure NTP in various annoying ways, and then failing to respond to requests to fix their systems, the NTP developers added a new command packet to the protocol. To help reduce the level of spurious network traffic due to obsolete configuration files, a special control message called the kiss-o'-death packet has been implemented. If enabled and a packet is denied service or exceeds the client limits, a compliant server will send this message to the client. A compliant client will cease further transmission and send a message to the system log. See the Authentication Options page for further information. Should other protocols include the same feature? If someone sends you a Dynamic DNS update, could the protocol include a kiss-o'-death packet to tell clients to go away? If someone keeps probing your HTTP server, should HTTP include a kiss-o'-death packet to tell clients to go away? If someone connects to your SMTP server, should SMTP include a kiss-o'-death packet to tell clients to go away. Or is this such a widely needed feature, should we try to include it in a base protocol such as IP/ICMP? In a large number of these cases, its not malicious, its misconfigured. A host could respond to a connection with an ICMP Go Away packet. Even if the end-host doesn't comply, an edge device or firewall using ICMP snooping could detect the Go Away packet and change its configuration. By pushing the control out to the edges, we avoid overloading the core with one-to-one configuration changes. Using a four-way handshake, its possible to protect against most types of spoofing and denial of service even without encryption or keys distribution. If you think the root servers are attacking you, Ok. Send a Go Away packet, and you won't get any more packets from the root server. Why would you do this? I don't know, but that's your choice. It would get the ISP out of the business of deciding what should be considered network abuse, and what isn't. After the user stops shooting himself in the foot (or runs out of toes), maybe he'll fix the broken auto-firewall software which thinks everyone is attacking him. At NANOG in Chicago, if anyone would like to discuss it further let me know.
Re: Security v. Privacy (was Re: Is there anything that actually gets users to fix their computers?)
> The difference being campus machines are null routed rather than > disconnected, and they are not reconnected until checked and clean. And once again, the question: how do you know the machines have been checked and cleaned before they are reconnected? Do you take the customers word, or do you perform some other check yourself? > Network security is high priority here and it doesn't matter what > machine is compromised, they are all disconnected in one way or another, > and yet we still have to nuke machines occasionally because of > suspicious (DDoS/scanning etc) traffic. Seems like a re-active policy. Why don't you check the computers before they start exhibiting suspicious behavior, such as when they are first connected to the network? Waiting until after the computer is compromised is too late. Some companies require all new computers to pass a network scan (e.g. ISS, Nessus, Retina, etc) before getting assigned a routable address. Should commercial service providers have the same policy when new customers connect to the network? Or is it considered a bad thing to warn customers about vulnerabilities in their computers in advance. Instead waiting until after your receive a complaint about something exploiting those vulnerabilities before taking action?
Re: Is there anything that actually gets users to fix their computers?
Robert Boyle [10/6/2003 9:42 AM] : What gets me is the moron admins who track down every "attack" they see. "Attacks" such as ICMP echo requests, Port 80 connections, etc. If they get huge logs that's one thing, but for four pings from a windows box or a mistyped IP address in a URL and they are worried about our "attack" These bogus reports outnumber legitimate complaints 4:1. 99% of them autogenerated by "personal firewall products". That include *screenshots* of "attack reports". Those can be safely auto-trashed, 99.999% of them are completely bogus stuff like "your DNS server is hacking me" srs -- Suresh Ramasubramanian <[EMAIL PROTECTED]> gpg# EDEDEFB9 Security and Antispam Operations Manager, Outblaze Limited
Re: Is there anything that actually gets users to fix their computers?
On Mon, 06 Oct 2003 00:12:07 EDT, Robert Boyle <[EMAIL PROTECTED]> said: > What gets me is the moron admins who track down every "attack" they see. > "Attacks" such as ICMP echo requests, Port 80 connections, etc. If they get > huge logs that's one thing, but for four pings from a windows box or a > mistyped IP address in a URL and they are worried about our "attack" These > bogus reports outnumber legitimate complaints 4:1. My favorite: "ntp-1.vt.edu is portscanning me very slowly with source port 123" The really sad ones are the ones who 3 days earlier dropped me a note to tell me they'll using our NTP server. pgp0.pgp Description: PGP signature
Re: Is there anything that actually gets users to fix their computers?
At 12:57 AM 10/5/2003, you wrote: At 2:11 AM + 10/5/03, Suresh Ramasubramanian wrote: For more fun, consider that you are [EMAIL PROTECTED], and get those It's the anti-virus ones that drive me nuts. "Someone in your domain sent us a virus which always forges the from line, but we're going to tell you anyway because we'd like you to buy our software..." What gets me is the moron admins who track down every "attack" they see. "Attacks" such as ICMP echo requests, Port 80 connections, etc. If they get huge logs that's one thing, but for four pings from a windows box or a mistyped IP address in a URL and they are worried about our "attack" These bogus reports outnumber legitimate complaints 4:1. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey
Re: Security v. Privacy (was Re: Is there anything that actuallygetsusers to fix their computers?)
On Sun, 5 Oct 2003, David A. Ulevitch wrote: > > How many times did you disable the same user's network access because > > they didn't actually fix their computer but told you it was fixed? > > Just once, if they weren't patched they were automatically turned down > again. (automated, not human processing) Forever? So the student can never use the university network again for as long as he or she remains at the school? Even if he or she promises the computer is really fixed this time?
Re: Security v. Privacy (was Re: Is there anything that actually gets users to fix their computers?)
Suresh Ramasubramanian wrote: Matthew Sullivan [06/10/03 11:38 +1000]: Third time their account is deleted. I am yet to have one that has reached the third time - 85k users here. Let me guess - that'd mostly be dialup users, right? Or maybe simply email users? Not (say) T1 and larger users? That's: Dialup, ISDN and analog (ISP) Hosted Servers (ISP) Gigabit/100M Connected Networks (Uni Campus/Colleges) Counting the campus & colleges machines there are a lot more than 85k. The difference being campus machines are null routed rather than disconnected, and they are not reconnected until checked and clean. We have one machine that within 2 weeks got trojaned twice, 4 months later it's still null routed because the machine owner cannot guarentee that it won't get trojaned again. Network security is high priority here and it doesn't matter what machine is compromised, they are all disconnected in one way or another, and yet we still have to nuke machines occasionally because of suspicious (DDoS/scanning etc) traffic. / Mat
Re: Security v. Privacy (was Re: Is there anything that actually gets users to fix their computers?)
On Mon, 06 Oct 2003 02:43:48 -, Suresh Ramasubramanian said: > > Matthew Sullivan [06/10/03 11:38 +1000]: > > Third time their account is deleted. > > > > I am yet to have one that has reached the third time - 85k users here. > > Let me guess - that'd mostly be dialup users, right? Or maybe simply email > users? Not (say) T1 and larger users? If it is mostly dialup users, it's all the more remarkable, as "conventional wisdom" has home users as being even less security-clued than the SOHO crowd or corporate sites... pgp0.pgp Description: PGP signature
Re: Security v. Privacy (was Re: Is there anything that actually gets users to fix their computers?)
Matthew Sullivan [06/10/03 11:38 +1000]: > Third time their account is deleted. > > I am yet to have one that has reached the third time - 85k users here. Let me guess - that'd mostly be dialup users, right? Or maybe simply email users? Not (say) T1 and larger users? -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 Manager, Outblaze.Com Antispam and Security Operations
Re: Removal of wildcard A records from .com and .net zones
On Sun, 05 Oct 2003 20:29:20 EDT, Brian Bruns <[EMAIL PROTECTED]> said: > world. Thats *20* minutes. > > Why does it take NetSol 24/48/72 hours to do the same thing? I guess it depends on whether your business model involves accepting money for doing a good job in resolving existent host names, or in accepting money for resolving non-existent host names pgp0.pgp Description: PGP signature
Re: Security v. Privacy (was Re: Is there anything that actually gets users to fix their computers?)
Suresh Ramasubramanian wrote: Sean Donelan [05/10/03 17:44 -0400]: What happens a few hours later when you start getting complaints again about the same customer? Do you turn the connection off again. And Sure, turn it off again. And again. Sooner or later, it will dawn on the customer that no, his system is not fixed. And in the meantime, both his bandwidth quota (if any) and the ISP's pipes avoid getting saturated with worms. We have a better way - first time they get turned off. Second time they get turned off and told if it happens again you will be told to get service elsewhere. Third time their account is deleted. I am yet to have one that has reached the third time - 85k users here. / Mat
Re: South America NOG ?
Bill, >> Is anyone aware of a South America NOG? or do they mainly use nanog? > >There was an operator's meeting in Argentina recently, unfortunately >scheduled at exactly the same time as the APNIC meeting. Primarily talk >about IXes, was my impression. I don't know how many attendees. Close to two hundred. You missed a good meeting! http://www.napla2003.com.ar/programa.html The presentations are all archived on that site. Martin
Re: South America NOG ?
> Is anyone aware of a South America NOG? or do they mainly use nanog? There was an operator's meeting in Argentina recently, unfortunately scheduled at exactly the same time as the APNIC meeting. Primarily talk about IXes, was my impression. I don't know how many attendees. -Bill
South America NOG ?
Is anyone aware of a South America NOG? or do they mainly use nanog? Pascal
Re: Removal of wildcard A records from .com and .net zones
Heres an interesting question Matt, maybe you can provide me with a worthwhile answer. Last night, I finally got around to registering a .org domain for my use. It took only 20 minutes from the time which I registered it, gave it my DNS servers, and paid for it, to when it was resolveable everywhere in the world. Thats *20* minutes. Why does it take NetSol 24/48/72 hours to do the same thing? -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.2mbit.com ICQ: 8077511 - Original Message - From: "Matt Larson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, October 03, 2003 5:50 PM Subject: Removal of wildcard A records from .com and .net zones > > VeriSign was directed by ICANN to suspend the Site Finder service by > 0100 UTC on Sunday, October 5. We requested an extension from ICANN > to give more notice to the community but were denied. We will be > removing the wildcard A records from the .com and .net zones beginning > at 2300 UTC on Saturday, October 4. The former behavior for these > zones (returning Name Error/RCODE=3 in response to queries for > nonexistent domain names) will be in place by 0100 UTC on Sunday, > October. > > Matt > -- > Matt Larson <[EMAIL PROTECTED]> > VeriSign Naming and Directory Services >
Re: Will reverting DNS wildcard have any adverse affects?
* [EMAIL PROTECTED] (Piotr KUCHARSKI) [Sat 04 Oct 2003, 20:51 CEST]: [..] > do arbitrary changes to them. Marking "com" and "net" as delegation-only > is not harming anything. (At least until ICANN changes its mind.) According to this mail: http://gnso.icann.org/mailing-lists/archives/registrars/msg00532.html ... apparently it breaks IDN resolution. Does anybody have the definite word on that? Regards, -- Niels.
Re: Security v. Privacy (was Re: Is there anything that actuallygets users to fix their computers?)
On Sun, 5 Oct 2003, Jamie Reid wrote: > While we were fighting blaster/nachi and others, we relied heavily on > IDS's to generate alerts for the worms, then we disabled their network > access and called them. Generic viruses are not an ISP's problem, but > a worm is something that affects the prviders infrastructure, and is > therefore a network operators business. Did the users actually believe you when you told them their computer had a worm? How many times did you disable the same user's network access because they didn't actually fix their computer but told you it was fixed? But I have a really important document that has to be sent right now, and I can't wait to fix the computer.
Re: Security v. Privacy (was Re: Is there anything that actually gets users to fix their computers?)
Sean Donelan [05/10/03 17:44 -0400]: > What happens a few hours later when you start getting complaints again > about the same customer? Do you turn the connection off again. And Sure, turn it off again. And again. Sooner or later, it will dawn on the customer that no, his system is not fixed. And in the meantime, both his bandwidth quota (if any) and the ISP's pipes avoid getting saturated with worms. -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 Manager, Outblaze.Com Antispam and Security Operations
Security v. Privacy (was Re: Is there anything that actuallygets users to fix their computers?)
While we were fighting blaster/nachi and others, we relied heavily on IDS's to generate alerts for the worms, then we disabled their network access and called them. Generic viruses are not an ISP's problem, but a worm is something that affects the prviders infrastructure, and is therefore a network operators business. Privacy is not an issue in this case as there is a policy being monitored by a policy monitoring tool, and enforced on a per-violation basis. It wasn't a fishing expedition that could assess the users configuration or usage, it was monitoring our network. There is no generalized way, without management access to the customers machine (via SMS or citrix or something), to check that the machine is in compliance with a network policy. An IDS can tell you if it violates policy, and you can act as your security procedures dictate. -- Jamie.Reid, CISSP, [EMAIL PROTECTED] Senior Security Specialist, Information Protection Centre Corporate Security, MBS 416 327 2324 >>> "Sean Donelan" [EMAIL PROTECTED]> 10/05/03 04:49pm >> [...] So from an ISPs point of view, is there a way for the ISP to quickly tell the customer if the particular computer is fixed without unduly intruding on the privacy of the customer? With home networks, there may be multiple computers behind a NAT/router/firewall. So a simple network scan doesn't always work. While we were fighting blaster/nachi and others, we relied heavily on IDS's to generate alerts for the worms, then we disabled their network access and called them. Generic viruses are not an ISP's problem, but a worm is something that affects the prviders infrastructure, and is therefore a network operators business. Privacy is not an issue in this case as there is a policy being monitored by a policy monitoring tool, and enforced on a per-violation basis. It wasn't a fishing expedition that could assess the users configuration or usage, it was monitoring our network. There is no generalized way, without management access to the customers machine (via SMS or citrix or something), to check that the machine is in compliance with a network policy. An IDS can tell you if it violates policy, and you can act as your security procedures dictate. --Jamie.Reid, CISSP, mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]Senior Security Specialist, Information Protection Centre Corporate Security, MBS 416 327 2324 >>> "Sean Donelan" mailto:[EMAIL PROTECTED]> 10/05/03 04:49pm >>">[EMAIL PROTECTED]> 10/05/03 04:49pm >>[...] So from an ISPs point of view, is there a way for the ISP to quicklytell the customer if the particular computer is fixed without undulyintruding on the privacy of the customer? With home networks, theremay be multiple computers behind a NAT/router/firewall. So a simplenetwork scan doesn't always work.
Re: Security v. Privacy (was Re: Is there anything that actually gets users to fix their computers?)
On Sun, 5 Oct 2003, Suresh Ramasubramanian wrote: > > So from an ISPs point of view, is there a way for the ISP to quickly > > tell the customer if the particular computer is fixed without unduly > > Isolate his IP and have all outbound http redirected to a page that > says "please call [escalated tech support number]" to get this fixed. > > Seems to be the only reasonably foolproof way. I think you missed the point. The problem isn't notification. Customer calls the escalated tech support number is swears the problem is fixed. Should the tech support person just take the customer's word that the problem is fixed and turn their connection back on? What happens a few hours later when you start getting complaints again about the same customer? Do you turn the connection off again. And then the customer again swears they have the problem fixed. How many times do you repeat the process? Other than taking the customer's word, is their any way for the ISP to verify the customer has fixed their computer before turning the connection on again?
Re: Security v. Privacy (was Re: Is there anything that actually gets users to fix their computers?)
Sean Donelan [05/10/03 16:49 -0400]: > There are some differences between private networks and public networks. > In a company, the company is the "owner" of the PCs and employees (in the Very true - and that was the context I mentioned this in. > So from an ISPs point of view, is there a way for the ISP to quickly > tell the customer if the particular computer is fixed without unduly Isolate his IP and have all outbound http redirected to a page that says "please call [escalated tech support number]" to get this fixed. Seems to be the only reasonably foolproof way. -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 Manager, Outblaze.Com Antispam and Security Operations
Security v. Privacy (was Re: Is there anything that actually gets users to fix their computers?)
On Sun, 5 Oct 2003, Suresh Ramasubramanian wrote: > Kee Hinckley [05/10/03 00:57 -0400]: > > Bringing this back to the more relevant topic. Is there something > > that ISPs could do to notify users and get in their face more without > > shutting off their connection? Perhaps a custom piece of > > I have seen corporate and university networks that make every PC have PC > Anywhere or its equivalent as part of the standard install, for activity to > be monitored. There are some differences between private networks and public networks. In a company, the company is the "owner" of the PCs and employees (in the US) have little expectation of privacy using company computers. On the public network, generally the customer owns the computer not the ISP. How far should an ISP go monitoring the activities of their customers? ISPs can and do notify customers by many methods such as popups, email, mail, phone calls, knocking on the door, etc. Notification doesn't seem to be the problem, but of the customer taking action. And even if the customer is willing, its difficult for them to tell if they have actually fixed their computers. Windows XP System Restore and anti-virus programs don't get along well. Booting Windows in "Safe Mode" requires dexterity. Most people don't have sniffers to check what their computers are transmitting. Sometimes it takes a non-expert several attempts to completely fix things. So from an ISPs point of view, is there a way for the ISP to quickly tell the customer if the particular computer is fixed without unduly intruding on the privacy of the customer? With home networks, there may be multiple computers behind a NAT/router/firewall. So a simple network scan doesn't always work.
RE: as6198 aggregation event
James Cowie wrote: > On Friday, we noted with some interest the appearance of more > than six hundred deaggregated /24s into the global routing > tables. More unusually, they're still in there this morning. > > AS6198 (BellSouth Miami) seems to have been patiently injecting > them over the course of several hours, between about 04:00 GMT > and 08:00 GMT on Friday morning (3 Oct 2003). If you look at the 09/19 and 09/26 CIDR Reports, BellSouth Atlanta (AS6197) did something similar during this time period -- they added about 350 deaggregated prefixes, most if not all /24's. > Usually when we see deaggregations, they hit quickly and they > disappear quickly; nice sharp vertical jumps in the table size. > This event lasted for hours and, more importantly, the prefixes > haven't come back out again, an unusual pattern for a single-origin > change that effectively expanded global tables by half a percent. That AS6197's additions are still present isn't encouraging. -Terry
as6198 aggregation event
On Friday, we noted with some interest the appearance of more than six hundred deaggregated /24s into the global routing tables. More unusually, they're still in there this morning. AS6198 (BellSouth Miami) seems to have been patiently injecting them over the course of several hours, between about 04:00 GMT and 08:00 GMT on Friday morning (3 Oct 2003). Here's a quick pic: http://www.renesys.com/images/6198.gif I can share more details offline. Usually when we see deaggregations, they hit quickly and they disappear quickly; nice sharp vertical jumps in the table size. This event lasted for hours and, more importantly, the prefixes haven't come back out again, an unusual pattern for a single-origin change that effectively expanded global tables by half a percent. Can anyone share any operational insight into the likely causes of this event? Has it caused any operational problems for anyone? Thanks! -- James Cowie Renesys Corporation
