This looks like a Tomcat specific fail2ban clone to me. My recommendation for users that want this sort of functionality is have the app write the offending IP address (and optional additional info) to a log file and configure fail2ban to monitor that log file.
Mark On 05/08/2020 18:51, Dave Fisher wrote: > Hi - > > In my experience the scans you are reporting may be from a white hat security > scan of your website that is contracted by your security team. These tend to > try every exploit that is known for any web server to make sure that your web > apps is secure. > > I’m not sure how the Tomcat team will respond to your ideas. But to me this > seems like a use case for a filter and/or a reason to put httpd in front of > Tomcat. > > All the best, > Dave > >> On Aug 5, 2020, at 10:17 AM, Alan Basche <alan.bas...@gmail.com> wrote: >> >>> >>> Alan, >>> >>> >>> What kind of protections does this module provide? How does it >>> integrate into Tomcat (e.g. custom >>> Filter/Valve/ServletContextListener, patches to arbitrary places in >>> Tomcat internals, etc.)? >>> >> >> The point of this code is to prevent malicious users from probing >> Tomcat hosted apps for weaknesses that can be exploited. After >> deploying Tomcat a year ago, I found that some automated programs were >> requesting hundreds of files that were not found on my system. >> Besides the security risk of revealing your system's configuration, a >> single attack could increase my daily access log file size by 3 or 4 >> times with all of the file requests. I was not able to find any way >> to discourage this activity with any Tomcat feature. So I started >> developing my own solutions to shutdown these visitors. Initially my >> efforts focused on manipulating the website apps' responses in various >> ways but ultimately, the most determined black-hats were not deterred. >> A few months ago I found a solution that worked quite well. I >> concluded that Tomcat should simply refuse to connect to bad IP >> addresses. Of course, Tomcat has no way of knowing when the server is >> being probed for vulnerabilities. However, the website apps are fully >> aware of an attack (e.g. when a user asks for 'wp-login.php', but the >> apps don't even use php technology). So the apps can determine if an >> attack is in-progress, and inform Tomcat of the attack so it can be >> dealt with. >> >> I added a new class IpHitTable.java to Tomcat that manages a list of >> bad IP addresses, checks for an IP address in the table, has a public >> method that allows apps to add a problem IP address, and can return an >> HTML-formatted String for use in a website page to view the bad IP >> address table. I modified Tomcat class NioEndpoint.java to call a >> method in IpHitTable to see if an IP address that wants to connect >> should be allowed. This bad IP address table in IpHitTable is built >> as the system runs and is not stored/loaded to/from a disk or config >> file. The table is empty each time Tomcat is started. >> >> When a web app gets a bad request, it tells Tomcat the IP address and >> how many bad hits are permissible before future connections should be >> refused, and then sends a response with a status code that causes >> Tomcat to disconnect the session >> (org.apache.coyote.http11.statusDropsConnection()) if Tomcat informed >> the app that the bad hits limit has been reached. My own web apps >> allow 3 bad requests before breaking a connection (to allow for >> legitimate file-not-found scenarios... the hostmaster removed/renamed >> HTML files for example). I also have a default web app (defined in >> server.xml, the 'Engine' definition parameter) that receives requests >> that are not bound for a particular app. This covers black-hats who >> come to my server by IP address and didn't even know it was a web >> server. The default web app does not allow 3 bad requests, but rather >> immediately disconnects and tells Tomcat to immediately refuse future >> connections. This type of request represents the vast majority of the >> black-hat probe attempts. >> >>> >>> Are you willing to post your code somewhere like GitHub where everyone >>> can see it? >>> >>> - -chris >> >> I have posted the 2 described classes at: >> >> https://github.com/alannotallan/tc-code-01 >> >> Some points regarding the code & design: >> >> - Look for *Alan* in NioEndpoint.java to see the bit of code I added. >> >> - I built at least 8 proof-of-concept systems before I came up with >> this design. They were meant to prove an idea, not implement a final >> version. Therefore, some changes are to be expected. >> >> - I didn't include the default web app since my app heavily uses a >> private library. I would create a bare-bones default web app to >> handle requests in the manner described. >> >> - I would add a valve to turn on/off this feature and set parameters as >> needed. >> >> - The IP address list is an ArrayList, which should probably be >> changed to some kind of hash list for performance reasons... although >> it would have to support listing every object for building the HTML >> table output. >> >> - At the moment I only support the NIO connection protocol. I can >> easily add NIO2 as well, but I have never been able to build an >> APR/native connection system after weeks of trying, so I didn't look >> into adding that code and would need help testing it. >> >> Alan >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
