• Resolved mrppp

    (@mrppp)


    Using below code if i use the two octets 65.100.(but my ip) and for some reason my entire ip changes locking me out. Can i just ftp the htaccess file, remove the code then login?

    # Protect wp-login.php from Brute Force Login Attacks based on IP Address
    <FilesMatch "^(wp-login\.php)">
    Order Allow,Deny
    # Add your website domain name
    Allow from example.com
    # Add your website/Server IP Address
    Allow from 69.200.95.1
    # Add your Public IP Address using 2 or 3 octets so that if/when
    # your IP address changes it will still be in your subnet range. If you
    # have a static IP address then use all 4 octets.
    # Examples: 2 octets: 65.100. 3 octets: 65.100.50. 4 octets: 65.100.50.1
    Allow from 65.100.50.
    </FilesMatch>

    Is it essential to put the server my website is on IP address # Add your website/Server IP Address
    And why do you need the actual site you are doing it on # Add your website domain name
    probably daft questions but just want to understand it a bit more.
    I have no fixed ip hence only use two octets but would like my wp login restricted as much as i can
    https://wordpress.org/plugins/bulletproof-security/

Viewing 15 replies - 1 through 15 (of 15 total)
  • Plugin Author AITpro

    (@aitpro)

    You can reverse the “Order” directive and use Deny,Allow instead of Allow,Deny and then you would only need to whitelist your Public (ISP) IP address.

    # Protect wp-login.php from Brute Force Login Attacks based on IP Address
    <FilesMatch "^(wp-login\.php)">
    Order Deny,Allow
    Allow from 65.100.50.
    </FilesMatch>

    Most ISP’s change your public IP address very regularly and very frequently. Some ISP’s only change the last octet of the IP address, some change the last 2 octets, some change the last 3 octets and some change all octets. Your options would be to try and use all possible IP addresses that you host uses or choose another way to protect your login page instead of doing this via IP address.

    # Protect wp-login.php from Brute Force Login Attacks based on IP Address
    <FilesMatch "^(wp-login\.php)">
    Order Deny,Allow
    Allow from 65.100.50.
    Allow from xxx.xxx.
    Allow from xxx.xxx
    </FilesMatch>
    Thread Starter mrppp

    (@mrppp)

    Ok so using

    # Protect wp-login.php from Brute Force Login Attacks based on IP Address
    <FilesMatch "^(wp-login\.php)">
    Order Deny,Allow
    Allow from 65.100.50.
    </FilesMatch>

    and only have this in the box and remove the server one i have

    # BRUTE FORCE LOGIN PAGE PROTECTION
    # Protects the Login page from SpamBots, HackerBots & Proxies
    # that use Server Protocol HTTP/1.0 or a blank User Agent
    RewriteCond %{REQUEST_URI} ^(/wp-login\.php|.*wp-login\.php.*)$
    RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
    RewriteCond %{THE_REQUEST} HTTP/1\.0$ [OR]
    RewriteCond %{SERVER_PROTOCOL} HTTP/1\.0$
    RewriteRule ^(.*)$ - [F,L]

    But using two octets of my ISP ip

    Plugin Author AITpro

    (@aitpro)

    Yes, you have reversed the “Order” directive.

    Or you can use both. See this forum topic: http://forum.ait-pro.com/forums/topic/protect-login-page-from-brute-force-login-attacks/

    Thread Starter mrppp

    (@mrppp)

    so am i correct in

    # Protect wp-login.php from Brute Force Login Attacks based on Server Protocol or IP
    # All legitimate humans and bots should be using Server Protocol HTTP/1.1
    RewriteCond %{REQUEST_URI} ^/wp-login\.php$
    RewriteCond %{THE_REQUEST} HTTP/1\.0 [OR]
    RewriteCond %{REMOTE_ADDR} !^xxx\.xxx\.xxx\.$
    RewriteRule ^(.*)$ - [F,L]

    and replace this with my isp ip as so
    RewriteCond %{REMOTE_ADDR} !^65\.100\.xxx\.$

    only 2 octets

    Plugin Author AITpro

    (@aitpro)

    Yes

    Thread Starter mrppp

    (@mrppp)

    cool thank you

    Plugin Author AITpro

    (@aitpro)

    If you want to add more IP addresses….

    # Protect wp-login.php from Brute Force Login Attacks based on Server Protocol or IP
    # All legitimate humans and bots should be using Server Protocol HTTP/1.1
    RewriteCond %{REQUEST_URI} ^/wp-login\.php$
    RewriteCond %{THE_REQUEST} HTTP/1\.0 [OR]
    RewriteCond %{REMOTE_ADDR} !^(xxx\.xxx\.xxx\.|xxx\.xxx\.|xxx\.xxx\.)$
    RewriteRule ^(.*)$ - [F]
    Thread Starter mrppp

    (@mrppp)

    Bum! i,m one who gets the 403 so guess i can’t use it

    Plugin Author AITpro

    (@aitpro)

    Or you could contact your host and ask them to upgrade their Proxy software to Server Protocol HTTP/1.1 which is the new Server Protocol as of 1999 – 15 years ago.

    Thread Starter mrppp

    (@mrppp)

    LOL i,m asking

    Plugin Author AITpro

    (@aitpro)

    What I have seen that is fairly common is a host offers both HTTP/1.0 and HTTP/1.1 and defaults to HTTP/1.0 usage. Why that would be I do not know. So it may already be available to you, but you were just not aware of that.

    Thread Starter mrppp

    (@mrppp)

    Thanks, i have raised a ticket see what they say, normally pretty good

    Thread Starter mrppp

    (@mrppp)

    Ignore

    Thread Starter mrppp

    (@mrppp)

    Ok i,m being told “Server version: Apache/2.2.25 (Unix) which is newer as compared to the HTTP/1.1.

    Means nothing to me but does that sound right?
    they also said use

    Order Deny,Allow
    Deny from all
    Allow from 127.0.0.1 # Exact IP
    Allow from 127. # Allows any IP where the first octet starts with 127

    in htaccess

    Plugin Author AITpro

    (@aitpro)

    Different things. Apache is the server type/software. HTTP/1.0 or HTTP/1.1 is the Server Protocol that would be configured in a server config file.

    Example: Nginx Reverse Proxy would have this type of configuration setting in the proxy.conf configuration file where you could set the protocol to 1.0 or 1.1. Squid Proxy and other Proxy software are generally similar – it is a configuration setting, but the Proxy software version must be updated to a version that can use Server Protocol HTTP/1.1 in order to configure the Proxy software to use it.

    # Defines if reverse-proxying should use HTTP 1.0 or 1.1
    # You should try which gives you better results,
    # or if you find any significant differences at all
    proxy_http_version		1.0;

    No that code is no good. It would affect your entire site and not just your Login page. There is no Login page condition in that basic crude example.

Viewing 15 replies - 1 through 15 (of 15 total)

The topic ‘Brute Force Login’ is closed to new replies.