March 2018 - Test - lists.nanog.org

RE: Comcast NOC Contact
by Robert Webb 02 Mar '18

02 Mar '18

Thanks to all off list replies. Comcast rep was able to help out getting info over to the NOC. -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Robert Webb Sent: Friday, March 2, 2018 10:53 AM To: nanog(a)nanog.org Subject: Comcast NOC Contact I know Virginia is having wind issues today. But can anyone from Comcast comment on intermittent routing issues between Charlottesville, VA and Ashburn, VA on their backbone? Issue appears to be between 69.139.206.9 ae-45-ar02.charlvilleco.va.ibone.comcast.net and 68.86.91.53 be-21508-cr02.ashburn.va.ibone.comcast.net Off list is fine.

1 0

Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks
by Stephen Satchell 02 Mar '18

02 Mar '18

Testing on a recently-load VM of CentOS 7.3: [root@localhost odd]# netstat -tan | grep 11211 [root@localhost odd]# netstat -uan | grep 11211 [root@localhost odd]# yum install memcached [root@localhost odd]# systemctl start memcached.service [root@localhost odd]# netstat -tan | grep 11211 tcp 0 0 0.0.0.0:11211 0.0.0.0:* LISTEN tcp6 0 0 :::11211 :::* LISTEN [root@localhost odd]# netstat -uan | grep 11211 udp 0 0 0.0.0.0:11211 0.0.0.0:* udp6 0 0 :::11211 :::* Since CentOS is supposed to be a near bit-by-bit copy of Red Hat Enterprise, this shows that when one loads memcached without modifying the configuration, plus expose 11211/udp to the world, one is now part of the problem. It also suggests that other near-clones of RHEL may also exhibit the problem. So I pulled the memcached repository from GitHub, and looked through the commits. NOTHING about updates to prevent DDoS. So I started looking around for the config file in the maintainer GIT project. Here is what I found: > # These defaults will be used by every memcached instance, unless overridden > # by values in /etc/sysconfig/memcached.<port> > USER="nobody" > MAXCONN="1024" > CACHESIZE="64" > OPTIONS="" > > # The PORT variable will only be used by memcached.service, not by > # memcached@xxxxx services, which will use the xxxxx > PORT="11211" Here is what CentOS has: > PORT="11211" > USER="memcached" > MAXCONN="1024" > CACHESIZE="64" > OPTIONS="" What's missing from both of these system configuration files? OPTIONS="-U 0" From the memcached man page: > -U <num> > Listen on UDP port <num>, the default is port 11211, 0 is off. So this answers the question about how anyone loading memcached fresh from a distribution can be a major player in the DDoS game. Now, in a lame defense of Red Hat, when one turns on the firewalld daemon, that daemon implements a mostly-closed access policy. "memcached" is not listed in the named services. Furthermore, looking at the output of 'iptables -vnL' I saw no way that a 11211/udp packet would make its way through the firewall. The policy of "defense in depth" would argue that setting the default to disable 11211/udp is still the right thing(r) to do.

1 0

Comcast NOC Contact
by Robert Webb 02 Mar '18

02 Mar '18

I know Virginia is having wind issues today. But can anyone from Comcast comment on intermittent routing issues between Charlottesville, VA and Ashburn, VA on their backbone? Issue appears to be between 69.139.206.9 ae-45-ar02.charlvilleco.va.ibone.comcast.net and 68.86.91.53 be-21508-cr02.ashburn.va.ibone.comcast.net Off list is fine.

1 0

[NANOG-announce] Program Committee appointments
by Ryan Donnelly 01 Mar '18

01 Mar '18

*Greetings, fellow NANOG enthusiasts,I’m pleased to announce that the board has appointed 11 individuals to the Program Committee. As always, making these appointments is an exercise in difficult choices; and these appointments were made especially challenging by this cycle’s 18 highly-qualified applicants.We are, at our core, a volunteer organization. It is through the interest and commitment of volunteers like these that we are able to deliver the exceptional program quality expected by our members, attendees and sponsors. We’d like to thank each of the 18 individuals that applied, and for those not selected, we would be delighted to entertain your candidacy during the next appointment cycle.The 11 members appointed to the Program Committee are:Vincent Celindro, Michaela Clifford, Michael Costello, Philippe Couture, Tom Kacprzynski, Ognian Mitev, Chris Pennisi, Steven Schechter, Benson Schliesser, Edward Winstead, Chris WoodfieldPlease join me in congratulating them.We’d also like to thank and recognize the contributions of Kevin Blumberg, Anna Claiborne, Allison Feese-Strickland, Steve Plote, Dani Roisman, Michael K. Smith, and Jesse Sowell for their service on the Program Committee.In the coming weeks, the new Program Committee will hold its first meeting and select a chair and a vice chair.I know I speak for the rest of the board when I say that we can’t wait to experience the output of our new PC in Denver for NANOG 73.See you in June!Best Regards,--ryan(for the NANOG Board of Directors)* _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

Removing the four stale TAL from the APNIC RPKI validation set.
by George Michaelson 28 Feb '18

28 Feb '18

Updating RPKI trust anchor configuration ------------------------------------------------------- APNIC has completed the process of transitioning from its previous Resource Public Key Infrastructure (RPKI) trust anchor arrangement to a new single trust anchor configuration. Each RIR will publish an 'all resources' global trust anchor, under which its own regional resources (IP addresses and ASNs) will be certified. APNICs trust anchor is one of the previous five, which has been retained as the sole trust anchor over all APNIC resource certificate products. If you are using relying-party software, such as the Dragon Research Labs RPKI Toolkit, RPSTIR or the RIPE NCC’s RPKI Validator, you are advised to update your software’s configuration to use only the current APNIC trust anchor, rather than the set of five APNIC trust anchors that were previously in use. The update is to remove four of the five: One has been retained as the current live Trust Anchor. Note: this update is not critical. However, if it is not done, the software will log or report warnings about being unable to retrieve the trust anchors that are no longer being used. All resources now validate under the single active trust anchor and no orphan products are valid under the other prior trust anchors. The current APNIC TAL is as follows: ------ rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9RWSL61YAAYumEiU8z8 qH2ETVIL01ilxZlzIL9JYSORMN5Cmtf8V2JblIealSqgOTGjvSjEsiV73s67zYQI 7C/iSOb96uf3/s86NqbxDiFQGN8qG7RNcdgVuUlAidl8WxvLNI8VhqbAB5uSg/Mr LeSOvXRja041VptAxIhcGzDMvlAJRwkrYK/Mo8P4E2rSQgwqCgae0ebY1CsJ3Cjf i67C1nw7oXqJJovvXJ4apGmEv8az23OLC6Ki54Ul/E6xk227BFttqFV3YMtKx42H cCcDVZZy01n7JjzvO8ccaXmHIgR7utnqhBRNNq5Xc5ZhbkrUsNtiJmrZzVlgU6Ou 0wIDAQAB ------ Configuring Relying Party Software ----------------------------------------------- RIPE NCC RPKI Validator: If you upgrade to RIPE validator rpki-validator-app-2.24 the correct Trust Anchor is configured. No further work is required. Dragon Research Labs Rcynic Validator: If you run rcynic, you need to remove all the TAL, TA or CER entries in rcynic.conf except ones which point to apnic-rpki-root-iana-origin.cer or the related TAL. If you use the trusted-certs/ directory, simply remove the four files which are named for the non-APNIC RIR as follows: cd /etc/trust-anchors # or wherever you place the TAL files rm apnic-rpki-root-ripe-origin.tal rm apnic-rpki-root-arin-origin.tal rm apnic-rpki-root-lacnic-origin.tal rm apnic-rpki-root-afrinic-origin.tal RPSTIR To modify an installed RPSTIR system, locate the /usr/local/etc/rpstir directory and remove all but the current live APNIC TAL. More information is in the attached PDF describing how to update the trust anchor configuration in these three popular relying-partner software systems. -George

2 1