+36 -20

_drafts/crowdec-for-homelab.md

Reviewed

··· 195 195 196 196 **Raspberry Pi4** 197 197 198 198 -  198 198 +  199 199 200 200 **Raspberry Pi5** 201 201 202 202 -  202 202 +  203 203 204 204 **i5-6500T** 205 205 206 206 -  206 206 +  207 207 208 208 **i5-13400T** 209 209 210 210 -  210 210 +  211 211 212 212 </details> 213 213 ··· 254 254 255 255 </details> 256 256 257 257 - ## Architecture Overview 257 257 + ## Crowdsec at Homelab Scale 258 258 259 259 - Architecture will be similar to https://docs.crowdsec.net/u/user_guides/multiserver_setup/ 259 259 + Now, we'll take all the above context to design a Crowdsec implementataion for our contrived homelab that respects the heterogenous compute power of machines in our network. 260 260 261 261 - * Management instance (docker) 262 262 - * located on most stable server 263 263 - * potentially on VPS if any services also live there 264 264 - * Log Process instances (docker) 265 265 - * Location based on 266 266 - * type of data source (docker containers can be tailed from anywhere) 267 267 - * expected traffic load 268 268 - * Use centralized log processor on beefy machine for high load, docker data sources 269 269 - * Use on-host log processor for low load or data sources that can't be tailed from docker 270 270 - * Showcase load testing stack to determine log processor feasability 271 271 - * Avoid log processor on same machine as Management unless lots of overhead 272 272 - * Bouncer on each point of ingress 273 273 - * Use firewall if possible 274 274 - * cloudflare tunnel fallback to reverse proxy bouncer 261 261 + ### Scenario 262 262 + 263 263 + * You have four machines in your lab: 264 264 + * **High Power Server (HPS)** that is the main "workhorse". It has the most memory and most compute. 265 265 + * **Low Power Server 1 (LPS1)** is a rasberry pi 4. You use it to **SSH** into your lab remotely. 266 266 + * It is the most stable machine because remote access needs to be available, always 267 267 + * **Low Power Server 2 (LPS2)** is a rasberry pi 4. It runs a **reverse proxy** where all external traffic is routed from. The traffic comes in through a router, or otherwise *not* a tunnel. 268 268 + * **Low Power Server 3 (LPS3)** is a mini pc. It runs **Nextcloud**, but not through the reverse proxy (for our contrived example). The traffic comes in through a router. 269 269 + * All of the externally accessible machines (LPS1-3) 270 270 + * have firewalls 271 271 + * You want to use crowdsec to protect these machines based on the activity they get from external traffic 272 272 + 273 273 + ### Architecture 274 274 + 275 275 +  276 276 + 277 277 + * To prevent [compute-intensive log processing](#log-processing-is-compute-intensive) from occurring on LPS1/LPS2 we will use a "centralized" [log processor](#log-processor) on HPS to ingest logs from LPS1/LPS2 using [Docker](https://docs.crowdsec.net/docs/next/log_processor/data_sources/docker) [acquistion data sources](#log-processor). 278 278 + 279 279 + * SSH log volume is unlikely to be as high as web traffic, and its more difficult (but not impossible) to offload this to HPS, so we will process SSH using a separate log processor directly on LPS1. 280 280 + 281 281 + * LPS1 is our more stable machine so we will deploy our [CS Management Instance](#management-instance-lapi) here as well, so that it's more likely all other components will always be able to reach it. 282 282 + 283 283 + * On each LPS machine we will install a CS [Firewall](https://docs.crowdsec.net/u/bouncers/firewall) [Bouncer](#bouncers) that will talk to our Management Instance on LPS1. 284 284 + 285 285 + Using the above plan best takes advantage of what our homelab has to offer: 286 286 + 287 287 + * Log processing and Management are independent instances which makes our [system more reliable](#separate-components-make-everything-more-reliable). 288 288 + * Offloading log processing where possible avoids [bottlenecking](#log-processing-is-compute-intensive) the hosts running critical services, and takes advantage of the higher compute from our HPS machine. 289 289 + 290 290 + Additionally, connecting our Management Instance to the Central API (Crowdsec cloud) means we get access to the [community blocklist](https://docs.crowdsec.net/docs/next/central_api/community_blocklist/) to proactively block threats with our firewall bouncers. 275 291 276 292 ## Implementation 277 293

assets/img/crowdsec/homelab-diagram-overview.png

Reviewed

This is a binary file and will not be displayed.

assets/img/crowdsec_bench/plot_13400.png assets/img/crowdsec/plot_13400.png

Reviewed

assets/img/crowdsec_bench/plot_6500t.png assets/img/crowdsec/plot_6500t.png

Reviewed

assets/img/crowdsec_bench/plot_pi4.png assets/img/crowdsec/plot_pi4.png

Reviewed

assets/img/crowdsec_bench/plot_pi5.png assets/img/crowdsec/plot_pi5.png

Reviewed