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
