In article <10309.2406.30280@avi.netaxs.com> Pete Kruckenberg wrote: : One of the criticisms of the change relative to this group : is that the previous stronger wording for the network : operator industry was watered down. Instead of : expecting/demanding/mandating that the industry collaborate : on network security (creating an ISAC and other measures), : the latest draft simply recommends that the industry : consider these measures. : Is there anything happening with collaborative security : policy and remediation in the industry? Has any effort : showed progress towards an effective ISAC or similar? Can : networks realistically collaborate on security, or do the : political and operational barriers not justify the effort? : Pete. Anything should of an action plan involving money or regulation is a very weak policy. Suggestions have never had much of an effect on Internet operators. I guess the real question is: What is going to happen over the next few years to get the infrastructure of the Internet to be more robust? I don't see market forces doing it. I don't suggest that the government use regulation, either. Perhaps the Feds (and maybe states) could use their purchasing power to effect change. Short of that, or regulation, the I don't see how the serious issues we have with the 'net will get resolved. I suppose that the "problem" is likely that people don't understand what a nice actually well-written worm could/would do if it were targeted at the infrastructure. Avi
On Tue, 14 Jan 2003, Avi Freedman wrote:
In article <10309.2406.30280@avi.netaxs.com> Pete Kruckenberg wrote:
[ SNIP ]
I suppose that the "problem" is likely that people don't understand what a nice actually well-written worm could/would do if it were targeted at the infrastructure.
If any operator doesn't believe it's coming, then I think they can safely be labeled naive. Even then, nothing is for free. -M
On Tue, 14 Jan 2003, Avi Freedman wrote:
: Is there anything happening with collaborative security : policy and remediation in the industry? Has any effort : showed progress towards an effective ISAC or similar? Can : networks realistically collaborate on security, or do the : political and operational barriers not justify the effort?
I guess the real question is: What is going to happen over the next few years to get the infrastructure of the Internet to be more robust? I don't see market forces doing it. I don't suggest that the government use regulation, either.
All of the initiatives (only a couple) I've found related to Internet operator security collaboration all appear to be pre 2000. At the May 2001 NANOG, which specifically focused on networking security, there was no presentation or (significant) discussion about inter-operator security collaboration. I was hoping to find that due to increased focus on infrastructure security post 9-11, there would actually have been increased activity in this area. Though there's certainly increased interest (probably more on the part of customers and government) I have not been able to find any evidence of increased activity. If anything, it /appears/ that generally inter-operator cooperation is actually decreasing. This may be a result of the competitive and financial changes in the market. This is alarming, considering the increase in attacks against infrastructure, and the sophistication of attacks over the last year. And we still use basically the same ineffective techniques to counteract and track attacks that became household words two years ago. I suspect a very effective worm would change this pretty quickly, most likely through onerous regulation. It's surprising that it hasn't happened already. Pete.
This is alarming, considering the increase in attacks against infrastructure, and the sophistication of attacks over the last year. And we still use basically the same ineffective techniques to counteract and track attacks that became household words two years ago.
yes.
I suspect a very effective worm would change this pretty quickly, most likely through onerous regulation. It's surprising that it hasn't happened already.
i've had absolutely no luck getting the source isp's to care about the problems i've seen at my home firewall in recent weeks. (see below if you wonder whether i'm implicating anyone here.) there's no other way to view the internet than as a worm-infested zombie. (this is a grep of just the port scans and attacks against ftp here.) Jan 1 18:40:44 fwlha /kernel: ipfw: 1800 Deny TCP 64.139.35.209:2559 204.152.184.163:21 in via dc0 Jan 1 18:41:32 fwlha /kernel: ipfw: 1800 Deny TCP 64.139.35.209:3478 204.152.188.62:21 in via dc0 Jan 3 06:15:19 fwlha /kernel: ipfw: 1800 Deny TCP 80.145.56.173:2113 204.152.184.163:57 in via dc0 Jan 3 06:15:37 fwlha /kernel: ipfw: 1800 Deny TCP 80.145.56.173:2595 204.152.184.163:21 in via dc0 Jan 3 06:15:40 fwlha /kernel: ipfw: 1800 Deny TCP 80.145.56.173:2595 204.152.184.163:21 in via dc0 Jan 4 09:02:17 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.0.37:4992 204.152.184.163:21 in via dc0 Jan 4 09:02:20 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.0.37:3314 204.152.184.163:21 in via dc0 Jan 4 09:03:08 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.0.37:3590 204.152.188.62:21 in via dc0 Jan 4 12:00:21 fwlha /kernel: ipfw: 1800 Deny TCP 61.187.223.85:4452 204.152.184.163:135 in via dc0 Jan 4 14:31:22 fwlha /kernel: ipfw: 1800 Deny TCP 203.44.175.56:21 204.152.184.163:21 in via dc0 Jan 4 14:31:29 fwlha /kernel: ipfw: 1800 Deny TCP 203.44.175.56:21 204.152.188.62:21 in via dc0 Jan 4 23:06:51 fwlha /kernel: ipfw: 1800 Deny TCP 81.50.67.165:1839 204.152.184.163:21 in via dc0 Jan 4 23:06:54 fwlha /kernel: ipfw: 1800 Deny TCP 81.50.67.165:1839 204.152.184.163:21 in via dc0 Jan 4 23:12:31 fwlha /kernel: ipfw: 1800 Deny TCP 81.50.67.165:2765 204.152.188.62:21 in via dc0 Jan 5 01:35:21 fwlha /kernel: ipfw: 1800 Deny TCP 24.204.53.253:3903 204.152.184.163:80 in via dc0 Jan 5 04:28:47 fwlha /kernel: ipfw: 1800 Deny TCP 202.96.237.247:4425 204.152.184.163:21 in via dc0 Jan 5 04:53:48 fwlha /kernel: ipfw: 1800 Deny TCP 12.102.38.251:1865 204.152.184.163:21 in via dc0 Jan 5 04:54:48 fwlha /kernel: ipfw: 1800 Deny TCP 12.102.38.251:2368 204.152.188.62:21 in via dc0 Jan 5 11:13:21 fwlha /kernel: ipfw: 1800 Deny TCP 12.212.111.82:1861 204.152.188.62:1433 in via dc0 Jan 10 15:35:21 fwlha /kernel: ipfw: 1800 Deny TCP 218.216.228.24:2258 204.152.184.163:445 in via vlan0 Jan 11 00:14:57 fwlha /kernel: ipfw: 1800 Deny TCP 217.57.93.19:54706 204.152.184.163:21 in via vlan0 Jan 11 00:16:31 fwlha /kernel: ipfw: 1800 Deny TCP 217.57.93.19:59226 204.152.188.62:21 in via vlan0 Jan 11 15:43:23 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.153.5:44688 204.152.184.163:21 in via vlan0 Jan 11 15:44:21 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.153.5:46979 204.152.188.62:21 in via vlan0 Jan 12 20:22:21 fwlha /kernel: ipfw: 3700 Deny TCP 207.1.8.15:2628 204.152.184.163:27374 in via vlan0 Jan 12 20:22:21 fwlha /kernel: ipfw: 3700 Deny TCP 207.1.8.15:2665 204.152.184.163:12345 in via vlan0 Jan 12 21:35:21 fwlha /kernel: ipfw: 4000 Deny TCP 209.237.238.161:1261 204.152.184.73:80 in via vlan0 Jan 12 21:35:21 fwlha /kernel: ipfw: 4000 Deny TCP 209.237.238.164:4200 204.152.184.73:80 in via vlan0 Jan 12 21:35:21 fwlha /kernel: ipfw: 4000 Deny TCP 209.237.238.165:4791 204.152.184.73:80 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3539 204.152.188.1:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3540 204.152.188.2:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3541 204.152.188.3:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3542 204.152.188.4:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3543 204.152.188.5:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3544 204.152.188.6:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3545 204.152.188.7:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3546 204.152.188.8:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3547 204.152.188.9:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3548 204.152.188.10:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3549 204.152.188.11:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3550 204.152.188.12:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3551 204.152.188.13:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3552 204.152.188.14:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3553 204.152.188.15:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3554 204.152.188.16:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3555 204.152.188.17:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3556 204.152.188.18:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3557 204.152.188.19:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3558 204.152.188.20:21 in via vlan0 Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3559 204.152.188.21:21 in via vlan0 Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3560 204.152.188.22:21 in via vlan0 Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3561 204.152.188.23:21 in via vlan0 Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3562 204.152.188.24:21 in via vlan0 Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3563 204.152.188.25:21 in via vlan0 Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3565 204.152.188.27:21 in via vlan0 Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3566 204.152.188.28:21 in via vlan0 Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3567 204.152.188.29:21 in via vlan0 Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3568 204.152.188.30:21 in via vlan0 Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3569 204.152.188.31:21 in via vlan0 Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3601 204.152.188.62:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3539 204.152.188.1:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3540 204.152.188.2:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3541 204.152.188.3:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3542 204.152.188.4:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3543 204.152.188.5:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3544 204.152.188.6:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3545 204.152.188.7:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3546 204.152.188.8:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3547 204.152.188.9:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3548 204.152.188.10:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3549 204.152.188.11:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3550 204.152.188.12:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3552 204.152.188.14:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3551 204.152.188.13:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3553 204.152.188.15:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3554 204.152.188.16:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3555 204.152.188.17:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3557 204.152.188.19:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3556 204.152.188.18:21 in via vlan0 Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3558 204.152.188.20:21 in via vlan0 Jan 13 03:40:28 fwlha /kernel: ipfw: 6200 Deny TCP 204.152.187.70:1492 204.152.188.18:21 in via vlan0 Jan 13 03:43:22 fwlha /kernel: ipfw: 6100 Unreach TCP 204.152.187.70:1497 204.152.188.18:21 in via vlan0 Jan 13 04:15:40 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4252 204.152.184.143:21 in via vlan0 Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4104 204.152.184.71:21 in via vlan0 Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4109 204.152.184.73:21 in via vlan0 Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4137 204.152.184.82:21 in via vlan0 Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4157 204.152.184.93:21 in via vlan0 Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4167 204.152.184.99:21 in via vlan0 Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4177 204.152.184.104:21 in via vlan0 Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4186 204.152.184.110:21 in via vlan0 Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4252 204.152.184.143:21 in via vlan0 Jan 13 04:15:45 fwlha /kernel: ipfw: 3500 Unreach TCP 80.128.237.81:4811 204.152.184.163:21 in via vlan0 Jan 13 04:15:48 fwlha /kernel: ipfw: 3500 Unreach TCP 80.128.237.81:4811 204.152.184.163:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2023 204.152.188.1:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2025 204.152.188.2:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2028 204.152.188.3:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2029 204.152.188.4:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2030 204.152.188.5:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2032 204.152.188.6:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2034 204.152.188.7:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2036 204.152.188.8:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2041 204.152.188.9:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2042 204.152.188.10:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2043 204.152.188.11:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2044 204.152.188.12:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2052 204.152.188.13:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2056 204.152.188.14:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2057 204.152.188.15:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 3500 Unreach TCP 80.128.237.81:2060 204.152.188.16:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2061 204.152.188.17:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2065 204.152.188.18:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2067 204.152.188.19:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2070 204.152.188.20:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2073 204.152.188.21:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2077 204.152.188.22:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2080 204.152.188.23:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2081 204.152.188.24:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2084 204.152.188.25:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2090 204.152.188.27:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2091 204.152.188.28:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2092 204.152.188.29:21 in via vlan0 Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2096 204.152.188.31:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2023 204.152.188.1:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2025 204.152.188.2:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2028 204.152.188.3:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2029 204.152.188.4:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2030 204.152.188.5:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2032 204.152.188.6:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2034 204.152.188.7:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2036 204.152.188.8:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2041 204.152.188.9:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2042 204.152.188.10:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2043 204.152.188.11:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2044 204.152.188.12:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2052 204.152.188.13:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2056 204.152.188.14:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2057 204.152.188.15:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 3500 Unreach TCP 80.128.237.81:2060 204.152.188.16:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2061 204.152.188.17:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2065 204.152.188.18:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2067 204.152.188.19:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2070 204.152.188.20:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2073 204.152.188.21:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2077 204.152.188.22:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2084 204.152.188.25:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2090 204.152.188.27:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2091 204.152.188.28:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2092 204.152.188.29:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2094 204.152.188.30:21 in via vlan0 Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2096 204.152.188.31:21 in via vlan0 Jan 13 04:17:24 fwlha /kernel: ipfw: 3500 Unreach TCP 80.128.237.81:2162 204.152.188.62:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2030 204.152.188.5:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2029 204.152.188.4:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2028 204.152.188.3:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2025 204.152.188.2:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2057 204.152.188.15:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2056 204.152.188.14:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2052 204.152.188.13:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2044 204.152.188.12:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2043 204.152.188.11:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2042 204.152.188.10:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2041 204.152.188.9:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2036 204.152.188.8:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2034 204.152.188.7:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2081 204.152.188.24:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2080 204.152.188.23:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2073 204.152.188.21:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2070 204.152.188.20:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2067 204.152.188.19:21 in via vlan0 Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2061 204.152.188.17:21 in via vlan0 Jan 13 07:21:57 fwlha /kernel: ipfw: 3500 Unreach TCP 217.141.146.245:4524 204.152.184.163:1433 in via vlan0 Jan 13 07:21:59 fwlha /kernel: ipfw: 3500 Unreach TCP 217.141.146.245:4524 204.152.184.163:1433 in via vlan0 Jan 13 14:43:21 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:4049 204.152.184.163:57 in via vlan0 Jan 13 14:43:33 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:4970 204.152.184.163:21 in via vlan0 Jan 13 14:43:36 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:4970 204.152.184.163:21 in via vlan0 Jan 13 14:43:37 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:1036 204.152.188.16:21 in via vlan0 Jan 13 14:43:37 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:1061 204.152.188.62:21 in via vlan0 Jan 13 14:43:40 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:1036 204.152.188.16:21 in via vlan0 Jan 13 14:43:40 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:1061 204.152.188.62:21 in via vlan0 Jan 13 14:43:42 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:4970 204.152.184.163:21 in via vlan0 Jan 13 14:43:46 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:1036 204.152.188.16:21 in via vlan0 Jan 13 14:43:46 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:1061 204.152.188.62:21 in via vlan0 Jan 14 05:25:58 fwlha /kernel: ipfw: 1610 Deny TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:26:06 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:26:07 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:26:07 fwlha /kernel: ipfw: 1610 Deny TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:26:07 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:26:09 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:26:09 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:26:12 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:26:14 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:26:14 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:26:17 fwlha /kernel: ipfw: 1610 Deny TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:26:17 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:26:17 fwlha /kernel: ipfw: 1610 Deny TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:26:24 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:26:25 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:26:27 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1744 204.152.188.26:21 in via vlan0 Jan 14 05:26:28 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:26:29 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1744 204.152.188.26:21 in via vlan0 Jan 14 05:27:07 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:27:16 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:27:21 fwlha /kernel: ipfw: 1610 Deny UDP 213.140.2.12:53 204.152.188.26:53 in via vlan0 Jan 14 05:27:27 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:27:42 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1899 204.152.188.26:21 in via vlan0 Jan 14 05:27:43 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1899 204.152.188.26:21 in via vlan0 Jan 14 05:27:44 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1899 204.152.188.26:21 in via vlan0 Jan 14 05:27:48 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:28:21 fwlha /kernel: ipfw: 1610 Deny UDP 213.140.2.21:53 204.152.188.20:53 in via vlan0 Jan 14 05:28:21 fwlha /kernel: ipfw: 1610 Deny UDP 213.140.2.21:53 204.152.188.26:53 in via vlan0 Jan 14 05:28:51 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:29:21 fwlha /kernel: ipfw: 1610 Deny UDP 213.140.2.21:53 204.152.188.26:53 in via vlan0 Jan 14 05:29:21 fwlha /kernel: ipfw: 1610 Deny UDP 213.140.2.12:53 204.152.188.26:53 in via vlan0 Jan 14 05:29:55 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:30:51 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:2446 204.152.188.26:21 in via vlan0 Jan 14 05:30:52 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:2446 204.152.188.26:21 in via vlan0 Jan 14 05:30:52 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.15.167:1081 204.152.188.26:21 in via vlan0 Jan 14 05:30:53 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:2446 204.152.188.26:21 in via vlan0 Jan 14 05:30:53 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.15.167:1081 204.152.188.26:21 in via vlan0 Jan 14 05:30:53 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.15.167:1081 204.152.188.26:21 in via vlan0 Jan 14 05:30:59 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:31:24 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:2627 204.152.188.26:21 in via vlan0 Jan 14 05:32:03 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:32:29 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:33:07 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:33:46 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:34:11 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:34:35 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:34:50 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:35:15 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0 Jan 14 05:35:39 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:35:54 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:36:43 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:36:58 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:37:44 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.14.136:2060 204.152.188.26:21 in via vlan0 Jan 14 05:37:47 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:37:52 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.14.136:2090 204.152.188.26:21 in via vlan0 Jan 14 05:38:02 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:38:51 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:39:07 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:39:55 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:40:10 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:40:59 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0 Jan 14 05:41:14 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0 Jan 14 05:46:25 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.56.136:3065 204.152.188.26:21 in via vlan0 Jan 14 05:52:50 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.14.139:2559 204.152.188.26:21 in via vlan0 Jan 14 05:55:36 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.14.136:3375 204.152.188.26:21 in via vlan0 Jan 14 05:55:37 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.14.136:3379 204.152.188.26:21 in via vlan0 -- Paul Vixie
On 14 Jan 2003, Paul Vixie wrote:
This is alarming, considering the increase in attacks against infrastructure, and the sophistication of attacks over the last year. And we still use basically the same ineffective techniques to counteract and track attacks that became household words two years ago.
yes.
I suspect a very effective worm would change this pretty quickly, most likely through onerous regulation. It's surprising that it hasn't happened already.
i've had absolutely no luck getting the source isp's to care about the problems i've seen at my home firewall in recent weeks. (see below if you wonder whether i'm implicating anyone here.) there's no other way to view the internet than as a worm-infested zombie.
One problem with notifications typically (that I've seen) is that there is no one to notify... there may be an email address, but most likely that's not even watched/read/responded-to/reacted-upon. From my experience we recieve less than 1 in 3K responses :( For UUNET I know that there is a response and action on 'all' complaints, provided there is enough info to take some action. NOTE, that action might not be 'disconnect' it might be 'notify downstream customer'... but atleast someone is doing something :) And there is a 24/7 security group responsible for dealing with live incidents. This is also not very common at most organizations. :( To start fixing this problem every ISP really needs some security folks dedicated to customer security issues... These folks need to have the ability to contact customers and shut off services until the problem has been rectified. Hopefully, once there are security folks at all ISP's the ISP's will be able to speak intelligently and civily to each other to cooperate and contain problems.
(this is a grep of just the port scans and attacks against ftp here.) -- snipped --
On Tue, 14 Jan 2003, Christopher L. Morrow wrote:
To start fixing this problem every ISP really needs some security folks dedicated to customer security issues... These folks need to have the ability to contact customers and shut off services until the problem has been rectified.
I'd be happy if every ISP had at least one competent engineer who cared about their job... Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
On Tue, 14 Jan 2003, Andy Dills wrote:
On Tue, 14 Jan 2003, Christopher L. Morrow wrote:
To start fixing this problem every ISP really needs some security folks dedicated to customer security issues... These folks need to have the ability to contact customers and shut off services until the problem has been rectified.
I'd be happy if every ISP had at least one competent engineer who cared about their job...
Andy
Which ISP is terminating spammers and hackers? The bean counters are looking TOS violations as revenue loss. I'd love to see a bar chart of TOS terminations in the US from 1998 to 2003. Would we be surprised? Is anyone surprised that SPAM became, and remained, a problem, a DDoS in it's own right? Trying to keep on the topic of infrastructure, the best thing that Uncle Sam could do for us is to fund research into new methods and procedures to detect infrastructure attacks which help us to define operational procedures on prevention and defense. Much like SPAM, we're not going to win a war on these people. We can only detect and defend. Perhaps countermeasures could fit in their was well in the case of a grand attack. I'd love to see a Operational security focused list sponsored by NANOG. -M
One problem with notifications typically (that I've seen) is that there is no one to notify...
We tried notifications to the netblock owner for every incident that exceeded a reasonable threshold. [1] It takes a lot of time to find netblock owners. Even after investing self to try to make the net a better place, the satisfactory response rate is very small.
there may be an email address, but most likely that's not even watched/read/responded-to/reacted-upon.
ditto.
recieve less than 1 in 3K responses :(
We may not have time to answer each of the mechanized notifications, but we process and respond to each incident. If only every ISP did at least that.
To start fixing this problem every ISP really needs some security folks dedicated to customer security issues...
I am the point of contact for the net in the sig below. We take all network abuse notifications seriously, and follow up with our customers. I am not hard to find. whois -h whois.arin.net bb122-arin
Hopefully, once there are security folks at all ISP's the ISP's will be able to speak intelligently and civily to each other to cooperate and contain problems.
Amen. At your service, -bryan bradsby Texas State Government Net me: 512-936-2248 NOC: 512-475-2432 877-472-4848 -- If all the world's a stage, I want to operate the trap door. -- Paul Beatty [1] (see: "Firewall Seen" by Robert Graham) http://www.robertgraham.com/pubs/firewall-seen.html
i've had absolutely no luck getting the source isp's to care about the problems i've seen at my home firewall in recent weeks. (see below if you wonder whether i'm implicating anyone here.) there's no other way to view the internet than as a worm-infested zombie.
hehe... I know the feeling. With DShield, we try hard to send out correlated and filtered reports in a standardized format to valid 'contact' addresses. There are some success stories, but more misses than hits overall. The 'misses' fall into two categories: - ignored/bad contact/ ( /dev/null group ) - or the "portscanning is not a crime" group. (at least they respond). What is an appropriate reaction if an ISP receive an abuse report? I know abuse@ is getting swamped with Excel Spreadsheets, screenshots and hate mail, and most of them are 'begnin' (P2P file sharing after glow and the like). But would it be too much for an ISP to send an email to the customer as they receive the first reports, a phone call after the third ... ? (BTW: Any ISPs here that would like a daily unfiltered report? I just streamlined that function last week.) here some dshield data for the IPs in your list
Jan 1 18:40:44 fwlha /kernel: ipfw: 1800 Deny TCP 64.139.35.209:2559 204.152.184.163:21 in via dc0
scanned 9 different targets , > 30 days ago
Jan 3 06:15:19 fwlha /kernel: ipfw: 1800 Deny TCP 80.145.56.173:2113 204.152.184.163:57 in via dc0 Jan 3 06:15:37 fwlha /kernel: ipfw: 1800 Deny TCP 80.145.56.173:2595 204.152.184.163:21 in via dc0 Jan 3 06:15:40 fwlha /kernel: ipfw: 1800 Deny TCP 80.145.56.173:2595 204.152.184.163:21 in via dc0
2 targets, > 30 days ago... TONLINE is receiving a daily summary report from us. For a while, they bounced it forth and back between departments for days. Now they just /dev/null it I think.
Jan 4 09:02:17 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.0.37:4992 204.152.184.163:21 in via dc0 Jan 4 09:02:20 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.0.37:3314 204.152.184.163:21 in via dc0
Wanadoo.fr... do I need to say more?
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3540 204.152.188.2:21 in via vlan0
3 different tagets... does ftp and P2P... -- -------------------------------------------------------------------- jullrich@euclidian.com Collaborative Intrusion Detection join http://www.dshield.org
On Tue, 2003-01-14 at 14:09, Paul Vixie wrote:
i've had absolutely no luck getting the source isp's to care about the problems i've seen at my home firewall in recent weeks. (see I recommend you blackhole the offending /32s from F. Obviously these worms, connected via unresponsive or incapable networks, are a danger to F and to our national infrastructure.
And while you're at it, renumber F into 69/8, preferably with the last octet 0 or 255. -- Jeff S Wheeler <jsw@five-elements.com>
On Tue, 14 Jan 2003, Pete Kruckenberg wrote:
All of the initiatives (only a couple) I've found related to Internet operator security collaboration all appear to be pre 2000. At the May 2001 NANOG, which specifically focused on networking security, there was no presentation or (significant) discussion about inter-operator security collaboration.
Whenever "security" comes up people get a little weird. Nevertheless there have been several inter-provider initiatives since 2000. - INOC-Dial by ASN included security contacts - ISP security BOF and nsp-security - FCC NRIC focus group on provider security best practices
Avi Freedman <freedman@freedman.net> writes:
Perhaps the Feds (and maybe states) could use their purchasing power to effect change. Short of that, or regulation, the I don't see how the serious issues we have with the 'net will get resolved.
I suppose that the "problem" is likely that people don't understand what a nice actually well-written worm could/would do if it were targeted at the infrastructure.
People do. I've been beating this particular horse for a while now, and we are starting to deploy the capex hammer. I suggest others start to do the same. See my presentation at the eugene nanog. /vijay
On 14 Jan 2003, Vijay Gill wrote:
Avi Freedman <freedman@freedman.net> writes:
Perhaps the Feds (and maybe states) could use their purchasing power to effect change. Short of that, or regulation, the I don't see how the serious issues we have with the 'net will get resolved.
People do. I've been beating this particular horse for a while now, and we are starting to deploy the capex hammer. I suggest others start to do the same. See my presentation at the eugene nanog.
I can see how purchasing power may motivate a vendor (and maybe lots of individual vendors) to fix their own problems, develop better products, or be more responsive. I'm trying to envision an RFP that awards business to one or a few network operators, but requires that they interoperate effectively with other operators who don't win any of the business. I've only got a state-level purchasing perspective, but I don't see it happening at any level. Is spending really an effective hammer (or gun) to make people work together if they aren't otherwise motivated to? Behavior related to the '96 Telecom Act doesn't inspire confidence. Can technical solutions be an effective band-aid for a complex poli-socio-economic problem like this? Pete.
On Tue, 14 Jan 2003 13:16:45 MST, Pete Kruckenberg <pete@kruckenberg.com> said:
I'm trying to envision an RFP that awards business to one or a few network operators, but requires that they interoperate effectively with other operators who don't win any of the business. I've only got a state-level purchasing perspective, but I don't see it happening at any level.
So you award the contract to a provider that has clueful engineers. How do you mandate/enable/whatever that they be able to interoperate effectively with the clueless vendor that didn't get the contract? Remember to address the fact that the clueless vendor would probably have to expend resources to support somebody else's contract, with no income to back it up. In addition, how would you enforce this without getting sued? You award the contract to Vendor A, they can't interoperate because Vendor B is a bunch of clueless weenies - now what do you do? -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
On 14 Jan 2003, Vijay Gill wrote:
I can see how purchasing power may motivate a vendor (and maybe lots of individual vendors) to fix their own problems, develop better products, or be more responsive.
The problem is that the "government" does not have large purchasing power compared to the commercial side of the house. The government doesn't buy in bulk, doesn't buy often and usually selects the lowest cost. Vendors design equipment/services for the customers who will buy it. The majority of those customers are revenue driven commercial entities that have always questioned the need to pay for any additional security. In the past, "security" has never been an easy sell to anyone when a cost was attached because it was never perceived to have the potential to bring in additional revenue and because those who were aware of security breaches of substance would not acknowledge them (this goes for government and industry). And sadly there are some vendors who are so big or have such a large share of their market space, that they just do what they want regardless. John S. Maddaus
Perhaps the Feds (and maybe states) could use their purchasing power to effect change. Short of that, or regulation, the I don't see how the serious issues we have with the 'net will get resolved. I suppose that the "problem" is likely that people don't understand what a nice actually well-written worm could/would do if it were targeted at the infrastructure.
People do. I've been beating this particular horse for a while now, and we are starting to deploy the capex hammer. I suggest others start to do the same. See my presentation at the eugene nanog.
So what's a good place to look for security requirements in RFPs for hardware/software vendors ? Thanks. Rajesh.
participants (14)
-
Andy Dills -
Avi Freedman -
Bryan Bradsby -
Christopher L. Morrow -
Jeff S Wheeler -
Johannes Ullrich -
Martin Hannigan -
Merlin Communications -
Paul Vixie -
Pete Kruckenberg -
Rajesh Talpade -
Sean Donelan -
Valdis.Kletnieks＠vt.edu -
Vijay Gill