- Test - lists.nanog.org

Re: ingress SMTP
by Robert Bonomi 04 Sep '08

04 Sep '08

> From nanog-bounces(a)nanog.org Wed Sep 3 11:58:37 2008 > From: Alec Berry <alec.berry(a)restontech.com> > Subject: Re: ingress SMTP > > Michael Thomas wrote: > > I think this all vastly underrates the agility of the bad guys. So > > lots of ISP's have blocked port 25. Has it made any appreciable > > difference? Not that I can tell. If you block port 25, they'll just > > use another port and a relay if necessary. > > I'm pretty sure it has, although without aggregate stats from various > ISPs it is hard to tell. Since mail transport is exclusively on port 25 > (as opposed to mail submission), a bot cannot just hop to another port. One small data-point -- on a personal vanity domain, approximately 2/3 of all the spam (circa 15k junk emails/month) was 'direct to inbound MX' transmissions. The vast majority of this is coming from end-user machines outside of North America. China, India Thailand, Brazil, Poland, "CZ", and a couple of providers each in Germany and France, appear to be the most prevalent sources _I_ see. The message count would be a fair bit higher, but I have several overseas networks (4 in DE, 2 in TW, 1 in CZ) plus pieces of 2 domestic networks (*da.uu.net, *pub-ip.psi.net) blocked at the firewall. Also firewalled are a couple of dozen IP addresses that have -each- made over 10k attempts to _relay_ mail through me. I'm seeing a significant amount of 'Received' header forgery, apparently intended to fool "dumb" header parsers into believing the direct-to-MX transmission _did_ go through the server associated with the domain used in the '"from: ", "from ", and "Reply-to: " lines. The good news is that only a _really_ dumb parser would be fooled by most of what I'm seeing. :)

3 3

ingress SMTP
by Ang Kah Yik 04 Sep '08

04 Sep '08

Hmm.. if it helps - here's a link to an archived discussion on the same issue earlier this year. http://www.mail-archive.com/nanog@merit.edu/msg52598.html -- Ang Kah Yik (bangky) -- http://blog.bangky.net

3 2

BCP blocking list for edge networks? (was: ingress SMTP)
by Jay R. Ashworth 04 Sep '08

04 Sep '08

Ok, mine is actualy even edgier than that; no transit at all, to paraphrase Steeley Dan. But does anyone have a pointer to a good set of ports to block in each direction through my Shorewall DNAT setup, preferably annotated? On reflection, that's actually only outbound; the necessity to set up inbound DNAT manually makes it a default-deny environment, which is one of the reasons that some people like NAT as a component of an edge firewall. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin)

1 0

Re: ingress SMTP
by matthew＠sorbs.net 03 Sep '08

03 Sep '08

----- Original Message ----- From: "Jay R. Ashworth" <jra(a)baylink.com> Date: Thursday, September 4, 2008 5:00 am Subject: Re: ingress SMTP > > Does anyone bother to run an MSA on 587 and *not* require > authentication? Many can be configured that way (example: Sun One/iPlanet mail server can). Whether they are or not depends on the admin. / M

1 0

198.32.64.12 -- Harmless mis-route or potential exploit?
by Dan Mahoney, System Admin 03 Sep '08

03 Sep '08

Hello all, While recently trying to debug a CEF issue, I found a good number of packets in my "debug cef drops" output that were all directed at 198.32.64.12 (which I see as being allocated to ep.net but completely unused). Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Sep 2 22:03:25: CEF-Drop: Packet for 198.32.64.12 -- no route Now, as nearly as I can tell, this IP address has never been used for anything, but I see occasional references to it, such as here: http://www.honeynet.org/papers/forensics/exploit.html So the question is, should I just ignore this as a properly dropped packet due to "no route" (this provider is running defaultless, so unless such a route exists, it should be okay). On the other hand, one of the other packets I'm seeing specifically refers to a DNS exploit, so should I then dispatch to people to trace down the source origin ? (Suffice it to say the resources are there to find it fairly easily, even if the source address is forged). -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---------------------------

14 19

Is the export policy selective under valley-free?
by Kai Chen 03 Sep '08

03 Sep '08

Just want to ask a direct question. Will an AS export all it gets from its customers and itself to its providers? Or even under valley-free, the BGP export policy is also selective? Thanks a lot, -- -Kai

7 14

hosting net guest
by Randy Bush 03 Sep '08

03 Sep '08

we have a couple of sharp net engs coming to nanog/arin in la from far less privileged parts of the world. i thought it might be nice if they could stay a few extra days or a week to see how those of us privileged to have larger markets and hence scaled up networks run our shows. would anyone on the left coast be willing to host a guest or two for a few days and let them see inside the guts of your operation? responses to me privately, please. and excuse poor response this week as i am on holiday. thanks. randy

1 0

Re: ingress SMTP
by hobbit＠avian.org 03 Sep '08

03 Sep '08

Wow, lots of responses already. Thanks, good discussion. I should clarify a little, that it's not necessarily about "blanket" port blocking or denying "random" ports as threats are perceived, but where needed in a well thought-out manner and trying to take customer needs [stated or observed] into account first. And back it up with AUP verbiage. There must be plenty of places where it just makes sense, and others where it's borderline, iffy, or unmanageable. One has to start *someplace*. Oh, and don't get me started about abuse-desk competency, or even existence, especially in the big providers. I'll bet most of them can't even find the *rack* where the autoresponder machine is, let alone actually figure out why its disk has been full for six months. Related question, now that some discussion has started: why the F does Gmail refuse to put real, identifiable injection-path headers in mail they relay out? The current "policy" only protects spammer identities behind a meaningless 10.x and is completely at odds with what almost every other freemail provider does, which of course breaks any receiving-end model. Who's here from Google that I can chat with about this? _H*

2 1

[NANOG-announce] Important Reminders and Announcement
by Betty Burke 03 Sep '08

03 Sep '08

Dear NANOG Community: Just a few reminders and a news item. The deadline for Steering Committee Nominations is near, Tue 2008-09-09. Complete election information is available on the NANOG website. The new process will work if many are involved... nudge: A great NANOG44 agenda is now posted. Make sure to check it out and register!! Merit, along with the entire NANOG community, appreciates the involvement and support from our sponsors. If you are interested, please send email to nanog-support(a)nanog.org, as a few sponsorship opportunities for NANOG44 remain. Do not miss out on your opportunity to be part of this meeting. As many of you know, Merit has been working to improve the NANOG.ORG website. We are very pleased to announce the new site will be launched on Thursday morning, Sept. 4, at 7 am EST. Members of the NANOG Steering Committee have been working with Merit, and we hope all issues have been resolved. We believe the community will find the new site to be much more useful. "I think the website looks great, is very professional, and a huge leap forward in functionality and usability", Philip Smith-SC Chair. New features include: - Graphic and Text version of the web site - New presentation archive that allows for searching by NANOG meeting, year, presenter and more. - "Print This" feature, which will strip away page navigation for easier printing. - Easier web site navigation and improved appearance - RSS Feeds and much more! The meeting archive and presentation archive are still being completed, but you will soon be able to access the remaining past meeting information. Thanks for being a part of NANOG. We hope you check out the new site and use it to keep in touch with important issues surrounding the Internet and the NANOG community. We look forward to seeing many of you in LA at NANOG44! and for your participation in the NANOG 2008 Elections process. As always, if you have any questions, concerns, or issues with NANOG support activities, please feel free to send a note to NANOG-Support(a)nanog.org or phone us at Merit (734)764-9430. All best. Betty Burke Merit/NANOG Project Manager www.nanog.org www.merit.edu _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

RE: ingress SMTP
by Skywing 03 Sep '08

03 Sep '08

Intercepting port 25 traffic of your customers (as an ISP), redirecting it to your own servers, and allowing the connection to complete sounds like a pretty slippery slope of badness to me. Sure, you should be using TLS anyway, but slurping up port 25 traffic begs the question of what is happening to the SMTP authentication credentials or the mail data that flows through said intercept. Blocking traffic versus intercepting it wholesale are very different ballgames. Now, obviously, whoever is providing your pipe has the technical ability to intercept your traffic. Actually doing this has proven widely unpopular (to place it nicely) when uncovered, even with the best of intentions. There is usually an implicit trust that your ISP won't be employing underhanded tactics like that in most people's minds, I think. I suspect that most people will call any interception of their outbound mail traffic "underhanded", even for if done for a perceived good reason in the mind of said ISP. - S -----Original Message----- From: Stephen Sprunk <stephen(a)sprunk.org> Sent: Wednesday, September 03, 2008 12:09 To: Alec Berry <alec.berry(a)restontech.com> Cc: north American Noise and Off-topic Gripes <nanog(a)merit.edu> Subject: Re: ingress SMTP Alec Berry wrote: > Michael Thomas wrote: > >> But the thing that's really pernicious about this sort of policy is >> that it's a back door policy for ISP's to clamp down on all outgoing >> ports in the name of "security". >> > > I don't think ISPs have anything to gain by randomly blocking ports. They may block a port that is often used for malicious behavior (135-139, 194, 445, 1433, 3306 come to mind) as a way to reduce their support calls-- but they would have to balance that with the risk of loosing customers. It's not as much a slippery slope as much as it is a tightrope act (yes-- I am metaphorically challenged). > I see nothing wrong with filtering commonly abused ports, provided that the ISP allows a user to opt out if they know enough to ask. When port 25 block was first instituted, several providers actually redirected connections to their own servers (with spam filters and/or rate limits) rather than blocking the port entirely. This seems like a good compromise for port 25 in particular, provided you have the tools available to implement and support it properly. I also agree with the comments about switching customers to 587. My former monopoly ISP only accepted mail on 25 and I had endless problems trying to send mail from airports, hotels, coffee shops, etc. while traveling. The same hotspots also tended to block port 22, so I couldn't even forward mail via my own server. However, my new monopoly ISP only accepts mail on 587, and I have yet to have a single problem with that from any hotspot I've used since the switch. Ditto for reading my mail via IMAPS/993, whereas I used to have occasional problems reading it via IMAP/143. S

1 0