- Test - lists.nanog.org

mail message charging? + nanog digest
by Allan Chong 02 Sep '97

02 Sep '97

After the latest round of spam in my mail box from throwaway accounts plus a spate of damn junk faxes..... Anyone implemented per message limits on SMTP mail? 1) a billing structure that allows say 1000 outgoing mail messages and either charges or shuts off the account beyond that. I wrote a series of scripts that injected each syslog mail entry into a Sybase database in real time at a previous job. 2) filters on dialup accounts that prevent SMTP connections to anything but the local SMTP server (much as there are spoofing filters on most dialup routers nowadays) 3) you'd have to authenticate your SMTP connections, which if they're from your local dialup pool, should be nothing more than checking your real time accounting database. (most ISPs aren't running real time accounting, but probably should be just to prevent multiple account abuse). A feature rich Radius server seems to be sorely lacking. This seems to be one piece of software that many large ISPs are writing on their own. 4) you could always allow "good" customers access through if they really needed SMTP access for some reason or another. The basic idea would be to get rid of the damn $20 dialup accounts most of the spam that is hitting my mailbox seems to be coming from. Anyone see any gaping flaws in this logic? BTW, there is a nanog digest going out twice daily. I'm willing to add any procmail filters for anything that will increase signal to noise. > >nanog-d Mon Sep 1 22:57:01 EDT 1997 > >This unofficial procmail'ed digest sponsored by Allan Chong. >Please mail subscribe/unsubscribe requests to allan(a)alum.mit.edu > >Contents: > > Altavista Hacked ? ("George J. Broadfoot III" <george(a)laserlink.net>) > Re: Altavista Hacked ? (Philip Steffora <steffora(a)av-ops.pa.dec.com>) > Re: Anyone Deployed Ascend's GRF IP Switch? ("Gary E. Miller" <gem(a)rellim.com>) > Digital's Altavista NOT hacked! (Philip Steffora <steffora(a)av-ops.pa.dec.com>) > Re: Altavista Hacked ? (jbodkin(a)attmail.com (Jimmy Bodkin)) > >---------------------------------------------------------------------- > >Date: Mon, 1 Sep 1997 15:09:29 +0000 >From: "George J. Broadfoot III" <george(a)laserlink.net> >Subject: Altavista Hacked ? > > -- Allan Chong allan(a)alum.mit.edu Eisenhower was very nice, Nixon was his only vice. -- C. Degen

1 0

Altavista Hacked ?
by George J. Broadfoot III 01 Sep '97

01 Sep '97

Anyone confirm that Altavista's home page was hacked today ? About 10:30 am EST I went there and found their "usual home page" included in a page that said hello to some hackers and had some small message about the page being hacked. When I got back to checking it at 15:00 EST that page was gone and the "usual Altavista home page" had returned. George J. Broadfoot III VP of Operations Laser Link Network Services, Inc. 610.566.2993 FAX 610.566.9093

2 2

Re: Altavista Hacked ?
by jbodkin＠attmail.com 01 Sep '97

01 Sep '97

Yes the page was Hacked but it looks like the Web master for Altavista has fixed the trouble. Jim Bodkin ____________________ Begin Original Message ___________________________ Date: 9/1/97 3:09 PM From: internet!laserlink.net!george (George J. Broadfoot III) Subject: Altavista Hacked ? To: internet!merit.edu!nanog Anyone confirm that Altavista's home page was hacked today ? About 10:30 am EST I went there and found their "usual home page" included in a page that said hello to some hackers and had some small message about the page being hacked. When I got back to checking it at 15:00 EST that page was gone and the "usual Altavista home page" had returned. George J. Broadfoot III VP of Operations Laser Link Network Services, Inc. 610.566.2993 FAX 610.566.9093

1 0

Re: Blocking spoofing at the source (was: ICMP Attacks??)
by David Bolen 29 Aug '97

29 Aug '97

Robert Sanders <rsanders(a)mindspring.net> writes: > I plan to deploy anti-spoofing filters throughout our access network > before the end of September. Is anybody else running or planning to > implement similar filters? We've been doing this (also with USR total control hardware) since we first started handling large scale dialup IP a bit over a year ago. Before USR had the dynamic filters, we just preloaded per-customer filters into each box and referenced it with a normal filter id. While we couldn't make the filters specific to the user, they did restrict traffic to the source address block from which all dynamic addresses were assigned, so even if they spoofed, it would still track back to a block that ANS was identified with, and we could work backwards through our call records to try to track it down. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l(a)ans.net / | ANS Communications, Inc. \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

1 0

Re: Blocking spoofing at the source (was: ICMP Attacks??)
by Robert Sanders 29 Aug '97

29 Aug '97

Phil Howard <phil(a)charon.milepost.com> writes: > As long as _one_ _of_ _the_ _routes_ would go back on the interface the > packet arrived on, not necessarily the best route, then the logic would > work in the majority of cases that I know of. > > But this could require a more extensive route lookup, which would do more > than just double the CPU time looking up routes. Not necessarily. For routers at the very edge of the network, each interface probably has a small and fairly static set of route candidates through it. The router could automatically update a magic IP traffic filter that's updated whenever the set of routes through the interface changes. This, possibly coupled with some aggressive aggregation, is for most cases a Simple Matter Of Programming that wouldn't significantly impact router performance. Even at the core, the cost of updating filter lists due to route flap has to be much, much less than the cost of doubling (or worse) the number of route table lookups per packet forwarded. regards, -- Robert

1 0

Re: Blocking spoofing at the source (was: ICMP Attacks??)
by Robert Sanders 29 Aug '97

29 Aug '97

"Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> writes: > I think if Ascend, Livingston, and USR -- just those 3 -- put filters > on their dialup ports to prevent source address spoofing, the problem > would probably drop in half. Don't hold your breath if you're expecting the vendors to implement it. I hope they do, but I'm certainly not waiting for it. Features tend to appear in order of financial impact, and I can't imagine the large customers of Ascend, Livingston, and USR walking away from their current access platforms if their vendors don't implement automatic source address filters. I say that as a fairly large USR/3com customer, but two or three ports shy of IBM and Compuserve. I've just finished some RADIUS server patches which implement per-user anti-spoofing filter creation on USR Total Control NETservers (and probably USR/3com HiPer ARCs, but I haven't tested with ours yet). I hope to have them working for Ascend Maxen within the next couple of weeks. Livingston doesn't seem to have the RADIUS support for specifying dynamic per-user filters (not just filter-ids), though I haven't investigated their ChoiceNet product thoroughly enough to know for sure. It certainly seems that it would need dynamic filter creation. Unfortunately, our RADIUS server has mutated to such an extent that our changes won't apply to any of the source-available RADIUS servers. We don't even use attribute/value users files anymore. All our user information is stored in a more abstract intermediate format. I want to port the filter code to the most popular versions (Livingston 1.16, Merit, Ascend), but I don't have much free time. If anybody's interested in using these filters, or especially if you're interested in helping to port them to other servers, please let me know. I plan to deploy anti-spoofing filters throughout our access network before the end of September. Is anybody else running or planning to implement similar filters? regards, -- Robert

1 0

The Cidr Report
by Tony Bates 29 Aug '97

29 Aug '97

1 1

Denied packets process-switched - no longer?
by Jeffrey S. Curtis 29 Aug '97

29 Aug '97

Warning: possibly useful operational content follows. Read at your own risk. Regarding the possible denial-of-service implications of cisco routers process-switching packets which have been denied by an access-list (as was mentioned previously on this list), I received the following update in this morning's list-of-bugs-and-their-new-status via email: ----------------------------------------------------------------------------- BugID: CSCdj35407 Title: ACL: Denied packets always sent to process level Feature: ip Version: 11.2(0.0) 11.1(0.0) 11.0(0.0) 11.3(0.0) Integrated: 11.1(13.5)CA Severity: 2 State: M Release Notes: Currently all packets denied by an access list are sent to the process level to generate an ICMP administratively prohibited message. Some of these packets are dropped because Cisco routers limit ICMP generation to two packets per second. This behavior results in excessive CPU load. ----------------------------------------------------------------------------- This means that they have integrated some sort of fix into 11.1(13.5)CA, and the "M" state means that they intend to provide the same fix in other versions of their software. Jeff -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis(a)anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 630/252-1789 Argonne, IL 60439 | Fax: 630/252-9689

2 1

RE: perf #s for GRF vs 7500 Re: Anyone Deployed Ascend's GRF IP S witch?
by Chris A. Icide 29 Aug '97

29 Aug '97

Rob, Comparing your BAY routers to everyone elses is like comparing a top fuel dragster to someones 69 Chevelle street racer. You folks have some heavily modified software and hardware, from what I understand. However, we've got a couple of BAY BCN/BLN routers about, and the numbers that have been mentioned previously in this thread are fairly accurate. Chris ---------- From: Rob Skrobola[SMTP:rjs@ans.net] Sent: Wednesday, August 27, 1997 12:02 PM To: Tony Li Cc: Paul Peterson; nanog(a)merit.edu Subject: Re: perf #s for GRF vs 7500 Re: Anyone Deployed Ascend's GRF IP S witch? Folks, We have bcn/bln's out there with over 60 bgp peers on a 64Mb ARE. Works fine. Taking in about 63000 pps (170 Mbps) over 6 interfaces with a high of 20k pps when I looked a couple of minutes ago..Not untypical of the 30 bcn's and bln's on our network.. So the 4-6 Mb per peer thing is inaccurate. On the way high side. RobS BGP Peers --------- Local Remote Remote Peer Connection BGP Total Address/Port Address/Port AS Mode State Ver Routes --------------------- --------------------- ------ ------- ---------- --- ------ .. 64 peers configured. Memory Usage Statistics (Megabytes): ------------------------------------ Slot Total Used Free %Free ---- -------- -------- -------- ----- 6 61.67 M 32.82 M 28.84 M 46 % >Subject: Re: perf #s for GRF vs 7500 Re: Anyone Deployed Ascend's GRF IP S witch? >From: Tony Li <tli(a)juniper.net> >paulp(a)winterlan.com (Paul Peterson) writes: > >> Bay claims to hold the entire Internet routing table in just 4-6MB RAM >> per BGP peer (I assume this is after convergence). They say that the >> method in which they do this is proprietary. I am just wondering if it >> is possible..... > >That's certainly possible. However, it would be interesting to see how it >scales with the number of peers. You could quickly find yourself needing >>64MB if it's even just linear. > >Tony

4 4

Mobile Agents and Security Workshop
by Account of Maryland Center for Telecommunications Research 29 Aug '97

29 Aug '97

*************************************************************** Mobile Agents and Security Workshop October 27-28, 1997 *************************************************************** Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County The Maryland Center for Telecommunications Research (MCTR) at the University of Maryland Baltimore County (UMBC) will hold the Workshop on Mobile Agents and Security (MAAS '97) on October 27- 28, 1997 at the UMBC campus. The workshop will be held in the Ballroom of the University Center on the UMBC campus. The goal of the workshop is to provide a forum where researchers and developers, from academia and industry, can meet to exchange ideas and report on leading-edge developments in the use of mobile agents in implementing solutions to security pcublems in networks and systems and also to discuss security problems caused by mobile agent technology. The participation in the workshop is by invitation only and limited to active researchers and developers in the subject area of the workshop. If you have made contributions to mobile agents and security and would like to participate in the workshop, please contact the workshop organizer: Dr. Deepinder Sidhu, Tel: (410) 455-3028 or 3063, Fax: (410) 455-3969, Email: mctr(a)cs.umbc.edu. The following hotels are closest to UMBC campus. BWI Airport is approximately five miles from UMBC Campus. * Sheraton International Hotel - BWI Airport. Closest to airport and UMBC campus. Tel: (410) 859-3300 or (800) 638-5858 * Holiday Inn - BWI Airport. Close to airport and UMBC campus. Tel: (410) 859-8400 or (800) HOLIDAY * Omni Inner Harbor Hotel. Close to Downtown Baltimore/Inner Harbor. About 20 minutes drive to UMBC campus. Tel: (410) 752-1100 or (800) 843-6664 For more information on the workshop and directions to UMBC, check our home page on WWW (http://www.mctr.umbc.edu) --------------------------------------------------------------- MAAS '97 REGISTRATION FORM (October 27-28, 1997) Name: Affiliation: Address: Tel: Fax: Email: Dietary Restrictions: Vegetarian ------ Kosher -------- ---------------------------------------------------------------

1 0