[CrowdSec][Plugin] Unable to register machine from DMZ via LAPI

[Baender]

If I try to perform the following command, on the VM in VLAN DMZ, it returns an error:

Code Select Expand

$ sudo cscli lapi register -u http://192.168.1.1:8080
FATA api client register: api register (http://192.168.1.1:8080/) http 400 Bad Request: http code 400, invalid body: invalid character 'C' looking for beginning of value

There seems to be an issue with the configuration of the OPNsense plugin crowdsec. If I perform a curl command:

Code Select Expand

$ curl http://192.168.1.1:8080
Client sent an HTTP request to an HTTPS server.

So in fact, it seems like port 8080 delivers HTTPS:

Code Select Expand

$ curl https://192.168.1.1:8080
curl: (35) error:0A000438:SSL routines::tlsv1 alert internal error
$ sudo cscli lapi register -u https://192.168.1.1:8080
FATA api client register: api register (https://192.168.1.1:8080/): Post "https://192.168.1.1:8080/v1/watchers": remote error: tls: internal error

Now I am unsure, how to solve it. If it helps, this is my firewall rule in DMZ:

Code Select Expand

Action Protocol Source Destination Port Description
Pass IPv4 TCP AppNextcloud 192.168.1.1/24 8080 Allow access to CrowdSec LAPI on OPNsense

AppNextcloud is an alias for IP 192.168.80.10

Other plugins installed: os-caddy (1.6.2)

[doktornotor]

So use https:// in the URL?  ???

[Baender]

This would be too easy, as there seems to be an error with TLS then:

Code Select Expand

tls: internal error

[doktornotor]

Perhaps post the output of

Code Select Expand

sudo cscli lapi register -u https://192.168.1.1:8080

[Baender]

Sorry, but..  ::) I already did that. So your first question already made no sense.

So in fact, it seems like port 8080 delivers HTTPS:

Code Select Expand

$ curl https://192.168.1.1:8080
curl: (35) error:0A000438:SSL routines::tlsv1 alert internal error
$ sudo cscli lapi register -u https://192.168.1.1:8080
FATA api client register: api register (https://192.168.1.1:8080/): Post "https://192.168.1.1:8080/v1/watchers": remote error: tls: internal error

If I visit https://192.168.1.1:8080 with my browser, I get this:

Code Select Expand


Secure Connection Failed

An error occurred during a connection to 192.168.1.1:8080. Peer reports it experienced an internal error.

Error code: SSL_ERROR_INTERNAL_ERROR_ALERT

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

Learn more...

[cookiemonster]

What do you have on your OPN crowdsec plugin settings:
LAPI listen address:
LAPI listen port:
And can you share the result of

Code Select Expand

$sudo sockstat -l | grep crowdsec

[Baender]

What do you have on your OPN crowdsec plugin settings:
LAPI listen address:
LAPI listen port:
And can you share the result of

Code Select Expand

$sudo sockstat -l | grep crowdsec

I didn't touch them and left them at the default values. In case it is relevant over 5 corners: I had to change the port of the WebGUI of the OPNsense to 8443 to use Caddy.

• LAPI listen address: 127.0.0.1
• LAPI listen port: 8080

Code Select Expand

root@OPNsense:/usr/local/etc/crowdsec # sudo sockstat -l | grep crowdsec
root     crowdsec   89455 16  tcp4   127.0.0.1:8080        *:*
root     crowdsec   89455 108 tcp4   127.0.0.1:6060        *:*


Ah, I see..

Code Select Expand


# sudo sockstat -l
[...]
root     caddy      62076 11  tcp46  *:8080                *:*
root     caddy      62076 12  udp46  *:8080                *:*
[...]


[doktornotor]

This is the default config created with crowdsec /usr/local/etc/crowdsec/config.yaml (the relevant snippet):

Code Select Expand


api:
  client:
    credentials_path: /usr/local/etc/crowdsec/local_api_credentials.yaml
    insecure_skip_verify: false
  server:
    console_path: /usr/local/etc/crowdsec/console.yaml
    enable: true
    listen_uri: 127.0.0.1:8080
    log_level: info
    online_client:
      credentials_path: /usr/local/etc/crowdsec/online_api_credentials.yaml
    profiles_path: /usr/local/etc/crowdsec/profiles.yaml
    trusted_ips:
    - 127.0.0.1
    - ::1


Now:

Code Select Expand


# cat /usr/local/etc/crowdsec/local_api_credentials.yaml
login: localhost
password: eXcsUxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
url: http://127.0.0.1:8080/


If you have it on localhost, either fix the listen interface, or use port forward, not allow rule.,

Now, I do not think that anything beyond this absolutely basic config is supported via the GUI, and no idea about what you have done to cause crowdsec use TLS. This definitely will NOT work out of the box. Also, apparently you already have something else listening on 8080.

[Baender]

I solved it, by the following actions:

• Removed custom caddy file from /usr/local/etc/caddy/caddy.d (it remained there after some recent tries in order to redirect an Unifi Controller
• Change LAPI listen address to 192.168.1.1 in CrowdSec plugin settings
• Restart Caddy
• Stop CrowdSec and Start it

Code Select Expand

$ sudo cscli lapi register -u http://192.168.1.1:8080
INFO Successfully registered to Local API (LAPI) 
INFO Local API credentials written to '/etc/crowdsec/local_api_credentials.yaml'
WARN Run 'sudo systemctl reload crowdsec' for the new configuration to be effective.


Thank you guys, for the hint with sockstat -l . I had already suspected Caddy, but I would not have thought that the reason lay in a long-forgotten Caddy configuration.

[cookiemonster]

nothing like a good old console to dig into the problems. One reason I dislike strongly this latest madness with docker and their ilk.
And yes I was going to suggest to change to the IP from the loopback. Unless I have bad sectors in my brain, I read somewhere crowdsec-related about it.

[doktornotor]

Removed custom caddy file from /usr/local/etc/caddy/caddy.d (it remained there after some recent tries in order to redirect an Unifi Controller

Eh. Wouldn't bother, except for the controller GUI to be accessible via normal 443 and without having to deal with their non-existent certificate management. (Piece of junk, really.) Using HAproxy for this.