nitefood/asn: Network Lookup and Traceroute Server

nitefood/asn Targets Network Investigation Workflows

nitefood/asn addresses the need to investigate an autonomous system, IP address, prefix, URL, hostname, or network path through one command-oriented interface. The README positions it for OSINT and incident-response work, particularly where an analyst needs several kinds of network context without manually moving between separate lookup tools. Its scope includes autonomous-system registration, BGP statistics, RPKI validity, prefixes, AS paths, organization information, IP reputation, geolocation, fingerprints, and route tracing.

The project also extends beyond direct routing queries. Its Shodan reconnaissance mode can request information about CIDR blocks, URLs, individual IPs, and hostnames without sending packets to those targets, according to the README. Reported context includes open ports, known vulnerabilities, and identified software and hardware. Multiple targets, JSON results, and input from a file of IP addresses are documented as supported.

That makes the project relevant to analysts who want a compact operational script rather than a graphical console. It is not a packet-scanning framework or a replacement for a full traffic-analysis platform. Its output combines results from external public services and optional API-backed sources, so the completeness and freshness of an answer depend on those providers and on the input being queried.

BGP and RPKI Data Shape the Lookup Flow

For an AS number, the documented lookup path assembles registration and routing information. Results can include the organization name, RIR region, IXP presence, global AS rank, BGP neighbour count, originated IPv4 and IPv6 prefix counts, and incident history. Peering relationships are divided into upstream, downstream, and uncertain groups, then sorted by observed path count. The documentation presents this ordering as useful for distinguishing likely transit relationships from other observed peers.

Prefix data is aggregated to a less-specific INET(6)NUM object representing the relevant LIR allocation. Abuse contacts are also looked up where available. These features make the script useful when the question concerns ownership, routing context, or operational responsibility for a network resource.

RPKI validation is a separate layer. The README states that IP queries are checked through the RIPEStat RPKI validation API. During an AS path trace, nitefood/asn retrieves ASN and prefix information for each hop from the Prefix Whois public server, then matches those values against published RPKI ROAs. With the documented `-d` option, it can report an origin-AS mismatch or an unauthorized more-specific prefix and identify the offending AS in the path. These checks are described as warnings about possible route leaks or BGP hijacks, not as proof that an incident occurred.

Traceroute and Browser Server Modes

The path-tracing mode uses `mtr` and adds network context to the returned hops. Single IPs and DNS results can be traced, while detailed mode adds information such as RPKI ROA validity, organization or network names, and geographic location. Internet Exchange Points crossed by the trace are detected and highlighted. The value here comes from joining topology information with routing and ownership data instead of presenting traceroute addresses alone.

nitefood/asn can also run in listening mode. The README says that this turns it into a web-based traceroute and lookup server reachable from a browser or through clients such as `curl` and `elinks`. Browsers can use a bookmarklet or a custom search engine, while terminals can submit lookups over HTTP. Server mode therefore supports a different workflow from direct shell invocation: the person using the browser or terminal supplies a target, while the host running nitefood/asn performs the associated queries.

The documentation does not state the authentication model for listening mode, allowed target restrictions, or reverse-proxy guidance. The repository's container default exposes port `49200/tcp` and starts the service for all IPv6 interfaces. Exposing that port beyond a trusted environment therefore requires an access-control decision that the excerpt does not document. The port declaration alone does not establish that a deployment is safe or that authentication exists.

JSON API Mode Supports Scripted Consumers

JSON output is available in both interactive and server use, according to the README. This allows nitefood/asn to sit in a shell pipeline or serve as the data-producing component of a lookup API. The repository description also identifies it as a lookup API server, while the documented Shodan mode supports JSON, simultaneous targets, and an IP-list file as input.

The practical distinction is the interface rather than the investigation category. A command-line operator can request information directly, an HTTP client can reach listening mode, and another program can consume JSON rather than parsing human-oriented terminal output. The README excerpt does not publish an endpoint matrix, request schema, response schema, rate limits, or authentication documentation, so it would be unsafe to assume that every interactive mode has an equivalent public API route.

External lookups are a material dependency. RPKI validation uses RIPEStat, path-hop metadata uses Prefix Whois, and Shodan reconnaissance requires querying Shodan data. The description also names IP reputation, geolocation, and fingerprinting capabilities, but the cleaned excerpt does not identify every provider or token behind them. A deployment should therefore treat network access, provider availability, and applicable credentials as part of the feature set rather than as optional background.

Container Setup Starts an Unauthenticated Listener by Default

The documentation does not include the complete package-installation commands from the README, so it does not provide a safe, documented first-use command for a native Linux, macOS, or Windows installation. It does document a container route through the repository `Dockerfile`. The image is based on Alpine, installs dependencies such as `bash`, `curl`, `jq`, `mtr`, `nmap`, `nmap-ncat`, and `whois`, copies the `asn` executable to `/bin/asn`, and defaults to server mode.

The following repository configuration defines the default service invocation. It starts `/bin/asn` through the image entrypoint and listens on the IPv6 wildcard address.

USER nobody
EXPOSE 49200/tcp
ENTRYPOINT ["/entrypoint.sh", "/bin/asn"]
CMD ["-l", "::"]

For the container path, the repository supplies the image definition and entrypoint contract, but the documentation does not show the exact `docker build` or `docker run` command. A reader should not infer an undocumented publish port or client URL. The most concrete first-use fact available here is that the container's default command launches listening mode on `::` and declares TCP port `49200`.

The entrypoint writes three environment variables into files under `/etc/asn` when they are present: `IQS_TOKEN`, `IPINFO_TOKEN`, and `CLOUDFLARE_TOKEN`. Those environment variables are container configuration inputs, not commands. The image runs as `nobody`, which is a meaningful deployment boundary, although filesystem permissions and network restrictions still need to be considered for the chosen environment.

External Data Creates Accuracy and Availability Limits

nitefood/asn is unsuitable when the requirement is an authoritative, self-contained routing database. The README explicitly identifies RIPEStat and Prefix Whois as sources for validation and hop metadata. Shodan supplies its own record-based reconnaissance view. IP reputation, geolocation, fingerprinting, and related enrichment may also depend on services or tokens, although the documentation does not specify each complete provider chain.

This architecture has two distinct failure modes. A lookup can fail when a remote service is unavailable, rate-limited, inaccessible, or not configured with the required credential. It can also return an incomplete but syntactically valid report when a source has stale or limited data. The documented Shodan mode avoids sending packets to the target, but that property does not turn its output into a live verification of current exposure. Likewise, an RPKI warning identifies a mismatch against published routing data; it does not independently establish malicious intent.

The tool is also a poor fit for organizations that require a documented, versioned response schema, guaranteed synchronous results under network outages, or an investigation platform with a persistent case-management workflow. Those requirements are not established by the documented capabilities. The script is better suited to interactive investigation and lightweight automation where external enrichment is acceptable and the operator understands which source supports each answer.

Release Activity and MIT Upgrade Work

The repository is not archived. Its last push was on 2026-10-02, and the release history includes `v0.83.0` dated 2026-09-16, `v0.82.0` dated 2026-09-10, and `v0.81.1` dated 2026-08-27. Those dates indicate recent project activity, but the documentation does not provide changelogs, migration notes, or a documented compatibility policy for upgrades.

nitefood/asn is distributed under the MIT license. That designation is relevant when deciding whether the script can be incorporated into internal tooling, but the organization should review the repository's actual `LICENSE` file and account for separately distributed services, API terms, databases, and container packages. The MIT project license should not be treated as a substitute for the terms attached to third-party data or optional services.

Upgrade planning is also operationally relevant because this Shell project depends on command-line utilities and remote APIs. The Dockerfile currently reflects a specific Alpine base and package set, while the repository advertises support across several Linux distributions, BSD systems, macOS, Windows, and Raspberry Pi. The documentation does not document how upstream provider changes or dependency changes will be surfaced, so operators should compare the version being replaced with the target release and preserve their token, listening-mode, and access-control configuration before deployment.

Editorial conclusion

Adopt nitefood/asn when responders need a script-driven way to combine network routing data, traceroutes, Shodan records, and JSON lookups from one interface. Do not choose it as a replacement for a dedicated BGP analytics platform or a full reconnaissance suite. Before deployment, verify the external data services and optional API tokens used by each lookup, confirm that its listening endpoint matches the intended access controls, and review the MIT license against your organization’s requirements.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nitefood/asn on GitHub
4. README
5. Releases