Saw that TIFKAT suggests that customers manually change their DNS settings to sort out website access issues: http://helpbusiness.spark.co.nz/app/answers/detail/a_id/3701/related/1 What actually happened? Seen suggestions that it was a DNS amplification DDoS that might have been related to Spark customers clicking on phishing messages that had them download some form of malware that compromised their computers. Spark said: http://www.spark.co.nz/help/servicealert/mobileservicealert/ “The root cause is likely to be a handful of customers on our network whose computers are affected by malware, generating high levels of traffic destined for overseas sites.” Looks like it’s an ongoing issue too, as per the Spark service alerts. Has anyone seen any more detail on the incident? If this isn’t super operational, please email me off-list. Thanks -- Juha Saarinen twitter: juhasaarinen
Paranoid me thinks the timing of LightBox's entry and this are related: https://www.youtube.com/watch?v=zOu8b23_h8k&list=PLqpZC2iaEqGs8HGudtGjX2N6iU4Qo4Z66 Cheers... Clark [Don's tinfoil hat] [beer]
It's alleged to be a DNS amplification attack, of which the US-CERT says at https://www.us-cert.gov/ncas/alerts/TA13-088A : "The primary technique consists of an attacker sending a DNS name lookup request to an open DNS server with the source address spoofed to be the target’s address. " The Spark DNS servers do not appear to be open, so the attack can only be coming from their own customers. Therefore, can someone comment on whether Spark has BCP38 in place, since ingress filtering is the main defence against such attacks? Regards Brian Carpenter On 07/09/2014 10:29, Juha Saarinen wrote:
Saw that TIFKAT suggests that customers manually change their DNS settings to sort out website access issues:
http://helpbusiness.spark.co.nz/app/answers/detail/a_id/3701/related/1
What actually happened? Seen suggestions that it was a DNS amplification DDoS that might have been related to Spark customers clicking on phishing messages that had them download some form of malware that compromised their computers.
Spark said:
http://www.spark.co.nz/help/servicealert/mobileservicealert/
“The root cause is likely to be a handful of customers on our network whose computers are affected by malware, generating high levels of traffic destined for overseas sites.”
Looks like it’s an ongoing issue too, as per the Spark service alerts.
Has anyone seen any more detail on the incident? If this isn’t super operational, please email me off-list.
Thanks
------------------------------------------------------------------------
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
On 9/6/2014 4:48 PM, Brian E Carpenter wrote:
The Spark DNS servers do not appear to be open, so the attack can only be coming from their own customers. Therefore, can someone comment on whether Spark has BCP38 in place, since ingress filtering is the main defence against such attacks?
A number of popular BNG platforms implement subscriber anti-spoofing by default; so it wouldn't surprise me if it was enabled for Spark as well. Even with BCP38 facing their own subscribers, it doesn't help protect against traffic being generated by their CPE - traffic which could be triggered by spoofed ingress traffic on the edge of the network caused by *other* operators not running BCP38 towards their subscribers; or caused by other mechanisms to trigger the traffic from the CPE.
On Sat, 2014-09-06 at 18:05 -0700, Alastair Johnson wrote:
On 9/6/2014 4:48 PM, Brian E Carpenter wrote:
The Spark DNS servers do not appear to be open, so the attack can only be coming from their own customers. Therefore, can someone comment on whether Spark has BCP38 in place, since ingress filtering is the main defence against such attacks?
A number of popular BNG platforms implement subscriber anti-spoofing by default; so it wouldn't surprise me if it was enabled for Spark as well.
Even with BCP38 facing their own subscribers, it doesn't help protect against traffic being generated by their CPE - traffic which could be triggered by spoofed ingress traffic on the edge of the network caused by *other* operators not running BCP38 towards their subscribers; or caused by other mechanisms to trigger the traffic from the CPE.
So is it just the relative size of my ISP ( voda ) that's kept it running?? Steve -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz Linkedin: http://www.linkedin.com/in/steveholdoway Skype: sholdowa
participants (5)
-
Alastair Johnson -
Brian E Carpenter -
Clark Mills -
Juha Saarinen -
Steve Holdoway