How to achieve page access only by LAN, filemanager’s users page.
Currently used rewrite if {uri} has users to /status 403.
How to achieve external network can not access this link, LAN can access.
Conditionally choose to perform the corresponding rewrite?
You could use http.ipfilter, available as an optional plugin, to allow only requests from 192.168.0.0/16, 172.16.0.0/12, or 10.0.0.0/8 IP blocks.
This way, the extranet cannot access.
How to differentiate only for this one page？
It looks like it allows you to specify a base path to work on, e.g. ipfilter /foo { ... }. Replace /foo with the folder you want to whitelist LAN access for.
This is a page of the plugin. It is not a folder. It needs to be judged by {uri} or {path}, so I don’t know how to do it.
The /foo section doesn’t operate on a file folder, it operates directly on the URI (the path).
So ipfilter /foo { ... } will affect any request from a client for a path such as /foo/bar/etc.
Thx for you help first.
LAN: 192.168.2.0/24
# ipfilter rule
ipfilter /users {
rule allow
ip 192.168.100.0/24
}
Ipfiles doesn’t seem to be running.
You’ve configured ipfilter to protect the /users folder, but your screenshots indicate that the path is not /users but actually /files/users.
Filemanager comes with the path “/files”, how to configured path of ipfilter.
This problem is bothering me, rewriteonly used uri has not used starts_with.
:80 {
root D:\www
gzip
ipfilter /users {
rule allow
ip 192.168.100.0/24
}
filemanager / D:\www {
database D:\caddy\filemanager.db
}
}
Have you tried ipfilter /files/users { ... }?
The base path works on the path as requested by the client - the path you see in the browser. How filemanager works is irrelevant; ipfilter works if the path in the browser URL bar matches the path you write in the Caddyfile.
ipfilter /files/users {
rule allow
ip 192.168.2.0/24
}
Still no working.
What address are you connecting from?
:2015 {
root /users/whitestrake/projects/test
gzip
log stdout
errors stdout
ipfilter /files/users {
rule allow
ip 192.168.1.0/24
}
filemanager / /users/whitestrake/projects/test/files {
database /users/whitestrake/projects/test/filemanager.db
}
}
Connecting from ::1, I get:
whitestrake at apollo in ~/Projects/test
❯ curl -IL localhost:2015/files/users
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
Server: Caddy
X-Content-Type-Options: nosniff
Date: Wed, 04 Apr 2018 04:45:24 GMT
Content-Length: 14
::1 - - [04/Apr/2018:14:45:24 +1000] "HEAD /files/users HTTP/1.1" 403 14
Also testing from another computer, located at 192.168.0.40:
192.168.0.40 - - [04/Apr/2018:14:43:36 +1000] "HEAD /files/users HTTP/1.1" 403 14
When I change ipfilter to ip 192.168.0.0/24, it works as expected from another computer:
192.168.0.40 - - [04/Apr/2018:14:47:42 +1000] "HEAD /files/users HTTP/1.1" 200 3360
Successful. Thx for your help.
log stdout
Tracked web requests.
Filemanager internal request is not the same as the external display path.
This is a page I do not want to disable extranet access.
request uri=/api/users
ipfilter /api/users {
rule allow
ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
It seems this plugin ipfilter can only use the path follows the domain in the URI. Only work on request uri,not display uri.
Specifically, the URI requested by the client; ipfilter operates before proxies or rewriting can occur, so it always operates on the initial URI received by Caddy.
For the security of the win server, wrote the following code:
# Begin - Security
# ipfilter rule
ipfilter /api/users /api/settings {
rule allow
ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
# status
status 403 /forbidden
# deny all direct access for these folders
rewrite {
if_op or
if {uri} has Recycle
if {uri} has RECYCLE
if {uri} has PerfLogs
if {uri} has Program # Program_Files|Program_Files_(x86)|ProgramData
if {uri} has Recovery
if {uri} has System
if {uri} has Users
if {uri} has Windows
if {uri} has caddy
to /forbidden
}
# deny running files
rewrite {
if_op or
if {uri} has boot
if {uri} has Documents
if {uri} has Pagefile
if {uri} has .clp
if {uri} has .com
if {uri} has .dll
if {uri} has .drv
if {uri} has .exe
if {uri} has .ini
if {uri} has .pif
if {uri} has .rec
if {uri} has .sys
to /forbidden
}
# deny running scripts inside core system folders
rewrite {
regexp /($Recycle.Bin|$RECYCLE.BIN|PerfLogs|Program_Files|Program_Files_(x86)|ProgramData|Recovery|System_Volume_Information|Windows)/.*\.(txt|xml|md|html|yaml|php|pl|py|cgi|twig|sh|bat|ini)$
to /forbidden
}
# deny running scripts inside user folder
rewrite {
regexp /Users/.*\.(txt|md|yaml|php|pl|py|cgi|twig|sh|bat|ini)$
to /forbidden
}
# deny access to specific files in the root folder
rewrite {
regexp /(LICENSE.txt|composer.lock|composer.json|nginx.conf|web.config|htaccess.txt|\.htaccess)
to /forbidden
}
## End - Security
Complex and tedious, Can it be streamlined?
If you’re after advice on that Caddyfile, here’s my two cents:
I am assuming, based on the things you’re trying to block, that you’re going to be running filemanager with access to your entire file system. This is a completely backwards way to secure any server, let alone a Windows server.
You wasted your time by writing that Caddyfile (which seems mostly copied from the app-specific Grav example Caddyfile) if you expect it to adequately protect your entire file system from an attacker.
My strong recommendation is to throw it all out, rethink your security strategy for file sharing (exposing everything and then scrambling to cover up exploitable content is insane), and start over with something simpler with a secure-by-default approach.
There are a number of inefficiencies such as the overuse of blanket {uri} has checks and unnecessary reliance on regex… But, generally speaking, there’s nothing in your Caddyfile that I expect not to function as you’ve written it.
I also think there is a problem with this method.
The plugin (filemanager) has too high permissions. It has a beautiful interface, It is easy to access, just only one password. It has one parameter:
scope is the path, relative or absolute, to the directory you want to browse in. Defaults to ./.
Someone will get admin password, then modify scope on the web page, someone can add and delete windows system folders.
I hope scope written in caddyfile can not be changed through the web page. Just like it is not possible to modify caddyfile through the web page.
I want to specify the scope of filemanager by caddyfile. It cannot be modified by filemanager. Must be modified by caddyfile. Caddyfile can only be modified by Intranet.
Now, ipfilter solved the problem of caddyfile LAN access. The author of filemanager suggested running caddy by created a low-level permission win account.
I really don’t know which way is more reasonable.
Update2
Folder structure: C:.…\Desktop\www\test, All the files needs to share are in test folder.
:80 {
root C:\...\Desktop\www
gzip
log stdout
drrors stdout
ipfilter /api/users /api/settings {
rule allow
ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
status 403 /forbidden
rewrite {
if {path} ends_with resource/
to /api/resource/test
}
rewrite {
if_op and
if {path} has resource
if {path} not_ends_with resource/
if {path} not_has test
to /forbidden
}
rewrite {
ext .asp .bat .cgi .clp .com .conf .config .dll .drv .exe .htaccess .html .ini .js .json .lock .md .php .pif .pl .ps1 .py .rec .sh .sys .twig .vbs .wsf .wsh .xml .yaml
to /forbidden
}
filemanager / C:\...\Desktop\www {
database C:\...\Desktop\caddy\filemanager.db
}
}
rewrite to the “test” folder, In the internal network, obtain the admin password of filemanager to modify the scope like C:/, display nothing and 403.I feel this is a positive way. Please make some suggestions again. Thx so much.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.