Closed glaslos closed 11 years ago
I've created 4 new designs for my own servers that I'm going to test.
We can extract the search queries users made from the hpfeeds data and analyze them. Then, we can redo the search queries and see the results. If we see that the search results in only Glastopf sites then we can blacklist the relevant dorks. May be, we can black list them in some central location that you were talking about in other issues. What do you think?
How do you want to get the search queries in the first place? In some cases it's the path but sometimes it's stuff like "WordPress" and the attacker then requests "/wp-data/something.php". But your idea is going in the right direction. I think the bigger problem are search queries where you combine to paths from different applications.
Since 7a2b97286d7ce82b927897ff4b3b2857ca46e4ee Glastopf has had a fully functional (at least i think so...) WSGI wrapper, which means that we can wrap all sorts of middleware around Glastopf. We might be able to abstract some of the fingerprintability work away from the main Glastopf codebase by using different kind of WSGI wrapper. Maybe we could have some basic middleware that puts a cloak(IIS, Apache emulators?) around Glastopf? I have in no way thought this concept entirely through - just wanted to share the idea.
I'd say fingerprintability is less about the web server then the content served by Glastopf. Right now you can easily find most of the Glastopf instances with some well chosen search requests. Not sure how this changed with the support from mnemosyne...
Yes, you are right. But emulating a webserver could be part of reducing fingerprintability. Regarding mnemosyne i think we need to wait a bit to see the impact, currently i see 1-2 Glastopf instances bootstrapping themselves every day. I hope that we will see some impact when operators start upgrading their honeypots ... and google starts forgetting :-).
Have you tried any web server fingerprinting tools on Glastopf?
Nope
Will be handled in #27
We should start to make the honeypot less obvious to detect. This will be part of the new attack surface creation. So with a more variable layout/design/etc. you will not be able to "see" the honeypot.
I'm not a big fan to ship a dork collection with the honeypot. We might want to ship some for bootstrapping and then remove them as soon as the honeypot is collecting attacks. But what Google has seen, Google will remember so this might cause issues.
Integrating additional dorks from a exploit database is great but could make us vulnerable for detection.