Setting up HoneyPot (MHN)

Define type of honeypot you'll be running.

1) Serving Spam Traps embedded in content.

2) Open SMTP relays.

3) Embedding bot catcher code in HTML or robots.txt files.

4) Running old Kernel versions to trap hackers.

5) Running old PHP versions to trap hackers.

6) Running fail2ban + iptables Tarpitting to shutdown bot by consuming all their resources.

These are a few HoneyPot types which jump to my mind immediately.

Describe type of HoneyPot(s) you'd like to run + likely you'll have many great suggestions.

Tip: If you'd like to run many HoneyPots + track which IPs attack which HoneyPots, run exactly one HoneyPot in one LXD container with unique IP per LXD container.

Morning Gents,
  Thanks for the comments so far, i am initially looking at the MHN server and linked deploy-able honey pots, The above comments are very interesting and i will look into LXD containers as this seems a great option.

You must take MHN data with a grain of salt.

This project tracks + commingles large numbers of IPs with no provision of IP device fingerprinting.

The problem here is with mass NAT infrastructures like VPN + cell network connections, where 1000s-10000s (no one knows for sure) all share a common IP address.

If you do blind blocking using MHN data, then you'll end up with situations like one connection initiating an attack over an IP shared by say... all AT&T users connected to a cell tower in Austin, Texas in the 78749 zipcode...

Or... all TorGuard users connecting out of some IP in Atlanta, Georgia.

Now image NHM commingling 1000s of site's data, all incorrectly flagging NAT'ted IPs as bad.

You're only a short road to going out of business if you do any blocking with this data.

So MNH data might be entertaining to watch... and... you should never use it for any realtime blocking.

Best if you answer my question above.

State what type of attacks are being levied against your site + likely someone can suggest both a HoneyPot solution + actual realtime remediation to block attacks... or Tarpit them, which is even better...

Thanks for the Info David,
If i brake this down the basics of what i am looking to achieve the solution maybe much easier and i might be off on a tangent already.

Key requirement:
- Monitor internal networks for unauthorised access with where possible centralised logging/alerts, i have multiple networks that i would like to place systems into that monitor unauthorised access (in the event either the network has already been compromised or we have users snooping around when there is no need). Again to keep things simple working on basics like access to shares not presented to users, SQL database access attempts, SSH/FTP access attempts...

We have IDP/IPS available on external firewalls that have been configured and good Base / Best Practice security policies in place that should lock down systems but additional layers and piece of mind in the event these have been bypassed already would be good.

I hope this is not too general but anything you could suggest would be a great starting block.

Monitor internal networks for unauthorised access with where possible centralised logging/alerts, ...

This sounds more like you need a central logging server for tracking logins, not a honeypot.

I'd also change ssh away from port 22 if only the sysadmins need access.  Why leave it available to standard users?  You want your logs as small as possible so that you can see the actual attacks versus the accidental, mistakes that people make.  Reduce the noise and you'll better be able to find the signal when someone actually attempts to connect.  I never leave ssh on standard ports unless it must be a public login server.

Thanks for the additional suggestions, i think most of these are in use/implemented by the related Architects (Fail2Ban for example is already running on phone systems etc.)

As for the central logging i have looked at a test setup for Wazuh but this needs additional works to get it up and running over such a diverse setup we have.

Let me expand a little more on the setup, please keep in mind this is a layered approach and by default local systems should be hardened with best practice in mind:

- 5 Networks split over independent geographical locations
- Following Services setup to alert any access (SSH,FTP.SFTP,SQL,SMB,IIS/Web default port scanning....)

As the above are not production systems or presented to users the only people that should have access to these systems are Administrators, As such i would like an alert to be trigger in the event these systems are accessed, or attempted access. This maybe overkill but would provide strong indicators that things were happening within the network that should not.

Example: compromised Active Directory User Account, Compromised local Machine within the trusted IP range. This would be permitted to access local resources but would not trigger any alerts

Example: Local account compromised, Permissions elevated (yes we can trigger on the Elevation (ATA etc.). Account is then used to Pivot to other systems, this again may not trigger any alerts.

Uber Paranoid...

Based on your subsequent comments, my suggestions still stands.  You don't describe a honeypot, but hardened servers.

You want to minimize your signal to noise ratio and reduce your logs and alerts first.  Change the port numbers of all those services to something other than the default and force those admins to use the other ports.  They're not production systems, so they don't need to be on standard production ports.  That removes all unwanted access from script kiddie port scanners or just random, honest mistypes by normal users on your own network and you'll only see access from anyone that's actively trying to connect.  You don't want your logs filling up so much that it becomes a chore to look through or your alerts to be eventually ignored.  Yes, you can trim afterwards, but it would be better not to have the extra noise in the first place.

Honeypots are for something else.  You're likely misunderstanding the term.  Honeypots are created to attract as much attempts at access as possible, generally with planted, false data and open ports that are moderately easy to gain access to.  It's meant to lure attackers with easier access to keep them away from the hardened production systems.  Sometimes it's used to attempt to ensnare them to divulge more information and track them down for sting operations.  What you've been describing so far is not a honeypot, unless you also want one of those.

If you want your systems secure, you don't really want a honeypot on your networks.  That just attracts attention to your networks.  It's not a security device and has the opposite effect.  I would recommend that you don't set one up unless you are actively trying to catch someone that has been trying to intrude into the other systems on your networks.  You generally set one up when someone's been trying to attack you and you've had to call law enforcement, or if you're a researcher.  Not too many people should want a honeypot set up on their networks, because it will just attract nuisance.

Thanks for all the comments guys, it has given me plenty to think about