Feature Request: GeoIP enrichment, SMTP notifications, and expanded IP detail view

[AlecMcCutcheon]

Hi, I thought it would be interesting if the tool could support additional context around logged IP addresses.

1. GeoIP Integration

It would be useful if DeceptiFeed could enrich logs with GeoIP data (only for public IPs). This could include details such as country, ASN, ISP, or proxy/VPN detection.

Some free APIs that don’t require an API key and could be used by default:

ip-api.com
– free for non-commercial use, supports JSON/XML/CSV, ~45 requests/min.

ipinfo.io/lite
– free and unlimited, provides country + ASN data.

country.is
– free, no key, returns just the country code.

Ideally, the API provider would be configurable by the user.

2. SMTP Email Notifications

It might be helpful to have optional email notifications (via a configurable SMTP server). Example behavior:

Send an email alert when a new/first-time public IP is observed.

Avoid repeated alerts for the same IP.
This would give admins real-time awareness of new scanning/probing activity without spamming them.

3. Separate Enriched Endpoint + UI Integration

The existing threat intelligence feed should remain as just a list of IP addresses for firewall/blocklist compatibility.

In addition, it could be useful to:

Provide a separate endpoint (e.g. /api/ip-details) that returns GeoIP + ASN/ISP metadata for each IP in JSON.

Extend the web UI so that clicking an IP address shows more detailed info, or add a separate “IP detail” page with the enriched data.

Together, these features would make DeceptiFeed not only a honeypot and intel feed, but also a lightweight tool for context and alerting.

Thanks for considering!

[r-smith]

One of my design goals is no 3rd party libraries and no outbound connections to other services.

Adhering to these design goals:

• GeoIP would be possible via offline databases like the one from MaxMind. Or in Deceptifeed's web interface, geoip lookup could be performed by the client using javascript. I'll look at some options.
• SMTP would go against my design goals, though I may make an exception because I do want some kind of alerting and reporting. I was actually considering doing RSS feeds for this and already have a partial working solution.

[AlecMcCutcheon]

Also, is there any way to expose the HTTP/HTTPS login as some kind of API? The idea would be to design a custom honeypot-style login portal and forward those requests to the API to trigger authentication events, instead of being limited to basic authentication only.

I’m not sure how feasible this is, but I’m also running behind a reverse proxy, and it seems that whenever traffic goes through the proxy—even with proxy headers enabled—the public client IPs aren’t being forwarded correctly. It would be great if this were supported, or if there’s something obvious I’m misconfiguring on my end.

Also the RSS feed ideas pretty cool, Could definitely hook that up externally myself to some kind of alerting system

[AlecMcCutcheon]

Or, alternatively, while I do like the idea of making things accessible via an API (and that could still be useful), it might be interesting to support multiple configurable login portals that all report back to DeceptiFeed.

Instead of relying on a basic-auth style blank page, it would be cool to have a templated, web-based GUI login that can be customized with things like a custom background, branding, and overall look-and-feel. This might already be partially possible by replacing the HTML (I remember seeing something along those lines during configuration), but I wasn’t sure how it would communicate back to the backend if basic authentication wasn’t being used.

[r-smith]

Regarding the HTTP honeypot: you can provide your own page and content to serve. Use, <homePagePath> in your config to point to either a single html file or to a directory with your content. If pointing to a directory, you need an index.html file in the directory to serve as the default landing page.

Example configuration snippet:

<server type="http">
  <enabled>true</enabled>
  <port>8080</port>
  <homePagePath>/var/www/my_fake_site</homePagePath>
</server>

Only static content is supported, like: html, css, javascript, and images. You can't serve dynamic content like php or python.

No API needed for this portion - any GET or POST request is logged and any interaction gets the source IP added to the threatfeed.

Regarding honeypots behind a proxy: this is fully supported, but Deceptifeed needs to be told it's behind a proxy. It works with Proxy Protocol or an HTTP header, like X-Forwarded-For. If it's a web proxy like Nginx or Apache, it's probably adding an HTTP header with the original client IP. In your honeypot config, you'd add <sourceIpHeader>X-Forwarded-For</sourceIpHeader> (replace with the header name added by your proxy).

Example configuration snippet:

<server type="http">
  <enabled>true</enabled>
  <port>8080</port>
  <sourceIpHeader>X-Forwarded-For</sourceIpHeader>
</server>

Once set, Deceptifeed extracts the IP address in the header to use as the "source IP" when updating the threatfeed. This can be validated by checking the honeypot logs. Every log entry will have source_ip (the IP extracted from the header), proxy_ip (the IP of your proxy server), proxy_parsed (true or false depending on whether it extracted an IP from the header), and proxy_error (contains an error message if it couldn't extract an IP from the header).

[AlecMcCutcheon]

Question: Is there a way to have Deceptifeed recognize certain query parameters or headers in a POST request and display them in the logs, instead of just showing the raw request data?

For example, with SSH you can see the username and password that were attempted. It would be really useful if you could specify which query parameters to extract and display in a similar way. That way, if I’m doing something like a client-side geolocation lookup and sending the results in the POST request, I could map those fields to custom keys and have them show up naturally in the logs.

Basically, it would be great if there were a way to dynamically define which request fields should be parsed and displayed based on what you configure.

also adding adblock as a format for Threat Feed API would be cool for DNS Servers

[AlecMcCutcheon]

btw your info helped me get this set up with a fully custom honeypot — HTTP/HTTPS, SSH, Telnet, and SIP. It’s been working great with my firewall so far. Check out the HTTP/HTTPS one: gateway.svc.ackvyn.org. It also gets hits on my public IP lol.

If anyone wants the HTML to set up something like mine, let me know. @r-smith you're welcome to use it too if you want—just don’t keep the ackvyn name in the HTML since that’s tied to my domain.

If anyone wants help setting up a custom one, you know where to find me lol. NOTE: it is feeding into my firewall, if you login you will be blocked