Mik3

Before expanding my array further I am waiting the next major unraid release where multiple pool/array will finally be a reality. Not really a fan using only 2 parity drive for 28 data drive, particularly if you consider the rebuild time when you use 18+TB hard drive. I experienced a drive failure twice and unraid was great into rebuilding that but guys, lost some sleep for 2/3 days. If multiple arrays becomes a reality I would like to build 2/3 "unraid array" in a single server each containing 12 disk (2 parity).

Dear devs, I just upgrade to rc7 from rc6 and what I noticed is that ALL unraid setting are reset. Had to go through every setting to change back to the desired value. I don't know if this has been reported yet. This is the only issue I have encountered so far with the minimal setup I have. Thanks again for the hard work and the AMAZING product unraid will be when the 6.12 will hit the stable channel.

What you did with nextcloud is partially correct. Everytime you want a service protected by crowdsec, you need the correct parser and the logs. However this is only half of the equation as once crowdsec analyze the log and finds something bad it will report back through the local API that this IP should be banned. However no automatic action are taken as nextcloud doesn't know that. Depending on how you are hosting nextcloud: If it's through a reverse proxy like swag than additional configuration might be required. If you are using the incorporated web server then you need to do some additional configuration in the nextcloud docker itself. I can't help further as I don't use nextcloud and I don't know how you host your instance. Try to post your question/scenario and I'll try my best to help. Crowdsec protection depends on the parser. For example, nextcloud collection protects against bruteforce and enumeration. For how to test: Temporary disable the nextcloud anti-bruteforce tool so to let crowdsec parser do it's job. If it works it should block your attack if it's properly configured. You can ban your ip and try to access your nextcloud instance, if the configuration is correct you shouldn't be able to reach it. For a pattern to verify your best bet is to look at the nextcloud crowdsec parser documentation and see which pattern is looking for and replicate that yourself. Hopefully this helps.

I updated the guide. Try to set your API key without using the ${}. Let me know if you have further issues

Ok Solved the issue. I tested and it's working. There was an error in the guide about setting the api key. You just have to set the api key without the ${}. I updated the guide. Let me know if you have further issues.

I am still working on it. I need to try and setup swag from scratch to see if there is a problem with the custom configurations. Having a busy work schedule which is not helping at all. If you could have a little bit more patience I'll try to solve the issue as soon as I can.

I tested that myself again and I got the same behaviour. Looks like swag is not communicating or blocking the connection. I will investigate the issue and post the solution. I'll keep you updated. Thanks for the report.

Hmm, that's strange. Is the IP a local IP or a public one? Local IP aren't blocked.

Dear community, I have been looking for a quick reference guide on how to setup crowdsec with swag but I wasn't able to find one, hence this post. Hopefully this will be useful to someone else. Please let me know in the comment if there is a mistake, if you would add something else to make it easier to follow or if the setup can be improved in anyway. Comments, suggestion are always welcome and a way for me to learn more. Let's begin... PREREQUISITES: -------------------------- Unraid 6.11.5 or greater (might work on previous version but I didn't test) Unraid community app plugin Swag (linuxserver.io docker) already set up SETUP: ------------ STEP 1 - Installing CrowdSec --------------------------------------------- Go into the community app and search for crowdsec (IBRACORP docker maintainer), then hit install. Before applying you need to set the following variables: Network type => Custom: <swag> Replace with the custom docker network type you created when you first created swag Auth logs to analyze => /mnt/user/appdata/swag/log/nginx Replace the path with the swag log folder (the one listed is the default) Crowdsec logs to analyze => /mnt/user/appdata/swag/log/nginx Collections => crowdsecurity/nginx crowdsecurity/http-cve If you need more check https://hub.crowdsec.net/browse/ Then check that the ports 8080 and 6060 are NOT in use by another container and click apply otherwise you need to change those ports variable as well. STEP 2 - Crowdsec Configuration ---------------------------------------------------- Let the docker pull finish then open the docker logs and wait for it to finishing the initial setup, then look for the following message: msg="Starting processing data" Once you see the message shut down the container. Go to the crowdsec appdata folder (default is /mnt/user/appdata/crowdsec) and edit the acquis.yaml file. Under the first "filenames:" add the following line: /var/log/crowdsec/*.log Your file should look similar to this: filenames: - /var/log/nginx/*.log - ./tests/nginx/nginx.log - /var/log/crowdsec/*.log <------------------------------------ this is the line we added #this is not a syslog log indicate which kind of log it is labels: type: nginx --- [...] By default crowdsec bans for 4h to modify that value we need the profiles.yaml file in the crowdsec appdata folder. Edit profiles.yaml search for the line decisions and replace 4h with whatever vaule you want/need. An example below: [...] decisions: - type: ban duration: 20h <--------Default is 4h, replace this vaule according to your needs. [...] Now we can start the crowdsec docker, again check docker logs to make sure no errors are show and search for the line msg="Starting processing data" time="01-02-2023 00:03:00" level=info msg="Adding file /var/log/swag/access.log to datasources" type=file time="01-02-2023 00:03:00" level=info msg="Adding file /var/log/swag/error.log to datasources" type=file time="01-02-2023 00:03:00" level=info msg="Adding file /var/log/swag/unauthorized.log to datasources" type=file If you see this, it means that everything is OK and crowdsec is now parsing the logs. STEP 3 - SWAG <-> Crowdsec configuration -------------------------------------------------------------------- Crowdsec is parsing the logs and making decisions but no further action is taken and the connection is not effectively blocked as swag doesn't know anything about crowdsec decisions. To make crowdsec communicate with swag we need to configure the swag container and the crowdsec bouncer. First of all we need to install the swag bouncer inside crowdsec, to do so run in the shell the following command: docker exec -t crowdsec cscli bouncers add swag The command will return an API key. Copy that api key as we need it for the next step Now we need to edit the swag docker container and add the following variables: DOCKER_MODS: linuxserver/mods:swag-crowdsec CROWDSEC_API_KEY: ${API} <-------------Replace API with the API key you obtained from the cscli command in crowdsec CROWDSEC_LAPI_URL: http://[IP]:8080 <-----Replace IP with the Ip address of the crowdsec docker. 8080 is the default port, if you changed that you need to change it here as well. NOTE: Replace "${API}" with the api key you obtained. DO NOT USE THE '$' or the brackets '{' '}'. Example: ${API} becomes hj43gg061... To create the above variable you can use the UnRAID webGui. Remember variables and values are case sensitive. Once you have done that click apply and start the container. Open swag docker logs and check that the mod installation is successful and that the following line appears. nginx: [alert] [lua] init_by_lua:8: [Crowdsec] Initialisation done This means that the crowdsec mod is successfully installed and swag is now communicating with crowdsec docker. If you want to double check that the communication between the two docker is successful you can run the following command docker exec -t crowdsec cscli bouncers list The output is a table with the name,latest time and auth method with the bouncer. CONCLUSION --------------------- Now everytime a connection attempt is made, swag will communicate with crowdsec docker, check if the ip is banned and allow/reject the connection. You can check the crowdsec decisions by running the following command: docker exec -t crowdsec cscli decisions list If you want to test the ban you can use the cscli command to ban the ip. Example: docker exec -t crowdsec cscli decisions add --ip [IP] --type ban --duration 15m <--- Replace IP with your IP Then if you try to connect to your swag instance from that IP you should receive a 403 error. To unban the ip just run the following: docker exec -t crowdsec cscli decisions delete --ip [IP] That's all. Hopefully you find it useful. Please let me know if something is not clear and I'll do my best to improve it. Have fun and stay safe! REFERENCES ---------------------- Blocking malicious connections with crowdsec and swag SWAG docker mod Crowdsec COLLECTIONS

Sorry for the late reply I was busy at work. I tried to setup again using the host mode and changing the port to something else. Maybe he doesn't like 808 XD. Anyway now looks like it's working. I'll do more tests and if anything strange comes up I'll report back. To solve this just change the view from basic to advanced and modify the value "WebUI: http://[IP]:[PORT:80]/". Change 80 to the port you use..in your example 9080. Thanks again for your time and help. Have a nice day!

Hi, thanks for your work much appreciated. Probably it's me but the docker is not working. Please find below all the details. OS: Unraid 6.11-rc5 Fresh install of docker, no previous appdata. I change the net to host, change the HTTP and WS port to something not used but when the container is pulled, it still shows port 80 and port 443 in the docker details in unraid. 192.168.1.2:443/TCP192.168.1.2:443 192.168.1.2:5900/TCP192.168.1.2:5900 192.168.1.2:6080/TCP192.168.1.2:6080 192.168.1.2:80/TCP192.168.1.2:80/opt/deCONZ/mnt/user/appdata/deconz Docker logs shows in RED [deconzcommunity/deconz] Using options .......... --http-port=808 --ws-port=4434 Same happens if using the custom network to br0. Even if I leave the standard configurations the red line is still showed in the docker logs. What am I doing wrong?

@Grant123 You can always add extra parameter in the docker by using the appropriate menù. It's at the end of the page. Also consider that some stuff have changed with the latest release since I wrote this guide. I am quite busy at moment, whenever I'll find the time I'll try to update this guide with the latest infos.

Updated from RC7. No issue so far with VPN (wireguard) or any of the docker except: Upon update the reboot wasn't successful, the system was hanging (I don't have any error/info as no monitor is attached). After 552 secs, I did a normal power down (pressing the power button and the system immediately shut down, like when no boot device found) and restart, one of the btrfs disk cache was missing (again as I did have the same issue upon reboot on the rc4/5). I shut down, changed sata port on the card and reboot. Same issue so I removed the device as the cache was raid 1 anyway so no data loss but I am not sure if the problem is my disk or the update as, as stated before, I had the issue before. The disk shows correctly under unassigned devices now that it has been removed from the cache pool. The only SMART error I have on the drive is the UltraDMA CRC that occurred after I removed the drive. I don't have diagnostics as I did 2 reboot after the changes and forgot to save what happened, however no info/issue in the system log as far as I remember. Hopefully the explanation makes sense. If not please let me know and I try to rephrase it.

Oh I didn't know it was already reported.. I must have missed it. Apologies. I don't want to switch it to none (default) as I won't be able to see my docker in the folder. I can wait for a fix. Thanks again for your time.

To be honest the RC4 is quite stable and I prefer to have the security fixes in place.