RE: 69/8...this sucks -- Centralizing filtering..
On Tue, 11 Mar 2003, Simon Lyall wrote: > Could someone publish a name of a valid resource (or even pingable ip) in > 69/8 space? This would allow people to test their (and their upsteams) > filters quickly while we wait for the list to come out. 69.atlantic.net (69.28.64.8) is a loopback on our Gainesville, FL office router. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: 69/8...this sucks -- Centralizing filtering..
On Mon, 10 Mar 2003, Michael Whisenant wrote: > First I appreciate your message that you sent to us at NASA late Friday > regarding a new address block that you received from ARIN. In that message > you suggest that the issue was a BOGON route filter that had not been > updated. Then without allowing sufficient time to respond to your message > (you sent it to an administrative account and not the NOC) you decided to > flame NASA. My mention of NASA wasn't meant at all as a flame. It was just an example that not all the networks with outdated filters are remote nets in far away countries that my customers wouldn't care about. A few I've found are. I had to look up the country code to find that .al is Albania. I had actually planned to mention at some point that NASA was the first (only so far) network to respond to the few messages I sent out late last friday, and that their reported network has already been fixed. I can only assume that none of the previous 94 allocation holders of 69/8 space noticed or complained to the right people. > If you feel that you have any issue reaching a NASA resource then you can > send a message to [EMAIL PROTECTED] and/or the tech/org/noc POC on any > address space. NISN is NASA's ISP and as such announce via AS297 that > address space. As for sending the message to the wrong addresses, I can only suggest updating your ARIN info. I sent the message to all the POCs (except the abuse one) for the relevant NetRange. This is what I'll be doing when I send out the automated messages. The ones sent friday were done by hand. Can you elaborate on how a firewall config was the problem? If whatever was done there is commonly done, it may be worth revising my form message before I send out a large number of them. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 69/8...this sucks
On 10 Mar 2003, Jeff S Wheeler wrote: > I repeat my suggestion that a number of DNS root-servers or gtld-servers > be renumbered into 69/8 space. If the DNS "breaks" for these neglected > networks, I suspect they will quickly get enough clue to fix their ACLs. Moving a number of them won't do anything. Broken networks would just use the ones they can reach. Moving the root-servers isn't a good option anyway since lots of Bind setups are distributed with a . hints file containing A records for the root-servers, and these hints files are updated probably less frequently than bogon filters. Since the root-servers have been reduced to refering queries to the gtld-servers and nstld servers and perhaps others, these latter servers would be the ones to move that would cause no pain for networks that work, and immediate notification and motivation to fix filters for networks with outdated filters. I don't suppose there's even a slim chance of this happening? -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: 69/8...this sucks -- Centralizing filtering..
On Mon, 10 Mar 2003, E.B. Dreger wrote: > Now, how can we force that? Sufficient reward for doing so, or > pain for failure. Evidently "some people can't reach you" isn't > enough pain, and having full reachability isn't enough reward. I think the only way that's relatively guaranteed to be effective is to move a critical resource (like the gtld-servers) into new IP blocks when previously reserved blocks are assigned to RIR's. I still have a couple hundred thousand IPs to check (I'm going to step up the pace and see if I can get through the list today), but I already have a list of several hundred IPs in networks that ignore 69/8. The list includes such networks as NASA, the US DoD, and networks in China, Russia, and Poland. Those are just a few that I've done manual whois's for. I haven't decided yet whether I'll send automated messages to all the broken networks and give them time to respond and fix their filters, or just post them all to NANOG when the list is complete. Are people interested in seeing the full list (at least the ones I find) of networks that filter 69/8? Does Atlantic.Net get an ARIN discount for doing all this leg work? :) -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Question concerning authoritative bodies.
On Sun, 9 Mar 2003, E.B. Dreger wrote: > > In AOL's case, they couldn't even tell us why our mail was > > being rejected or our connections to their MX's blocked and I > > had to wait a week for their postmaster dept. to get to my > > ticket and return my call to fill me in on what was going on. > > E. Much better to put a semi-descriptive code in the 5.x.x > and give a contact phone number and/or off-net email box. There was a multiline message (when our connections weren't just refused or immediately closed). 550-The information presently available to AOL indicates that your server 550-is being used to transmit unsolicited bulk e-mail to AOL. Based on AOL's 550-Unsolicited Bulk E-mail policy at http://www.aol.com/info/bulkemail.html 550-AOL cannot accept further e-mail transactions from your server or your 550-domain. Please have your ISP/ASP contact AOL to resolve the issue at 550 703.265.4670. Trouble was, the people at 703.265.4670 can't help you. They just take your name, number, and some other basic info, and open a ticket that the postmaster group will "get to eventually". On the affected system, I ended up changing the source IP for talking to AOL's servers. > True. It cracks me up when someone complains about being on > Selwerd XBL. xbl.selwerd.cx might be useful for a few points in a spamassassin setup. I don't use it. [EMAIL PROTECTED] implied that some of the other DNSBLs include selwerd. I'm not aware of any, but I'm sure there are lots of DNSBLs I've never heard of and know nothing about. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Question concerning authoritative bodies.
On Sun, 9 Mar 2003, Jack Bates wrote: > networks back it. Blocking the scans at a TCP/IP level is easily detectable. > Provider received email from said server, IP was submitted for testing, no > connection can be established to said server. Place it in the "wouldn't > allow scan list". Politely ask AOL to use the "wouldn't allow scan list" for > all inbound smtp connections. Lots of people run outgoing mail servers that don't accept connections from the outside. A scarey number of people run "multihomed" mail servers where traffic comes in on one IP, leaves on another, and the output IP doesn't listen for SMTP connections. > People want the abuse of unsecured relays for smtp stopped. I'm afraid it is Some do. Some see absolutely nothing wrong with their running open relays. You're going to need a serious authority figure with some effective means of backing up their policy to change these minds. BTW...these topics have been discussed before. Before we all get warnings from the nanog list police, have a look at the thread I started back in 8-2001 http://www.cctec.com/maillists/nanog/historical/0108/msg00448.html -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Question concerning authoritative bodies.
On Sun, 9 Mar 2003, Jack Bates wrote: > > > made. Instead of contacting 3-5 DNSBLs, one must contact every ISP that > > > happened to do a scan during the outage period. Centralizing scanning > for > > > security issues is a good thing in every way. It is the responsible > thing to do. This, IMO, is where the real headache lies. If every provider (or just every large provider) has their own private DNSBL, and worse, doesn't do much to document how it works...i.e. how to check if IPs are in it, how to get IPs out of it, then it becomes a major PITA to deal with these providers when one of your servers gets into their list. I've personally dealt with this several times over the past couple years with Earthlink and more recently with AOL. In each case, there was no way (other than 5xx errors or even connections refused) to tell an IP was listed. In each case, there was no documented procedure for getting delisted. In AOL's case, they couldn't even tell us why our mail was being rejected or our connections to their MX's blocked and I had to wait a week for their postmaster dept. to get to my ticket and return my call to fill me in on what was going on. > networks are issuing their own relay and proxy checks. At this rate, in a > few years, we'll see more damage done to server resources by scanners than > we do from spam and those who would exploit such vulnerabilities. I doubt that's possible. If an average sized ISP mail server receives messages from, say, a few thousand unique IPs/day, and if that ISP wanted to test every one of those IPs (with some sane frequency limiting of no more than once per X days/weeks/months) then it doesn't take long at all to get through the list. Suppose every one of those servers decided to test you back. Now you're looking at a few thousand tests/day (really a fraction of that if they do any frequency limiting). I've got servers that each reject several hundred thousand (sometimes >1 million) messages/day using a single DNSBL. Also, I suspect consensus on a central authority and testing methods is highly unlikely. People can't agree on "what is spam?" or how to deal with providers who turn a blind eye to spammer customers (spews). How will a single central DNSBL bring all these people with opposing views together? Two obvious reasons for the existence of dozens of DNSBLs are: 1) not agreeing with the policies of existing ones...thus you start your own 2) not trusting existing ones (not being willing to give up control over what you block to some 3rd party), so you start your own I suspect AOL and Earthlink run their own DNSBLs primarily for the second reason. How would you convince them to trust and give up control to a central authority? Even if IANA were to create or bless some existing DNSBL and decree that all IP address holders will submit to testing or have their space revoked (yeah, that'll happen) there would still be those who weren't happy with the central DNSBL thus creating demand for additional ones. > network. These arguments would be diminished if an authoritative body > handled it in a proper manner. At what point do we as a community decide > that something needs to be done? Would it not be better to have a single > test suite run against a server once every six months than the constant > bombardment we see now? Parts of the community have already decided and have helped to create central quasi-authoratative DNSBLs. If nobody uses a DNSBL, who care's what's in it? If a sufficient number of systems use a DNSBL, that creates authority. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
69/8...this sucks
Atlantic.Net has just joined the 69/8 club of ARIN members with assignments in this IP block that's apparently in numerous outdated bogon filters. As I posted I'd do earlier if given space from this block, I've written some code to check reachability to a large number of remote IPs from 2 source IPs...one in one of our older ARIN blocks, one in the new 69 block. I'm feeding this code a very large list of known mail server IPs, and having it ping each IP...only it'll ignore /24's once reachability from both the old and new IPs has been established to an IP in that /24. It's only just getting started on the list, but I've already found dozens of networks that appear to be problems. I've hand confirmed a couple and sent off emails to the ARIN contacts. It looks like there are going to be so many networks to notify, I'll have to write some more code to automate these emails. What have others in this situation done? Are you actually assigning 69/8 IP's to unsuspecting customers and hoping they won't notice parts of the internet ignoring them? According to ARIN's whois server, there are 95 subdelegations for NET-69-0-0-0-0...we're the 95th. I don't know if ARIN has other "less tainted" IP space to give out, but something ought to be said/asked about this at the next meeting. I realize ARIN can't guarantee global routability of IP space, but should they continue to give out IP blocks they absolutely know are not fully routable on the internet today? -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: anti-spam vs network abuse
On 1 Mar 2003, Michael Lamoureux wrote: > andy> If so, why outlaw the act of probing? Why not outlaw "probing > andy> for the purposes of..."? > > What's the offset into the probe packets to the "intent of the this > probe" field? And would you trust it if there were one anyway? People speed, drive drunk, and run over pedestrians. Should we outlaw cars? Maybe just in California? :) > What's a legit probe? One where the owner gave you permission in > advance to run the scan? I can't think of another definition of that > phrase. When you walk into the secure part of an airport or some schools in rough neighborhoods, you're scanned for metallic objects. When you exchange traffic with certain networks, they may also want to check you out to see what risk may be associated with accepting your data in the future. If your system is an open relay/proxy, then there's elevated risk that at some point (if not already), the data coming from your system will be SPAM. Some networks will choose not to accept your data or to tag it in order to prevent their customers from having to accept unwanted data. > This is a completely naive statement. There are 0 networks that I'm > willing to believe have 0 vulnerabilities on them. There may be 0 > that you know about, but that doesn't mean there aren't more > vulnerabilities which aren't public knowledge lurking in sendmail or > bind or ssh or ssl or apache or any number of other services you have > running. So if nobody probes your network, it's more secure? -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Who uses RADB? [was BGP to doom us all]
On Sat, 1 Mar 2003, Mark Radabaugh wrote: > Who actually uses RADB to build filters other than Verio? While my > experience with other providers is limited Verio is the only one (of the > ones we have used) who used RADB entries for BGP peers. AFAIK, Level3 and C&W. I have to keep RADB entries (actually altdb, and c&w's own) up to date in order for each of them to accept our routes and our BGP customers' routes. > Overall it wasn't the best solution IMHO for a couple of reasons: > > - there was nothing to keep us from making bogus entries in the RADB > - filters were only updated once a day making changes slow OTOH, they don't have to pay someone to answer and respond to email sent to bgp-admin. They won't accept routes you accidentally leak to them. Is it secure? Not really. Is it cheap, reliable automation, I suspect so. > This is not meant as a complaint toward Verio - I'm simply trying to decide > why we should go to the added expense of entering our routes in a RADB. To > date I have seen no operational difference between using RADB and not using www.altdb.net. No expense other than the time you spend keeping your objects up to date. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: anti-spam vs network abuse
On Fri, 28 Feb 2003, Andy Dills wrote: > Actually, I think the debate starts with Paul telling Jon that Jon isn't > passively scanning connection hosts, he's actively trawling for open > proxies, that Paul has the logs to prove it, and that since Paul is in > California, Jon has broken the law. He was using considerable artistic license with the numbers when he said every IP on every net he owns had been checked by NJABL. The reality is more like 0.06% of the IPs on 3 networks he owns or manages were checked over the span of about 7 months. At that rate (if my math is correct), it would take almost 1000 years to scan all the IPs on those networks. Hopefully, someone will have solved this spam problem by then. > You don't have to. This is why I never understood why people care so much > about probing. If you do a good job with your network, probing will have > zero affect on you. All the person probing can do (regardless of their > intent) is say "Gee, I guess there aren't any vulnerabilities with this > network." When I hooked up my first server on the internet back in 1993, I was kind of shocked that some far away stranger was trying to log into my POP3 server. Unwanted connections have been a fact of life on the internet probably since its beginning. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: anti-spam vs network abuse
On Fri, 28 Feb 2003, Roy wrote: > I haven not checked NJABL but some of the other other open relay testers use > scenarios that are illegal (actually criminal) in California. If you mean the use of "incorrect" from addresses, I believe that law only applies if the message(s) sent with someone else's address results in damage. I'm not here to debate the issue, and I certainly didn't mean to start such a long thread here (the same post went to spam-l, where it was nearly ignored), but I don't think 1 test message sent every 4 weeks (or less frequently) will cause damage[1]. [1] yes...I am aware of one case where were ORBZ got in some hot water over an SMTP envelope that effectively broke an outdated version of Lotus Domino. NJABL takes precautions to not repeat that mishap. Just to be safe, mayby I'll avoid visiting the People's Republic of Kalifornia. That shouldn't be so hard. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
anti-spam vs network abuse
We (Atlantic.Net) have gotten a flurry of abuse complaints from people who's systems have been scanned by 209.208.0.15 (rt.njabl.org...a DNSBL hosted on our network). I'm hoping the new PTR record will head off many complaints now. For the past 15 months, NJABL has reactively tested systems that have connected to participating SMTP servers to see if those systems are open relays. Just over a week ago, NJABL added open proxy testing to its relay testing software. The proxy testing checks for a variety of common proxy software/protocols on about 20 different ports simultaneously. This is apparently setting off some IDS/firewall alarms. We do not consider what NJABL does abuse, and we reply to all the complaints explaining that the complainant should go have a look at http://njabl.org/ and hopefully they'll understand why their system was scanned. This sort of activity is becoming more common / mainstream, so people ought to just get used to it. Road Runner is doing the same thing (according to http://sec.rr.com/probing.htm) which is pretty ironic given how their security department has gotten along with (or not) various DNSBLs in the past. BTW...in the week that NJABL has been testing for open proxies, more than 18000 have been detected, pretty much all of which are actively being abused by spammers, else mail would not have come through them. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: RIPE Down or DOSed ?
On Thu, 27 Feb 2003, Kai Schlichting wrote: > Secrecy over a public resource = no oversight = facilitator of abuse. > > Why do I get the distinct feeling that this "move" by Level3 is > aimed not at creating greater customer privacy (it never served > POC email addresses), or protecting themselves from getting their > customer base poached by other providers, but at preventing > people from identifying spamming Level3 customers (of which they > seem to have 100's) by organization name and being able to > correlate activity from different netblocks of theirs. Though I agree, Level3 seems to host a good number of spammers, they're by no means the only guilty party. Pulled at random from recent spams I've submitted to NJABL are 69.6.4.104, 69.6.4.114, and 69.6.4.156. whois @arin.net yields the following: ... NetRange: 69.6.0.0 - 69.6.63.255 CIDR: 69.6.0.0/18 NetName:WHOLE-2 NetHandle: NET-69-6-0-0-1 Parent: NET-69-0-0-0-0 NetType:Direct Allocation NameServer: NS1.WHOLESALEBANDWIDTH.COM NameServer: NS2.WHOLESALEBANDWIDTH.COM ... Where are the swips? The rest of that record makes no mention of an rwhois server. Doing a bunch of whois requests for IPs in that block, I found only one swip (for a /21). I realize the ARIN regs don't seem to require that reassignment info be made available to the public (just to ARIN), but using your innocent customers (if there are any) as a shield to hide your spammer customers is just wrong. Should I block 69.6.4.0/24 from sending email into my systems? 69.6.0.0/18? http://www.njabl.org/cgi-bin/lookup.cgi?query=69.6.4.104 http://www.njabl.org/cgi-bin/lookup.cgi?query=69.6.4.114 http://www.njabl.org/cgi-bin/lookup.cgi?query=69.6.4.156 -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 69.0.0.0/8 - Please update your filters
On Tue, 25 Feb 2003, Haesu wrote: > And how quickly would those ASN's respond to or even comprehend the > bogon-filter update notices? If those ASN's are competent and > quick-responsive ones, we should not even be having these prroblems to > begin with. If the alternative is getting space, giving it to customers, and explaining why they can't reach X, Y, and Z on their connection to us, but they can on other internet connections, we're going to at least have to try. I like the idea of moving the gtld servers into such space. That way, the networks that are at fault will break, and they'll be well motivated to fix their filters. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: 69.0.0.0/8 - Please update your filters
On Tue, 25 Feb 2003, Stephen Sprunk wrote: > Thus spake "E.B. Dreger" <[EMAIL PROTECTED]> > > I _still_ like the idea of putting DNS roots in new IP blocks > > during sunrise and having the final octet be .0 and/or .255. It > > would be nice to catch dated bogon filters, lame attempts at > > smurf stopping, _and_ stale root.cache in one blow. > > From an academic standpoint, that would be a very interesting experiment. > However, most of us are paid to keep our networks or services running, not > to intentionally break them. The trouble is, some people are neglecting their jobs and making things rough for others (the people getting new allocations). Somebody with one of these new cursed allocations ought to setup a system with two IPs (one from the new block, one from an older established block) and do reachability tests to various parts of the net, and then automate sending a notice of bogus filters to those ASNs reachable from the old IP, but not from the new one. If I end up with some of this space, I'll be doing this. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: IP Management tool for service providers
On Thu, 20 Feb 2003, John Todd wrote: > Here's one. I haven't used it in production, but the demo that I was > given was pretty slick. Works on pretty much any POSIX platform... > Alas, it is commercial software. > > Voyager IP http://www.vger.com/products.shtml#v_ip Where did you see a demo? Any idea what it costs? I just sent them an email. Not much info on their web site, and their contact submission form is broken. > This was referenced on the list back in Jan of 2002: > http://www.freeipdb.org/ http://www.globalcrossing.com A coworker took a look at this recently. He had some difficulty getting it installed properly and it lacks some features we'd require relating to the tracking of IP allocations in the ways ARIN demands. > This was referenced on the list in November of 2001: > http://www.brownkid.net/NorthStar/ I just installed this. Installation went easily, but it doesn't seem to actually work :) After adding a big block of space and creating one allocation in it, the links to create additional subnets bring up the wrong page. It seems very browser dependent. i.e. with various versions of Netscape and Mozilla on Linux, some of the pages don't work (but don't produce any error messages). The same pages did work in IE on Windows, at least until the whole thing quit working. It also lacks necessary features and doesn't seem to be flexible enough to incorporate the features I want without digging into the code. The basics of what I think an IP allocation tracking system needs (at least for any ARIN member) are: 1) Ability to track allocations from multiple IP blocks 2) Ability to track type of assignment (i.e. assigned vs reserved) 3) Ability to track service category as required on ARIN additional request form. i.e. Dial-up|Cable|Web Hosting|Leased Line| xDSL|Co-location|Wireless|Other- 4) Storage of customer name and contact info for each allocation 5) Storage of justification info for each assignment 6) Ability to present unallocated space in such a way that allocations can be done efficiently. i.e. if a /28 needs to be allocated, make it easy to find unallocated existing /28's, rather than do unnecessary subnetting to create a new /28. 7) Auditing. When it's additional request time, you need to be able to audit your assignments and add up how much space is reserved, how much is assigned, how much is being used for each of the various ARIN defined categories, look up justifications, etc. 8) Automated swip/unswip or hooks to automate rwhois maintenance would be nice, but not absolutely required. The systems I've seen so far lack multiple features from the above list. Is everyone just using flat files, spreadsheets, or home grown solutions? -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: M$SQL cleanup incentives
On Sat, 22 Feb 2003, Stephen Sprunk wrote: > As one hoster put it to me, DoS and worm traffic is billable so it's not in > the hoster's interests to protect customers -- quite the opposite in fact. Whether or not the traffic is billable is irrelevant if your network is effectively down. One infected host connected to a 2900XL effectively kills the switch. I was fortunate enough to be on vacation and not even have net access when the initial slammer wave hit. But when I was back and on-call, we had a single customer get (re-?)infected, killing the switch they were on and noticably slowing down the network for the whole POP. > What will you do when a similar worm appears on 53/udp or some other > heavily-used port? We lucked out with Sapphire because MS/SQL is generally Be screwed unless we've completed planned upgrades. But in this case, I can filter until we've upgraded our network to hardware that's better able to deal with such traffic. Just because filtering might not always work doesn't mean it shouldn't be done when it does work. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: M$SQL cleanup incentives
On Sat, 22 Feb 2003, Doug Clements wrote: > The issue I had with your argument is "forever". You should realize as well > as anyone that the course of software development and implementation will > mitigate the threats of the slammer worm until it's nothing more than a bad > memory. Unlikely in this case. A reasonably fast system infected with slammer is capable of generating enough traffic to make the Cisco 2900XL switch its plugged into incapable of passing normal traffic. All it takes is one infected customer's system to really foul up the network it's attached to. The only plus side is, this is perfect justification to management for replacing any switches customers connect to with newer ones that (at least claim to) do per-port rate limiting. If your network is able to contain slammer infected boxes without melting down, who cares if you have a few infected customers? You don't need to filter, and they'll all be encouraged to fix their systems sooner. I setup inbound 1434/udp filters the 3rd time we had a customer (different ones each time) get (re-?)infected weeks after the initial outbreak. Sure, some DNS replies and assorted other packets will get dropped, but AFAIK, nobody has complained or even noticed...and we've had no more re-infections since the filters were put in place. I don't believe we'll have to filter 1434/udp forever, but I plan to leave the filters in place until we no longer need them or until they hurt more than they help. -- Jon Lewis [EMAIL PROTECTED]| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: scripts to map IP to AS?
On Thu, 20 Feb 2003, William Allen Simpson wrote: > Anybody have a pointer to scripts to map IP to AS? I suspect the easiest thing to do would be to write some code to query a looking glass, perhaps even install your own for this > There are still 10K-20K hosts spewing M$SQL slammer/sapphire packets, > and I'd like to start blocking routing to those irresponsible AS's > that haven't blocked their miscreant customers. but automatically blocking AS's that send some 1434/udp traffic your way sounds like a really bad idea and would setup an easy way to DoS your network by "tricking" you into blocking certain AS's. Why not just block 1434/udp at your ingress points and be happy? -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: DC power versus AC power
On Fri, 27 Dec 2002, Scott Granados wrote: > It is likely that in many settings during power failures transition from ac > street power to ac generator power will have some lag and during that time > your hardware could loose power. This of course depends on ups systems in > use and many factors. Dc usually however is clean in its transition and > goes with out saying is battery backed up. I'll add to that, that since DC removes the need for your own UPS's, by going with DC, you save rack space, deploy less gear (UPS's are HEAVY), and don't have to worry about which POPs have how many UPS's with dead batteries at any given time. OTOH, since with DC you're unlikely to have any backup power of your own, it is important to wire up both an A side and B side. Some places (like certain telcos) like to briefly turn off parts of their DC power grids somewhat regularly. This makes gear with only one set of DC inputs rather annoying. Does anyone actually wire up both the A side and B side to a single DC power supply and use diodes to keep the two supply grids separate? DC also avoids bulky AC power cords...and not only are the wires less bulky, but you'll likely cut them to the actual length needed. Since DC wiring is usually screwed down, they don't get bumped or accidentally pulled out of the outlets as often. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Operational Issues with 69.0.0.0/8...
On Mon, 9 Dec 2002, Todd A. Blank wrote: > I hereby challenge one of you to trade CIDRs with us. You take this > 69.1.192.0/19 ARIN assigned us and you go spend your valuable time, > resources, and money working out what seems to be "nobody's problem". Was this an initial allocation into which you're renumbering out of provider space, or a trade-in (you gave some block back to ARIN and got this one)? Based on the newness of your ASN and sho ip bg regex _26483, I'm guessing it's your first allocation. Assuming you did this because you were about out of the space allocated to you by your provider(s), have you looked into getting some more space from your providers to keep things running while the issues with 69.0.0.0/8 filters are worked out? Even if they've already given you as much space as their policies allow, I suspect you could talk them into bending the rules in a case like this. Creating more networks to renumber sucks, but it beats losing customers, and you have plenty of time...probably even more than the ARIN published guidelines for renumbering due to the problems you've encountered...and what can ARIN do if you go beyond their suggested deadline anyway? I don't have any spare CIDRs to trade you. In fact, I'll be doing the ARIN dance again soon to get more space since we're running out. I'm really not looking forward to being in the same boat as you, but at least I know now to expect trouble, especially if we get a chunk of the same /8 you did. In your first message, you posted a couple of web sites that were not reachable from your IP space. It'd be more useful (to people in your shoes) and more embarrassing (to the offending networks) if you could post the names of the networks/backbones you've identified thus far that are still filtering 69.0.0.0/8. Maybe someone reading this list will know someone who knows someone at those networks and be able to get something done. If nothing else, it gives the next guy who gets 69.0.0.0/8 space a starting point of networks to check connectivity to and networks to contact if things don't work for them. Then those networks will have multiple people pestering them to fix their filters even if not everyone affected has customers that actually care about reaching those nets. > Also, if you would like to come over and answer the support calls and > explain to our customers why the competitor's networks can reach these > sites, but ours can't. Hey - after all, it's just CIDR - it's all the > same, right? Have you given customers in the affected space the option of renumbering back into your previous IP space? > What all of you don't know, is that for the first month we had this > CIDR, we could not register hosts on it at NetSol/Verisign, because > their core registry did not recognize it. We have been getting F***ed That should have set off some alarm bells and prompted a post to nanog a month ago. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Operational Issues with 69.0.0.0/8...
On Fri, 6 Dec 2002, Ralph Doncaster wrote: > ARIN clients should have the ability to exchange defective "goods". It > seems ARIN won't do this. And posting to NANOG or similar lists doesn't > seem to fix the problem. Sooner or later someone's going to decide to let > the lawyers deal with it. I don't think ARIN's resources should be wasted > in the courts. ARIN can't change (or even detect) who's filtering what. They likely have no way of knowing in advance if any IP block is filtered anywhere. How many places need to block your IP before you declare the IP bad? Should ARIN announce and test connectivity with some standard suite before giving each allocation? Should the end-user be given some trial period during which they can do this? What happens when ARIN runs out of IPs that don't appear to be filtered by any recognized network? This is an unfortunate pitfall that goes along with portable IP space and BGP. When I got the company's first ARIN block at a previous employer (back in the late 90s), we ran into issues with several large/well known networks ignoring our BGP route. Some were fixed just by doing the RADB thing. Some had to be emailed or phone called before they fixed their filters. This isn't a new problem, and there's no magic solution ARIN can execute...at least not that anyone's come up with so far. ...wondering when we'll hear from Dalph on the matter. :) -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Odd DDoS, anyone else seen this?
On Mon, 25 Nov 2002, Christopher L. Morrow wrote: > On Mon, 25 Nov 2002 [EMAIL PROTECTED] wrote: > > > > Can anyone think of a reason why this sort of traffic should be routed at > > all? Does anyone actually drop hosts on to addresses ending in x.x.x.0? > > > > I've seen cable modem users have .0 ips. DSL ports too. I was spammed today from a Verizon DSL IP of 4.46.3.0. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: sprint passes uu?
On Tue, 15 Oct 2002, Brian wrote: > > The interesting part of that to me is that the total number of prefixes in > a full feed is in the low 100,000 range, so this still represents a very > large percentage of the entire prefix pie. > > > > x.x.x.x 4 1239 2396636 438162 6144276100 9w3d47637 > > x.x.x.x 4 701 3768775 499186 6144276100 1w5d45410 It's hard to know how large a percentage though without knowing how many Sprint customers are also UU customers. i.e. The combination of Sprint and UU customer routes could still be just 47637 prefixes, though I'm sure it's somewhere between that and 47637+45410. It's certainly not 47637+45410, which would falsely suggest that together Sprint and UU have roughly 80% of the internet as customers. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: iBGP next hop and multi-access media
On Mon, 7 Oct 2002, Ralph Doncaster wrote: > > > > As others are saying... it isn't "local". It's not "local" > > > > unless in the same subnet. Physical topology often correlates > > > > with higher layers, but it's not strictly 1:1. > > > > > > Manually configuring a static route in router A would achieve the result: > > > ip route 172.16.16.0 255.255.255.0 fa0/0 > > > > Why are we doing basic IP routing 101 on NANOG? > > OK, since it's so basic why don't you explain how to have router A > dynamically learn from router B that there is a new subnet on the local > ethernet? You don't. Even if you did somehow manage that on the routers, how will the hosts get packets back to a router for which they have no route? With no route to get packets back to the router, they're going to use their default route. Or you could write your own IP stack. I have a friend who did this for a networked environmental probe. Rather than utilizing IP routing, this device's primitive IP stack simply sends replies to the MAC address from which they came. I suspect the IP stack on Cisco switches may do something similar. I don't think you're going to find this functionality in many 'normal' IP stacks. > > Don't route IP blocks to the ethernet. That's using ARP as your routing > > protocol and it's horribly fragile. I've seen one ISP do that (they were > > very technically challenged) and it's a setup that broke way too easily. > > So then what do you call a connected route (for an ethernet interface on a > router)? If you use ethernet, at the edges of your network you HAVE to > route IP blocks to the ethernet. I don't have to. Go ahead and do it your way. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: iBGP next hop and multi-access media
On Sun, 6 Oct 2002, Ralph Doncaster wrote: > > As others are saying... it isn't "local". It's not "local" > > unless in the same subnet. Physical topology often correlates > > with higher layers, but it's not strictly 1:1. > > Manually configuring a static route in router A would achieve the result: > ip route 172.16.16.0 255.255.255.0 fa0/0 Why are we doing basic IP routing 101 on NANOG? Don't route IP blocks to the ethernet. That's using ARP as your routing protocol and it's horribly fragile. I've seen one ISP do that (they were very technically challenged) and it's a setup that broke way too easily. Paging Dalph Roncaster. Clean-up in aisle one. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: selective prepends...one more time
On Mon, 30 Sep 2002, Leo Bicknell wrote: > In a message written on Tue, Oct 01, 2002 at 12:16:07AM +0200, Iljitsch van Beijnum >wrote: > > I think most customers don't know how this works. Maybe someone should > > write a book that explains this kind of stuff... > > I'm not so sure I'd come to that conclusion. I think when most > customers see a problem on their transit providers network they Some NOCs, even ones that support this on their network, don't understand it...or at least have staff that don't even come close to grasping it. It wouldn't surprise me at all if it's beyond a great many customers. > Most people I see using this feature fall into two catagories. > The first type doesn't believe the provider can fix the problem > but is forced to use them (due to price, management, whatever) and > uses this to avoid their NOC because it doesn't work. The second > type of person believes they can actually do a better job of routing > than their upstream. This may even be true in some cases (where > the customer has several transit providers all supporting this > 'feature'), however I suspect in many cases the customer is actually > making their own life worse. Consider a network with several transit providers. Each transit pipe is incapable of handling all that network's traffic. The pipes may even be of wildly different sizes. Letting BGP decide where traffic goes (or comes from) with no tuning just won't work. You'd end up with some pipes overutilized and others underutilized. In this case, selective prepends make it possible to shift traffic around or decide "we're going to try forcing all ASxyz traffic to come to us over pipe A." There's also the occasional case of medium to long term overloaded peering between large providers in which case you might want to do all you can to force traffic to/from ASxzy to not come/go via pipe A. > increased. Even if we assume all the people using it really need > it, is it worth risking the performance of 500 or 1000 customers > for the 5-10 who actually use the features? I wonder if anyone from Sprint or C&W is willing/able to say what percentage of multihomed customers utilize these communities? With enough full views from enough route-servers, it might even be possible to analyze the data and see how many use this. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
selective prepends...one more time
>From last week's thread on Cogent service and selective prepends, I've compiled a list of transit providers that support BGP communities for selective prepends when propagating routes to peers. sprint c&w gblx.net level3 Williams Communications Group internap.com Is anyone aware of others, preferably of similar size to Sprint and C&W (and in the US) that support this? I need to choose an additional provider real soon and already have Sprint and C&W. We'll be connecting ideally in Orlando, FL, but can take connectivity in most of the bigger cities in FL. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _____ http://www.lewis.org/~jlewis/pgp for PGP public key_
RE: Cogent service
On Fri, 20 Sep 2002, Dale Levesque wrote: > I must agree with everyone else's synopsis. There bandwidth is cheap, > and connection is reliable. They however do have some congestion issues > and are not very flexible when it comes to special needs. What are these 'special needs' people keep mentioning? What special needs might you have of your transit providers? Speaking of special...having played around a little with the BGP communities supported by C&W and Sprint, I'm wondering which other big transit providers (it seems almost a waste to say Tier 1 anymore) support community strings that will let you (the customer) cause them to selectively prepend route announcements to their peers. This seems to be a really handy tool for balancing (or at least trying to balance) traffic across multiple transit providers without having to resort to the sort of all or nothing results you'd get by prepending your announcements to the transit provider, or worse, deaggregating your IP space for traffic engineering. AFAIK, Genuity does not have this. UUNet has a very rudimentary version which allows you to cause them to do prepending to all or no non-customer peers. Sprint and C&W do it very differently but allow you to select which peers to prepend to (though you'll likely have to work with several Sprint engineers or get lucky to get it working). If there are others that support the sort of flexibility of Sprint and C&W, and have decent T3 level pricing, I'd like to hear about/from them. -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: e-mail blacklists (was Re: SPEWS?)
On Thu, 20 Jun 2002 [EMAIL PROTECTED] wrote: > On Thu, 20 Jun 2002, J.D. Falk wrote: > > > But spamcop's in specific is still based on spamcop user > > complaints, and most of the spamcop user complaints I've seen > > have been grossly mistargetted. > > How? I find spamcop to be very reliable, and the basis of many actions. Spamcop is a perfect example of garbage in / garbage out. I've had a number of servers in spamcop's blacklist for the following reasons: 1) Local user misinterprets headers and reports one of our own MX's thinking it generated a spam he/she received. We get blacklisted. 2) Remote user gets the same message a few times from one of our users (some tax related documents) and for reasons unknown to us, reports it as spam, and we're blacklisted. 3) Local user runs a mailing list on one of our servers and leaves posting open (yeah...that was a bad idea, but lots of lists still do it). List gets spammed. A list member reports our server, causing it to be blacklisted. This one is actually listed right now, and we've gotten a few "why can't I send email to ...?" questions from other customers on the same server. The idea of a spam blacklist with an army of contributors is appealing. In theory, it could blacklist large numbers of spam sources, perhaps before they get a chance to hit your servers...but the reality is an army of idiots turning a good idea into an unusable mess. Some sort of hybrid of spamcop with dsbl, where those who screw up have their contributing rights revoked would be far more interesting. There also needs to be some method for intervening when someone screws up rather than having to just wait out expiration of a listing that should never have happened. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
mail-abuse.org down?
Yesterday morning, I noticed mail-abuse.org appeared to be down (unreachable). I checked again, and it's still unreachable. In fact, I can't even reach its name server. I did some more looking last night, and it seems it's not down, it's just unreachable from my network. Even stranger, it's only unreachable from Atlantic.Net's primary ARIN block of 209.208.0.0/17. Traceroutes die at so-1-1-0.mpr1.sql1.us.mfnx.net (209.249.203.58). Router interfaces (using provider IPs) and a smaller IP block from an ISP we acquired are able to reach mail-abuse.org, as are other networks I have access to. We don't appear to be listed in the MAPS RBL+. I've tried clearing BGP sessions, forcing packets out through alternate paths, with no affect. Is this some weird routing glitch somewhere between me and MAPS or has someone at MAPS or vix.com decided they don't like me? Also, though it seems to be on a totally different network, I've just noticed I have the same problem reaching f.root-servers.net only from 209.208.0.0/17. Here traceroutes die at 189.ATM11-0-0.BR1.PAO1.ALTER.NET (146.188.148.105). I certainly hope this isn't yet another case of someone confusing Atlantic.Net/Internet Connect Company, Inc. with ATLANTIC INTERNET (NETBLK-Q0417-65-124-104-0) 621 NW 53RD ST. SUIT E135 BOCA RATON, FL 33487 US Netname: Q0417-65-124-104-0 Netblock: 65.124.104.0 - 65.124.111.255 Atlantic Internet is full of commercial spammers and has just recently resulted in several providers blacklisting our primary ARIN block thinking we were the same company. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
AOL and Sprint
Anyone else unable to reach AOL this morning via Sprint's network? I can get there through C&W or UUNet, but not via Sprint. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Controlling Spam to the NOC
On Thu, 23 May 2002 [EMAIL PROTECTED] wrote: > > You hit it dead on: use all the tools at your disposal, but preemptively > "whitelist" your customers. Unfortunately, the whitelisting isn't always as > easy as it sounds. If they are within your IP space, you're good to go, but > if they have the rare portable block, or they are multihomed, etc., you need > to be more careful. > > > In Short: Whitelist like crazy, and then blacklist like mad! We do both...but I wouldn't say whitelist like crazy. More like whitelist as needed, and find a blacklist or one of the message body parsing utils you like...or both. For the rare emergency when a customer (or non-customer) needs to talk to our NOC and can't get email through, we have these neat things called telephones. They work pretty well. In fact, I think mine often works too well. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: list problems?
On Wed, 22 May 2002, Andy Dills wrote: > > >From the number of personal replies I got about these topics, it seems > > like many people are interested in sharing information about how to do > > routing on a budget, or how to avoid getting shot in the foot with your > > Cisco box. > > Routing on a budget? Dude, you can buy a 7200 for $2 grand. Why bother > with a linux box? Heh, at least use FreeBSD :) Before the dot com implosion, they weren't nearly that inexpensive. The average corporate user will also need smartnet (what's that on a 7200, a K or a few per year?) for support, warranty, and software updates. Some people just don't appreciate being nickled and dimed by cisco and forced to either buy much more router than they need, or risk ending up with another cisco boat anchor router when the platform they chose can no longer do the job in the limited memory config supported. I have a consulting customer who, against my strong recommendation, bought a non-cisco router to multihome with. It's PC based, runs Linux, and with the exception of the gated BGP issue that bit everyone running gated a few months ago, has worked just fine. It's not as easy to work with in most cases, but there are some definite advantages, and some things that Linux actually makes easier. They'd initially bought a 2621 when multihoming was just a thought, and by the time it was a reality, 64mb on a 2621 couldn't handle full routes. The C&W/PSI depeering (which did affect this customer, as they were single homed to C&W at the time and did regular business with networks single homed to PSI) was proof that without full routes, you're not really multihomed. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: RADB & RRs
On Thu, 16 May 2002, Ralph Doncaster wrote: > > I've been registering my routes in ARIN's RR, only to find that nobody > uses it. ;-( > Do any of the RRs mirrored by the RADB offer free maintainer-IDs? altdb.net...everything's free there. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: IP renumbering timeframe
On Mon, 6 May 2002, Stephen J. Wilcox wrote: > I think they're on dangerous ground, whether or not their contract says > the IPs should be returned if they not only stop routing them but then > start contacting third parties that they have no relationship with and ask > them to stop routing them with the end result being that your business > cannot function then I'd say this looks more malicious than pure business > and I'd suggest to them a courtroom might view it that way too. This whole thing sounds fishy. He never passed any traffic to cogent, but he was using their IPs. Why wasn't he using Peer1's IPs? Cogent tried to get them shut down on a sunday? Is there a serious BOFH in Cogent's network monitoring group? I doubt the billing department would be open sunday afternoon to order the disconnect, much less know to suggest contacting Peer1 to ask them to stop routing the space. It sounds like there's an awful lot missing from the story. This is why using provider IP space sucks...but you have to plan accordingly. If you're in dispute and plan to terminate service, start renumbering. I've been there and done that. I've also been on the other end and let a customer have several months to renumber, but that was a special case and they left on relatively good terms. A customer who left without paying their bill would likely not be treated so well. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: anybody else been spammed by "no-ip.com" yet?
On Fri, 3 May 2002 [EMAIL PROTECTED] wrote: > Do you have data on approximate amount of this extra mail bandwidth due to > spam per user? Actually lets be more exact, can some of you with 10,000 > real user mail accounts reply how much traffic your mail server is using > and if you have spam filter, how much (in percentage) of mail were filters. > And how big were the filterd spam in comparison to all other regular mails? > And if possible how much in amount of disk space was it in comparison to > all other emails? Since sendmail applies our dnsbl rules before accepting the message, I can't say how much bandwidth the blocked spam would have used. On a MX that handles mail for several tens of thousands of actual user accounts, it's not unusual for us to deliver ~400k messages and reject anywhere from 200k-500k messages. A few weeks ago we had a several day period during which we rejected > 1,000,000 messages/day. The rejected numbers can be somewhat inflated though by the 'alphabet spammers'. I'm not sure what else to call them...but these are the people who try to send mail to every conceivable address @yourdomain. If you run a large mail server, you've probably seen them hit you. When they dump their random address spam on an open relay, that relay gets blacklisted pretty quickly, resulting in large numbers of dnsbl rejected messages that would have eventually bounced as 'no such user' bounces, and likely double bounced. Worse, IMO, than the bandwidth issue (mail from/rcpt to/571 doesn't use that much bandwidth), is the mail server load issue. A couple of open relays pounding on our mail servers trying to deliver a truckload of spam someone dumped on them will drive up the load in no time. I'm seriously considering adapting some existing code to watch syslog data and use kernel packet filtering to cut off connectivity for say 24h from IP's after N dnsbl caused rejections in Y minutes. This should reduce load considerably. While typing this I was just watching the log on one mail server and noticed several rejections/sec from mail.ignacio.k12.co.us. That system is an open relay (listed in several blacklists) and has been trying to deliver mail to atlantic.net since last wednesday. We've rejected from them the following numbers of messages: Wed: 82102 Thur: 286861 Fri: 215779 Sat (so far): 62128 -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: UUNET instability?
On Thu, 25 Apr 2002, Chris Pace wrote: > > It was really bad this morning. I had problems with Bellsouth, AT&T and > Qwest's connection to UUNET. > Does anyone know if there is a web site or newsgroup I can get alerts and > updates about what is going on with UUNET ? There's www.noc.uu.net, but unless the problem is long lasting or severe enough that it can't be swept under the rug, they don't seem to admit to anything on that page. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net | _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: UUNET instability?
On Thu, 25 Apr 2002, Streiner, Justin wrote: > Anyone else seeing routing instability through UUNET or have any more > details? I saw a significant drop in my inbound and outbound traffic to > them around 10:00AM EDT. UUNET has a prompt on their phone menus about I saw the same thing on our UUNET connection. Backbone: Normalhm -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: UUNET service
er.net > | - || 164 |x | UUNET > Technologies, Inc. | > | 43 | 50| 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET > | Baltimore, MD, USA | -05:00 | 173 |x | UUNET > Technologies, Inc. | > | 44 | 50| 65.195.230.218 | core62007-gw.customer.alter.net > | - || 158 | -x | UUNET > Technologies, Inc. | > | 45 | 50| 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET > | Baltimore, MD, USA | -05:00 | 168 |x | UUNET > Technologies, Inc. | > | 46 | 50| 65.195.230.218 | core62007-gw.customer.alter.net > | - || 166 |x | UUNET > Technologies, Inc. | > | 47 | 50| 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET > | Baltimore, MD, USA | -05:00 | 159 |x | UUNET > Technologies, Inc. | > | 48 | 60| 65.195.230.218 | core62007-gw.customer.alter.net > | - || 140 | x- | UUNET > Technologies, Inc. | > | 49 | 60| 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET > | Baltimore, MD, USA | -05:00 | 145 | x- | UUNET > Technologies, Inc. | > | 50 | 60| 65.195.230.218 | core62007-gw.customer.alter.net > | - || 170 | -x | UUNET > Technologies, Inc. | > | 51 | 70| 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET > | Baltimore, MD, USA | -05:00 | 137 | x- | UUNET > Technologies, Inc. | > | 52 | 60| 65.195.230.218 | core62007-gw.customer.alter.net > | - || 133 | x- | UUNET > Technologies, Inc. | > | 53 | 60| 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET > | Baltimore, MD, USA | -05:00 | 142 | x- | UUNET > Technologies, Inc. | > | 54 | 60| 65.195.230.218 | core62007-gw.customer.alter.net > | - || 147 | x- | UUNET > Technologies, Inc. | > | 55 | 60| 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET > | Baltimore, MD, USA | -05:00 | 143 | x- | UUNET > Technologies, Inc. | > | 56 | 60| 65.195.230.218 | core62007-gw.customer.alter.net > | - || 156 | -x | UUNET > Technologies, Inc. | > | 57 | 60| 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET > | Baltimore, MD, USA | -05:00 | 167 | -x | UUNET > Technologies, Inc. | > | 58 | 60| 65.195.230.218 | core62007-gw.customer.alter.net > | - || 167 | -x | UUNET > Technologies, Inc. | > | 59 | 60| 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET > | Baltimore, MD, USA | -05:00 | 170 | -x | UUNET > Technologies, Inc. | > | 60 | 60| 65.195.230.218 | core62007-gw.customer.alter.net > | - || 174 | -x | UUNET > Technologies, Inc. | > | 61 | 70| 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET > | Baltimore, MD, USA | -05:00 | 173 | -x | UUNET > Technologies, Inc. | > | 62 | 60| 65.195.230.218 | core62007-gw.customer.alter.net > | - || 178 | -x | UUNET > Technologies, Inc. | > | 63 | 60| 65.195.230.217 | 500.Serial2-11.GW4.BWI1.ALTER.NET > | Baltimore, MD, USA | -05:00 | 186 | -x | UUNET > Technologies, Inc. | > | 64 | 60| 65.195.230.218 | core62007-gw.customer.alter.net > | - || 183 |x- | UUNET > Technologies, Inc. | > | ... | | | > | || || > | > | ? | | 162.33.138.132 | online.mmsi-usa.com > | ?Woodbridge, NJ 07095 || || RAM > Communications Consultants, Inc. | > > > - > Roundtrip time to 65.195.230.218, average = 183ms, min = 152ms, max = > 210ms -- 12-Apr-02 3:04:18 PM > > Bradley Corner > Northeast Florida Multiple Listing Service, Inc. > 7801 Deecreek Club Rd Ste 1 > Jacksonville FL 32217 > (904) 394-9494 > > -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: solutions to the spam problem
3. Private Address Space The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: 10.0.0.0- 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) Someone has done an Apnic registration for rfc1918 private IP space. What this has to do with solving spam problems is still a mystery to me...unless someone is suggesting spammers (or perhaps all of Korea) should be assigned non-routable IP space. On Wed, 3 Apr 2002, Andy Dills wrote: > > On Wed, 3 Apr 2002, Sabri Berisha wrote: > > > > > [sabri@bofh sabri]$ whois -h whois.apnic.net 172.21.3.168 > > > > % Rights restricted by copyright. See > > http://www.apnic.net/db/dbcopyright.html > > % (whois6.apnic.net) > > > > inetnum: 172.21.3.168 - 172.21.3.199 > > netname: DSB-KR > > > > (I heared about this via IRC so credits for discovery go somewhere else :) > > Mind explaining exactly what your discovery is, for those of us without > mind reading abilities? > > Andy > > > Andy Dills 301-682-9972 > Xecunet, LLCwww.xecu.net > > Dialup * Webhosting * E-Commerce * High-Speed Access > -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Verio as an DS3 upstream provider - comments?
On Sat, 23 Mar 2002, Jason Slagle wrote: > > AFAIK, Verio is shrinking back to a small footprint. As far as I'm concerned, Verio is the new AGIS...host to many "bulletproof" commercial spammers. Complaints to abuse@ and a host of other verio addresses are apparently ignored since I keep receiving spams from the same verio customers. The worst one is: Custom Offers (NETBLK-C052-128-121-16-224) C052-128-121-16-224 128.121.16.224 - 128.121.16.255 Verio Data Centers - Sterling/Dulles (NETBLK-VRIO-128-121-000) VRIO-128-121-000 128.121.0.0 - 128.121.31.255 Verio Inc. (NETBLK-VRIO-128-121) VRIO-128-121128.121.0.0 - 128.121.255.255 > ... > I would avoid them if at all possible. I would agree and would not recommend anyone buy anything from verio. If you have circuit contracts up for renewal, ask your salesdroid about verio's policy on spam, and take your business elsewhere. -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _____ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Yahoo Hacked?
I saw signifigant DNS server load issues on all our DNS servers this evening beginning around that same time. It looked as if either yahoo.com had an accident with their DNS or someone did some cache poisoning. We were passing out SERVFAIL to anyone looking up pretty much anything.yahoo.com...and there were lots of *.yahoo.com queries going on. No...I don't think it has anything to do with vanity NS records as below...but I was considering posting about the DNS issue anyway. On Tue, 19 Mar 2002, David McGaugh wrote: > Maybe it has nothing to do with it then, but No one saw a significant > decrease in traffic with Yahoo between 17:00 PST and 17:15 PST? > > David McGaugh wrote: > > > > whois -h whois.internic.net yahoo.com > > > > Whois Server Version 1.3 > > > > Domain names in the .com, .net, and .org domains can now be registered > > with many different competing registrars. Go to http://www.internic.net > > for detailed information. > > > > YAHOO.COM.REALLY.NEEDS.TO.GET.A.CLUE.AT.JIMPHILLIPS.ORG > > YAHOO.COM.IS.TRYING.TO.STEAL.YAHOO.VU.HOW.ACIDULOUS.COM > > YAHOO.COM.IS.NOT.CANADIAN.ORG > > YAHOO.COM.BR > > YAHOO.COM.AND.SAFESEARCH.COM.AINT.NOTHING.COMPARED.TO.SHEEPSTER.COM > > YAHOO.COM.AINT.NOTHIN.COMPARED.TO.SAFESEARCH.COM > > YAHOO.COM > > > > To single out one record, look it up with "xxx", where xxx is one of the > > of the records displayed above. If the records are the same, look them > > up > > with "=xxx" to receive a full display for each record. > > > > >>> Last update of whois database: Tue, 19 Mar 2002 17:10:53 EST <<< > > > > The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and > > Registrars. > > -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
