- Test - lists.nanog.org

Re: DNS Blocking
by Paul Vixie 19 Aug '04

19 Aug '04

i wrote: > > ... confuse and make errors for whoever queries it: > > > > @ SOA localhost hostmaster.localhost > > NS localhost > > localhost A 127.0.0.1 > > * MX 0 localhost > > A 127.0.0.1 > > > > if you put a zone like that in place on a server that's receiving > > unwanted queries for some zone, they will soon stop, or not. you > > win either way -- the queries stop, or you laugh your ass off. dan answered: > There weren't rfc1918. i'm sorry if i mixed too many topics in one post. it doesn't have to be rfc1918. let's say that someone registers a zone, let's call it nanogtest.vix.com, and points it at your nameservers without your permission. in response, let's create a zone file with this content: --- @ SOA localhost hostmaster.localhost 42 3600 1800 604800 3600 NS localhost localhost A 127.0.0.1 * MX 0 localhost A 127.0.0.1 --- note that this content is all-purpose. it doesn't matter what the real zone is called. in bind's named.conf, add something like this: --- zone "nanogtest.vix.com" { type master; file "pri/nanogtest.vix.com"; }; --- and you're done. any query that anyone sends to your server for that zone will be sent something that will hurt them. eventually they will realize that it's hurting them, and they will stop.

4 3

DNS Blocking
by Dan Mahoney, System Admin 19 Aug '04

19 Aug '04

Hey guys, I was recently hammered by someone making a ton of requests for a non-existent subdomain of a domain that I host. The requests were coming in from forged ips, and presumably being used to flood other people. Because DNS is udp based, and the sender of the queries honestly didn't care about getting a response back, traditional firewalls were useless. I imagine a sniffing firewall that can look at the packet payloads would have been more useful, but I was wondering if anyone knew a way to better mitigate this type of attack. I posted on comp.protocols.dns.bind, didn't get back anything of use. I posted on webhostingtalk, and got a pointer at the "securing bind" paper (which neither addresses the situation, nor includes anything to prevent it). What I was basically asking for was a "silently drop queries for X-domain" option. But one doesn't exist in bind. I know it's a little off-topic, but I'd appreciate any pointers. -Dan Mahoney -- "...Somebody fed you sugar. Shit!" --Tracy, after noticing Gatorade on my desk. Ezzi Computers, October 18th 2003 Approx 11PM --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------

3 3

Re: OT - 3 Free Gmail invites
by Robert Bonomi 19 Aug '04

19 Aug '04

> From owner-nanog(a)merit.edu Thu Aug 19 12:43:05 2004 > Date: Thu, 19 Aug 2004 10:39:43 -0700 > From: Lou Katz <lou(a)metron.com> > To: nanog(a)nanog.org > Subject: Re: OT - 3 Free Gmail invites > > > On Wed, Aug 18, 2004 at 10:13:29PM -0700, Jonathan Nichols wrote: > > > > Joshua Brady wrote: > > > > >I've got 2 Gmail invites up for grabs for the first 2 to email me offlist. > > > > > > > You know, I'm having trouble finding people that *don't* have gmail.com > > accounts already. :P > > Because G-mail scans INCOMING mail without the sender's consent, we will NEVER > have a G-mail account and have considered blocking them. Are you seriously considering blocking _everybody's_ mail? In today's world practically *everybody* scans incoming mail. Spam, viruses, scams, bogus bounce messages, etc., etc., ad nauseum. > have a G-mail account and have considered blocking them. We actively discourage > our clients from using this service. Do you similarly discourage the use of ATT WorldNet, MSN, Yahoo, Earthlink, Hotmail, AOL, Earthlink, Panix, Flashnet, Netscape.net, RCN, Corecomm, Comcast, Cogent, RoadRunner, Cox, Adelphia, etc. ? *EVERY*ONE* of those providers also scans all INCOMING mail. *Without* the sender's consent. Do you do any anti-spam and/or anti-virus scanning of *your* incoming mail? Why does it seem like the description 'two-faced' applies to your attitude? > If you want to let a service scan YOUR mail, > it is your perogative, but you cannot give them permission to scan MY mail to you. > And, just BTW, legally, _yes_ I *can* give a third-party permission to scan any/all of my incoming mail, including yours. And you, the sender, do =not= have anything to say about the matter. LEGAL FACT: I can hire _anybody_ to read my mail, on my behalf, 'annotate' it for me, and provide me with the 'marked up' copy, *without* violating any of your 'intellectual property rights' (e.g., "copyright"). You have absolutely no say in the matter, whatsoever. And it doesn't matter whether the 'mail' in question is postal mail, or 'e-mail'. The law is _exactly_ the same. *ANYTHING* that _I_ can legally do with/to my incoming mail, I can hire an 'agent' (someone acting 'at my direction', and 'on my behalf') to do. Now, if that person I hired were to give copies of my incoming mail to _someone_else_ (other than myself), *then*and*only*then* would you have a cause for action against "someone". If that person distributed those copies _at_my_direction_, they would be immune; your 'cause for action' would be against _me_. OTOH, if they did it *without* my permission, then and =only= then, would you have cause for action against _them_. Of course, if _I_ were to do that self-same thing -- give copies of incoming mail to 'someone else', then *I* would be liable to the sender for those acts.

2 1

RE: "scanning" e-mail [WAS: 3 Free Gmail invites]
by Joe Johnson 19 Aug '04

19 Aug '04

Plus, didn't the courts rule that an ISP can read their customer's emails? The wire-tap laws say you can't read communications in-transit, but once it hits the server's NIC, it is no longer in transit. May be sleazy, but it is legal. Joe Johnson > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Patrick W Gilmore > Sent: Thursday, August 19, 2004 12:56 PM > To: nanog(a)nanog.org > Cc: Patrick W Gilmore > Subject: "scanning" e-mail [WAS: 3 Free Gmail invites] > > > On Aug 19, 2004, at 1:39 PM, Lou Katz wrote: > > > On Wed, Aug 18, 2004 at 10:13:29PM -0700, Jonathan Nichols wrote: > >> > >> Joshua Brady wrote: > >> > >>> I've got 2 Gmail invites up for grabs for the first 2 to email me > >>> offlist. > >>> > >> > >> You know, I'm having trouble finding people that *don't* have > >> gmail.com > >> accounts already. :P > > > > Because G-mail scans INCOMING mail without the sender's consent, we > > will NEVER > > have a G-mail account and have considered blocking them. We actively > > discourage > > our clients from using this service. If you want to let a service scan > > YOUR mail, > > it is your perogative, but you cannot give them permission to scan MY > > mail to you. > > I believe your last statement is factually incorrect. I absolutely > _can_ do anything I please with "your" e-mail you send to me. Not only > that, I also believe I _may_ do it. You send me e-mail, the e-mail is > now mine. I can post it publicly, put it into a search engine, or > deleted it, and you have no say in the matter. Might not be polite, > but it certainly it not illegal. Don't like it, don't send me e-mail. > (Please. :) > > Google is simply indexing mail for their users as a service - an > unobtrusive, completely benign service just like virus checking or > procmail scripts which have been used for years. And it certainly does > not require the consent of the sender. How I manage my mailbox is MY > business. You have exactly zero say over whether I let Google do it or > Mail.app. > > Perhaps you are worried that Google will read your e-mail? Or maybe > let others read it? Well, I hope you never send e-mail to anyone who > does not run their own dedicated mail server on their own dedicated > hardware and encrypt the SMTP session. 'Cause you are worried about > something that has been happening for decades. (Plus I think you have > to be more than a little arrogant to think anyone at Google gives a > fart about the e-mail you send.) > > But hey, it's your e-mail, send it or not as you please. I like the > idea behind G-mail, I just can't deal with a web-based e-mail client. > You don't, then don't use it. > > Just please don't spout factual fallacies like saying I can't give > someone permission to do things to my inbox. > > -- > TTFn, > patrick >

1 0

Re: OT - 3 Free Gmail invites
by Alon Tirosh 19 Aug '04

19 Aug '04

Ksowa! I leave my desk for 5 minutes and theres like 50 requests. Im out on this account, Ill open my other one and serve the 5 I have on there in a couple minutes. The window is now closed though, sorry.

1 0

Nix on free accounts
by Susan Harris 19 Aug '04

19 Aug '04

Folks, let's abandon the gmail thread, which is not relevant to network operations.

1 0

Re: OT - 3 Free Gmail invites
by John Neiberger 19 Aug '04

19 Aug '04

>Uh, could we _please_ get back to something with operational content, or >nothing at all? > >Anyone have anything concrete on the SHA-0 / MD5 compromise, for instance? >Any operational impact there, that we need to worry about in the near >term? No worries. I don't think your gmail account is susceptible to this vulnerability. :) John --

1 0

Blocked port 25? -- problem discovered, thanks!
by Byron L.Hicks 19 Aug '04

19 Aug '04

Thanks for everyones help and good information. The problem has been discovered and a solution is pending. NMSU peers with UNM, and we provide backup Internet routing for each other. UNM is in the process of adding Time Warner Telecom as a peer, and they are not advertising NMSU's routes correctly. The result is that all customers connected to Time Warner Telecom are using UNM as a transit to get to NMSU. UNM also has a filter on their border router to prevent access to unauthorized SMTP servers, and this affectively blocked the Time Warner Telecom to NMSU mail traffic. I am presently working with the UNM engineers to fix this problem. I didn't see the Time Warner Telecom correlation in my traceroutes, because many of the places were multihomed, and the traffic from NMSU was taking a different ingress into their network. It would seem that my byronhicks(a)byronhicks.com email is broken, too. It would appear that I let my domain expire, and the email address I have on record with Network Solutions is not longer valid. bleah.. Too early in the morning to have to deal with this stuff. Thanks again to all the NANOG members that helped me quickly diagnose this problem. -- Byron L. Hicks Network Engineer NMSU ICT

1 0

RE: Blocked port 25?
by Michel Py 19 Aug '04

19 Aug '04

Looks like your personal email has issues too... > Your message did not reach some or all of the intended > recipients. Subject: RE: Blocked port 25? Sent: > 8/19/2004 6:49 AM The following recipient(s) could not > be reached: 'byronhicks(a)byronhicks.com' on 8/19/2004 > 6:49 AM The destination server for this recipient could > not be found in Domain Name Service (DNS). >nslookup >Default Server: localhost >Address: 127.0.0.1 >set type=ns >byronhicks.com >Server: localhost >Address: 127.0.0.1 >*** localhost can't find byronhicks.com: Non-existent domain Is your mail server 128.123.3.5? Looks like I can't get to it from home; I'm on one of these netblocks that are marked as dynamic IPs although it also serves static IP addresses such as myself. I can send UDP DNS queries and get replies to/from it just fine though, so it's likely not a routing issue but indeed a filtering issue. Conventional wisdom says that the problem is either at your end or somewhere in Time Warner, and possibly because your mail server is also a DNS server. Setup a machine that listens on 25 on another IP on the same subnet, and let me know the IP, I'll give it another shot. Michel. Tracing route to dns1.NMSU.Edu [128.123.3.5] over a maximum of 30 hops: 3 9 ms 8 ms 9 ms dist1-vlan60.scrm01.pbi.net [64.171.152.130] 4 9 ms 8 ms 9 ms bb1-g8-3-0.scrm01.pbi.net [64.171.152.247] 5 13 ms 13 ms 13 ms bb1-p12-3.sntc01.sbcglobal.net [151.164.188.121] 6 12 ms 13 ms 13 ms bb2-p9-0.sntc01.sbcglobal.net [151.164.40.166] 7 13 ms 13 ms 13 ms core2-p6-1.crscca.sbcglobal.net [151.164.241.193] 8 13 ms 13 ms 13 ms bb1-p8-0.crscca.sbcglobal.net [151.164.40.62] 9 14 ms 14 ms 14 ms ex1-p13-0.pxpaca.sbcglobal.net [151.164.190.206] 10 13 ms 13 ms 14 ms as4323-twtelecom.pxpaca.sbcglobal.net [151.164.248.110] 11 15 ms 15 ms 16 ms 66.192.250.45 12 62 ms 62 ms 61 ms core-01-so-0-0-0-0.phnx.twtelecom.net [168.215.55.114] 13 72 ms 72 ms 73 ms dist-01-so-2-3-0-0.albq.twtelecom.net [66.192.251.243] 14 72 ms 72 ms 73 ms 66.192.247.133 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out.

1 0

FW: hey had eric sent you
by Riley, Marty 19 Aug '04

19 Aug '04

I'm running short on theories and options, so I thought I would see if any other ISPs have seen this problem on your network(s). If so, what was the cure? mjr -----Original Message----- The Unknown problem. Symptoms: At random times dialup, dedicated, & internal network users are unable to pass TCP traffic to off network sites. ICMP and UDP appears to be uneffected by the outage which lasts anywhere from 2 to 5 minutes. The problem appears to be wide spread with similar reports from WVNET and other ISPS. nTelos is experiencing a similar problem but we have yet to confirm it is the same. Problem has changed in it's action but remained similar enough to consider it the same problem. Effected Platforms: Windows 2000 Pro, XP Home, XP Pro, & 2003 Server. Uneffected Platforms: Unix, MacOS (?) History: During the week of 2/9/04 the call center started recieving reports of users being unable to connect to sites off the CityNet network. Sites hosted on the internal network are uneffected by the outage. Initally it was thought to be a Internet Explorer problem possably caused by the KB832894 / IE SP1 or other updates but after further investigation it was found that Mozilla users were encountering the same problem. After several days of testing it was determined that during the outage any TCP session started on any port would fail. TCP sessions started before the outage continue to work and show no ill effects from the outage. After logging connection attempts at various intervals on many machines there appears to be no sort of pattern in the outages. Most machines encounter the problem, some more than others and a few do not encounter it at all. The duration and frequency of the outage is very fluid. During an outage, we can verify that the packet does seem to leave and reenter the network: Mar 5 22:28:04 pittpa-chaswv-ds3 17083: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17084: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17085: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 1 packet Mar 5 22:28:09 pittpa-chaswv-ds3 17086: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 1 packet Mar 5 22:33:24 pittpa-chaswv-ds3 17089: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3378), 7 packets Mar 5 22:33:24 pittpa-chaswv-ds3 17090: SLOT 1:6d20h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.14.174(3376), 17 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17092: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3378) -> 216.41.224.3(80), 7 packets Mar 5 22:33:58 pittpa-chaswv-ds3 17093: SLOT 2:6d20h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.14.174(3376) -> 216.41.224.3(80), 18 packets Mar 5 00:58:30 pittpa-clarwv-ds3 16062: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 1 packet Mar 5 00:58:30 pittpa-clarwv-ds3 16063: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16067: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.3(80), 1 packet Mar 5 01:03:28 pittpa-clarwv-ds3 16068: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16069: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 1 packet Mar 5 01:03:34 pittpa-clarwv-ds3 16070: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3228), 1 packet Mar 5 01:03:39 pittpa-clarwv-ds3 16072: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3239) -> 216.41.224.3(80), 1 packet Mar 5 01:03:47 pittpa-clarwv-ds3 16073: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3183) -> 216.41.224.3(80), 74 packets Mar 5 01:04:13 pittpa-clarwv-ds3 16075: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3183), 72 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16078: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3218) -> 216.41.224.3(80), 4 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16079: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3217) -> 216.41.224.3(80), 3 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16080: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3221) -> 216.41.224.3(80), 19 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16081: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3228) -> 216.41.224.3(80), 5 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16082: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3229) -> 216.41.224.3(80), 6 packets Mar 5 01:08:46 pittpa-clarwv-ds3 16083: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3236) -> 216.41.224.3(80), 9 packets Mar 5 01:08:47 pittpa-clarwv-ds3 16084: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3233) -> 216.41.224.3(80), 12 packets Mar 5 01:08:47 pittpa-clarwv-ds3 16085: SLOT 2:5d22h: %SEC-6-IPACCESSLOGP: list 113 permitted tcp 69.43.23.23(3239) -> 216.41.224.3(80), 21 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16087: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3239), 19 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16088: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3228), 4 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16089: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3217), 2 packets Mar 5 01:09:12 pittpa-clarwv-ds3 16091: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3218), 3 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16092: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3221), 17 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16093: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3229), 5 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16094: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3236), 7 packets Mar 5 01:09:13 pittpa-clarwv-ds3 16096: SLOT 1:5d22h: %SEC-6-IPACCESSLOGP: list 111 permitted tcp 216.41.224.3(80) -> 69.43.23.23(3233), 9 packets Network analysis showed significant amounts of spoofed multicast traffic and odd arp traffic. 10:17:16.416222 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 278 10:17:16.421886 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 334 10:17:16.423873 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 262 10:17:16.426948 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 254 10:17:16.432095 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 298 10:17:16.435921 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 274 10:17:16.439959 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 328 10:17:16.445317 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 326 10:17:16.449688 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 330 10:17:16.463537 IP 192.168.1.1.1900 > 239.255.255.250.1900: udp 322 Steps were taken to elminiate the spoofed traffic on the routers and access servers in the form of ACLs and filter lists. Neither have eliminiated the problem... but to what extent they might have helped has yet to be determined. The problem is still occuring, for some users the duration of the outage seems to have shortened other users notice no difference. It is not yet known if the filtering on the routers and access servers or the conversion to the 10.x.x.x network has made any difference. We should have a better idea in the upcoming days. What Doesn't help: Removing windows updates. Turning off XP firewall. Searching for malware. (SpyBot-SD, Adaware) Virus scanning (Various softwares) Specifying dns servers. Reinstalling windows.

7 6