[nsp-sec] Question for the team - who would be willing to participate in a "exercise"
Smith, Donald
Donald.Smith at CenturyLink.com
Tue Oct 31 15:56:58 EDT 2017
> ________________________________________
> From: nsp-security [nsp-security-bounces at puck.nether.net] on behalf of Alfredo Sola [alfredo at solucionesdinamicas.net]
> Sent: Monday, October 30, 2017 6:07 AM
> To: Barry Greene
> Cc: Nsp-Security List
> Subject: Re: [nsp-sec] Question for the team - who would be willing to participate in a "exercise"
>
> ----------- nsp-security Confidential --------
>
>
> > We can build up to this list. Start with the real simple, then work up to more complicated response actions.
>
> I will add to the lists:
>
> - Blackhole IP by region. Useful for many instances where the legitimate traffic is mostly from a region (like a country or group of countries). Also in attacks where if sources within a region or two are blackholed, the >services can survive while still providing services to their legitimate users. Initially regions could be as large as continents, and be refined later on to countries.
Destination Black Hole Filter? (DBHF) or SBHF?
I can see where this could be used by countries for evil/censorship. (Pakistan youtube...)
>
> I submitted this to Team Cymru’s OTRS (which is a fantastic service BTW).
OTRS? Do you mean UTRS?
>
> Many of these can be transported using RFC5575 so while they are not going to fix DOS, there could be room for some real improvements that folk can actually implement.
>
> Of course, all of this requires that more network operators actually use the resources that already exist. For example, UTRS has 475 participants, out of almost 60k ASN in the routing table. Which makes it the more >impressive the fact that it actually works.
We did a lot of reports for UTRS, trying to justify our using it. We didn't justify it. I only saw one other network operator do reports and those also didn't justify the effort. Most attacks that would have been blocked by us weren't very large on our network. The BGP isn't production quality.
One day I saw a few HUNDRED of the same announcement. That got fixed but it took a day or two. When JTK ran it, we were serious about trying to use it. But after he left it is managed by a group of people, that told me "this is not a production service" during an unplanned outage.
That is fine but I can't run my network using services that aren't production quality...
I have worked with cymru for many years, I support their efforts, this one I would say was a failure :(
>
> ————————————————8<————————————————
>
> - for a list of 1M attacking IPs, please prevent them from sending outbound traffic from your networks
No, unsupported by many of the routers.
> - for a packet characteristic (eg, udp/80 packet, or syn packet > 512 bytes, etc), please prevent it from reaching my network
This is possible, but probably to a /32 or /25 probably not a large cidr block (ok there are ways to do larger blocks but you have to prevent leaks.
> - (using netflow) trace the source of spoofed traffic and make it stop (BCP38, ACLing your customer, etc)
This is not trivial, and the source will almost always be compromised systems, notifying them may help but you really need to trace through all the stepping stones, meaning a lot of coordination between ISPs.
So I trace it back to a set of ips, hand off that set of ips and some talk talkers with the hopes that it means we found the c2s, then someone traces the c2s top talkers, ... guessing 3 or 10 layers deep stepping stones to find the bad guys.
> - de-peer a rogue ASN which is conducting BGP hijacks, sending spoofed attack traffic, etc (including the case where the rogue network is a well-known major network which is misbehaving and won't respond to
> complaints)
There are a lot of lists of "bad" ISPs/ASNs, which one is the trusted one. Which one would you suggest we all get behind or ???
Most rogue ASNs are just poorly funded and poorly run (not well staffed). Their also cheep (not well staffed). I don't know of many that are really EVIL :)
>
>
> - SITREP - a reflection attack is hitting a several WHO sites used for pandemic management. At this time, there is an emerging situation in Asia with a new strain of flu. We need to get these site back only. There look to > be 6 IPs which are the key C&C/Stressors behind these WHO attacks.
> - Ask - Please deploy a RTBH for these 6 sites for one hour, then remove. That would provide enough time to deploy additional capacity. The source ASN for the stressor/C&C may or may not be able to help.
1 DBHF or 10000 SBHF? BTW all BHFing is Remote Triggered so RT no longer really adds to the TLA (FLA)
> - Ask - Respond with an ACK to the Trust Group when the RTBH is deployed. Respond with a ACK to this Trust Group.
How much are you dropping?
How much is being dropped by all?
Do you have legal authority to ask me to drop this traffic?
I have a huge list of things that have to be worked out to do DDoS peering, that I am in the process of changing into a RFC to help others do DDoS peering.
That is based on inter-ISP flowspec, but can/could be used for DBHFing too.
I have an example DDoS peering contract.
I believe at least initially bi-lateral DDoS peering is the way to go but open to other suggestions.
>
> ————————————————8<————————————————
>
> --
> Alfredo Sola
> https://www.tecnocratica.net
>
>
>
>
> _______________________________________________
> nsp-security mailing list
> nsp-security at puck.nether.net
> https://puck.nether.net/mailman/listinfo/nsp-security
>
> Please do not Forward, CC, or BCC this E-mail outside of the nsp-security
> community. Confidentiality is essential for effective Internet security counter-measures.
> _______________________________________________
>
>
if (initial_ttl!=255) then (rfc5082_compliant==0)
Donald.Smith at centurylink.com
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
More information about the nsp-security
mailing list