[TLP:CLEAR]

Voor het doen van onderzoek kan het nodig of nuttig zijn de IP-space van het SURF-netwerk te scannen, of om vanaf een host in het SURF-netwerk netwerken buiten SURF te scannen. Indien niet zorgvuldig uitgevoerd kan dit tot veel (al dan niet terechte) klachten leiden van degenen die gescand worden. Vandaar dat SURFcert de volgende richtlijnen heeft opgesteld waaraan scans moeten voldoen.

Eisen aan de host

  1. De host heeft een PTR-record (reverse DNS) met een betekenisvolle, zo specifiek mogelijke naam waaruit blijkt dat het hier een doelbewuste scanhost betreft en wie er voor verantwoordelijk is. Voorbeelden: resolverscan.surfcert.nl. ddosresearch.onderzoeksgroep.uvharderwijk.nl.

  2. Op de host/het IP-adres draait een webserver in elk geval op poort 80, die een webpagina serveert waarin expliciet gemaakt wordt wat de bedoeling is van de scans en met wie contact opgenomen kan worden bij vragen. Er is duidelijk wie er verantwoordelijk is dat het onderzoek goed en correct verloopt.

    Voorbeeld-teskt voor op webpagina 
    <title of research>

This host performs scans of other machines on the public internet as
part of a research project performed by <responsible org>.

<description of research>
Scan sites for X

Which sites?

<Brief description of the scope of your research / the type of sites
you scan.>

Duration

The scanning will occur from <X> till <Y>.

Results & Responsible Disclosure

The results of our research will be safely stored locally, so we can
do data analysis on it. After our analysis we will
<course of action>
All the collected data will be destroyed after our research.

Opt-out

If you don’t want your site included in this research you can
opt-opt by emailing <contact point>. We will then exclude the specified sites from
our research.

Questions

For further questions about the research you can send an email to 
<responsible reseacher> who is the supervisor of this project and
can answer questions about it.

Eisen aan de scan

  1. Denk van te voren na over welke effecten de scan kan hebben op target hosts, eventuele IDS'en en SIEMs en zorg dat deze beperkt blijven. Denk na over de ontvangers van de scan en voorkom dat ze tijd verspillen aan het opvolgen van bijvoorbeeld onnodige alerts.
  2. Bepaal de scope nauwkeurig zodat er niet meer gescand wordt dan nodig is voor het onderzoeksdoel. Vraag, zo nodig, toestemming bij een ethische commissie.
  3. Zorg voor een juiste pacing van de requests en randomiseer ze over de totale IP-space zodat doelnetwerken niet onredelijk veel requests tegelijk krijgen.
  4. Indien het protocol het toestaat, neem dan ook in het protocolbericht informatie op over de scan en verantwoordelijke. Bijvoorbeeld een duidelijke User-Agent header bij HTTP-gebaseerde scans.
  5. Bied een opt-out mogelijkheid aan en maak ook duidelijk aan de gescanden hoe ze hier gebruik van kunnen maken (zie boven).
  6. Kondig de scan van te voren aan bij de verschillende response teams die hier mogelijk klachten over gaan ontvangen (bv het lokale CSIRT en/of SURFcert).

For research purposes, it may be required or useful to scan the IP-space of the SURF-network, or to scan networks outside of SURF from a host inside the SURF-network. When precautions are not taken, this can lead to many complaints (valid or not) from those who are being scanned. For this reason SURFcert has established guidelines for scans to comply with.

Requirements for the host

  1. The host has a PTR record (reverse DNS) with a meaningful name, as specific as possible, indicating this is an intentional scan host and who is responsible for it. Examples: resolverscan.surfcert.nl. ddosresearch.onderzoeksgroep.uvharderwijk.nl.

  2. A webserver runs on the host/its IP address on at least port 80, which serves a web page that makes explicit what the goals of the scans are and who can be contacted for questions. It's evident who is responsible for the research being carried out in a correct and responsible manner.

    Example text for the web page 
    <title of research>

This host performs scans of other machines on the public internet as
part of a research project performed by <responsible org>.

<description of research>
Scan sites for X

Which sites?

<Brief description of the scope of your research / the type of sites
you scan.>

Duration

The scanning will occur from <X> till <Y>.

Results & Responsible Disclosure

The results of our research will be safely stored locally, so we can
do data analysis on it. After our analysis we will
<course of action>
All the collected data will be destroyed after our research.

Opt-out

If you don’t want your site included in this research you can
opt-opt by emailing <contact point>. We will then exclude the specified sites from
our research.

Questions

For further questions about the research you can send an email to 
<responsible reseacher> who is the supervisor of this project and
can answer questions about it.

Requirements for the scan

  1. Before you start, think about the effects the scan can have on target hosts, possible IDSes and SIEMs and ensure these remain limited. Think about the recipients of the scan and prevent them wasting time on e.g. chasing unnecessary alerts.
  2. Determine the scope to be as targeted as possible so not more is scanned than is necessary for the research goal. If appropriate, get approval from an ethical committee.
  3. Ensure the correct pacing of requests and randomise them over the complete IP space, such that target networks do not receive an unreasonable number of requests simultaneously.
  4. Where the protocol allows it, put information inside the protocol message about the scan and the responsible person. For example a clear User-Agent header in HTTP based scans.
  5. Offer a possibility for opt-out and make it clear to scan targets how they can make use of this (see above).
  6. Announce an intention to scan in advance with incident response teams that may receive complains (e.g. the local CSIRT and/or SURFcert).



  • No labels