Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: port-filtering experiment #891

Merged
merged 20 commits into from
Sep 14, 2022
Merged

Conversation

DecFox
Copy link
Contributor

@DecFox DecFox commented Aug 28, 2022

Checklist

Description

This is a premature implementation of the port-filtering experiment.

@DecFox DecFox changed the title Port filtering feat: port-filtering experiment Aug 28, 2022
@hellais
Copy link
Member

hellais commented Sep 5, 2022

I took a look at the PR and did some light testing of it and it looks good to me.

Some high level comments which we should keep in mind before deploying this include:

  1. We should consider how we are going to distinguish between port blocking and the blocking of the IP of the test helper. Ideas for how we might go about doing this include (possibly a combination of them):
  • Using a much larger set of ports, potentially with some randomised ones too and consider the whole experiment as invalid if we notice that no port is reachable
  • Using something like MLab so we have a larger pools of IPs available
  • Using ICMP or UDP to test reachability with the test helper
  1. We should extend the set of ports which we scan and possibly add support for parallelising it. According to nmap-services (https://github.com/nmap/nmap/blob/master/nmap-services) there are 70 ports which are open with a probability >= 2%. This is probably a reasonable cutoff point.
  2. If we are to extend the list of ports, we might also want to add the ability to pass a port list as an input file (or a CLI flag). In doing so I wonder if the structure of having all the measurement in a single measurement file is going to scale well. That is to say if you do a port scan of 10k ports then you will end up with a very "fat" measurement file with all the port results in it, conversely we could generate one measurement entry per port and perhaps that would scale better. Input from @FedericoCeratto and @bassosimone on this point would be helpful.

@DecFox DecFox marked this pull request as ready for review September 14, 2022 15:46
bassosimone pushed a commit to ooni/spec that referenced this pull request Sep 14, 2022
Copy link
Contributor

@bassosimone bassosimone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This is a great starting point to begin experimenting!

🐳 💯 🔝 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants