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

Add features like showing dead hosts and MAC addresses. #761

Open
MauJFernandez opened this issue Aug 8, 2023 · 3 comments
Open

Add features like showing dead hosts and MAC addresses. #761

MauJFernandez opened this issue Aug 8, 2023 · 3 comments
Assignees
Labels
Type: Enhancement Most issues will probably ask for additions or changes.

Comments

@MauJFernandez
Copy link

Please describe your feature request:

I developed an internal tool which uses fing to passively discover new hosts in the network and gather a bunch of information. I'm using fing because the output not only tells me if the host is up or not, but it also gives me information such as the MAC adress of the host and the vendor, for example:

└─# fing redactedIP/32 -o table,json -r 1       
20:05:59 > Discovery profile: Default discovery profile
20:05:59 > Discovery class:   data-link (data-link layer)
20:05:59 > Discovery on:      redactedIP/32

20:05:59 > Discovery round starting.
{"NetworkAddress":"redactedIP/32","NetworkFamily":"INET4","NetworkBearer":"Ethernet","Hosts":[{"Name":"","Hostname":"redactedHostname","HardwareAddress":"9A:7E:99:B4:54:D2","Address":"redactedIP","Vendor":"HP","State":"up","LastChangeTime":""}]}
20:06:02 > Discovery round completed in 3.052 seconds.
20:06:02 > Network redactedIP/32 has 1/1 hosts up.

I want to replace fing with naabu first for the speed, and second because it's not open source, but I can't do it because it lacks such features.

Another feature I'd like to see implemented is a flag to also show dead hosts when doing a Host Discovery with naabu, not only alive hosts, for example:

└─# naabu -host redactedRange/24 -sn -json -show-dead    

                  __
  ___  ___  ___ _/ /  __ __
 / _ \/ _ \/ _ \/ _ \/ // /
/_//_/\_,_/\_,_/_.__/\_,_/

		projectdiscovery.io

[INF] Current naabu version 2.1.6 (latest)
[INF] Running host discovery scan
[INF] Found alive host 10.0.0.1 (10.0.0.1)
**[INF] Found dead host 10.0.0.2 (10.0.0.2)**
[INF] Found alive host 10.0.0.3 (10.0.0.3)

Describe the use case of this feature:

I'd like to get rid of closed source tools that I currently use to develop internal applications.

@MauJFernandez MauJFernandez added the Type: Enhancement Most issues will probably ask for additions or changes. label Aug 8, 2023
@MauJFernandez
Copy link
Author

Hi, are these proposals considered?

@Mzack9999
Copy link
Member

@MauJFernandez Apologies for the very late reply. I think we can add the MAC info during the host discovery phase ad an additional field in the json output and infer the vendor with something like https://github.com/n3integration/mac2vendor/blob/master/mapping.go

About the second proposal it's a bit confusing: An host is considered dead when unresponsive or when it responds somehow and under continuous traffic stops responding?

@Mzack9999 Mzack9999 self-assigned this Mar 18, 2024
@MauJFernandez
Copy link
Author

@Mzack9999 Lol I was never expecting an answer, what a surprise.

May I suggest another database? Altough the one you provided is already mapped to a go function, it's 5 years old, maybe you can use https://maclookup.app/downloads/json-database which not only is updated but it also has more than double the amount. It's a bit on the chunkier side at 6MB to include as is, but maybe you can gzip it? Don't know how it could affect performance to do it every scan with a MAC discovery parameter.

About the second proposal it's a bit confusing: An host is considered dead when unresponsive or when it responds somehow and under continuous traffic stops responding?

Yeah, in my case I would consider a dead host as unresponsive (my tool just sends 1 ICMP packet, if it gets a response then it's alive, otherwise it's dead), like sending a ping and getting 100% packet loss. I'm curious what would the real life of "it responds somehow and under continuous traffic stops responding" means, if I read that I only think of a denial of service haha.

Thanks for taking this proposal into consideration!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Enhancement Most issues will probably ask for additions or changes.
Projects
None yet
Development

No branches or pull requests

2 participants