ivre / masscan

IVRE's fork of the famous TCP port scanner. See below for details.

IVRE

IVRE (Instrument de veille sur les réseaux extérieurs) or DRUNK (Dynamic Recon of UNKnown networks) is a network recon framework, including tools for passive and active recon. IVRE can use data from:

• Passive tools:
  • Zeek
  • Argus
  • Nfdump
  • p0f
  • airodump-ng
• Active tools:
  • Nmap
  • Masscan
  • ZGrab2
  • ZDNS
  • Nuclei
  • httpx
  • dnsx
  • tlsx
  • Dismap

The advertising slogans are:

• (in French): IVRE, il scanne Internet.
• (in English): Know the networks, get DRUNK!
• (in Latin): Nunc est bibendum.

The names IVRE and DRUNK have been chosen as a tribute to "Le Taullier".

Overview

You can have a look at the project homepage, the screenshot gallery, and the quick video introduction for an overview of the Web interface.

We have a demonstration instance, just contact us to get an access.

A few blog posts have been written to show some features of IVRE.

Documentation

IVRE's documentation is hosted by Read The Docs, based on files from the doc/ directory of the repository.

On an IVRE web server, the doc/* files are available, rendered, under /doc/.

On a system with IVRE installed, you can use a --help option with most IVRE CLI tools, and help(ivre.module) with most IVRE Python sub-modules.

License

IVRE is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

IVRE is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with IVRE. If not, see the gnu.org web site.

Support

Try --help for the CLI tools, help() under Python and the "HELP" button in the web interface.

Have a look at the FAQ!

Feel free to contact the author and offer him a beer if you need help!

If you don't like beer, a good scotch or any other good alcoholic beverage will do (it is the author's unalienable right to decide whether a beverage is good or not).

Contributing

Code contributions (pull-requests) are of course welcome!

The project needs scan results and capture files that can be provided as examples. If you can contribute some samples, or if you want to contribute some samples and would need some help to do so, or if you can provide a server to run scans, please contact the author.

Contact

For both support and contribution, the repository on Github should be used: feel free to create a new issue or a pull request!

You can also join the Gitter conversation (that is the preferred way to get in touch for questions), or use the e-mail dev on the domain ivre.rocks.

Talking about IVRE

Research

If you are using IVRE in you research, please cite it as follows:

IVRE contributors. IVRE, a network recon framework. https://github.com/ivre/ivre, 2011-2022.

Here is the appropriate bibtex entry:

@MISC{ivre,
    title = {{IVRE}, a network recon framework},
    author={IVRE contributors},
    url = {https://ivre.rocks/},
    howpublished = {\url{https://github.com/ivre/ivre/}},
    year = {2011--2022},
}

Technical documents & blog posts

You can mention "IVRE, a network recon framework", together with the project homepage, https://ivre.rocks/ and/or the repository, https://github.com/ivre/ivre.

On twitter, you can follow and/or mention @IvreRocks.

masscan's Issues

Fix for --adapter-port (upstream PR not merged)

Hey there @p-l-

As usual, thanks for maintaining this fork, it's made my life so much easier

FYI, I just submitted robertdavidgraham#738 upstream

This adds the saving of --adapter-port value, which was simply missing from the masscan_echo function

With this you can properly resume a scan that uses --adapter-port/--source-port and you can also see more correct output when using --echo (since they share a function, just use a different FILE * (paused.conf vs stderr)

I tried not to bork any whitespace this time, but please let me know if you prefer any changes (or feel free to make said changes yourself)

Thanks!

Q: merge with another project

hello, hi
would you mind to merge with https://github.com/bi-zone/masscan-ng ?
they add https and MSF, seems interesting

Useful or unnecessary cruft? (get numa node & bind tx thread for ZC performance)

Hey @p-l-

I wanted your opinion on something...

Currently, when I use ZC mode, I have simple bash wrappers to determine the NUMA node for an interface, and invoke masscan with taskset, to bind the masscan process for the best performance in the tx loop

I'll be honest, I did this strictly for correctness and don't know how much it helps performance, or when- presumably it only matters near --rate 1000000

(It's also possible to set and use huge pages allocated specifically to a node, though I don't currently do that and am not sure it matters)

It's only a few lines of bash and IMO not appropriate for inclusion in the masscan repo

What are your thoughts on adding this natively within masscan? The objective is to make it easier to do without requiring any wrappers outside/around masscan

It would be wrapped with ifdef(linux) and would only apply if:

1. ZC is present/active
2. (probably) a specific command-line flag is given

I would have done this long ago but I didn't feel like figuring out how to do it properly in C as I wasn't familiar with the interfaces. But I recently noticed that the PF_RING examples have small, simple functions to do it all

References:

• busid2node - determine the NUMA node for a device (requires knowing the bus ID for the device, which can be retrieved easily with a PF ring API call)
• bind2node - self-explanatory
• bindthread2core - self explanatory

These 3 functions are not part of the PF ring API. If implemented, they would be forklifted from the examples and live in the masscan code

Note that the function(s) to get the bus ID of a device are part of the PF ring API, so dlopen/dlsym would have to retrieve it (same as how the other PF ring functions are loaded/resolved)

There are probably very few people who would benefit from this (besides me, perhaps) and the benefit is small since it can already be done as a wrapper by anyone who cares to look up the commands (for the most part)

Do you think it's worth implementing an "auto-pin to NIC NUMA node" in C or is it better left to the user?

If added, I think it would remain undocumented or "experimental" because I don't want anyone to have to support those trying to understand what it does or how it works (or doesn't work)

I can't really convince myself either way and don't have strong feelings about it; since it would be a PR to your fork, I decided to punt the decision to you 😊

I'm happy to send the PR if you want it (after copying, pasting and testing)

BTW, you saw rob is starting to pull your patchset upstream? Hopefully makes your life easier in the long run

Thanks