A curious question this time. Someone just made the following HTTP requests to my server:
127.0.0.1 - - [02/Jun/2021 15:28:00] "GET //wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:00] "GET //xmlrpc.php?rsd HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:00] "GET / HTTP/1.0" 200 -
127.0.0.1 - - [02/Jun/2021 15:28:00] "GET //blog/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:00] "GET //web/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:01] "GET //wordpress/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:01] "GET //website/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:01] "GET //wp/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:01] "GET //news/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:01] "GET //2018/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:01] "GET //2019/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:01] "GET //shop/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:01] "GET //wp1/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:01] "GET //test/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:01] "GET //media/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:01] "GET //wp2/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:01] "GET //site/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:02] "GET //cms/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
127.0.0.1 - - [02/Jun/2021 15:28:02] "GET //sito/wp-includes/wlwmanifest.xml HTTP/1.0" 404 -
Anyone any idea why someone would try this. I know it has something to do with WordPress (that I don't use/have installed anyway) But I still wonder why someone would try to make these requests.
Thx a lot,
Jules
P.S. The server says it comes from localhost but that is because it goes through Nginx
This is commonplace. Today more than 40% of the world's internet traffic are bots and 25% are malicious bots.
They are just bots that are constantly looking for possible security flaws in as many indexed domains as possible in order to compromise the site.
There are tools that can help you detect these requests and take action. For example fail2ban.
Related
I'm running an e-commerce store on top of Wordpress/Woo-commerce and I'm wondering whether it's normal to have an almost non-stop GET request log in apache's access log.
My website is hosted on Amazon EC2 running on Wordpress Bitnami's image.
Here's part of the log:
172.31.33.229 - - [09/May/2020:14:18:10 +0000] "POST /wp-cron.php?doing_wp_cron=1589033890.9472939968109130859375 HTTP/1.1" 200 -
172.31.33.229 - - [09/May/2020:14:18:10 +0000] "GET /product-category/printable-templates/wedding-templates/wedding-invitation-templates?query_type_color=or&filter_color=bluebrowncoralgreenturquoise&product_orderby=rating HTTP/1.1" 301 -
172.31.33.229 - - [09/May/2020:14:18:11 +0000] "GET /product-category/printable-templates/wedding-templates/wedding-invitation-templates/?query_type_color=or&filter_color=bluebrowncoralgreenturquoise&product_orderby=rating HTTP/1.1" 200 17499
172.31.33.229 - - [09/May/2020:14:18:15 +0000] "GET /product-category/printable-templates/wedding-templates/wedding-invitation-templates?query_type_color=or&filter_color=purpleredturquoise&product_view=list&product_count=45 HTTP/1.1" 301 -
172.31.33.229 - - [09/May/2020:14:18:16 +0000] "GET /product-category/printable-templates/wedding-templates/wedding-invitation-templates/?query_type_color=or&filter_color=purpleredturquoise&product_view=list&product_count=45 HTTP/1.1" 200 17390
172.31.33.229 - - [09/May/2020:14:18:21 +0000] "GET /product-category/printable-templates/wedding-templates?query_type_color=or&filter_color=black%2Cblue%2Ccoral%2Cmagenta%2Corange%2Cpeach%2Cturquoise HTTP/1.1" 301 -
172.31.33.229 - - [09/May/2020:14:18:22 +0000] "GET / HTTP/1.1" 301 230
What's weird is that eventually, it logs 100% CPU usage causing my server to go frozen. If I restart the EC2 instance, everything will be back to normal again until after around more than 12hours on the average.
Note that 172.x.x.x is part of my subnet, I don't understand why I have this log.
Another clue would be in the top, what's eating my CPU is numerous entries of
php-fpm: pool wordpress.
The URL is https://templatesandvectors.com.
I have installed ORDS recently and running it in standalone mode on port 9090. When I try to access my apex site through
host:9090/ords/f?p=102
it fails to load theme CSS file with HTTP request returning 404 response. URL in request header is:
host:9090/ords/timesheet_hris/r/102/files/theme/102/v196/54649182592070537.css
However when I try to access my site with previously used URL:
host:8080/apex/f?p=102
through HTTP DB embedded port it runs just fine with 200 response. In this case URL in request header is:
host:8080/apex/r/timesheet_hris/102/files/theme/102/v196/54649182592070537.css
ORDS log:
192.168.34.163 - - [06/Sep/2017:11:12:41 +0000] "GET /ords/f?p=102:23:13670589014823::NO::: HTTP/1.1" 200 -
192.168.34.163 - - [06/Sep/2017:11:12:44 +0000] "GET /i/app_ui/css/Core.min.css?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:44 +0000] "GET /i/app_ui/css/Theme-Standard.min.css?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:44 +0000] "GET /i/libraries/jquery-ui/1.10.4/themes/base/jquery-ui.min.css?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:44 +0000] "GET /i/themes/theme_42/1.0/css/Core.min.css?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:44 +0000] "GET /i/libraries/font-awesome/4.5.0/css/font-awesome.min.css?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:44 +0000] "GET /i/libraries/apex/minified/desktop.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:44 +0000] "GET /i/libraries/apex/minified/legacy.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:44 +0000] "GET /i/libraries/jquery-migrate/1.4.1/jquery-migrate-1.4.1.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:44 +0000] "GET /i/libraries/apex/minified/widget.apexTabs.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:44 +0000] "GET /i/libraries/jquery/2.2.3/jquery-2.2.3.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:45 +0000] "GET /i/libraries/apex/minified/widget.stickyWidget.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:45 +0000] "GET /i/libraries/apex/minified/widget.stickyTableHeader.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:45 +0000] "GET /i/libraries/hammer/2.0.4/hammer-2.0.4.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:45 +0000] "GET /i/themes/theme_42/1.0/js/modernizr-custom.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:45 +0000] "GET /i/plugins/com.oracle.apex.carousel/1.0/com.oracle.apex.carousel.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:45 +0000] "GET /i/themes/theme_42/1.0/js/theme42.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:45 +0000] "GET /i/libraries/apex/minified/widget.treeView.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:45 +0000] "GET /i/libraries/apex/minified/widget.report.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:45 +0000] "GET /i/apex_ui/js/minified/devToolbar.min.js?v=5.1.1.00.08 HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:45 +0000] "GET /i/favicon-32x32.png HTTP/1.1" 304 -
192.168.34.163 - - [06/Sep/2017:11:12:44 +0000] "GET /ords/timesheet_hris/r/102/files/theme/102/v196/54649182592070537.css HTTP/1.1" 404 15226
192.168.34.163 - - [06/Sep/2017:11:12:45 +0000] "GET /ords/timesheet_hris/r/102/files/static/v124/funkcia.js HTTP/1.1" 404 15207
192.168.34.163 - - [06/Sep/2017:11:12:46 +0000] "GET /ords/timesheet_hris/r/102/files/static/v124/MAIND%20logo.png HTTP/1.1" 404 15210
192.168.34.163 - - [06/Sep/2017:11:12:47 +0000] "GET /ords/timesheet_hris/r/102/files/static/v124/funkcia.js HTTP/1.1" 404 15204
192.168.34.163 - - [06/Sep/2017:11:12:48 +0000] "GET /i/apex_ui/theme_roller/utr-base.js HTTP/1.1" 304 -
ORDS java exception stack trace:
DispatcherNotFoundException [statusCode=404, reasons=[]]
at oracle.dbtools.http.entrypoint.Dispatcher.choose(Dispatcher.java:87)
at oracle.dbtools.http.entrypoint.Dispatcher.dispatch(Dispatcher.java:98)
at oracle.dbtools.http.entrypoint.EntryPoint$FilteredServlet.service(EntryPoint.java:240)
at oracle.dbtools.http.filters.FilterChainImpl.doFilter(FilterChainImpl.java:73)
at oracle.dbtools.url.mapping.RequestMapperImpl.doFilter(RequestMapperImpl.java:125)
at oracle.dbtools.url.mapping.URLMappingBase.doFilter(URLMappingBase.java:103)
at oracle.dbtools.url.mapping.filter.URLMappingFilter.doFilter(URLMappingFilter.java:148)
at oracle.dbtools.http.filters.HttpFilter.doFilter(HttpFilter.java:47)
at oracle.dbtools.http.filters.FilterChainImpl.doFilter(FilterChainImpl.java:64)
at oracle.dbtools.http.cors.CORSResponseFilter.doFilter(CORSResponseFilter.java:83)
at oracle.dbtools.http.filters.HttpResponseFilter.doFilter(HttpResponseFilter.java:45)
at oracle.dbtools.http.filters.FilterChainImpl.doFilter(FilterChainImpl.java:64)
at oracle.dbtools.http.errors.ErrorPageFilter.doFilter(ErrorPageFilter.java:94)
at oracle.dbtools.http.filters.HttpFilter.doFilter(HttpFilter.java:47)
at oracle.dbtools.http.filters.FilterChainImpl.doFilter(FilterChainImpl.java:64)
at oracle.dbtools.http.auth.ForceAuthFilter.doFilter(ForceAuthFilter.java:44)
at oracle.dbtools.http.filters.HttpFilter.doFilter(HttpFilter.java:47)
at oracle.dbtools.http.filters.FilterChainImpl.doFilter(FilterChainImpl.java:64)
at oracle.dbtools.http.filters.Filters.filter(Filters.java:47)
at oracle.dbtools.http.entrypoint.EntryPoint.service(EntryPoint.java:82)
at oracle.dbtools.http.entrypoint.EntryPointServlet.service(EntryPointServlet.java:49)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at oracle.dbtools.rt.web.HttpEndpointBase.dispatchableServices(HttpEndpointBase.java:116)
at oracle.dbtools.rt.web.HttpEndpointBase.service(HttpEndpointBase.java:81)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:258)
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)
I will appreciate any help because I have not been able to solve this for 2 days now and would like to switch to ORDS completely, disabling DB embedded HTTP server on 8080.
EDIT: I tried to deploy it on Apache Tomcat instead of Standalone and got same issue.
After some time I found solution with my colleague. Running this command in webapps directory and restarting Tomcat solved our problem. Hope this post will help someone in the future.
java -jar ords.war validate --database apex
You will need to follow the steps to enable Static File Support from the Apex Installation Manual, which basically means installing/enabling RESTful services in APEX.
Looking at the URL's of your (Themeroller?) css file, it occurs to me, that the "r" folder is different. Could it be, you have to modify this? Dit you enter the path yourself? How did you add the file path?
This is my docker-compose file:
version: '2'
services:
db:
image: mysql:5.7
volumes:
- db_data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: wordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: wordpress:latest
ports:
- "8000:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_PASSWORD: wordpress
varnish:
image: eeacms/varnish
depends_on:
- wordpress
ports:
- 9000:6081
environment:
DNS_ENABLED: "true"
BACKENDS: wordpress
BACKENDS_PORT: 80
volumes:
db_data:
wordpress is running on 0.0.0.0:8080 and on 172.17.0.1:8080
But the /etc/hosts of varnish container is like this
root#4cc3dc214d69:/# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.17.0.3 wordpress fd3f01c29d6a dockoor_wordpress_1
172.17.0.3 wordpress_1 fd3f01c29d6a dockoor_wordpress_1
172.17.0.3 dockoor_wordpress_1 fd3f01c29d6a
172.17.0.4 4cc3dc214d69
varnish is mapping wordpress to 172.17.0.3
That why while trying to access 0.0.0.0:8000 i get
Error 503 Backend fetch failed
Backend fetch failed
Guru Meditation:
XID: 3
Varnish cache server
Can someone please point out whats wrong with my compose file?
P.S docker-compose log shows that varnish do hit worpress but its getting a 302 response.
02 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:19 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:20 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:21 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:22 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:23 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:24 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:25 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:26 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:27 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:29 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:30 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:31 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:32 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:33 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:34 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:35 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:36 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:37 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:38 +0000] "GET / HTTP/1.1" 302 338 "-" "-"
wordpress_1 | 172.17.0.4 - - [25/Mar/2017:10:45:39 +0000] "G
Your link appears to be working as expected. 0.0.0.0 is not an IP address you connect to, that's a listener IP that tells the networking stack to listen on all interfaces rather than a specific IP on the host. In your case, all IP's includes 127.0.0.1 (loopback inside the container) and 172.17.0.3 (the IP reachable by other containers on that network.
Note that links are largely deprecated, it's preferred to configure the containers on a network (other than the default bridge) and use the built in DNS discovery. Similarly, compose version 1 file formats are also largely deprecated, you should consider upgrading to at least the version 2 compose file format. With that format, a network will be created by default for your containers to communicate.
Here's an example of your compose file in version 2 format:
version: '2'
services:
wordpress:
image: wordpress
ports:
- 8080:80
mysql:
image: mariadb
environment:
MYSQL_ROOT_PASSWORD: examplepass
varnish:
image: eeacms/varnish
ports:
- "8000:6081"
environment:
DNS_ENABLED: "true"
BACKENDS: "wordpress"
BACKENDS_PORT: 8080
The http 302 is a redirect, whatever you are running is able to see the url but isn't following the redirect or wordpress is not configured to give a correct redirect.
Update: The varnish error you are seeing is because you are probing / on the wordpress server which is responding with a 302 redirect. Varnish appears to need a 200 success code for the url it is probing. For that, you can add a variable like the following to your varnish environment:
BACKENDS_PROBE_URL: /wp-includes/js/jquery/jquery.js
In my nginx access.log have seen some POST request like these, this request is over 20 time in 1 second, this tunnel.jsp there is no inside my server, but this ip can through this way(using 80 port) to change something on my server, how can I only block the tunnel.jsp using nginx or there are other ways to stop this without close 80 port?
xxx.xxx.xxx.xxx - - [14/Mar/2017:02:26:24 +0800] "POST /v1/bet/attach/tunnel.jsp?cmd=read HTTP/1.1" 200 5 "-" "-"
xxx.xxx.xxx.xxx - - [14/Mar/2017:02:26:24 +0800] "POST /v1/bet/attach/tunnel.jsp?cmd=read HTTP/1.1" 200 5 "-" "-"
xxx.xxx.xxx.xxx - - [14/Mar/2017:02:26:24 +0800] "POST /v1/bet/attach/tunnel.jsp?cmd=read HTTP/1.1" 200 5 "-" "-"
xxx.xxx.xxx.xxx - - [14/Mar/2017:02:26:24 +0800] "POST /v1/bet/attach/tunnel.jsp?cmd=read HTTP/1.1" 200 5 "-" "-"
xxx.xxx.xxx.xxx - - [14/Mar/2017:02:26:24 +0800] "POST /v1/bet/attach/tunnel.jsp?cmd=read HTTP/1.1" 200 5 "-" "-"
xxx.xxx.xxx.xxx - - [14/Mar/2017:02:26:24 +0800] "POST /v1/bet/attach/tunnel.jsp?cmd=read HTTP/1.1" 200 5 "-" "-"
if you are planning to ban the IP where the request is coming from, you can try fail2ban
I noticed that in my access logs these records are flooding. I'm not sure is this a brute force attack because the IP address is my server's IP.
How can I figure what's going on?
185.124.86.73 - - [27/Dec/2016:06:39:04 +0300] "POST /wp-login.php HTTP/1.0" 500 - "-" "-"
185.124.86.73 - - [27/Dec/2016:06:39:04 +0300] "POST /wp-login.php HTTP/1.0" 500 - "-" "-"
185.124.86.73 - - [27/Dec/2016:06:39:04 +0300] "POST /wp-login.php HTTP/1.0" 500 - "-" "-"
185.124.86.73 - - [27/Dec/2016:06:39:04 +0300] "POST /wp-login.php HTTP/1.0" 500 - "-" "-"
185.124.86.73 - - [27/Dec/2016:06:39:04 +0300] "POST /wp-login.php HTTP/1.0" 500 - "-" "-"
185.124.86.73 - - [27/Dec/2016:06:39:04 +0300] "POST /wp-login.php HTTP/1.0" 500 - "-" "-"
185.124.86.73 - - [27/Dec/2016:06:39:05 +0300] "POST /wp-login.php HTTP/1.0" 500 - "-" "-"
185.124.86.73 - - [27/Dec/2016:06:39:05 +0300] "POST /wp-login.php HTTP/1.0" 500 - "-" "-"
185.124.86.73 - - [27/Dec/2016:06:39:05 +0300] "POST /wp-login.php HTTP/1.0" 500 - "-" "-"
185.124.86.73 - - [27/Dec/2016:06:39:05 +0300] "POST /wp-login.php HTTP/1.0" 500 - "-" "-"
185.124.86.73 - - [27/Dec/2016:06:39:05 +0300] "POST /wp-login.php HTTP/1.0" 500 - "-" "-"
The Solution was to Create a mod_security rule to block such offending IP address.
Create file name “wpbrute.conf” in /usr/local/apache/conf/modsec_rules and add following to it.
SecRule REQUEST_LINE "POST .wp-login."
"pass,initcol:ip=%{REMOTE_ADDR},setvar:ip.maxlimit=+1,deprecatevar:ip.maxlimit=1/600,nolog,id:35011"
SecRule IP:MAXLIMIT "#gt 10" "log,deny,id:350111,msg:'wp-bruteforce:
denying %{REMOTE_ADDR} (%{ip.maxlimit} connection attempts)'"
Open file /usr/local/apache/conf/modsec2.user.conf and add include path as below and save the file.
Include /usr/local/apache/conf/modsec_rules/wpbrute.conf
Now all the attacked to the “wp-login.php” should be stopped