April 2014 - Test - lists.nanog.org

CVE-2014-0160 mitigation using iptables
by Fabien Bourdaire 10 Apr '14

10 Apr '14

Following up on the CVE-2014-0160 vulnerability, heartbleed. We've created some iptables rules to block all heartbeat queries using the very powerful u32 module. The rules allow you to mitigate systems that can't yet be patched by blocking ALL the heartbeat handshakes. We also like the capability to log external scanners :) The rules have been specifically created for HTTPS traffic and may be adapted for other protocols; SMTPS/IMAPS/... # Log rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT" # Block rules iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=0x18030000:0x1803FFFF" -j DROP # Wireshark rules $ tshark -i interface port 443 -R 'frame[68:1] == 18' $ tshark -i interface port 443 -R 'ssl.record.content_type == 24' We believe that this should only be used as a temporary fix to decrease the exposure window. The log rule should allow you to test the firewall rules before being used in production. It goes without saying that if you have any suggested improvements to these rules we would be grateful if you could share them with the security community. Clearly, use of these rules is at your own risk ;) ECSC SOC Team Researchers: Adam Shore Alex Innes Fabien Bourdaire -- ECSC Ltd - http://www.ecsc.co.uk

5 4

Akamai DNS for GoDaddy hosted servers?
by Nanog Smitasin 10 Apr '14

10 Apr '14

Anyone else hosting at GoDaddy seeing NXDOMAIN from some Akamai servers? Example: # dig +trace ip-redacted.ip.secureserver.net ; <<>> DiG 9.9.5 <<>> +trace ip-redacted.ip.secureserver.net ;; global options: +cmd <snip> secureserver.net. 172800 IN NS cns1.secureserver.net. secureserver.net. 172800 IN NS cns2.secureserver.net. secureserver.net. 172800 IN NS a9-67.akam.net. secureserver.net. 172800 IN NS a8-67.akam.net. secureserver.net. 172800 IN NS a1-245.akam.net. secureserver.net. 172800 IN NS a20-65.akam.net. secureserver.net. 172800 IN NS a11-64.akam.net. secureserver.net. 172800 IN NS a6-66.akam.net. <snip> # dig ip-redacted.ip.secureserver.net(a)cns1.secureserver.net ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28818 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5 ;; WARNING: recursion requested but not available <snip> ;; ANSWER SECTION: ip-redacted.ip.secureserver.net. 3600 IN A REDACTED ;; AUTHORITY SECTION: ip.secureserver.net. 3600 IN NS cns2.secureserver.net. ip.secureserver.net. 3600 IN NS cns1.secureserver.net. <snip> # dig ip-redacted.ip.secureserver.net @a9-67.akam.net <snip> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56606 ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ip-redacted.ip.secureserver.net. IN A ;; AUTHORITY SECTION: secureserver.net. 3600 IN SOA cns1.secureserver.net. dns.jomax.net. 2014041000 300 600 2592000 3600 ;; Query time: 13 msec ;; SERVER: 184.85.248.67#53(184.85.248.67) ;; WHEN: Thu Apr 10 09:11:21 PDT 2014 ;; MSG SIZE rcvd: 115

1 0

ICANN issues call for public input on process to develop IANA stewardship transition plan
by John Curran 10 Apr '14

10 Apr '14

NANOGers - As you may have heard, the United States National Telecommunications and Information Administration (US NTIA) has a contract with ICANN for administration of the Internet technical identifiers [e.g. DNS names, IP address spaces, and protocol parameters], and recently proposed transitioning stewardship of these tasks over to the Internet technical community. ICANN is facilitating the development of a plan to accomplish this, and their initial draft of a process for plan development has been released and is available for public comment. Comments on the proposed process are due by 8 May 2014, and as that is well before NANOG 61 in June, I'm drawing attention to this opportunity via the list. You can find more information regarding the proposed process and how to provide feedback attached. FYI (and thanks!) /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [arin-announce] ICANN issues Call for Public Input on the IANA Functions Transition Date: April 9, 2014 at 12:41:18 PM EDT To: arin-announce(a)arin.net<mailto:arin-announce@arin.net> ICANN has issued a call for public input on a newly released Draft Proposal, based on initial community input, of the principles, mechanisms, and process to develop a proposal to transition NTIA's stewardship of the IANA functions. Details are available at: http://www.icann.org/en/about/agreements/iana/transition/draft-proposal-08a… Feedback can be submitted via the publicly archived mailing list: ianatransition(a)icann.org. We encourage ARIN community members to participate, and call to your attention that the deadline to contribute is 8 May 2014 (midnight UTC). Regards, Communications and Member Services American Registry for Internet Numbers (ARIN)

1 0

Fwd: Serious bug in ubiquitous OpenSSL library: "Heartbleed"
by Paul Ferguson 09 Apr '14

09 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm really surprised no one has mentioned this here yet... FYI, - - ferg Begin forwarded message: > From: Rich Kulawiec <rsk(a)gsp.org> Subject: Serious bug in > ubiquitous OpenSSL library: "Heartbleed" Date: April 7, 2014 at > 9:27:40 PM EDT > > This reaches across many versions of Linux and BSD and, I'd > presume, into some versions of operating systems based on them. > OpenSSL is used in web servers, mail servers, VPNs, and many other > places. > > Writeup: Heartbleed: Serious OpenSSL zero day vulnerability > revealed > http://www.zdnet.com/heartbleed-serious-openssl-zero-day-vulnerability-reve… > > Technical details: Heartbleed Bug http://heartbleed.com/ > > OpenSSL versions affected (from link just above): OpenSSL 1.0.1 > through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT > vulnerable (released today, April 7, 2014) OpenSSL 1.0.0 branch is > NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable > - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNDg9gACgkQKJasdVTchbIrAAD9HzKaElH1Tk0oIomAOoSOvfJf 3Dvt4QB54os4/yewQQ8A/0dhFZ/YuEdA81dkNfR9KIf1ZF72CyslSPxPvkDcTz5e =aAzE -----END PGP SIGNATURE-----

24 35

Re: Yahoo DMARC breakage
by Larry Sheldon 09 Apr '14

09 Apr '14

On 4/9/2014 5:11 PM, bmanning(a)vacation.karoshi.com wrote: > On Wed, Apr 09, 2014 at 05:49:27PM -0400, Jeff Kell wrote: >> >> The most "sane" out-of-mind response should only be sent *if* the >> out-of-mind person is named explicitly as a recipient in the RFC822 >> header. Anything To: somelist@somehost does not qualify :) >> >> Jeff > > and just how is an algorithm supposed to detect that > <jeff-kell(a)utc.edu> is a single human and not a list? It is really too bad that there is not place to put a "precedence" that the software could key on--with values like "bulk" or "junk" or "list". -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

3 2

Re: Yahoo DMARC breakage
by Larry Sheldon 09 Apr '14

09 Apr '14

On 4/9/2014 7:02 PM, Jeff Kell wrote: > On 4/9/2014 7:22 PM, Larry Sheldon wrote: >> On 4/9/2014 5:11 PM, bmanning(a)vacation.karoshi.com wrote: >>> On Wed, Apr 09, 2014 at 05:49:27PM -0400, Jeff Kell wrote: >>>> >>>> The most "sane" out-of-mind response should only be sent *if* the >>>> out-of-mind person is named explicitly as a recipient in the RFC822 >>>> header. Anything To: somelist@somehost does not qualify :) >>>> >>>> Jeff >>> >>> and just how is an algorithm supposed to detect that >>> <jeff-kell(a)utc.edu> is a single human and not a list? >> >> It is really too bad that there is not place to put a "precedence" >> that the software could key on--with values like "bulk" or "junk" or >> "list". > > Headers of your message include: > >> Precedence: list [snip] I knew that. > Proper mail clients can provide "list links" based on the List- headers, > but few if any actually do. > > So take your pick, but my point remains, it still retains: > >> Date: Wed, 9 Apr 2014 18:22:51 -0500 >> From: Larry Sheldon <LarrySheldon(a)cox.net> >> Organization: Maybe tomorrow >> User-Agent: Mozilla/5.0 (Windows NT 5.1; >> rv:24.0) Gecko/20100101 Thunderbird/24.4.0 >> To: <nanog(a)nanog.org> >> Subject: Re: Yahoo DMARC breakage > > And I'm nowhere mentioned. I only appear in the "envelope RCPT TO:<> > RFC821 header", nowhere in the RFC822 header. > > It's not rocket science if you have headers available (which even > Outlook can see, although you have to jump through a few hoops to see them). My point is, and was only that the ID10t's robot-responder needs only two rules (one of which is sortakinda off topic in a muchmorphed OT threadlet) are: If the Precedence is "list", "junk", or "bulk" DO NOTHING, else, if the address to which the proposed babblegram is to be sent has received a babblegram from us since the controlling file was created DO NOTHING, else, BABBLEON. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0

real-world data about fragmentation
by Joe Abley 09 Apr '14

09 Apr '14

Hi all, It's common wisdom that a datagram that needs to be fragmented between endpoints (because it is bigger than the path MTU) will demonstrate less reliable delivery and reassembly than a datagram that doesn't need to be fragmented, because math, firewall, other, take your pick. Is anybody aware of any wide-scale studies that examine the probability of fragmentation of datagrams of different sizes? For example, I could reasonable expect an IPv4 packet of 576 bytes not to be fragmented very often (to choose a size not at random). The probability of a 10,000 octet IPv4 packet getting fragmented seems likely to be 100%, if we're talking about arbitrary paths across the Internet. What does the curve look like between 576 bytes and 10,000 bytes? I might expect exciting curve action around 1500 bytes (because ethernet), 1492 (PPPoE), 1480 (GRE), etc. But I'm interested in actual data. Anybody have any pointers? IPv4 and IPv6 are both interesting. Joe

5 4

any network folks from github.com here?
by Dave Curado 08 Apr '14

08 Apr '14

Please contact me off list? Thank you.

1 0

[NANOG-announce] NANOG on THE ROAD - LA - May 20, 2014
by Betty Burke <betty＠nanog.org> 08 Apr '14

08 Apr '14

The NANOG on the Road series will be coming to Los Angeles<https://www.nanog.org/meetings/road3/home>on May 20, 2014. Hosted by NANOG in partnership with Los Nettos at the USC campus, the program will include research and education presentations along with relevant NANOG meeting content. Topics to include security, IPv6, research and commercial network differences, along with network tools discussion. The meeting will be held at the Radisson Hotel Los Angeles- Midtown<https://www.nanog.org/meetings/road3/home/hotel>@ USC on Tuesday, May 20, 2014. Registration is required, however there is no fee to attend. Please visit the NOTR website and register today<https://www.nanog.org/meetings/road3/home/registration> . The morning will include featured speakers. Lunch will be provided, followed by an afternoon of NANOG presentations. The day will conclude with a graduate student poster session during the Closing Reception. Please pass along this information to those who may not be able to attend a full NANOG meeting, and wish to learn more about NANOG and the topics discussed. Sincerely, Betty on behalf of the NOTR Programming Committee -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 _______________________________________________ NANOG-announce mailing list NANOG-announce(a)mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

web.de security contact
by Ruben Rögels 08 Apr '14

08 Apr '14

Hi, someone knowing a security contact for web.de, please contact me off list. Thanks! Regards, Ruben

1 0