Azure Marketplace Image SOC Failure - No Auth Screen

[not-mike-wazowski]

Version

2.4.60

Installation Method

Other (please provide detail below)

Description

configuration

Installation Type

Standalone

Location

cloud (Azure Marketplace)

Hardware Specs

Exceeds minimum requirements

CPU

8

RAM

32 GiB

Storage for /

255G

Storage for /nsm

255G

Network Traffic Collection

other (please provide detail below)

Network Traffic Speeds

Less than 1Gbps

Status

No, one or more services are failed (please provide detail below)

Salt Status

No, there are no failures

Logs

Yes, there are additional clues in /opt/so/log/ (please provide detail below)

Detail

This red box appears when I open up my SOC web portal. I can't find errors anywhere, except after entering the so-soc docker instance and viewing /opt/sensoroni/logs/sensoroni-server.log. Here are some of the errors I see there: Any idea what this might be? I'm accessing the portal over an ssh tunnel from my local machine and have explicitly allowed my IP from the SO install process. Any help would be greatly appreciated

{"fields":{"error":"Post \"https://hai-securityonion:8086/api/v2/query?org=Security+Onion\": dial tcp 10.1.1.1:8086: connect: connection refused"},"level":"error","timestamp":"2024-04-16T17:14:16.710240555Z","message":"Unable to determine latest value"}
{"fields":{"error":"Access denied","requestId":"ed74ef5a-17c6-43a3-8e7b-5985853f3ec2","requestor":null},"level":"warn","timestamp":"2024-04-16T17:14:19.958371012Z","message":"Request did not complete successfully"}
{"fields":{"contentLength":115,"elapsedMs":0,"impl":"/build/web/middleware.go:34:github.com/security-onion-solutions/securityonion-soc/server.(*Server).Start.Middleware.func2.1","remoteAddr":"10.1.1.1:43828","requestId":"ed74ef5a-17c6-43a3-8e7b-5985853f3ec2","requestMethod":"GET","requestPath":"/api/info","requestQuery":{},"requestor":null,"sourceIp":"10.1.1.1:43828","statusCode":401},"level":"info","timestamp":"2024-04-16T17:14:19.958556228Z","message":"Handled request"}
{"fields":{"error":"Access denied","requestId":"de75ff14-ae0e-4ef2-8116-10fe22dcf949","requestor":null},"level":"warn","timestamp":"2024-04-16T17:14:24.044402362Z","message":"Request did not complete successfully"}
{"fields":{"contentLength":115,"elapsedMs":0,"impl":"/build/web/middleware.go:34:github.com/security-onion-solutions/securityonion-soc/server.(*Server).Start.Middleware.func2.1","remoteAddr":"10.1.1.1:43828","requestId":"de75ff14-ae0e-4ef2-8116-10fe22dcf949","requestMethod":"GET","requestPath":"/api/users/","requestQuery":{},"requestor":null,"sourceIp":"10.1.1.1:43828","statusCode":401},"level":"info","timestamp":"2024-04-16T17:14:24.044505371Z","message":"Handled request"}
{"fields":{"error":"Access denied","requestId":"f2fcdf4e-65c0-4bac-825b-fd690a80ae12","requestor":null},"level":"warn","timestamp":"2024-04-16T17:14:24.069584932Z","message":"Request did not complete successfully"}
{"fields":{"contentLength":115,"elapsedMs":0,"impl":"/build/web/middleware.go:34:github.com/security-onion-solutions/securityonion-soc/server.(*Server).Start.Middleware.func2.1","remoteAddr":"10.1.4.5:43828","requestId":"f2fcdf4e-65c0-4bac-825b-fd690a80ae12","requestMethod":"GET","requestPath":"/api/roles/","requestQuery":{},"requestor":null,"sourceIp":"10.1.1.1:43828","statusCode":401},"level":"info","timestamp":"2024-04-16T17:14:24.069660538Z","message":"Handled request"}
{"fields":{"error":"Access denied","requestId":"11058fba-7e53-4988-b9bf-b0cda65571a6","requestor":null},"level":"warn","timestamp":"2024-04-16T17:14:33.702908134Z","message":"Request did not complete successfully"}
{"fields":{"contentLength":115,"elapsedMs":0,"impl":"/build/web/middleware.go:34:github.com/security-onion-solutions/securityonion-soc/server.(*Server).Start.Middleware.func2.1","remoteAddr":"10.1.4.5:43828","requestId":"11058fba-7e53-4988-b9bf-b0cda65571a6","requestMethod":"GET","requestPath":"/api/info","requestQuery":{},"requestor":null,"sourceIp":"10.1.1.1:43828","statusCode":401},"level":"info","timestamp":"2024-04-16T17:14:33.703070148Z","message":"Handled request"}

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[not-mike-wazowski]

I've explicitly allowed localhost and my VM's private IP using so-firewall as well, so I believe I can eliminate host firewall issues

[not-mike-wazowski]

Some other issues presenting in parallel:

• 'Disconnected from manager' banner at the top (I'm using standalone mode)
• Profile -> Settings (/auth/self-service/settings/browser/) returns 404 page not found
• Alerts, Hunt, Administration->Users displays a cogwheel it never gets past -- freezes the UI

[not-mike-wazowski]

From /opt/so/log/nginx/error.log:

2024/04/16 17:52:32 [error] 31#31: *2 connect() failed (111: Connection refused) while connecting to upstream, client: 10.1.1.1, server: 10.1.1.1, request: "POST /sensoroniagents/api/node HTTP/1.1", upstream: "http://10.1.1.1:9822/api/node", host: "10.1.1.1"

[not-mike-wazowski]

Looking at more documentation, I'm realizing there's no login page when I connect to server. This would explain 401 unauthorized errors. The remaining question is why is the web server failing to serve auth?

Changing title to reflect this

[not-mike-wazowski]

Confirmed seeing same problem on Import mode

[jertel]

Hello, and thanks for providing so much detailed information on attempts to troubleshoot this on your own!

The typical input on the above screen for cloud images is "other", and you would specify a specific hostname that correctly resolves both externally for analyst browsers to the manager node's public IP, and internally for the SOC, InfluxDB, and other docker images running on the SO nodes to the manager node's internal IP. For single node grids this is simple but for larger grids it involves either manual host entries on each node, or setting up a DNS resolver for your internal network.

Since you are choosing to tunnel your analyst browser connection through the SSH connection, this complicates matters because now your analyst browser running on your local machine must correctly resolve the specific hostname/domain name (entered during setup) to the client's workstation host, which is then port forwarded over the SSH tunnel to the manager node. Further, that tunneled connection must be served by the so-nginx container, not the so-soc container. From what you've described, it sounds like the so-soc container is receiving those tunneled connections, which is leading to the auth being bypassed and then resulting in 401's on the SOC UI (since the user session was never properly authenticated).

I recommend unwinding some of the added complexity with your SSH tunnel, and first get comfortable with setting up SO in the cloud where the analyst is able to login and access the SOC UI, directly to the manager node public IP, without errors. After that is mastered, move on to further locking down access via either a VPN or SSH tunnel.

[not-mike-wazowski]

Yep this is correct. Managing cloud access controls is out of my scope right now, but the SSH port forwarding was the problem. SOCKS tunnel ftw

Thanks for the detailed and helpful response -- makes sense.