How to achieve page access only by LAN?

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.

https://caddyserver.com/docs/http.ipfilter

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
}

Snipaste_2018-04-04_12-22-32

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.

Snipaste_2018-04-04_17-20-26Snipaste_2018-04-04_17-27-22
Filemanager internal request is not the same as the external display path.

Snipaste_2018-04-04_17-13-19
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
}
}
  1. The intranet has permission to see the scope modification page (/api/users /api/settings).
  2. All file browsing requestes are 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.
  3. There is a drawback, one more level of directory.
  4. How to block “no extension file”?

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.