February 2004 - NANOG - lists.nanog.org

Re: Data Center Building Considerations
by J. Oquendo 04 Feb '04

04 Feb '04

You can try checking out the following documents. http://www.ieee802.org/3/10GBT/public/nov03/diminico_1_1103.pdf http://www.webtechniques.com/archives/1999/08/newton/ If you need info on Tempest shielding etc, http://www.politrix.org/foia/tempest =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x51F9D78D Fingerprint 2A48 BA18 1851 4C99 CA22 0619 DB63 F2F7 51F9 D78D http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x51F9D78D sil @ politrix . org http://www.politrix.org sil @ infiltrated . net http://www.infiltrated.net "Men have been taught that it is a virtue to agree with others. But the creator is the man who disagrees. Men have been taught that it is a virtue to swim with the current. But the creator is the man who goes against the current. Men have been taught that it is a virtue to stand together. But the creator is the man who stands alone." -- Ayn Rand

1 0

Re: Strange public traceroutes return private RFC1918 addresses
by Michael.Dillon＠radianz.com 04 Feb '04

04 Feb '04

>Which (as discussed previously) breaks things like Path MTU Discovery, >traceroute, If RFC1918 addresses are used only on interfaces with jumbo MTUs on the order of 9000 bytes then it doesn't break PMTUD in a 1500 byte Ethernet world. And it doesn't break traceroute. We just lose the DNS hint about the router location. A more important question is what will happen as we move out of the 1500 byte Ethernet world into the jumbo gigE world. It's only a matter of time before end users will be running gigE networks and want to use jumbo MTUs on their Internet links. Could we all agree on a hierarchy of jumbo MTU sizes that with the largest sizes in the core and the smallest sizes at the edge? The increment in sizes should allow for a layer or two of encapsulation and peering routers should use the largest size MTU. Thoughts? --Michael Dillon

12 23

Data Center Building Considerations
by Aaron Thomas 04 Feb '04

04 Feb '04

Hello, We are doing some preliminary research into relocating our facilities into a new building. This building has not been built and we would like to have some input into at least one of the floors being suitable for a Data Center installation. What I was wondering is if there are any serious design consideration with respect to floor loading, access for things like HVAC/Power, and general convenience issues such as cable management, access security and the like. If anyone has recently gone through any kind of building design or similar work for this type of installation, perhaps you would be able to share your experience or information on the subject. Either a reply to the list or off list would be great. Cheers, Aaron

2 1

Sup2/MSFC2 Working netflow config for hybrid
by Malayter, Christopher 04 Feb '04

04 Feb '04

Hello All, I am looking for a valid working configuration example to do NDEv1 off a 6509 SUP2/MSFC2 running in hybrid mode. Any assistance offline would be great. -Chris

1 0

Re: here are some postfix patterns i found useful today
by Paul Vixie 04 Feb '04

04 Feb '04

several of you thanked me privately for the earlier post on this thread, and in the time since then i have been inundated with even more variations of antivirus messages, so i'm posting an update. the bad news is, you have to use body checks as well as header checks. the good news is, i don't think the antivirus companies are going to start swizzling their headers and bodies in order to bypass these checks. about half of them include commercial advertising in their warnings, but that doesn't make them spammers (does it?) the stronger these viruses become, the more antivirus warnings i receive. to that end, i've made rejecting this chatter at the smtp level a priority. (otherwise i'd end up blackholing them at the ip source level, which would cause subsequent false positives on the non-antivirus mail they send out.) > what you do is, install postfix 2.0 or later, set header_checks to some > filename (in your main.cf), header_checks = regexp:/var/local/sa/postfix/headfilt.regex body_checks = regexp:/var/local/sa/postfix/bodyfilt.regex > and in that file, you put the following: bodyfilt.regex: /^Sorry Dangerous Attachment has been Removed/ REJECT body4 / is removed from here because it contains a virus$/ REJECT body5 /^WARNING: This e-mail has been altered by MIMEDefang/ REJECT body6 headfilt.regex: /^Subject:.*ALERTE \- Vous avez envoye un mail avec virus/ REJECT av /^Subject:.*ALERTE\: un virus a / REJECT av /^Subject:.*ALERT\! Virus found in your mail/ REJECT av /^Subject:.*Anti-Virus Notification/ REJECT av /^Subject:.*AntiVir ALERT/ REJECT av /^Subject:.*Anti\-Virus Notification/ REJECT av /^Subject:.*Antigen Notification/ REJECT av /^Subject:.*Antigen found VIRUS/ REJECT av /^Subject:.*Antivirus stopped your message/ REJECT av /^Subject:.*BANNED FILENAME/ REJECT av /^Subject:.*Disallowed attachment type found/ REJECT av /^Subject:.*Email Quarantined Due to Virus/ REJECT av /^Subject:.*Failed to clean virus file/ REJECT av /^Subject:.*File blocked - ScanMail for Lotus/ REJECT av /^Subject:.*Inflex scan report \[\d+\]/ REJECT av /^Subject:.*InterScan NT Alert/ REJECT av /^Subject:.*MMS Notification/ REJECT av /^Subject:.*MailSure Virus Alert/ REJECT av /^Subject:.*Message deleted/ REJECT av /^Subject:.*NAV detected a virus/ REJECT av /^Subject:.*Norton Anti.* detected/ REJECT av /^Subject:.*Ochrona antywirusowa/ REJECT av /^Subject:.*RAV AntiVirus scan/ REJECT av /^Subject:.*RECIPIENT \! Virus Notify \!/ REJECT av /^Subject:.*Report to Sender/ REJECT av /^Subject:.*Returned due to virus\; was\:/ REJECT av /^Subject:.*SAV detected a violation in a / REJECT av /^Subject:.*SENDER \! Virus Notify \!/ REJECT av /^Subject:.*ScanMail Message\: To Sender\, virus found / REJECT av /^Subject:.*Symantec AntiVirus/ REJECT av /^Subject:.*This message contains unsolicited data/ REJECT av /^Subject:.*VIRUS .* IN MAIL FROM YOU/ REJECT av /^Subject:.*VIRUS .*IN YOUR MAIL/ REJECT av /^Subject:.*VIRUS NO SEU EMAIL/ REJECT av /^Subject:.*Virus Alert/ REJECT av /^Subject:.*Virus Check Alert/ REJECT av /^Subject:.*Virus Detected by Network Assoc/ REJECT av /^Subject:.*Virus Notification from Redstone/ REJECT av /^Subject:.*Virus Notification\:/ REJECT av /^Subject:.*Virus Quarantine Notification/ REJECT av /^Subject:.*Virus Warning/ REJECT av /^Subject:.*Virus found in / REJECT av /^Subject:.*Virus in Ihrer Nachricht/ REJECT av /^Subject:.*Virus in\:/ REJECT av /^Subject:.*Votre message contient un virus/ REJECT av /^Subject:.*Warning\: E-mail viruses detected/ REJECT av /^Subject:.*WorldSecure Server notification/ REJECT av /^Subject:.*\[SmartFilter\] Virus Alert / REJECT av /^Subject:.*\[Virus detected\]/ REJECT av /^Subject:.*\{VIRUS\?\}/ REJECT av /^Subject:.*message .* contains a virus/ REJECT av /^Subject:.*virus found in sent message/ REJECT av /^Subject:.*virus trouve dans le message envoye/ REJECT av /^Subject:.*virus trovato in un messaggio inviato / REJECT av and as before, i cannot recommend the following article highly enough: > see also <http://www.attrition.org/security/rant/av-spammers.html>.

1 0

Re: in case nobody else noticed it, there was a mail worm released today
by Roger Marquis 04 Feb '04

04 Feb '04

Scott Francis <darkuncle(a)darkuncle.net> wrote: > I've been wondering lately, after about 10 years of email worms spreading in > exactly the same manner with every incarnation ... why do you think people > haven't learned not to open unexpected attachments yet? Blaming it on end users is one way to look at the problem, but not a way that will result in a solution. You should be wondering, after 10+ years of virus laden MS operating systems, why they haven't fixed this stuff. Similar vulnerabilities in Unix, Mac, and other OS were fixed long ago. They're not patched in Windows because MS doesn't have to. MS doesn't write secure code because they are a monopoly and maintain that status by introducing subtle OS bugs that plague competitive third party applications. They don't publish an API for many of their system calls so nobody can write secure code other than MS themselves. They also run as much of their own software as possible in priviliged mode for performance (to avoid context switching). You'll never seen any real security from this type of business model. > (Note: I really do not want this to degenerate into another rant against > vendor M; Sorry for not sharing your disinterest in the actual reasons we continue to see these viruses and trojans infecting MS and, for all intents and purposes, only MS operating systems. -- Roger Marquis Roble Systems Consulting http://www.roble.com/

10 18

[OT] need att.net postmaster contact
by Omar 04 Feb '04

04 Feb '04

Hi, I have a mailing list host which runs into occasional issues with att.net/worlnet.att.net. Their abuse address has been responsive in lifting listings in their block list, but I've not been able to get anyone to respond about a more permanent solution, like setting up a feedback loop and whitelisting our netblocks. Can anyone contact me or direct me to a manager/director in the postmaster group (off-list, of course)? Thanks much, Omar Thameen

1 0

CULPRIT - poor connectivity to new b.root-servers.net
by bill 04 Feb '04

04 Feb '04

upstream routing for the new and old prefixes for b.root-servers.net is asymetric. inbound is generally weighted to arrive through Level3, while the outbound is generally weighted to depart through verio. due to exceptional work from Level3 and Los Nettos, they were able to identify that Verio filters using "golden" prefixes... "I believe I have found the culprit. I think that Verio was filtering the b root traffic out because it was not a blessed source address." and "I have a strange feeling that Verio (the return path for 209.244/14 according to Walt, and probably for lots of other blocks) is filtering source addresses" Verio was asked to update its "blessed" or "golden" prefix list so that packets from "B" would reach thier intended destinations. Third party reports indicate that this "correction" has been applied within Verio. I would appreciate private replies on the efficacy of this ACL modification. --bill

3 2

RE: Road Runner refusing us, others?
by Michel Py 04 Feb '04

04 Feb '04

Looks like your IP 24.92.226.159 is listed at block.blars.org http://www.blars.org/errors/block.html -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mark Jeftovic Sent: Wednesday, February 04, 2004 6:49 AM To: nanog(a)merit.edu Subject: Road Runner refusing us, others? Road Runner is refusing our email forwarders again, according to one of customers they are also refusing yahoo as well, maybe a few others. Anyone else? Can somebody from RoadRunner contact us off list? > > Final-Recipient: rfc822; > Action: failed > Status: 5.0.0 > Diagnostic-Code: X-Postfix; host nymx-1.nyroc.rr.com[24.92.226.159] > said: 550 > 5.7.1 Mail Refused - 216.220.40 - See > http://security.rr.com/mail_blocks.htm#security - 20040203 >

1 0

Re: Road Runner refusing us, others?
by Brent_OKeeffe＠asc.aon.com 04 Feb '04

04 Feb '04

I just sent an email from a Yahoo account to me roadrunner account. Worked fine. Brent Mark Jeftovic <markjr(a)easydns.com> Sent by: owner-nanog(a)merit.edu 02/04/2004 09:48 AM To: nanog(a)merit.edu cc: Subject: Road Runner refusing us, others? Road Runner is refusing our email forwarders again, according to one of customers they are also refusing yahoo as well, maybe a few others. Anyone else? Can somebody from RoadRunner contact us off list? > > Final-Recipient: rfc822; > Action: failed > Status: 5.0.0 > Diagnostic-Code: X-Postfix; host nymx-1.nyroc.rr.com[24.92.226.159] > said: 550 > 5.7.1 Mail Refused - 216.220.40 - See > http://security.rr.com/mail_blocks.htm#security - 20040203 >

1 0