- NANOG - lists.nanog.org

RE: SECURITY: Abuse & upnormal traffic in 207.218.250.181 [ev1.net]
by John Obi 09 Feb '04

09 Feb '04

Hello folks, I would like to thank everyone who helped out to get this issue resolved. Many thanks go to Mr. Alif Terranson the OpSec Engineering Manager from Savvis Communications Corporation. Thanks, -J __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0

RE: Dumb users spread viruses
by Michel Py 09 Feb '04

09 Feb '04

> Robert Boyle wrote: > Please help me resist the siren song of Outlook 2003. What I retain from your very good post is that if _you_ are having trouble resisting the siren song, there is nothing to do for the typical non-technical CEO, as all they care about is feature and ease of use. Microsoft may be crap, but as long as the users are screaming for it, no problemo. After you've shown them that they can have their email, calendaring, contacts, etc in their cell phone, that their administrative assistant can manage it from the office, and that it fits in their shirt pocket and is updated quasi real-time, the sale is over. Real story: A month ago I had a non-technical customer that used her windoze cell phone to open a critical m$ word file from the basement of capitol hill. One can whine all they want about Outlook, if one does not provide a solution that looks as good IN THE USER'S MIND, one will continue so see Outlook being the dominant app and Windows being the dominant OS. Michel.

1 0

Applying HD Ratio to all IPv4 allocations
by Michael.Dillon＠radianz.com 09 Feb '04

09 Feb '04

I'm going to present the following policy change at the ARIN meeting in April. In a few days I have to submit the exact wording to ARIN and I'm looking for comments before I do this. Basically this policy loosens the rigid 80% utilization requirement in a progressive fashion to recognize the inevitable overhead of hierarchy in larger networks. 1. All requests for additional IPv4 address space shall require the efficient utilization of the sum total of all existing allocations including all space reassigned to customers, if any. 2. The HD(Host Density) ratio of the sum total of all previous allocations shall be greater than or equal to .966 and the HD ratio of the most recent allocation shall be greater than or equal to .930 in order to receive additional space. 3. The HD ratio is calculated as log(utilized IPv4 addresses) divided by log(total addresses in all previous allocations). In this formula, log refers to the natural logarithm. Rationale: The HD ratio was proposed as a way to determine allocation usage thresholds for IPv6 address allocations. For more details on this, please refer to RFC 3194 <http://www.faqs.org/rfcs/rfc3194.html>. There is some detailed background discussion about applying the HD ratio to IPv4 allocations in a proposal by Paul Wilson posted to the APNIC mailing list on Aug 7, 2003 http://www.apnic.net/mailing-lists/sig-policy/archive/2003/08/msg00000.html and he presented the it to the annual APNIC policy meeting using these slides http://www.apnic.net/meetings/16/programme/sigs/docs/policy/addpol-pres-wil… I am not suggesting that ARIN should adopt the APNIC proposal and although Paul invents a new name for the HD ratio, I prefer to keep the original term. The basic thrust of this proposal is to replace the rigid 80% usage criterion by the more flexible HD ratio and to shift the emphasis away from the last allocated block to include the total allocated address space. To that end, the .930 criterion for the last block is a lot looser than the existing requirements for the last block. This is because the utilization threshold establishes a time buffer between the beginning of an ARIN application for additional addresses and the final deployment of new addresses in the operational network. By using a looser criterion as network size grows, we are also expanding this time buffer. This recognizes that the economy is more dependent than ever on the smooth running of our networks and we should not artificially force larger members to operate with virtually no safety buffers for implementing new addresses. This safety buffer size is important because larger networks have more involved processes for changes to their network and these processes take time. Paul Wilson's paper contains ample discussions of the technical justification for using the HD ratio. I have proposed that we use the .966 number that he suggests, I believe there may be valid arguments for reducing this slightly, perhaps to .960. ------------------------------------------------------- Michael Dillon Capacity Planning, Prescot St., London, UK Mobile: +44 7900 823 672 Internet: michael.dillon(a)radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030

2 1

Re: Dumb users spread viruses
by John Payne 09 Feb '04

09 Feb '04

--On Sunday, February 8, 2004 10:46 PM +0000 Paul Vixie <vixie(a)vix.com> wrote: > There is nothing wrong with a user who thinks they should not have to know > how to protect their computer from virus infections. However, someone attending NANOG should at least have cleaned up slammer before connecting to the wireless...

5 5

OT - Special Interest Texas Reunion
by Timothy Brown 09 Feb '04

09 Feb '04

If you don't know what i'm talking about, just ignore this! Those of you who are interested in another Texas Reunion, in the vein of Toronto and last night, drop me a line privately today. Tim

1 0

Re: Stopping open proxies and open relays
by Simon Waters 09 Feb '04

09 Feb '04

NANOG Digest wrote: > > It would help if systems would only execute code that is signed > properly. This would make malware traceable. However the current way of > getting your code signed is in many cases too costly for the casual open > source developer so people are used to running unsigned or selfsigned > application even when the facilities to check signatures would already > exist in the system. (though for example in Windows, signatures are only > checked at install, not runtime) My supply of free software is signed by the developer/maintainer and the trust relationship established through GnuPG, and Keyservers. The OS has facilities to check these at install time if you want. You'd only need to check at run time if root had altered the executables - and he is a pretty solid chap here ;) Similarly when I distribute free software it is always accompanied by signed MD5 hash of each file distributed. So I don't think it is costly to do if you pick a suitable model. The certificate authority approach is pointless until they provide proper support for revocation, which most didn't last time I looked, but I believe it is getting better. (I'm in the cynical group who believes that the Certificate Authorities are a conspiracy to tax encryption). But typically signing only proves the authorship, it doesn't tell you anything about how well written (and thus compromisable) the code is, or how trustworthy the recipient is ('anyone the certificate authority will accept money off' - to paraphrase a comment), or how well protected their keys are. Signing is a fine approach, but I think sandboxing should take priority. Here even if the code is subverted by malformed data, the key stolen, etc etc - the damage is limited. Lots of installed copies of IE seem happy to run any "signed ActiveX" plugin - even when it is Spyware. Although I'm not clear if this is down to a bad choice of defaults, or users not understanding that even signed cheques bounce (indeed unsigned cheques don't get that far usually). One more to check and switch to 'prompt' if you still use IE. Popular spyware seems to go under inspiring names like spy.exe, trojan.exe etc, but relatively knowledgable Internet users still manage to get it installed against their wishes. I'm sure there is a more appropriate forum - but then there are probably web pages discussing it in great details. Of course neither approach excludes the other.

1 0

RE: abusereporting (was Re: Monumentous task of making a list)
by Stephen Gill 09 Feb '04

09 Feb '04

Hi Mikael, Aside from the standardization issue, some of the problems with reports as they stand are that they can be routed to the wrong people, there is no clear way of verifying the authenticity of the data, and the sheer number of reports can inundate a given abuse helpdesk such that they are tempted not to take any action at all. Having a standardized report format is a great idea. In our experience information needs to come from a trusted source or people are less likely to act on the information provided. We've also found it helpful to submit the reports to the ASN maintainers (ISPs) using real-time BGP routing table information to determine who is responsible for a given netblock rather than relying on archaic whois data. The reports are also rolled up into concise summaries where possible so as not to inundate AS maintainers with unnecessary data. If you'd like to quickly determine who is routing a given IP address, you can send your queries to the CYMRU whois server. More information about it can be found here: http://www.cymru.com/BGP/whois.html Members of NSP-SEC receive reports on a weekly or ad-hoc basis summarizing what others are seeing emanating from their networks. The reports are in turn processed by many, such that ISPs can alert their own customers and downstreams of potential problems. A summary of what types of reports are submitted can be found here: http://www.nanog.org/mtg-0310/pdf/cymru.pdf We agree that having a timestamp is crucial to problem resolution, most preferably in GMT. We accompany all IP numbers with an ASN which is used to route the report to the appropriate network boundary. All reports receive a context quantifying and providing a scope around the data. Cheers, Steve, for Team Cymru. -- Date: Sun, 8 Feb 2004 10:43:11 +0100 (CET) From: Mikael Abrahamsson <swmike(a)swm.pp.se> Subject: abusereporting (was Re: Monumentous task of making a list) On Sun, 8 Feb 2004, Suresh Ramasubramanian wrote: > The problem with trojans etc is that there so damn many of them, so the > less time spent actually tracking down the user who was on IP X at time > Y, the better it is for the ISP's staffers who handle complaints about > these. I have asked about this before. Wouldnt it be very nice if there was a standardized way to report IP-number and timestamp and type of complaint? I've seen something produced by some workgroup (RIPE?) but that was a huge document about XML and it seemed non-trivial to implement. I was more into the idea of having basically email headers like: X-ABUSEREPORT-IP: <ip> X-ABUSEREPORT-DATE: <unix timestamp> X-ABUSEREPORT-TYPE: <spam|abuse|ddos|other> This should make it trivial for most automated tools to append this (spambouncer etc) and make it much easier for the abuse system to do a user lookup before presenting the abuse email to the handler, even providing the user email address so the handler can take action. - -- Mikael Abrahamsson email: swmike(a)swm.pp.se

2 1

Stopping open proxies and open relays
by Adi Linden 09 Feb '04

09 Feb '04

I am looking for ideas to stop the spam created by compromised Windows PC's. This is not about the various worms and viruses replicating but these boxes acting as open relays or open proxies. There are valid reasons not to run antivirus software, coupled with clueless users, this results in machines that SPAM again just a few hours after having been cleaned. Adi

10 12

Re: P2P open source blocking project
by Michael.Dillon＠radianz.com 09 Feb '04

09 Feb '04

>> For those you want to kill the various p2p programs..there is a >> promising project at the following address: >I'd like to further reduce the functionality of my internet transport >because why? In order to spur the development of more sophisticated P2P protocols and encourage users to switch over to using them. The net *IS* an ecosystem, after all. Read up on eigentrust and "emergent behavior" and "complex adaptive systems". The current crop of popular P2P networks are quite crude and deserve to be killed off in favor of more robust models. --Michael Dillon

1 0

Re: Dumb users spread viruses
by Paul Vixie 09 Feb '04

09 Feb '04

> Uneducated users should live with the slowness. It's protecting the rest of > the world from their blissful ignorance. if it protected them or anybody else i'd say you were right, but since it's a pattern matcher it always takes 2 to 24 hours for a new pattern file to be developed and distributed after a new worm is released. why even bother? > The average Windows user CANNOT BE TRUSTED TO DO THE RIGHT THING because > they are blindly trusting the (1) operating system's security, and (2) > non-malicious intent of the things they view or download. > > This is established fact, with oodles of hard-earned stats to back it up. once you add a particular operating system to the equation i can't disagree (mostly due to lack of facts i've actually gathered or checked personally.) however, in the situation you describe, the fault is still with the OS, not with the end user. as i said before, if we (the creators and distributors of the products and services these users depend on) can't make them safe, then the fault is with us, not with the people using them. it's as if not knowing how the fuel injectors work on my car could make it blow up on the freeway. we'd blame the manufacturer, not the driver, right?

4 3