- NZNOG - lists.nznog.org

Snapchat question
by Tony Wicks 10 Apr '14

10 Apr '14

Hi all, we have had some users say they intermittently can't use this application. After downloading this app (and deciding it should go into the why the hell was that ever invented pile) it seems a bit difficult to fault find any issues. Does anyone know how this thing communicates ? Is it normally intermitttant ? Thanks all

2 1

Heartbleed OpenSSL Vulnerability
by Dean Pemberton 10 Apr '14

10 Apr '14

Hi All, NZITF (in conjunction with InternetNZ) have been endeavouring to raise awareness about this issue. We have compiled some information on our website, which may be of use to you and/or your clients. Please feel free to share this link as widely as you see fit. http://www.nzitf.org.nz/news.html The NZITF is treating this as an ongoing security issue with significant implications. As a result we are intending to monitor this situation and update our advice as required. We have tree basic messages for website owners: 1. Establish if your site's servers are vulnerable. 2. Patch the vulnerable servers. 3. Revoke/reissue keys and certificates. If you are vulnerable it is imperative that you do steps 2 AND 3. Not one, but both. You should also be encouraged to discuss this very important issue with your regular security consultants. If you have feedback or information please feel free to contact me so we can include it in the advice on the website. Regards, Dean

17 19

Re: [nznog] [PAG] Message concerning Certs
by Ewen McNeill 08 Apr '14

08 Apr '14

On 2014-04-09 22:40 , Dean Pemberton wrote: > And from the same twitter thread saying it was unlikely... > [can extract private key on vulnerable FreeBSD if it is first request] "first request after restart" is a special case too ("possible, but unlikely"). The same thread/poster also says: "[...] Does not work on Debian. [...]" (also https://twitter.com/1njected/status/453781230593769472) which implies (as noted in that thread) something about the FreeBSD malloc patterns makes it more likely/possible than Debian's malloc. Those (who were) running a vulnerable OpenSSL on FreeBSD may wish to take that into account in their assessment :-) The main thing which is certain is that it's going to be a well studied/probed bug. Ewen

1 0

Re: [nznog] Message concerning Certs
by Michael Sutton 08 Apr '14

08 Apr '14

The exploit has been rumoured for some time. Does it matter who the primary actors are. They have all the private keys by now and g's/s-view/wifi/scan has the other half; so that deals with the white-hats. All historical data dumps can be retrospectively analysed at any time for eternity at ones leisure. As for the code which is in the wild I enclose a graph of 3 hours traffic from the http://filippo.io/Heartbleed/# site which is using something like 31 machines showing ~2000 sites being tested every minute, ~360,000 over 3hours and that is from a public site; an unknown% will be blackhats. This is catastrophic and you should believe it's not only our guys that have it but every other *worth their salt. InternetNZ almost became a CA in ~2004. We could have fixed this hole now for .nz with a working revocation system. Then INZ had a new team on board and it was .... The ironical blowback is that our "own" might be just as threatened by this. We just have to get on and deal with this as a priority tomorrow and for the next decade. I am a patriot by the way, Yours Michael amI#6 -----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Don Stokes Sent: Wednesday, 9 April 2014 8:37 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Message concerning Certs Is there any indication out there as to how widely this bug has been exploited? I.e. if you've patched servers in the last 24 hours, how likely is it that your certificate keys have been leaked over the last months / year? Not looking for accurate numbers, just roughly where on the scale of, "this is possible but no reports of actual use" to "all the black hats have been doing this for years so you're screwed unless you re-issue and revoke your certs" the exploit lies. Also, last time I worried about this, certificate revocation was, uh, largely unimplemented. That was a while ago. How well does it work now? And with potentially large numbers of revoked certs? -- don _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Callplus postmaster contact
by Jean-Francois Pirus 08 Apr '14

08 Apr '14

Can a Callplus/Slingshot/Tranzpeer postmaster contact me. We're having issue with forward emails for our clients to Callplus addresses, the clients are complaining mail is being dropped. PS: I have tried contacting postmaster(a)callplus.net.nz and this is what I got after 4 days: > This message was created automatically by mail delivery software. > A message that you sent has not yet been delivered to one or more of its > recipients after more than 72 hours on the queue on mxdsrv1.tranzpeer.net. > > The message identifier is: 1WTNur-0005YH-G5 > The subject of the message is: Mail server issue: > The date of the message is: Fri, 28 Mar 2014 16:47:21 +1300 > > The address to which the message has not yet been delivered is: > > sysops(a)noc.tranzpeer.net > (generated from postmaster(a)callplus.net.nz) > Delay reason: SMTP error from remote mail server after RCPT TO:<sysops(a)noc.tranzpeer.net>: > host 192.168.69.1 [192.168.69.1]: 451 4.3.2 Please try again later Our logs are full of the following: Apr 8 12:41:40 tiny postfix/smtp[14531]: 4FE0DDFA92F: host mxi1.callplus.net.nz[202.180.66.203] refused to talk to me: 421 4.7.0 Not allowed. Apr 8 12:41:40 tiny postfix/smtp[14532]: B7E63DFA8DC: host mxi1.callplus.net.nz[202.180.66.203] refused to talk to me: 421 4.7.0 Not allowed. Apr 8 12:41:40 tiny postfix/smtp[14537]: 9B205DFA940: host mxi1.callplus.net.nz[202.180.66.203] refused to talk to me: 421 4.7.0 Not allowed. Apr 8 12:41:40 tiny postfix/smtp[14537]: 9B205DFA940: to=<BLAH(a)slingshot.co.nz>, relay=mxi2.callplus.net.nz[202.180.66.204]:25, delay=1347, delays=1346/0.58/0.06/0, dsn=4.7.0, status=deferred (host mxi2.callplus.net.nz[202.180.66.204] refused to talk to me: 421 4.7.0 Not allowed.) Apr 8 12:41:52 tiny postfix/smtp[14530]: 4B069DFA8E2: host mxi1.callplus.net.nz[202.180.66.203] said: 451 4.3.2 Please try again later (in reply to RCPT TO command) Apr 8 12:41:52 tiny postfix/smtp[14531]: 4FE0DDFA92F: to=<BLAH(a)callplus.net.nz>, relay=mxi2.callplus.net.nz[202.180.66.204]:25, delay=1391, delays=1379/0.25/0.1/12, dsn=4.3.2, status=deferred (host mxi2.callplus.net.nz[202.180.66.204] said: 451 4.3.2 Please try again later (in reply to RCPT TO command)) Apr 8 12:41:52 tiny postfix/smtp[14532]: B7E63DFA8DC: to=<BLAH(a)callplus.net.nz>, relay=mxi2.callplus.net.nz[202.180.66.204]:25, delay=1866, delays=1853/0.29/0.1/12, dsn=4.3.2, status=deferred (host mxi2.callplus.net.nz[202.180.66.204] said: 451 4.3.2 Please try again later (in reply to RCPT TO command)) Apr 8 12:42:04 tiny postfix/smtp[14530]: 4B069DFA8E2: to=<BLAH(a)callplus.net.nz>, relay=mxi2.callplus.net.nz[202.180.66.204]:25, delay=1790, delays=1766/0.25/12/12, dsn=4.3.2, status=deferred (host mxi2.callplus.net.nz[202.180.66.204] said: 451 4.3.2 Please try again later (in reply to RCPT TO command)) Apr 8 12:56:58 tiny postfix/smtp[17081]: E3622DFA91C: host mxi1.callplus.net.nz[202.180.66.203] refused to talk to me: 421 4.7.0 Not allowed. Apr 8 12:56:59 tiny postfix/smtp[17081]: E3622DFA91C: to=<BLAH(a)slingshot.co.nz>, relay=mxi2.callplus.net.nz[202.180.66.204]:25, delay=0.07, delays=0.01/0/0.05/0, dsn=4.7.0, status=deferred (host mxi2.callplus.net.nz[202.180.66.204] refused to talk to me: 421 4.7.0 Not allowed.) Apr 8 13:00:24 tiny postfix/smtp[17832]: 061A4DFA8F6: host mxi1.callplus.net.nz[202.180.66.203] said: 451 4.3.2 Please try again later (in reply to RCPT TO command) Apr 8 13:00:36 tiny postfix/smtp[17832]: 061A4DFA8F6: to=<BLAH(a)callplus.net.nz>, relay=mxi2.callplus.net.nz[202.180.66.204]:25, delay=24, delays=0.02/0.01/12/12, dsn=4.3.2, status=deferred (host mxi2.callplus.net.nz[202.180.66.204] said: 451 4.3.2 Please try again later (in reply to RCPT TO command)) Apr 8 13:01:22 tiny postfix/smtp[17829]: D7FB0DFA91F: host mxi1.callplus.net.nz[202.180.66.203] said: 451 4.3.2 Please try again later (in reply to RCPT TO command) Apr 8 13:01:34 tiny postfix/smtp[17829]: D7FB0DFA91F: to=<BLAH(a)slingshot.co.nz>, relay=mxi2.callplus.net.nz[202.180.66.204]:25, delay=25, delays=0.64/0.04/12/12, dsn=4.3.2, status=deferred (host mxi2.callplus.net.nz[202.180.66.204] said: 451 4.3.2 Please try again later (in reply to RCPT TO command)) Apr 8 13:02:06 tiny postfix/smtp[17851]: 4F55DDFA934: host mxi1.callplus.net.nz[202.180.66.203] said: 451 4.3.2 Please try again later (in reply to RCPT TO command) Apr 8 13:02:15 tiny postfix/smtp[17832]: 1ABBEDFA0E0: host mxi1.callplus.net.nz[202.180.66.203] said: 451 4.3.2 Please try again later (in reply to RCPT TO command) Apr 8 13:02:18 tiny postfix/smtp[17851]: 4F55DDFA934: to=<BLAH(a)slingshot.co.nz>, relay=mxi2.callplus.net.nz[202.180.66.204]:25, delay=24, delays=0.02/0/12/12, dsn=4.3.2, status=deferred (host mxi2.callplus.net.nz[202.180.66.204] said: 451 4.3.2 Please try again later (in reply to RCPT TO command)) Apr 8 13:02:27 tiny postfix/smtp[17832]: 1ABBEDFA0E0: to=<BLAH(a)callplus.net.nz>, relay=mxi2.callplus.net.nz[202.180.66.204]:25, delay=24, delays=0.01/0.01/12/12, dsn=4.3.2, status=deferred (host mxi2.callplus.net.nz[202.180.66.204] said: 451 4.3.2 Please try again later (in reply to RCPT TO command)) Apr 8 13:15:04 tiny postfix/smtp[20825]: 4D5B9DFA923: host mxi1.callplus.net.nz[202.180.66.203] said: 451 4.3.2 Please try again later (in reply to RCPT TO command) Apr 8 13:15:16 tiny postfix/smtp[20825]: 4D5B9DFA923: to=<BLAH(a)callplus.net.nz>, relay=mxi2.callplus.net.nz[202.180.66.204]:25, delay=24, delays=0.07/0/12/12, dsn=4.3.2, status=deferred (host mxi2.callplus.net.nz[202.180.66.204] said: 451 4.3.2 Please try again later (in reply to RCPT TO command)) Apr 8 13:16:39 tiny postfix/smtp[21318]: 377AFDFA8DC: host mxi1.callplus.net.nz[202.180.66.203] said: 451 4.3.2 Please try again later (in reply to RCPT TO command) Apr 8 13:16:51 tiny postfix/smtp[21318]: 377AFDFA8DC: to=<BLAH(a)callplus.net.nz>, relay=mxi2.callplus.net.nz[202.180.66.204]:25, delay=24, delays=0.01/0/12/12, dsn=4.3.2, status=deferred (host mxi2.callplus.net.nz[202.180.66.204] said: 451 4.3.2 Please try again later (in reply to RCPT TO command)) Apr 8 13:24:14 tiny postfix/smtp[21330]: 8FF10DFA8E2: host mxi1.callplus.net.nz[202.180.66.203] said: 451 4.3.2 Please try again later (in reply to RCPT TO command) Apr 8 13:31:51 tiny postfix/smtp[24414]: 1ABBEDFA0E0: host mxi1.callplus.net.nz[202.180.66.203] said: 451 4.3.2 Please try again later (in reply to RCPT TO command) etc... Thanks. -- Jean-Francois Pirus | Technical Manager francois(a)clearfield.com | Mob +64 21 640 779 | DDI +64 9 282 3401 Clearfield Software Ltd | Ph +64 9 358 2081 | www.clearfield.com

7 7

ICONZ-Webvisions (NZ) to cease operating externally-reachable NTP servers
by Mark Foster 07 Apr '14

07 Apr '14

Hiya folks - again... ! :-) ICONZ-Webvisions (the entity formerly known simply as ICONZ in NZ) are making changes to their NTP server arrangements on the evening morning of 10 April (so, overnight tomorrow night). The details of the changes being made can be viewed at: http://iconz-webvisions.com/en/support/outages/new-zealand In short, if you have been using 'ntp.iconz.net' or 'ntp.iconz.co.nz' by DNS name, you'll have already seen a change; this now is CNAME'd to s2.ntp.net.nz (which happens to sit in our DC)[1]. Anyone who has been using any of our (very long lived) NTP servers by IP address, these IP's will stop responding to NTP queries from outside of our network, in the wee hours of 10 April. Much like the DNS changes recently made, this is most likely to be noticed by people who've been using these IP's for historical or habitual reasons. Customers with concerns about this change are invited to contact our Customer Care team on 0800 843 638 or via support.nz(a)iconz-webvisions.com<mailto:support.nz(a)iconz-webvisions.com>. Non-customers, should probably change their NTP timesource to a publically available resource; I do very much value and recommend the services offered by NZRS, with details at www.ntp.net.nz<http://www.ntp.net.nz>. Regards Mark. [1] This was done in conjunction with NZRS and mainly as an 'interim' measure. Those DNS records may be removed completely at some stage in the future. Anyone using those hostnames should move to using services such as those offered by NZRS, and bypass our DNS entries completely, as soon as possible. -- Mark Foster Technical Services Manager - Australia & New Zealand [iconz-webvisions-logo-png] www.iconz-webvisions.com<http://www.iconz-webvisions.com/> ICONZ-Webvisions, ICONZ House, 60 Airedale Street, Auckland 1010, New Zealand

1 1

OpenSSL vulnerability
by Dean Pemberton 07 Apr '14

07 Apr '14

Here's one to keep an eye on. Seems to be getting a bit of attention. http://www.kb.cert.org/vuls/id/720951 http://heartbleed.com/ Work with your vendors to confirm if you're at risk.

1 0

tk[1-4].ihug.co.nz
by Joel van Velden 07 Apr '14

07 Apr '14

Hi List After Mark's announcement about removal of Iconz public ntp I thought I should check my ntpd configs. Can anyone from Vodafone give an update on tk[1-4].ihug.co.nz? After many mergers and acquisitions it occurs to me that perhaps these could be dusty machines under someone's desk that could disappear one day without announcement? Any official comment? Is there an official webpage about them? Regards, Joel van Velden

1 0

Software Defined Networking (SDN) Presentation
by Jay Best 07 Apr '14

07 Apr '14

Hey is anyone else going to this? I haven't seen many of you guys from NZNOG in ages, so would be good to catchup for old times sake! Cheers, J *Software Defined Networking (SDN) Presentation* Auckland Tourism, Events and Economic Development and Massey University invite you to an informative and engaging presentation by world leading New Zealand expert Mr. Josh Bailey from Google around SDN research in New Zealand and beyond. SDN has been generating a lot of press in the network industry and research worlds. While a community has arisen to energetically debate what SDN is? There are concrete research efforts and deployed systems exploring the implications of separating control and data planes. These include Google's B4 network (which connects Google data centers together) and uses OpenFlow and CityLink's efforts in New Zealand to produce an SDN controlled Internet exchange. This presentation will describe some recent research both here in NZ and in the US, including work at REANNZ and Victoria University on building and deploying an open source SDN controller and experiments including RPKI. Date: Monday, 14th April 2014 Time: 4.30pm - 6.30pm Venue: Room OR 4, Building 102 Massey Albany Campus Gate 4 Eastbourne Road, Old Albany Highway. Cost: Complimentary RSVP: Shona Alo (s.alo(a)massey.ac.nz) if you would like to attend

1 0

Bitstream 3a DHCP manipulation
by Dave Mill 07 Apr '14

07 Apr '14

Hi all I posted a few weeks ago about MAC limits on Bitstream 3a connections. This is related to that. This is a UFF Bitstream 3a connection. I've discovered that a customer's only complaint with a Bitstream 3a connection from us is that DHCP doesn't work over this. I've obtained some pcaps from both ends and I can see the following changes occurring to a DHCP Request: 1) The transaction ID is changed 2) Option 82 is added. More specifically, sub-option 1 Agent Circuit ID is present and has a valid length. sub-option 2 Agent Remote ID is present, has a length of 0 and no content which wireshark doesn't seem to like much. I've had a brief read of RFC3046 and I can't really tell if its valid to have a sub-option with a length of 0 or not. https://tools.ietf.org/html/rfc3046#page-8 I never see any DHCP ACKs coming back from the customer's DHCP server. I've had a read of some of UFF's Bitstream3a docs and can't see any mention of DHCP. I can see in one of our initial requests we had to fill out we can choose to have DHCP Relay Agent Functionality but this seems to be related to Bitstream2 only and also this defaults to be disabled. I don't know what DHCP server the customer is using right now but I hope to find this out soon. Questions for anyone with more experience in this than myself: -Can changing the DHCP Request transaction ID cause issues? -Has anyone come across DHCP servers not liking option 82 being set, or not liking sub-option 2 having a 0 length? -Has anyone successfully used DHCP across a Bitstream3a connection? How about a UFF Bitstream3a connection? -Am I missing anything obvious? Obviously I might end up talking to UFF over this but I just want to see what others on the list know before doing so. Again, I don't really want to debate the wisdom of plugging two LANs in over a Bitstream3a connection. Cheers Dave

9 12