[NCAP-Discuss] why enhanced controlled interruption - not legal

Fri Feb 25 16:14:54 UTC 2022

Right. The most "conservative" way to do this would be:

TCP except 80 and 443: Immediately (on SYN) return RST and log sending IP, source, and destination ports. This should be safe is all cases.

TCP 80/443: Full HTTP/S server interaction (to get the notification quality). But you have no control over what is sent, even if you drop it on the floor it is still sent.

UDP is a problem. Most "conservative" thing to do is ignore/drop everything and log connections. But you have no control over what was sent, even if you drop it on the floor. Extremely common protocols like SIP send sensitive information (including possibly human names) in these initial packets. ICMP unreachable doesn't help as it is mostly ignored/blocked along the way so it would not reliably prevent information from being egressed (and it's too late anyway, it happens in response after the initial packet is sent).

Biggest problem protocols are HTTP/S and all the stuff that uses HTTP/S as a wrapper (RPC, all the REST APIs folks are making-up, etc, etc, etc). WebDAV over HTTP/S (yes, HTTP no S!) is also a surprisingly common thing (reference our little bug MS15-011 thru -014). Those are the most common connections, least likely to get blocked somewhere along the way (egress filtering), and most likely to contain sensitive information that is "unblockable."

SMB/CIFS may use UDP sometimes. The initial packet (the one we're dropping - usually SMB CREATE or NEGOTIATE) may contain sensitive information (the file or pipe name being accessed remotely, machine and share names, GUIDs). Note that if SMB Signing is enabled, the SMB request is still sent in the clear, it's just signed. Doesn't help in this case.

All that being said, having personally run the largest honeypot of this type (corp.com), the most interesting data certainly comes from engaging in the protocol exchanges to some degree. That's how you tell what's really going on. If you're just logging connecting IP addresses (the most "conservative" approach) you don't really get much except a raw count and whatever you can ascertain from the IP itself. And those counts *will be gamed* if these statistics matter for applicants or other interested parties. Ditto that for HTTP/S; at the very least one would want to inspect the full URI a bit and there starts the slippery slope.

So my strongly held position holds: the cure is worse than the disease. 

Jeff

> -----Original Message-----
> From: Thomas, Matthew <mthomas at verisign.com>
> Sent: Friday, February 25, 2022 9:27 AM
> To: Jeff Schmidt <jschmidt at jasadvisors.com>; rubensk at nic.br; ncap-
> discuss at icann.org
> Subject: Re: [NCAP-Discuss] why enhanced controlled interruption - not legal
> 
> A server can be configured to have various ports open but nothing would
> actually be listening on those ports via a set of IPTABLE rules. The connection
> attempts would be logged but no data would be exchanged besides what is
> basically in the IP headers - IP address, port, and you would probably add a
> timestamp. This still enables the identification of clients and understanding of
> what services/ports they are trying to attempt to reach.
> 
> On 2/25/22, 9:51 AM, "Jeff Schmidt" <jschmidt at jasadvisors.com> wrote:
> 
>     Caution: This email originated from outside the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> 
>     Please explain specifically how the envisioned honeyport may be
> conducted as not to cause data exfiltration.
> 
>     > -----Original Message-----
>     > From: NCAP-Discuss <ncap-discuss-bounces at icann.org> On Behalf Of
>     > Thomas, Matthew via NCAP-Discuss
>     > Sent: Thursday, February 24, 2022 7:34 PM
>     > To: rubensk at nic.br; ncap-discuss at icann.org
>     > Subject: Re: [NCAP-Discuss] why enhanced controlled interruption - not
> legal
>     >
>     > Rubens,
>     >
>     > ECI can be conducted in a variety of technical ways that minimizes or
>     > eliminates the majority of data privacy concerns.  I would be careful to
> paint
>     > such broad strokes here.  Nor would I say it is not technically feasible -
> this
>     > type of analysis has been going on for the last decade via other
> operators.
>     > Can you please elaborate as to why this non-technically feasible
> (disregarding
>     > data concerns and purely on a technical point-of-view)?
>     >
>     > Matt
>     >
>     > On 2/21/22, 6:09 PM, "NCAP-Discuss on behalf of Rubens Kuhl via NCAP-
>     > Discuss" <ncap-discuss-bounces at icann.org on behalf of ncap-
>     > discuss at icann.org> wrote:
>     >
>     >
>     >     Jim,
>     >
>     >     There is one aspect of enhanced controlled interruption that is not
>     > business, privacy or liability related, which is the controlled exfiltration
> aspect
>     > of it. This is a serious information security show stopper, and one that a
>     > technically-focused group can't ignore.
>     >
>     >     But even on the non-technical feasibility, this won't be the first time
> the
>     > same idea will be suggested, so we at least need a backup plan since the
>     > likelihood of this idea not being adopted is known to be very high. If this
> was
>     > the first time we could at least plea that we didn't know if it would be
>     > accepted or not, but the new name doesn't make the idea a new one.
>     >
>     >
>     >
>     >     Rubens
>     >
>     >
>     >
>     >
>     >     > On 21 Feb 2022, at 16:45, James Galvin <galvin at elistx.com> wrote:
>     >     >
>     >     > Speaking as co-Chair:
>     >     >
>     >     > This discussion of the purpose and value of enhanced controlled
>     > interruption is essential.  As a group we need to understand all points of
>     > view, make sure to defend any choice we make, and mention relevant
>     > counterpoints so the community understands why we made our choice.
>     >     >
>     >     > Toward that end I want to remind us that this is a technical group and
> we
>     > ultimately will make the best technical choice we can based on the data
> we
>     > have at hand.
>     >     >
>     >     > There are legal questions associated with the use of enhanced
> controlled
>     > interruption.  There are related business, privacy, and liability questions.
>     > These questions have very limited scope in our work.  It is appropriate for
> us
>     > to note the questions and suggest future study of them, but in general it
> is
>     > not within scope for us to resolve them.
>     >     >
>     >     > Let’s remind ourselves as to why enhanced controlled interruption
> (ECI)
>     > is part of our currently proposed solution.
>     >     >
>     >     > We have been asked to provide guidance on how to assess name
>     > collisions and consider what mitigation and remediation might be
> possible.
>     > The data we have tells us the following.
>     >     >
>     >     > 1. Root servers do not have a full picture of name collisions by
>     > themselves.
>     >     >
>     >     > 2. What we do know from root servers is only from DNS queries and
> that
>     > information is waning as the DNS infrastructure evolves.
>     >     >
>     >     > Those two facts alone tell us the development of a mitigation and
>     > remediation plan is problematic at best.
>     >     >
>     >     > ECI exists because it is currently the only mechanism that has been
>     > proposed to obtain sufficient information to develop a mitigation or
>     > remediation plan.  We can certainly note the additional risks that the
> ICANN
>     > Board will need to consider, that are outside the technical scope of our
> work.
>     >     >
>     >     > Or, if another mechanism or procedure manifests in our discussions,
> then
>     > we’ll certainly consider that.
>     >     >
>     >     > I don’t want to repeat discussion we’ve already had.  As we develop
> text
>     > for our final work product all of this will get discussed again and captured
>     > appropriately.  Please do continue the discussion on the list as it will
> inform
>     > our final work product.
>     >     >
>     >     > Thanks,
>     >     >
>     >     > Jim
>     >     > _______________________________________________
>     >     > NCAP-Discuss mailing list
>     >     > NCAP-Discuss at icann.org
>     >     > https://secure-
>     >
> web.cisco.com/1P4Dp2Sc9OPZVocMuZV4eUr4QhKrx4RCJtIYFMaAby2EIQ-
>     >
> 4f3uzTV72acUoDPP9ABTcZ_Ptf3W8e_JWSZat9JcYkirfwIgITdnPogmTOtdgluG
>     > qVewET-
>     > 9XwmPmg3IA72nhSWLxj8Er8rZWNVxCAkeAFX09ISJByh6ubs1H44HA-
>     > NIS24TBMp2QG-
>     >
> UmotADfFpsvGjAi9f0NYene5nGmwzIfzNxJiIM5UQo4dmMXvnhx7Iw0R_MS4
>     >
> LwEKxiF2dij/https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fncap
>     > -discuss
>     >     >
>     >     > _______________________________________________
>     >     > By submitting your personal data, you consent to the processing of
> your
>     > personal data for purposes of subscribing to this mailing list accordance
> with
>     > the ICANN Privacy Policy (https://secure-
>     >
> web.cisco.com/1_UTSzm1ByKwHFs5SDrJJ9o0g0FlF3hVs_41gBB5mAhbAr76Fx
>     >
> MPO7xpByU3nZz4ekjF4gnvS4P8NcYd9FfCrhe1bKb_2dKe7obYfmKfTe8VO8-
>     >
> pWPICJK33_230I2PbCzFpJWanAjLACV4AvvcKk_0iReflXlOvapwoAUyPzfpuKJ7
>     > R9yGTBvokGRMfD81VP-CAIzvGIADn9-rtiTL-
>     >
> SE0F0HK8BFyKll6BJBWhZ98OH_mzBF0r3cmbjcioLxvAU/https%3A%2F%2Fww
>     > w.icann.org%2Fprivacy%2Fpolicy) and the website Terms of Service
>     > (https://secure-
>     >
> web.cisco.com/1P8se2tAgB_LhShz82zwzc2pbJI9bYJGDuVr7CXfssLTqFG4h_4
>     >
> AWptue4EbKUAWKeWayrhPO5c7Im1f_5q3IaDOgkLPedwv4zHjAaPt26AHK2ie
>     >
> yU9XwedNNTHVl0grxz1AxjuKpzQdh4P8KI_vHokOSlGZlFtXOZUi07xfkupmLM
>     > uzwej3DywRn20d-z-uA1zo1cv8nO-
>     >
> Y9xdua7zqYIZyW89lrwPcBtpC7GNvjcsxsWQFficMKrG7rKpXyJl7c/https%3A%2
>     > F%2Fwww.icann.org%2Fprivacy%2Ftos You can visit the Mailman link
> above
>     > to change your membership status or configuration, including
> unsubscribing,
>     > setting digest-style delivery or disabling delivery altogether (e.g., for a
>     > vacation), and so on.
>     >
>     >
>     > _______________________________________________
>     > NCAP-Discuss mailing list
>     > NCAP-Discuss at icann.org
>     > https://secure-
> web.cisco.com/1IjAnFqSXMGr19lTU1eTQ85nzH0e4Hc6TRaYkSvaw0NK-
> Bu51d39cipyaLwH7YIEbhmu2-lI6X6thS2BKODzF_76Med8-
> g952rzaqGkAKsCvSQWOqQpio_ZZH7eCkqkkPWbfbbAtfyIJX1cUBeEAFhTFmB
> UOCzCglvuL__Nspd6ZnQRTUARCfItUvvfrLDGXmniy7F_Fpt7NuK3q53AKP-
> wOIX5qQbe6wa2AspdsZR9BambqksvOuxV4fulVainXh/https%3A%2F%2Fmm
> .icann.org%2Fmailman%2Flistinfo%2Fncap-discuss
>     >
>     > _______________________________________________
>     > By submitting your personal data, you consent to the processing of your
>     > personal data for purposes of subscribing to this mailing list accordance
> with
>     > the ICANN Privacy Policy (https://secure-
> web.cisco.com/1Y9BlFn9QsfJP0EWDc4SOfgMWKQ90rrcXEvM2HMdCWNvQvE
> 29Fm9DxpZs11j10AEkd8shlMwX0LceLQS3IUMCSoteRClCKyB6HUOdOaZdtip7
> GTyCsp4uf8kKZuF3a4hycj54Ft2Lesx6H0-
> MmbnXfwG8L7bCMepHUfz2rNeIWojGNiBkPLalReFgZejPNJIOYSyVceSrV0X9j
> 1TRXr1nflpFFug92DBn5_ofQnG_bmvY1fFfm2KO3cwT2aJzPdz-
> /https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy) and the
>     > website Terms of Service (https://secure-
> web.cisco.com/1tBDlnlM8lh395ru9_GXBg3a2BEIquWb-
> i30vEkU2t7g9orPImN_rkRwQMfuqq_WDDFxmPC0xtAHjBSAlUj1bhMzp0Ls-
> 5XPvbVAsPLl0C1m-YM-x0l22svuTQ3v4EkzIhIbReUikOGBXs-
> 3vVhdsDvK3kSh67GiiSXdpnfQUZDn9rEdtxsJ_cnCoDazkB3r9VURQ07lhMAC48
> x1txFniOFOB_JNBY2op1VODXjGfBI7t8-5rs-
> zieYbc77tsKp4J/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos You can
> visit
>     > the Mailman link above to change your membership status or
> configuration,
>     > including unsubscribing, setting digest-style delivery or disabling delivery
>     > altogether (e.g., for a vacation), and so on.