Best practices for sending network maintenance notifications
All, We recently, at $dayjob, had one of our peers (at Symantec) send out a network maint notification, putting 70 addresses in the "To:" field, rather than using BCC or the exchange's mailing list. Naturally, when you mail 30 addresses, of the forms peering@ and noc@ various organizations, you're likely to hit at least a few autoresponders and ticket systems... And at least one or two of those autoresponders are of course brainded and configured to reply-all. (In this case, Verizon's ServiceNow setup was such a stupid responder). And that made things fun in our own ticket system, as our RT setup happily created a bunch of tickets. My question for the group -- does anyone know if there's a "best practices" for sending maint notifications like this? An RFC sort of thing? While it would define a social protocol, rather than a truly technical one, if there's not such a document, it seems like it could useful. And once such a thing exists, exchanges could of course helpfully point their members AT it (for both their humans, and ticket systems, to follow). -Dan --
Paging someone at SonicWall/Dell
All, If anyone has any contacts at Dell/SonicWall that can assist, their latest firewalls have a misfeature that have started blocking F-root (ISC, my Day-job) as a possible botnet responder. You can reach me, 24/7, at 703-338-2497, or at dmaho...@isc.org. Needless to say, this is seriously bad. As we ourselves are not Sonicwall users, our options here are limited. I've gotten their usual call center nonsense where they told me "I need to contact my system administrator" and wouldn't transfer me further. I've submitted a "removal" request via the form at http://botnet.global.sonicwall.com/change, but that still doesn't help if there's a firmware out there doing broken hueristics and mass-DDOSing folks. If for some reason there actually IS some botnet-related traffic going on toward the root servers (the root servers get a LOT of garbage, so this doesn't surprise me), we'd like to know that too. -Dan Mahoney -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
Paging Level3 Mail Admins: Your messagelabs config is broken
Note: sending this from my personal account to increase odds of someone seeing it. My work address is dmaho...@isc.org. ISC is having trouble mailing n...@level3.net, we keep getting redirected to a messagelabs error, seems to be happening from any address we send from, including personal addresses and the (sender/envelope) address of our ticket system. This is probably nonoptimal. You can reach me voice at 650-423-1362, or our noc number at 650-423-1310. Final-Recipient: rfc822; n...@level3.net Original-Recipient: rfc822;n...@level3.net Action: failed Status: 5.0.0 Remote-MTA: dns; cluster5.us.messagelabs.com Diagnostic-Code: smtp; 553-Sorry, your email address j...@isc.org has been 553-blacklisted. Refer to the Troubleshooting page at 553-http://www.symanteccloud.com/troubleshooting for more 553 information. (#5.7.1) Sep 19 23:32:58 amstel postfix/smtp[93402]: ED44E1FCBC3: to=n...@level3.net, relay=cluster5.us.messagelabs.com[216.82.250.51]:25, delay=6.6, delays=1.4/0/5.1/0.16, dsn=5.0.0, status=bounced (host cluster5.us.messagelabs.com[216.82.250.51] said: 553-Sorry, your email address dmaho...@isc.org has been 553-blacklisted. Refer to the Troubleshooting page at 553-http://www.symanteccloud.com/troubleshooting for more 553 information. (#5.7.1) (in reply to RCPT TO command)) -Dan Mahoney (hat: isc.org operations group). --
198.32.64.12 -- Harmless mis-route or potential exploit?
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 ---
