Woodgnome's questions

I would like to allow standard users to install my application that require elevated permissions, for example, installing "Per machine" that writes to C:\Program Files.

There's a number of ways to do this, but the least intrusive (compared to advertising/publishing/SCCM) seems to be enabling the group policy "Always install with elevated privileges".

This obviously is a security risk, but can it be properly mitigated by configuring AppLocker to run only MSIs signed by one or more specific publishers or are there some workarounds to abuse this?

I'm using Varnish to cache static files in front of an Apache2 webserver. It's a mix of small files (CSS/JS/images) and large files (from 200 MB to 2 GB).

I've limited both transient and malloc storage in the daemon to 8/12 GB respectively:

ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :8000,PROXY -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,12G -s Transient=malloc,8G

This seems to be respected when checking varnishstat:

SMA.s0.g_bytes           2.67G
SMA.s0.g_space           9.33G
                        12.00G (total)
SMA.Transient.g_bytes    3.26G
SMA.Transient.g_space    4.74G
                         8.00G (total)

But not so when checking top:

MiB Mem :  32169.8 total,    274.4 free,  30405.1 used,   1490.3 buff/cache
MiB Swap:  16382.0 total,   9683.5 free,   6698.5 used.   1360.4 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 3118 vcache    20   0   51.4g  29.3g   1.3m S   7.9  93.2   3:30.05 /usr/sbin/varnishd

This memory usage causes the server to swap, then thrash and eventually invoke oom-killer to destroy the Varnish daemon.

The server is a VM with 32 GB memory. I've also tried with other transient/malloc limits and piping the large files with no difference in behavior.

What could be the issue?

VCL:

backend default {
    .host = "127.0.0.1";
    .port = "8001";
}

sub vcl_recv {
    unset req.http.X-Cache-Request;

    // Unset cookies and indicate that this request should be cached
    if (req.http.host ~ "^static.example.com(:\d+)?$"){
        unset req.http.Cookie;
        set req.http.X-Cache-Request = "1";
    }
}

sub vcl_backend_response {
    // Set TTL if request that should be cached and status code is 2xx, 3xx or 4xx
    if (
        bereq.http.X-Cache-Request
        && beresp.status >= 200 && beresp.status < 500
        && beresp.http.Cache-Control !~ "no-cache"
    ){
        unset beresp.http.Set-Cookie;
        set beresp.ttl = 1w;
    }
}

sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

Been running a couple of fio tests on a new server with the following setup:

• 1x Samsung PM981a 512GB M.2 NVMe drive.
  • Proxmox installed with ZFS on root.
  • 1x VM with 30GB space created and Debian 10 installed.
• 6x Intel P4510 2TB U.2 NVMe drives connected to 6x dedicated PCIe 4.0 x4 lanes with OCuLink.
  • Directly attached to the single VM.
  • Configured as RAID10 in the VM (3x mirrors striped).
• Motherboard / CPU / memory: ASUS KRPA-U16 / EPYC 7302P / 8x32GB DDR4-3200

The disks are rated up to 3,200 MB/s sequential reads. From a theoretical point of view that should give a max bandwidth of 19.2 GB/s.

Running fio with numjobs=1 on the ZFS RAID I'm getting results in the range ~2,000 - 3,000 MB/s (the disks are capable of the full 3,200 MB/s when testing without ZFS or any other overhead, for example, while running Crystal Disk Mark in Windows installed directly on one of the disks):

fio --name=Test --size=100G --bs=1M --iodepth=8 --numjobs=1 --rw=read --filename=fio.test
=>
Run status group 0 (all jobs):
   READ: bw=2939MiB/s (3082MB/s), 2939MiB/s-2939MiB/s (3082MB/s-3082MB/s), io=100GiB (107GB), run=34840-34840msec

Seems reasonable everything considered. Might also be CPU limited as one of the cores will be sitting on 100% load (with some of that spent on ZFS processes).

When I increase numjobs to 8-10 things get a bit weird though:

fio --name=Test --size=100G --bs=1M --iodepth=8 --numjobs=10 --rw=read --filename=fio.test
=>
Run status group 0 (all jobs):
   READ: bw=35.5GiB/s (38.1GB/s), 3631MiB/s-3631MiB/s (3808MB/s-3808MB/s), io=1000GiB (1074GB), run=28198-28199msec

38.1 GB/s - well above the theoretical maximum bandwidth.

What exactly is the explanation here?

Additions for comments:

VM configuration:

iotop during test:

I'm not quite sure if there's a term for the architecture I'm looking to set up, but I'll try to explain.

I have an API and clients calling it with a session ID. The session ID is associated with local session info stored in a PHP session in Memcache (or fetched from a MySQL database if expired). Depending on the session info the user may or may not get access to the API (so it doesn't just require a valid login to access the API, but rather a license associated with that particular client).

I would like to cache requests such that two requests with same parameters (but from different clients/with different session IDs) are cached as one request, but maintaining the session info check.

In the former case (Varnish with separate auth check):

 ________                _____________       _________        ________
|        |  Request w.  |     SSL     |     |         |      | Apache | 
| Client |--------------| termination |-----| Varnish |------| + PHP  |
|        |     SID      |             |     |         |      |  API   |
 ‾‾‾‾‾‾‾‾                ‾‾‾‾‾‾‾‾‾‾‾‾‾       ‾‾‾‾|‾‾‾‾        ‾‾‾‾‾‾‾‾
                                                 | SID
                                             ____|_____
                                            | Validate |
                                            |   SID    |
                                            |          |
                                             ‾‾‾‾‾‾‾‾‾‾

In other words:

1. Client sends request with SID.
2. SSL termination because Varnish.
3. Varnish separates the SID from the requests and forwards it to validation in one backend.
4. If valid Varnish separates and forwards the parameters to the API backend (or if not valid Varnish returns the error response from the validation backend).
5. Varnish returns (and caches) the API response without SID.

Or the latter case (Varnish after an auth check):

 ________                __________                     _________        ________
|        |  Request w.  | Validate |  Request without  |         |      | Apache | 
| Client |--------------|   SID    |-------------------| Varnish |------| + PHP  |
|        |     SID      |          |        SID        |         |      |  API   |
 ‾‾‾‾‾‾‾‾                ‾‾‾‾‾‾‾‾‾‾                     ‾‾‾‾‾‾‾‾‾        ‾‾‾‾‾‾‾‾

In other words:

1. Client sends request with SID.
2. A separate process (I'm currently thinking Node.js) validates the SID.
3. If valid the request parameters will be separated and forwarded to Varnish and API backend (or if invalid an error response will be returned).
4. The response from Varnish is returned.

I have no problems implementing the latter solution, but I'm somewhat concerned about using Node.js as a reverse proxy (some of the requests are for files of 200-500 MB) and I would also like to avoid implementing a Node.js session validation which I already have implemented in Apache/PHP (using that validation in the latter solution is not an option due to the amount of concurrent request the API is receiving).

I'm sure the former option is also considered the "better" option, but the posts I have found all seem to claim that responses are cached on a per-user basis, which is not what I want.

Any input on which solution to go for and how to implement the former would be appreciated.

I'm using UltraEdit (Windows) to edit files on remote SFTP servers. For some reason I can no longer connect to one of those servers.

Here's what was changed:

1. The server was moved (and updated) from one VM to another - usually this only prompts about rsa fingerprint changed and then works with no other changes needed.
2. I've been trying out different software for mapping SSH/SFTP as a Windows drives.

The connection seemed to break after mapping the server in ExpanDrive (I'm almost certain that I continued working on the server after it was moved and updated).

Some points worth noting:

• The problem only exists for this particular server as I can still connect to the other VMs (which are in the same network and have the same requirements to log in).
• I can still connect to the server with PuTTY (after updating rsa fingerprint)
• FileZilla SFTP also works as well
• Some driver mappers work (SFTP Net Drive, sshfs), some don't (ExpanDrive, WebDrive)
• I've removed all entries containing the server name in the registry.

Faulty server info

• Linux titan 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) - x86_64 GNU/Linux
• Distributor ID: Debian
• Description: Debian GNU/Linux 8.1 (jessie)
• Release: 8.1
• Codename: jessie

Info from working server

• Linux ymer 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux
• Distributor ID: Debian
• Description: Debian GNU/Linux 7.8 (wheezy)
• Release: 7.8
• Codename: wheezy

Any idea what could be causing the connection issue in UltraEdit/drive mappers?