limit access to admin panel by IP Address?

[Jswerv3]

Is there a way to limit access to admin panel by IP Address?

Or another way of saying it is: I pick which IP addresses are whitelisted and everyone else is blocked?

[RevengeFNF]

You can do that server side. Just limit access to the acp folder with the ip you want. 

[Jswerv3]

1 hour ago, RevengeFNF said:

You can do that server side. Just limit access to the acp folder with the ip you want. 

 

Can you tell me how?

[RevengeFNF]

20 minutes ago, Jswerv3 said:

 

Can you tell me how?

Do you use Apache, Nginx or other? 

[Jswerv3]

1 minute ago, RevengeFNF said:

Do you use Apache, Nginx or other? 

ngin

[RevengeFNF]

https://www.nginx.com/resources/admin-guide/restricting-access/

You have an example there. Very simple and easy. 

[Tracy Perry]

I'm on a CentOS 7/CentMin Mod stack server.

This works just fine

location /admin {
    auth_basic                      "Restricted Access";
    auth_basic_user_file             /usr/local/nginx/passwd/the.keys.to.the.kindgom;
    root /path/to/your/root/directory/;
    include /usr/local/nginx/conf/staticfiles.conf;
    include /usr/local/nginx/conf/php.conf;
        }

 

[Jswerv3]

13 minutes ago, Tracy Perry said:

I'm on a CentOS 7/CentMin Mod stack server.

This works just fine

location /admin {
    auth_basic                      "Restricted Access";
    auth_basic_user_file             /usr/local/nginx/passwd/the.keys.to.the.kindgom;
    root /path/to/your/root/directory/;
    include /usr/local/nginx/conf/staticfiles.conf;
    include /usr/local/nginx/conf/php.conf;
        }

 

what about whitelisting ips?

[Tracy Perry]

9 minutes ago, Jswerv3 said:

what about whitelisting ips?

Just replace the auth_basic line with 

    allow XXX.XXX.XXX.XXX/32;
    allow 127.0.0.1;
    deny  all;

where XXX.XXX.XXX.XXX is your STATIC IP.  If  you are on a DHCP ISP, then this will NOT work for you.

[Jswerv3]

4 minutes ago, Tracy Perry said:

Just replace the auth_basic line with 

    allow XXX.XXX.XXX.XXX/32;
    allow 127.0.0.1;
    deny  all;

where XXX.XXX.XXX.XXX is your STATIC IP.  If  you are on a DHCP ISP, then this will NOT work for you.

How can I tell if I am on a DHCP ISP? I am fairly sure its static, but I want to double check.

[Tracy Perry]

1 hour ago, Jswerv3 said:

How can I tell if I am on a DHCP ISP? I am fairly sure its static, but I want to double check.

Your bill.. most ISP's charge an additional fee for a static IP (mine is something like $12 a month extra).  You can check in your router and see how it is set up also.  Unless you specifically requested a static IP odds are you do not have one.

[ASTRAPI]

You can also trick users as an extra security measure by keeping the admin path and password protect it using nginx and set real admin path protected again on a new path.

Most users will think that the admin panel is at default location when they see the login pop up

But maybe i should not post such info lol

[Jswerv3]

44 minutes ago, ASTRAPI said:

You can also trick users as an extra security measure by keeping the admin path and password protect it using nginx and set real admin path protected again on a new path.

Most users will think that the admin panel is at default location when they see the login pop up

But maybe i should not post such info lol

Very interesting tactic haha. So instead of whitelisting IPs, you can password protect the public facing admin panel login page on IPBoard with a Password, before you actually get to the login page to input your username and password to use the panel?

So it is like:

Go to admin panel URL

Password protected (via nginx)

correct password entered

regular login screen

enter user and pass

into ipb admin panel

[ASTRAPI]

yup

[Jswerv3]

4 minutes ago, ASTRAPI said:

yup

Is that a good security precaution to use? Is it easy to break or bruteforce at all? 

Sounds like a better option than limiting to IPs

[ASTRAPI]

No it's not easy to brute force because:

1)Using a password like: (Q#m1H$e2ylfY;rY\0ZM*$8VrK^x;SU) is not easy at all to brute force

2)Even if someone break on it then he must brute force the second ipb login and this will not be easy as he must modify the brute force script to always login to the first pop up and try each password on ipb login and that will cause a huge delay and make it very hard to break it.

But limiting to an IP is good also

You can use both !

 

[Jswerv3]

1 minute ago, ASTRAPI said:

No it's not easy to brute force because:

1)Using a password like: (Q#m1H$e2ylfY;rY\0ZM*$8VrK^x;SU) is not easy at all to brute force

2)Even if someone break on it then he must brute force the second ipb login and this will not be easy as he must modify the brute force script to always login to the first pop up and try each password on ipb login and that will cause a huge delay and make it very hard to break it.

But limiting to an IP is good also

You can use both !

 

How would I setup the initial nginx login? If you dont mind

[ASTRAPI]

Don't know what stack are you using but you can find a lot of tutorials about it in Google searching something like this:

How to password protect a folder using Nginx

 

 

[Jswerv3]

45 minutes ago, ASTRAPI said:

Don't know what stack are you using but you can find a lot of tutorials about it in Google searching something like this:

How to password protect a folder using Nginx

 

 

So just by simply placing a password on a folder server side will prompt me to enter that password on the front end to access? 

[ASTRAPI]

No.

You must also add a block like Tracy Perry post above on nginx conf file and restart Nginx

But again Google it and try it