This PR adds 2 options akin to ip-addr and ip-addr-file that allow to tell Masscanned to not respond to packets that are from a given IP address.

The packets are dropped at the IP layer, following what was already done for restricting the IP addresses that Masscanned should impersonate.

I haven't added that dropping logic in ARP (which would be based on the Sender Protocol Address), and didn't defer the decision to ICMPv6 when relevant, as I am unsure if it should. What do you think should be done here? Should such an option drop ARP requests when Sender Protocol Address is ignored? What if SPA is manipulated? Either way the two options fit my personal case and motivation for them.

The comment that was modified in ipv6.rs is so it matches the same one in ipv4.rs, which doesn't have a typo.

• answers to SMB2 protocol requests
• answers SMB1 protocol requests
• adds "generic" packet classes: "Packet" and "PacketDissector". This could probably be abstracted a bit more, and generalized to other masscanned protos

SMB1

smbclient -U "" -N -L 10.1.1.1 -d10 --option='client min protocol=NT1'

SMB2

smbclient -U "" -N -L 10.1.1.1 -d10

Updates the requirements on pnet to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

• adds answers to SessionSetup requests -> NTLM challenge

This needs https://github.com/ivre/masscanned/pull/45 to be able to work in prod / add a functional test :P

• ~~on top https://github.com/ivre/masscanned/pull/41~~
• adds a functional test for SMB
• full refactor of the test suite & cleanups
• ability to select what tests to run: TESTS=smb ./test

Also, one (applicative) protocol should be able to transport another protocol, applicative or not.

This will be particularly helpful for protocols supporting both TCP and UDP with minor changes (e.g., the size is added at the beginning of the packet in TCP and not in UDP; both RPC and DNS, at least, do that).

The second part will also help for encapsulation, e.g.,VXLAN.

Bumps clap from 4.0.29 to 4.0.30.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps clap from 4.0.22 to 4.0.23.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hello,

as mentioned in another issue I'd personally enjoy the logs supporting a different, key-based format, mainly logfmt.

I'm proposing to do it myself and PR, but would just like to be sure it's fine by maintainers / makes sense first. e.g. are you already in the process of adding json?

I think I'd just pretty much copy ConsoleLogger's implementation, along adding a --format CLI option with default as current.

Updates the requirements on clap to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Updates the requirements on pnet to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Hello,

I would like to log ARP activity concerning a machine running masscanned, using masscanned. By that I include ARP Requests who-has (assuming the machine sees it).

However, in my current setup, masscanned seems to detect those when the destination MAC is the unicast MAC of the machine, but not when it's a broadcast (I haven't tested multicast as of writing this).

About ARP handling, the README states that

masscanned anwsers to ARP requests, for requests that target an IPv4 address that is handled by masscanned (i.e., an address that is in the IP address file given with option -f

So it doesn't talk about the frame. (oh uh I guess typo at anwsers btw)

About Ethernet handling, the README states that

masscanned answers to Ethernet frames, if and only if the following requirements are met:

• the destination address of the frame should be handled by masscanned, which means:

  • masscanned own MAC address,
  • the broadcast MAC address ff:ff:ff:ff:ff:ff,
  • a multicast MAC address corresponding to one of the IPv4 addresses handled by masscanned (RFC 1112),
  • a multicast MAC address corresponding to one of the IPv6 addresses handled by masscanned ;

• EtherType field is one of ARP, IPv4 or IPv6.

My environment is a Debian 11 machine. I'm using the arping binary from the APT iputils-arping package (NOT from the arping package, which gives a close but different utility).

That binary's convention is to send its first packet as a MAC broadcast. It is stated in their manpage:

-b
           Send only MAC level broadcasts. Normally arping starts from sending broadcast, and switch to unicast after reply received.

And I can confirm it by running a tcpdump -qen -i INTERFACE arp along, with which I get:

ATTACKER_MAC   > ff:ff:ff:ff:ff:ff, ARP, length 42: Request who-has MASSCANNED_IP (ff:ff:ff:ff:ff:ff) tell ATTACKER_IP, length 28
MASSCANNED_MAC > ATTACKER_MAC,      ARP, length 42: Reply           MASSCANNED_IP is-at MASSCANNED_MAC,                 length 28

So the machine running masscanned is answering to the ARP requests, itself. It does so as long as it's up.

However masscanned doesn't seem to pickup on it (when it's a broadcast) though the asked IP is the IP it's assigned to respond for (and though it does when the MAC is unicast).

It doesn't appear in eth either. There's just nothing.

That means another machine can just run arping -f, arping -c 1 or arping -b against the machine IP and I won't know about it, which is rather frustrating.

I'm unsure if this is

1. some sort of race condition : the system handling and clearing the request too fast for masscanned to see?
2. similarly, these things maybe staying in kernel space, never for a user space application like masscanned to see
3. a bug/untreated case on masscanned's part / in its dependencies
4. something peculiar about my setup I haven't considered, and didn't see doc about how it could be a problem

For 1. , I tried doing arptables -P INPUT DROP, i.e. setting the default policy to drop ARP requests (after accepting only some source IPs, and not the one I run arping from). But it didn't change anything for that issue. The machine's still answering and it's still not masscanned.

My motivation for that was that I'm doing the equivalent with iptables (DROP all INPUT in a specific interface) to "leave IP traffic to masscanned", and in that case it's working like a charm (instead of veth shenigans I don't understand and that'd make me lose the info of the original IP sender).

For 2. , I'm unsure of how I'd go about it. Ideally I'd send packets to user space in some way, and have masscanned pick them up normally in some way. ebtables (ebtables-nft) has a built-in ulog "thing" to pass the packets to a userspace daemon through "netlink multicast sockets", which I assume is generally ulogd. And I have little idea what this all means. I guess if all else fails I could do something with ebtables' log "thing" that syslogs it instead, and forget about masscanned for that ARP edgecase.

Also I could probably be using nft itself directly but it seems daunting 😨 and also doesn't seem to accomodate ARP more than ebtables-nft.

For 3. , I haven't really looked into it, at first glance I don't really get how ARP is handled and thus it doesn't seem like a simple thing to look through.

4 is pretty clear in and of itself

I'm opening this issue to ask if you've encountered / thought about this, and maybe would have ideas how to go around it, similarly as to how there's a tutorial of one way to setup masscanned in a peculiar environment, making use of veths.

Sorry for the wall of text and keep in mind I know little about networking or Rust, and nothing about kernel thingies.

Hello,

at the moment, using the tool one can specify an exact list of IP addresses to impersonate in a file, or it defaults to all of them.

It could be nice to:

• be able to specify them from the command line, maybe in a comma-separated list
• be able to use CIDR notation or another way to specify a range of IP addresses
• be able to ignore specific addresses, when impersonating all of them / a range (e.g. with CIDR)

These last two can probably be achieved by careful routing of what to listen to masscanned, e.g. as done in https://masscanned.readthedocs.io/en/latest/usage.html where it's to ignore tcp on a port, but it still looks to me as an interesting feature to have directly in the tool.

In its current state the related part of the codebase already seems to, at least initially, want to support "blacklisting" IPs, but not fully.

e.g. the function to extract ip addresses from the given file, defined at https://github.com/ivre/masscanned/blob/851a418add74d13189bb0f46786d2b4f91f69cb2/src/utils/parsers.rs#L97-L135 takes a blacklist Option argument, likely to ignore ip addresses, but doesn't act on it. And when it's called at https://github.com/ivre/masscanned/blob/851a418add74d13189bb0f46786d2b4f91f69cb2/src/masscanned.rs#L179 the argument is hardcoded to None.

Maybe this is written down in some todo/roadmap but since I don't have access to it I'm asking anyway.

When two patterns are added to the smack, with wildcards, and such as wildcards of one pattern overlaps the other one, the smack fails to match in some situations.

The minimalistic example that has been added as a test case (failing for now) is the following:

    fn test_wildcard_collision() {
        let mut smack = Smack::new("test".to_string(), SMACK_CASE_INSENSITIVE);
        smack.add_pattern(
            b"****abcd",
            0,
            SmackFlags::ANCHOR_BEGIN | SmackFlags::WILDCARDS,
        );
        smack.add_pattern(
            b"******abcd",
            1,
            SmackFlags::ANCHOR_BEGIN | SmackFlags::WILDCARDS,
        );
        smack.compile();
        let mut state = BASE_STATE;
        let mut offset = 0;
        let id = smack.search_next(&mut state, &b"xxxxabcd".to_vec(), &mut offset);
        assert!(id == 0);
        let mut state = BASE_STATE;
        let mut offset = 0;
        let mut id = smack.search_next(&mut state, &b"xxxxxxabcd".to_vec(), &mut offset);
        assert!(id == 1);
        let mut state = BASE_STATE;
        let mut offset = 0;
        let mut id = smack.search_next(&mut state, &b"xxxxaxabcd".to_vec(), &mut offset);
        assert!(id == 1);
    }

In this example, the last search (xxxxaxabcd) fails, while it shouldn't:

• after reading the first four characters, the smack cannot decide between the two patterns,
• after reading the first a, it still could be either of the two patterns,
• but when the fifh x is read, then it should be decided that it cannot be the second pattern,
• eventually, after reading the whole string, it should be decided that the first pattern matches (while it currently does not).

Note that this don't happen if the first a in the string to parse is replaced by a b for instance.

State of FSM is not currently stored in TCB structure, which means it is lost between each packets.

Hence, for instance, parsing a HTTP request received in two different TCP packets (same TCP connection) fails.

Hi everyone,

That project seems interesting. However, can logs be enhanced to get a proper format to ingest it into whatever {ELK, Splunk, whatever} platform?

At least, mandatory things would be:

• scanning time (timestamp)
• source ip address
• interface which got the packets to
• probe

Just a quick search and I found this which might be interesting : https://rust-lang-nursery.github.io/rust-cookbook/development_tools/debugging/config_log.html

Thanks for that project, looking forward to it.