On Wed, Apr 10, 2013 at 4:32 PM, Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Howard, > > On 4/10/13 1:23 PM, Howard W. Smith, Jr. wrote: > >> As others have mentioned, I wouldn't give this too much thought: > >> someone is scanning you for vulnerabilities. I'll bet if you log > >> the full headers of those requests, you'll see something like > >> "admin/admin" or "scott/tiger" in the WWW-Authenticate headers. > >> Just someone knocking on your door to see if the latch works. Can > >> you mostly ignore them. > >> > > > > Nice analogy, and definitely, I can ignore and have been ignoring > > them. Just thought I might ask the list, and see if my current > > securing-tomcat approach is common and/or sufficient. :) > > There is a free utility for *NIX systems called fail2ban which can be > configured to scan log files (and other data sources) for certain > patterns. You can do things like say "if we get 10 or more failed > requests from a certain IP address, update the firewall to drop all > packets from that IP for a while". I wonder if there exists something > like that for the Windows world. > Don't know if there exists anything like that in Windows world. > > You can have fail2ban watch things like failed attempts to login to > ssh, and I think you could probably do something like that with 404 > responses from your web-service logs, too. Of course, you have to make > sure that your site doesn't have too many "legit" 404s on it that > people will trigger this rather draconian response, but you can always > un-ban them fairly easily :) > Some legit 404s definitely show up for every enduser that access the webapp via mobile device, because PrimeFaces has 2 files that no longer exist in the JAR file, and I just reported this in their Issue Tracker. 127.0.0.1 - - [10/Apr/2013:20:00:54 -0400] "GET /apple-touch-icon-precomposed.png HTTP/1.1" 404 - 127.0.0.1 - - [10/Apr/2013:20:00:54 -0400] "GET /apple-touch-icon.png HTTP/1.1" 404 - Also, netbeans IDE and start-stop-tomcat implementation results in the following: 127.0.0.1 - - [10/Apr/2013:20:11:05 -0400] "HEAD /netbeans-tomcat-status-test HTTP/1.1" 404 - 127.0.0.1 - - [10/Apr/2013:20:11:05 -0400] "HEAD /netbeans-tomcat-status-test HTTP/1.1" 404 - 127.0.0.1 - - [10/Apr/2013:20:11:05 -0400] "HEAD /netbeans-tomcat-status-test HTTP/1.1" 404 - Ummm, I replaced my IP address with localhost address above. :) > >> On the other hand, I wonder why you are seeing these requests in > >> your Tomcat logs, since you: > >> > >>> I mentioned earlier that I removed the manager apps. The server > >>> is behind a firewall router, port 8080 is port-forwarded from > >>> the router to the server, the web app has login page (and > >>> login servlet/filter in place), but SSL is not configured just > >>> yet. That is definitely on my to-do list to complete, ASAP, as > >>> the CEO has given me the go-ahead. > >> > >> Are you not filtering by URL anywhere? > > > > > > Good question. not filtering any IP addresses at the firewall > > level, and really don't have a need unless some > > really-serious-harmful infiltration occurred. Looking at the > > localhost access logs, I am able to develop a reliable list of IP > > addresses to add to a 'safe list', but i have not found that > > necessary to do...just yet. > > If you find that you are getting lots of penetration attempts from a > small set of IP addresses, just firewall them out. > Our organization just went with Cox@Business internet connection, and the tech guy connected to our cable modem or network (at point of installation), and informed us that we need to configure the router to not respond to PING, so I did that, and honestly, the only hack attempts that I 'see' are the hack attempts against port 8080. I would assume that they do the same on port 80, too. Right? It's interesting that apache httpd port 80 seem to not show/reveal hack attempts against port 80...as mentioned by Esmond Pitt in his response to this thread. I would only firewall-out/block IP addresses, if I seen multiple/repeated attempts from the same IP address(es), but how many 'bots' exhibit the same IP address. I definitely don't know much about 'bots' implementation, but I would assume bots derive random-generated IP addresses. right? > >> If you don't expect anyone in Asia to be legitimately accessing > >> your site, you could do something drastic like close your site to > >> some CIDR pattern that blocks all that stuff. > > > > Interesting. Earlier, Chuck mentioned, "GIYF", and agreed on that > > point, and that would be my first step, if I needed to learn a bit > > more about CIDR. :) > > 192.168.1.223/17 > > It allows you to specify a bit pattern and bitmask at the same time. > Interesting. > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJRZcx2AAoJEBzwKT+lPKRYIaIP/iuhaVAkSUzpT17vIcPYipow > SIHqIo291znp7kedMDsg3Md8uPw3hfREM/aRmbcFmFYIMPbja0YcM3AukeLHNRxu > wY+YhzFxCkaBP+blxCheQXHGWV2YM3hWlPigHhmhHvx/e382mGBqJl/YhasdVh3b > vE1gmbpIPbhr2lUjX+Kp8k27Pf1fNFIgUEh0rqlGZ0F1WxNizr9uGnk/qQyXwSd5 > 6AjEiWufODbzSEOBTX1DkL8ixaH5tisHOBicsesuDt0dZaW2JfoDoqJn+Qa+lEsa > c8O2DHw1hlXT+T7IEjpVcvC36HnfC5uUHBAFiXyqQJuJhbtgUJRuR69DHCUDKzx8 > +4HULQ5t40BKP/xw4eFtiObEH2vkwUEmLXwe74mcWWrb5BzyuZurJygqFyWFlIwV > KLMIHrqsgDdxImFqJBbE627xnANQVa6C+nkAjSs9sqqJC1InL/rbuE0ZFccdEjIz > JfUR4/yXlySzaVxBdOHdFD7cOTf0AR/hLnTf5aiASHxL8eV7y/n07tmda7+KJ4HK > QCP0LvXu/cP2atoY40qHkn9kCIjaEZgj0dnBtgZHw0nu7YsTkMAs5fBsUXU/Fb35 > rPNcHwKJWwdc4J0RXsdXOTbYkeVZNxMrDETxb37hZva3UeNrs8dWXgfVe1SGwhWY > hug9wCMjxUKNhh+3lSly > =TBia > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
