Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
Setting up HoneyPot (MHN)
Im am looking to setup a test environment for a Honey pot server/s and and looking for some open source application out there that might help. I have found the MHN Server and honey pot deployment but as im not an expert on Linux i seems to be hitting random errors (4-5 attempts to install so far) and have managed to resolve most of them BUT others experience with the applications would be very useful. I have trawled youtube and and followed the troubleshooting articles. Does anyone have experience setting this up locally and any build > instruction sets?
Thanks in Advance
Thanks in Advance
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
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.
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.
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...
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.
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.
Got it...
1) For ssh, use Fail2Ban, which automatically handles adaptive blocking/unblocking of IPs.
For example, you can have a simple ssh recipe says 5x bad passwords across any 4 hour period blocks the offending IP for an hour.
You can also set the https://wiki.meurisse.org/
Fail2Ban automatically bans/unbans.
I normally log to /var/log/fail2ban.log which you'll likely do also, so you can collect these logs to a centralized location.
2) SQL database access attempts are very easy to manage.
Best way is to locate code using database onto database machine, then close all IP connections to database.
If this can't be done, then just create your normal connections allowing access of a database machine from many clients.
Then, lock down the database machine with iptables (or your OS equivalent), where only whitelisted/ACLed IPs can connect to database machine.
3) Tracking access of shares not presented to users... This is an oddball one...
If a share exists + no one knows about it, unsure how it would ever be accessed.
I'd use Fail2Ban for this also. If a share was accessed that no one should know about... sounds like a Fail2Ban recipe to block that IP for a day or week.
Suggestion: Rather than running HoneyPots, focus on realtime remediation of attacks.
1) For ssh, use Fail2Ban, which automatically handles adaptive blocking/unblocking of IPs.
For example, you can have a simple ssh recipe says 5x bad passwords across any 4 hour period blocks the offending IP for an hour.
You can also set the https://wiki.meurisse.org/
Fail2Ban automatically bans/unbans.
I normally log to /var/log/fail2ban.log which you'll likely do also, so you can collect these logs to a centralized location.
2) SQL database access attempts are very easy to manage.
Best way is to locate code using database onto database machine, then close all IP connections to database.
If this can't be done, then just create your normal connections allowing access of a database machine from many clients.
Then, lock down the database machine with iptables (or your OS equivalent), where only whitelisted/ACLed IPs can connect to database machine.
3) Tracking access of shares not presented to users... This is an oddball one...
If a share exists + no one knows about it, unsure how it would ever be accessed.
I'd use Fail2Ban for this also. If a share was accessed that no one should know about... sounds like a Fail2Ban recipe to block that IP for a day or week.
Suggestion: Rather than running HoneyPots, focus on realtime remediation of attacks.
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...
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.
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.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial