site updates
This commit is contained in:
Whisker Jones
127
tech_docs/networking/CCNA-exam-prep.md
Normal file
127
tech_docs/networking/CCNA-exam-prep.md
Normal file
@@ -0,0 +1,127 @@
|
||||
# CCNA 200-301 Official Cert Guide, Volume 1 Study Reference
|
||||
|
||||
## Introduction
|
||||
- Overview of CCNA 200-301
|
||||
- Study Plan Guidelines
|
||||
|
||||
## Part I: Introduction to Networking
|
||||
# CCNA 200-301 Official Cert Guide, Volume 1 - Study Reference
|
||||
|
||||
## Part I: Introduction to Networking
|
||||
|
||||
### Chapter 1: Introduction to TCP/IP Networking
|
||||
- **"Do I Know This Already?" Quiz**
|
||||
- **Foundation Topics**
|
||||
- Perspectives on Networking
|
||||
- TCP/IP Networking Model
|
||||
- History Leading to TCP/IP
|
||||
- Overview of the TCP/IP Networking Model
|
||||
- TCP/IP Application Layer
|
||||
- HTTP Overview
|
||||
- HTTP Protocol Mechanisms
|
||||
- TCP/IP Transport Layer
|
||||
- TCP Error Recovery Basics
|
||||
- Same-Layer and Adjacent-Layer Interactions
|
||||
- TCP/IP Network Layer
|
||||
- Internet Protocol and the Postal Service
|
||||
- Internet Protocol Addressing Basics
|
||||
- IP Routing Basics
|
||||
- TCP/IP Data-Link and Physical Layers
|
||||
- Data Encapsulation Terminology
|
||||
- Names of TCP/IP Messages
|
||||
- OSI Networking Model and Terminology
|
||||
- Comparing OSI and TCP/IP Layer Names and Numbers
|
||||
- OSI Data Encapsulation Terminology
|
||||
- **Chapter Review**
|
||||
|
||||
### Chapter 2: Fundamentals of Ethernet LANs
|
||||
- **"Do I Know This Already?" Quiz**
|
||||
- **Foundation Topics**
|
||||
- An Overview of LANs
|
||||
- Typical SOHO LANs
|
||||
- Typical Enterprise LANs
|
||||
- The Variety of Ethernet Physical Layer Standards
|
||||
- Consistent Behavior over All Links Using the Ethernet Data-Link Layer
|
||||
- Building Physical Ethernet LANs with UTP
|
||||
- Transmitting Data Using Twisted Pairs
|
||||
- Breaking Down a UTP Ethernet Link
|
||||
- UTP Cabling Pinouts for 10BASE-T and 100BASE-T
|
||||
- Straight-Through Cable Pinout
|
||||
- Choosing the Right Cable Pinouts
|
||||
- UTP Cabling Pinouts for 1000BASE-T
|
||||
- Building Physical Ethernet LANs with Fiber
|
||||
- Fiber Cabling Transmission Concepts
|
||||
- Using Fiber with Ethernet
|
||||
- Sending Data in Ethernet Networks
|
||||
- Ethernet Data-Link Protocols
|
||||
- Ethernet Addressing
|
||||
- Identifying Network Layer Protocols with the Ethernet Type Field
|
||||
- Error Detection with FCS
|
||||
- Sending Ethernet Frames with Switches and Hubs
|
||||
- Sending in Modern Ethernet LANs Using Full Duplex
|
||||
- Using Half Duplex with LAN Hubs
|
||||
- **Chapter Review**
|
||||
|
||||
### Chapter 3: Fundamentals of WANs and IP Routing
|
||||
- **Part I Review**
|
||||
|
||||
## Part II: Implementing Ethernet LANs
|
||||
### Chapter 4: Using the Command-Line Interface
|
||||
### Chapter 5: Analyzing Ethernet LAN Switching
|
||||
### Chapter 6: Configuring Basic Switch Management
|
||||
### Chapter 7: Configuring and Verifying Switch Interfaces
|
||||
- **Part II Review**
|
||||
|
||||
## Part III: Implementing VLANs and STP
|
||||
### Chapter 8: Implementing Ethernet Virtual LANs
|
||||
### Chapter 9: Spanning Tree Protocol Concepts
|
||||
### Chapter 10: RSTP and EtherChannel Configuration
|
||||
- **Part III Review**
|
||||
|
||||
## Part IV: IPv4 Addressing
|
||||
### Chapter 11: Perspectives on IPv4 Subnetting
|
||||
### Chapter 12: Analyzing Classful IPv4 Networks
|
||||
### Chapter 13: Analyzing Subnet Masks
|
||||
### Chapter 14: Analyzing Existing Subnets
|
||||
- **Part IV Review**
|
||||
|
||||
## Part V: IPv4 Routing
|
||||
### Chapter 15: Operating Cisco Routers
|
||||
### Chapter 16: Configuring IPv4 Addresses and Static Routes
|
||||
### Chapter 17: IP Routing in the LAN
|
||||
### Chapter 18: Troubleshooting IPv4 Routing
|
||||
- **Part V Review**
|
||||
|
||||
## Part VI: OSPF
|
||||
### Chapter 19: Understanding OSPF Concepts
|
||||
### Chapter 20: Implementing OSPF
|
||||
### Chapter 21: OSPF Network Types and Neighbors
|
||||
- **Part VI Review**
|
||||
|
||||
## Part VII: IP Version 6
|
||||
### Chapter 22: Fundamentals of IP Version 6
|
||||
### Chapter 23: IPv6 Addressing and Subnetting
|
||||
### Chapter 24: Implementing IPv6 Addressing on Routers
|
||||
### Chapter 25: Implementing IPv6 Routing
|
||||
- **Part VII Review**
|
||||
|
||||
## Part VIII: Wireless LANs
|
||||
### Chapter 26: Fundamentals of Wireless Networks
|
||||
### Chapter 27: Analyzing Cisco Wireless Architectures
|
||||
### Chapter 28: Securing Wireless Networks
|
||||
### Chapter 29: Building a Wireless LAN
|
||||
- **Part VIII Review**
|
||||
|
||||
## Part IX: Appendixes and Online Resources
|
||||
- Appendix A: Numeric Reference Tables
|
||||
- Appendix B: CCNA 200-301, Volume 1 Exam Updates
|
||||
- Appendix C: Answers to Quizzes
|
||||
- Glossary
|
||||
- Index
|
||||
- Online Appendixes (D to R) for additional practice and topics
|
||||
|
||||
### **Study Tips**
|
||||
- Regularly review each part and complete associated quizzes.
|
||||
- Utilize online appendixes for practical exercises.
|
||||
- Follow the study planner for systematic progress.
|
||||
- Engage with study aids like the glossary and index for quick references.
|
||||
197
tech_docs/networking/NordVPN.md
Normal file
197
tech_docs/networking/NordVPN.md
Normal file
@@ -0,0 +1,197 @@
|
||||
Absolutely, let’s streamline the steps to set up NordVPN on a fresh OpenWrt device using CLI commands. This guide assumes you have basic knowledge of how to access your router via SSH and that OpenWrt is already installed on your device.
|
||||
|
||||
### Step 1: Access Your Router
|
||||
Connect to your router via SSH:
|
||||
```bash
|
||||
ssh root@192.168.1.1
|
||||
```
|
||||
Replace `192.168.1.1` with your router's IP address if it has been changed from the default.
|
||||
|
||||
### Step 2: Update and Install Necessary Packages
|
||||
Update the package manager and install OpenVPN and the necessary IP utilities:
|
||||
```bash
|
||||
opkg update
|
||||
opkg install openvpn-openssl ip-full
|
||||
```
|
||||
|
||||
### Step 3: Download and Set Up NordVPN Configuration Files
|
||||
Choose a NordVPN server that you want to connect to and download its OpenVPN UDP configuration. You can find server configurations on the NordVPN website.
|
||||
|
||||
1. **Download a server config file directly to your router**:
|
||||
Replace `SERVERNAME` with your chosen server's name.
|
||||
```bash
|
||||
wget -P /etc/openvpn https://downloads.nordcdn.com/configs/files/ovpn_udp/servers/SERVERNAME.udp.ovpn
|
||||
```
|
||||
|
||||
2. **Rename the downloaded configuration file for easier management**:
|
||||
```bash
|
||||
mv /etc/openvpn/SERVERNAME.udp.ovpn /etc/openvpn/nordvpn.ovpn
|
||||
```
|
||||
|
||||
### Step 4: Configure VPN Credentials
|
||||
NordVPN requires authentication with your service credentials.
|
||||
|
||||
1. **Create a credentials file**:
|
||||
Open a new file using `nano`:
|
||||
```bash
|
||||
nano /etc/openvpn/credentials
|
||||
```
|
||||
Enter your NordVPN username and password, each on a separate line. Save and close the editor.
|
||||
|
||||
2. **Modify the NordVPN configuration file to use the credentials file**:
|
||||
```bash
|
||||
sed -i 's/auth-user-pass/auth-user-pass \/etc\/openvpn\/credentials/' /etc/openvpn/nordvpn.ovpn
|
||||
```
|
||||
|
||||
### Step 5: Enable and Start OpenVPN
|
||||
1. **Automatically start OpenVPN with the NordVPN configuration on boot**:
|
||||
```bash
|
||||
echo 'openvpn --config /etc/openvpn/nordvpn.ovpn &' >> /etc/rc.local
|
||||
```
|
||||
|
||||
2. **Start OpenVPN manually for the first time**:
|
||||
```bash
|
||||
/etc/init.d/openvpn start
|
||||
```
|
||||
|
||||
### Step 6: Configure Network and Firewall
|
||||
Ensure the VPN traffic is properly routed and the firewall is configured to allow it.
|
||||
|
||||
1. **Edit the network configuration**:
|
||||
Add a new interface for the VPN:
|
||||
```bash
|
||||
uci set network.vpn0=interface
|
||||
uci set network.vpn0.ifname='tun0'
|
||||
uci set network.vpn0.proto='none'
|
||||
uci commit network
|
||||
```
|
||||
|
||||
2. **Set up the firewall to allow traffic from LAN to the VPN**:
|
||||
```bash
|
||||
uci add firewall zone
|
||||
uci set firewall.@zone[-1].name='vpn'
|
||||
uci set firewall.@zone[-1].network='vpn0'
|
||||
uci set firewall.@zone[-1].input='REJECT'
|
||||
uci set firewall.@zone[-1].output='ACCEPT'
|
||||
uci set firewall.@zone[-1].forward='REJECT'
|
||||
uci set firewall.@zone[-1].masq='1'
|
||||
uci commit firewall
|
||||
uci add firewall forwarding
|
||||
uci set firewall.@forwarding[-1].src='lan'
|
||||
uci set firewall.@forwarding[-1].dest='vpn'
|
||||
uci commit firewall
|
||||
```
|
||||
|
||||
3. **Restart the firewall to apply changes**:
|
||||
```bash
|
||||
/etc/init.d/firewall restart
|
||||
```
|
||||
|
||||
### Step 7: Test the Connection
|
||||
Check if the VPN connection is active and working:
|
||||
```bash
|
||||
ping -c 4 google.com
|
||||
```
|
||||
|
||||
You should now be connected to NordVPN through your OpenWrt router using the configured OpenVPN setup. This streamlined guide ensures you have a clear path through the configuration process with easy-to-follow CLI commands.
|
||||
|
||||
---
|
||||
|
||||
The CLI instructions you're interested in offer a more hands-on approach to setting up NordVPN on an OpenWrt router. This method is ideal if you're comfortable using the command line and want more control over the VPN configuration. Here's a simplified version of the process, broken down into manageable steps:
|
||||
|
||||
### 1. Access Router via SSH
|
||||
Connect to your OpenWrt router using SSH. The default IP is usually `192.168.1.1` unless you have changed it. The default username is `root`.
|
||||
|
||||
### 2. Install Necessary Packages
|
||||
Update your package list and install the required OpenVPN packages:
|
||||
```bash
|
||||
opkg update
|
||||
opkg install openvpn-openssl ip-full luci-app-openvpn
|
||||
```
|
||||
(Optional) Install `nano` for easier file editing:
|
||||
```bash
|
||||
opkg install nano
|
||||
```
|
||||
|
||||
### 3. Download OpenVPN Configuration
|
||||
Use NordVPN's server recommendation tool to find the best server and download its configuration file directly to your router:
|
||||
```bash
|
||||
wget -P /etc/openvpn https://downloads.nordcdn.com/configs/files/ovpn_udp/servers/[server-name].udp.ovpn
|
||||
```
|
||||
Replace `[server-name]` with the actual server name, such as `uk2054.nordvpn.com`.
|
||||
|
||||
### 4. Configure OpenVPN
|
||||
Edit the downloaded .ovpn file to include your NordVPN credentials:
|
||||
```bash
|
||||
nano /etc/openvpn/[server-name].udp.ovpn
|
||||
```
|
||||
Modify the `auth-user-pass` line to point to a credentials file:
|
||||
```plaintext
|
||||
auth-user-pass /etc/openvpn/credentials
|
||||
```
|
||||
Create the credentials file:
|
||||
```bash
|
||||
echo "YourUsername" > /etc/openvpn/credentials
|
||||
echo "YourPassword" >> /etc/openvpn/credentials
|
||||
chmod 600 /etc/openvpn/credentials
|
||||
```
|
||||
|
||||
### 5. Enable OpenVPN to Start on Boot
|
||||
Ensure OpenVPN starts automatically with your router:
|
||||
```bash
|
||||
/etc/init.d/openvpn enable
|
||||
```
|
||||
|
||||
### 6. Set Up Networking and Firewall
|
||||
Create a new network interface for the VPN and configure the firewall to route traffic through the VPN:
|
||||
|
||||
**Network Interface Configuration:**
|
||||
```bash
|
||||
uci set network.nordvpntun=interface
|
||||
uci set network.nordvpntun.proto='none'
|
||||
uci set network.nordvpntun.ifname='tun0'
|
||||
uci commit network
|
||||
```
|
||||
|
||||
**Firewall Configuration:**
|
||||
```bash
|
||||
uci add firewall zone
|
||||
uci set firewall.@zone[-1].name='vpnfirewall'
|
||||
uci set firewall.@zone[-1].input='REJECT'
|
||||
uci set firewall.@zone[-1].output='ACCEPT'
|
||||
uci set firewall.@zone[-1].forward='REJECT'
|
||||
uci set firewall.@zone[-1].masq='1'
|
||||
uci set firewall.@zone[-1].mtu_fix='1'
|
||||
uci add_list firewall.@zone[-1].network='nordvpntun'
|
||||
uci add firewall forwarding
|
||||
uci set firewall.@forwarding[-1].src='lan'
|
||||
uci set firewall.@forwarding[-1].dest='vpnfirewall'
|
||||
uci commit firewall
|
||||
```
|
||||
|
||||
### 7. Configure DNS
|
||||
Change DNS settings to use NordVPN DNS or another preferred DNS service:
|
||||
```bash
|
||||
uci set network.wan.peerdns='0'
|
||||
uci del network.wan.dns
|
||||
uci add_list network.wan.dns='103.86.96.100'
|
||||
uci add_list network.wan.dns='103.86.99.100'
|
||||
uci commit
|
||||
```
|
||||
|
||||
### 8. Prevent Traffic Leakage (Optional)
|
||||
To enhance security, add custom rules to block all traffic if the VPN disconnects:
|
||||
```bash
|
||||
echo "if (! ip a s tun0 up) && (! iptables -C forwarding_rule -j REJECT); then iptables -I forwarding_rule -j REJECT; fi" >> /etc/firewall.user
|
||||
```
|
||||
|
||||
### 9. Start the VPN
|
||||
Start the OpenVPN service and verify it's running properly:
|
||||
```bash
|
||||
/etc/init.d/openvpn start
|
||||
```
|
||||
|
||||
### 10. Check Connection Status
|
||||
Visit NordVPN's homepage or another site like `ipinfo.io` to check your IP address and ensure your traffic is routed through the VPN.
|
||||
|
||||
This setup should give you a robust and secure VPN connection on your OpenWrt router using NordVPN. If you encounter any issues, you may need to review the configuration steps or consult NordVPN's support for further troubleshooting.
|
||||
229
tech_docs/networking/OpenWrt.md
Normal file
229
tech_docs/networking/OpenWrt.md
Normal file
@@ -0,0 +1,229 @@
|
||||
```bash
|
||||
pct create 100 /var/lib/vz/template/cache/openwrt-rootfs.tar.xz \
|
||||
--unprivileged 1 --arch amd64 --ostype unmanaged --hostname openwrt-0 \
|
||||
--password fuzzy817 --tag network --storage local-lvm --memory 256 --swap 128 \
|
||||
--rootfs local-lvm:1,size=512M --net0 name=eth0,bridge=vmbr0,firewall=1 \
|
||||
--net1 name=eth1,bridge=vmbr1,firewall=1 --cores 1 --cpuunits 500 --onboot 1 --debug 0
|
||||
```
|
||||
|
||||
```bash
|
||||
pct start 100
|
||||
```
|
||||
|
||||
```bash
|
||||
pct create 110 /var/lib/vz/template/cache/kali-rootfs.tar.xz \
|
||||
--unprivileged 1 --arch amd64 --ostype debian --hostname kali-0 \
|
||||
--password fuzzy817 --tag tools --storage zfs-disk0 --cores 2 \
|
||||
--memory 2048 --swap 1024 --rootfs local-lvm:1,size=64G \
|
||||
--net0 name=eth0,bridge=vmbr0,firewall=1 --cpuunits 1500 --onboot 1 \
|
||||
--debug 0 --features nesting=1,keyctl=1
|
||||
```
|
||||
```bash
|
||||
pct start 110
|
||||
```
|
||||
|
||||
```bash
|
||||
pct create 120 /var/lib/vz/template/cache/alpine-rootfs.tar.xz \
|
||||
--unprivileged 1 --arch amd64 --ostype alpine --hostname alpine-0 \
|
||||
--password fuzzy817 --tag docker --storage local-lvm --cores 2 \
|
||||
--memory 1024 --swap 256 --rootfs local-lvm:1,size=8G \
|
||||
--net0 name=eth0,bridge=vmbr0,firewall=1 --cpuunits 1000 --onboot 1 \
|
||||
--debug 0 --features nesting=1,keyctl=1
|
||||
```
|
||||
```bash
|
||||
pct start 120
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Proxmox Container Setup Guide
|
||||
|
||||
## Introduction
|
||||
This guide provides detailed instructions for configuring OpenWRT, Alpine Linux, and Kali Linux containers on a Proxmox VE environment. Each section covers the creation, configuration, and basic setup steps necessary to get each type of container up and running, tailored for use in a lab setting.
|
||||
|
||||
## Links
|
||||
- [Split A GPU Between Multiple Computers - Proxmox LXC (Unprivileged)](https://youtu.be/0ZDr5h52OOE?si=F4RVd5mA5IRjrpXU)
|
||||
- [Must-Have OpenWrt Router Setup For Your Proxmox](https://youtu.be/3mPbrunpjpk?si=WofNEJUZL4FAw7HP)
|
||||
- [Docker on Proxmox LXC 🚀 Zero Bloat and Pure Performance!](https://youtu.be/-ZSQdJ62r-Q?si=GCXOEsKnOdm6OIiz)
|
||||
|
||||
## Prerequisites
|
||||
- Proxmox VE installed on your server
|
||||
- Access to Proxmox web interface or command-line interface
|
||||
- Container templates downloaded (OpenWRT, Alpine, Kali Linux)
|
||||
|
||||
## Container Configuration
|
||||
### OpenWRT Container Setup
|
||||
#### Description
|
||||
This section details setting up an OpenWRT container designed for network routing and firewall tasks.
|
||||
|
||||
#### Create and Configure the OpenWRT Container
|
||||
```bash
|
||||
pct create 100 /var/lib/vz/template/cache/openwrt-rootfs.tar.xz \
|
||||
--unprivileged 1 --arch amd64 --ostype unmanaged --hostname openwrt-0 \
|
||||
--password <password> --tag network --storage local-lvm --memory 256 --swap 128 \
|
||||
--rootfs local-lvm:1,size=512M --net0 name=eth0,bridge=vmbr0,firewall=1 \
|
||||
--net1 name=eth1,bridge=vmbr1,firewall=1 --cores 1 --cpuunits 500 --onboot 1 --debug 0
|
||||
```
|
||||
|
||||
#### Start the Container and Access the Console
|
||||
```bash
|
||||
pct start 100
|
||||
pct console 100
|
||||
```
|
||||
|
||||
#### Update and Install Packages
|
||||
```bash
|
||||
opkg update
|
||||
opkg install qemu-ga
|
||||
reboot
|
||||
```
|
||||
|
||||
#### Network and Firewall Configuration
|
||||
Configure network settings and firewall rules:
|
||||
```bash
|
||||
vi /etc/config/network
|
||||
/etc/init.d/network restart
|
||||
|
||||
vi /etc/config/firewall
|
||||
/etc/init.d/firewall restart
|
||||
|
||||
# Setting up firewall rules using UCI
|
||||
uci add firewall rule
|
||||
uci set firewall.@rule[-1].name='Allow-SSH'
|
||||
uci set firewall.@rule[-1].src='wan'
|
||||
uci set firewall.@rule[-1].proto='tcp'
|
||||
uci set firewall.@rule[-1].dest_port='22'
|
||||
uci set firewall.@rule[-1].target='ACCEPT'
|
||||
|
||||
uci add firewall rule
|
||||
uci set firewall.@rule[-1].name='Allow-HTTPS'
|
||||
uci set firewall.@rule[-1].src='wan'
|
||||
uci set firewall.@rule[-1].proto='tcp'
|
||||
uci set firewall.@rule[-1].dest_port='443'
|
||||
uci set firewall.@rule[-1].target='ACCEPT'
|
||||
|
||||
uci add firewall rule
|
||||
uci set firewall.@rule[-1].name='Allow-HTTP'
|
||||
uci set firewall.@rule[-1].src='wan'
|
||||
uci set firewall.@rule[-1].proto='tcp'
|
||||
uci set firewall.@rule[-1].dest_port='80'
|
||||
uci set firewall.@rule[-1].target='ACCEPT'
|
||||
|
||||
uci commit firewall
|
||||
/etc/init.d/firewall restart
|
||||
```
|
||||
|
||||
### Alpine Container Setup
|
||||
#### Description
|
||||
Set up an Alpine Linux container optimized for running Docker, ensuring lightweight deployment and management of Docker applications.
|
||||
|
||||
#### Create and Configure the Alpine Container
|
||||
```bash
|
||||
pct create 120 /var/lib/vz/template/cache/alpine-rootfs.tar.xz \
|
||||
--unprivileged 1 --arch amd64 --ostype alpine --hostname alpine-0 \
|
||||
--password <password> --tag docker --storage local-lvm --cores 2 \
|
||||
--memory 1024 --swap 256 --rootfs local-lvm:1,size=8G \
|
||||
--net0 name=eth0,bridge=vmbr0,firewall=1 --keyctl 1 --nesting 1 \
|
||||
--cpuunits 1000 --onboot 1 --debug 0
|
||||
```
|
||||
|
||||
#### Enter the Container
|
||||
```bash
|
||||
pct enter 120
|
||||
```
|
||||
|
||||
#### System Update and Package Installation
|
||||
Enable community repositories and install essential packages:
|
||||
```bash
|
||||
sed -i '/^#.*community/s/^#//' /etc/apk/repositories
|
||||
apk update && apk upgrade
|
||||
apk add qemu-guest-agent docker openssh sudo
|
||||
```
|
||||
|
||||
#### Start and Enable Docker Service
|
||||
```bash
|
||||
rc-service docker start
|
||||
rc-update add docker default
|
||||
```
|
||||
|
||||
#### Configure Network
|
||||
Set up network interfaces and restart networking services:
|
||||
```bash
|
||||
setup-interfaces
|
||||
service networking restart
|
||||
```
|
||||
|
||||
#### Configure and Start SSH Service
|
||||
```bash
|
||||
rc-update add sshd
|
||||
service sshd start
|
||||
vi /etc/ssh/sshd_config
|
||||
service sshd restart
|
||||
```
|
||||
|
||||
#### Create a System User and Add to Docker Group and Sudoers
|
||||
```bash
|
||||
adduser -s /bin/ash medusa
|
||||
addgroup medusa docker
|
||||
echo "medusa ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/medusa
|
||||
```
|
||||
|
||||
#### Test Docker Installation
|
||||
```bash
|
||||
docker run hello-world
|
||||
```
|
||||
|
||||
```bash
|
||||
docker volume create portainer_data
|
||||
```
|
||||
|
||||
```bash
|
||||
docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest
|
||||
```
|
||||
|
||||
```markdown
|
||||
[Portainer Dashboard](https://localhost:9443)
|
||||
```
|
||||
|
||||
### Kali Linux Container Setup
|
||||
#### Description
|
||||
Configure a Kali Linux container tailored for security testing and penetration testing tools.
|
||||
|
||||
#### Create and Configure the Kali Linux Container
|
||||
```bash
|
||||
pct create 110 /var/lib/vz/template/cache/kali-default-rootfs.tar.xz \
|
||||
--unprivileged 1 --arch amd64 --ostype debian --hostname kali-0 \
|
||||
--password <password> --tag tools --storage local-lvm --cores 2 \
|
||||
--memory 2048 --swap 1024 --rootfs local-lvm:1,size=10G \
|
||||
--net0 name=eth0,bridge=vmbr0,firewall=1 --cpuunits 1500 --onboot 1 \
|
||||
--debug 0 --features nesting=1,keyctl=1
|
||||
```
|
||||
|
||||
## Conclusion
|
||||
Follow these steps to successfully set up and configure OpenWRT, Alpine, and Kali Linux containers on Proxmox. Adjust configurations according to your specific needs and ensure all passwords are secure before deploying containers in a production environment.
|
||||
|
||||
```bash
|
||||
pct create 100 /var/lib/vz/template/cache/openwrt-rootfs.tar.xz \
|
||||
--unprivileged 1 --arch amd64 --ostype unmanaged --hostname openwrt-0 \
|
||||
--password <password> --tag network --storage local-lvm --memory 256 --swap 128 \
|
||||
--rootfs local-lvm:1,size=512M --net0 name=eth0,bridge=vmbr0,firewall=1 \
|
||||
--net1 name=eth1,bridge=vmbr1,firewall=1 --cores 1 --cpuunits 500 --onboot 1 --debug 0
|
||||
```
|
||||
|
||||
```bash
|
||||
pct create 110 /var/lib/vz/template/cache/kali-default-rootfs.tar.xz \
|
||||
--unprivileged 1 --arch amd64 --ostype debian --hostname kali-0 \
|
||||
--password <password> --tag tools --storage local-lvm --cores 2 \
|
||||
--memory 2048 --swap 1024 --rootfs local-lvm:1,size=10G \
|
||||
--net0 name=eth0,bridge=vmbr0,firewall=1 --cpuunits 1500 --onboot 1 \
|
||||
--debug 0 --features nesting=1,keyctl=1
|
||||
```
|
||||
|
||||
```bash
|
||||
pct create 120 /var/lib/vz/template/cache/alpine-rootfs.tar.xz \
|
||||
--unprivileged 1 --arch amd64 --ostype alpine --hostname alpine-0 \
|
||||
--password <password> --tag docker --storage local-lvm --cores 2 \
|
||||
--memory 1024 --swap 256 --rootfs local-lvm:1,size=8G \
|
||||
--net0 name=eth0,bridge=vmbr0,firewall=1 --keyctl 1 --nesting 1 \
|
||||
--cpuunits 1000 --onboot 1 --debug 0
|
||||
```
|
||||
99
tech_docs/networking/SOAR_lab.md
Normal file
99
tech_docs/networking/SOAR_lab.md
Normal file
@@ -0,0 +1,99 @@
|
||||
Creating a security operations environment with Wazuh and integrating Shuffle SOAR can greatly enhance your ability to monitor, analyze, and respond to threats in real time. Here's a consolidated reference guide to get you started, detailing the components needed, benefits, and areas of focus relevant today and into the future.
|
||||
|
||||
### Getting Started with Wazuh
|
||||
|
||||
**Installation and Configuration:**
|
||||
- **Wazuh Server Setup:** Begin by installing the Wazuh server, which involves adding the Wazuh repository to your system, installing the Wazuh manager, and configuring Filebeat for log forwarding【5†source】.
|
||||
- **Component Overview:** Wazuh consists of a universal agent, Wazuh server (manager), Wazuh indexer, and Wazuh dashboard for visualizing the data【6†source】【7†source】.
|
||||
|
||||
### Integrating Shuffle SOAR
|
||||
|
||||
**Setup and Integration:**
|
||||
- **Configuring Wazuh for Shuffle:** Configure Wazuh to forward alerts in JSON format to Shuffle by setting up an integration block in the `ossec.conf` file of the Wazuh manager【13†source】【14†source】.
|
||||
- **Creating Workflows in Shuffle:** Use Shuffle to create workflows that will process the Wazuh alerts. You can automate various security operations based on the type of alerts received, such as disabling a user account in response to detected threats【13†source】.
|
||||
|
||||
### Key Components and Benefits
|
||||
|
||||
- **Unified Security Monitoring:** Wazuh provides a comprehensive platform for threat detection, incident response, and compliance monitoring across your environment.
|
||||
- **Automation and Response:** Shuffle SOAR enables the automation of security operations, reducing response times to threats and freeing up resources for other critical tasks.
|
||||
- **Flexibility and Scalability:** Both Wazuh and Shuffle are designed to be scalable and flexible, allowing for customization according to specific organizational needs.
|
||||
|
||||
### Areas of Focus
|
||||
|
||||
1. **Threat Detection and Response:** Leveraging Wazuh's detection capabilities with Shuffle's automated workflows can significantly improve the efficiency of threat detection and response mechanisms.
|
||||
2. **Compliance and Auditing:** Wazuh's comprehensive monitoring and logging capabilities are invaluable for meeting compliance requirements and conducting audits.
|
||||
3. **Security Orchestration:** The integration of SOAR tools like Shuffle into security operations centers (SOCs) is becoming increasingly important for orchestrating responses to security incidents.
|
||||
4. **Cloud Security:** With the shift towards cloud environments, focusing on cloud-specific security challenges and integrating cloud-native tools into your security stack is crucial.
|
||||
|
||||
### Looking Ahead
|
||||
|
||||
- **Machine Learning and AI:** Incorporating machine learning and AI for anomaly detection and predictive analytics will become more prevalent, offering advanced threat detection capabilities.
|
||||
- **Zero Trust Architecture:** Implementing Zero Trust principles, supported by continuous monitoring and verification from solutions like Wazuh, will be critical for securing modern networks.
|
||||
- **Enhanced Automation:** The future lies in further automating security responses and operational tasks, reducing the time from threat detection to resolution.
|
||||
|
||||
### Conclusion
|
||||
|
||||
By integrating Wazuh with Shuffle SOAR, organizations can create a robust security operations framework capable of addressing modern security challenges. This guide serves as a starting point for building and enhancing your security posture with these powerful tools. As you implement and scale your operations, keep abreast of emerging technologies and security practices to ensure your environment remains secure and resilient against evolving threats.
|
||||
|
||||
|
||||
---
|
||||
|
||||
Given the topics covered, here are several labs and learning experiences designed to enhance your skills with Wazuh and Shuffle SOAR, particularly within a virtualized environment using KVM and isolated bridge networks. These exercises aim to provide hands-on experience, from basic setups to more advanced integrations and security practices.
|
||||
|
||||
### Lab 1: Basic Wazuh Server and Agent Setup
|
||||
|
||||
**Objective:** Install and configure a basic Wazuh server and agent setup within a KVM virtualized environment.
|
||||
|
||||
**Tasks:**
|
||||
1. Create a VM for the Wazuh server on KVM, ensuring it is connected to an isolated bridge network.
|
||||
2. Install the Wazuh server on this VM, following the [official documentation](https://documentation.wazuh.com/current/installation-guide/wazuh-server/index.html).
|
||||
3. Create another VM for the Wazuh agent, connected to the same isolated bridge network.
|
||||
4. Install the Wazuh agent and register it with the Wazuh server.
|
||||
|
||||
**Learning Outcome:** Understand the process of setting up Wazuh in a virtualized environment and the basic communication between server and agent.
|
||||
|
||||
### Lab 2: Advanced Wazuh Features Exploration
|
||||
|
||||
**Objective:** Explore advanced features of Wazuh, such as rule writing, log analysis, and file integrity monitoring.
|
||||
|
||||
**Tasks:**
|
||||
1. Write custom detection rules for simulated threats (e.g., unauthorized SSH login attempts).
|
||||
2. Configure and test file integrity monitoring on the agent VM.
|
||||
3. Use the Wazuh Kibana app to analyze logs and alerts generated by the agent.
|
||||
|
||||
**Learning Outcome:** Gain hands-on experience with Wazuh's advanced capabilities for threat detection and response.
|
||||
|
||||
### Lab 3: Integrating Wazuh with Shuffle SOAR
|
||||
|
||||
**Objective:** Integrate Wazuh with Shuffle SOAR to automate responses to specific alerts.
|
||||
|
||||
**Tasks:**
|
||||
1. Set up a basic Shuffle workflow that responds to a common threat detected by Wazuh (e.g., disabling a compromised user account).
|
||||
2. Configure Wazuh to forward alerts to Shuffle using webhooks.
|
||||
3. Simulate a threat that triggers the Wazuh alert and observe the automated response from Shuffle.
|
||||
|
||||
**Learning Outcome:** Learn how to automate security operations by integrating Wazuh with a SOAR platform.
|
||||
|
||||
### Lab 4: Security Hardening and Monitoring of Wazuh Environment
|
||||
|
||||
**Objective:** Apply security best practices to harden the Wazuh environment and set up monitoring.
|
||||
|
||||
**Tasks:**
|
||||
1. Implement SSH key-based authentication for VMs.
|
||||
2. Configure firewall rules to restrict access to the Wazuh server.
|
||||
3. Set up monitoring for the Wazuh server using tools like Grafana to visualize logs and performance metrics.
|
||||
|
||||
**Learning Outcome:** Understand the importance of security hardening and continuous monitoring in a security operations environment.
|
||||
|
||||
### Lab 5: Cloud Integration and Elastic Stack
|
||||
|
||||
**Objective:** Explore the integration of Wazuh with cloud services and Elastic Stack for enhanced log analysis and visualization.
|
||||
|
||||
**Tasks:**
|
||||
1. Configure Wazuh to monitor a cloud service (e.g., AWS S3 bucket for access logs).
|
||||
2. Set up Elastic Stack (Elasticsearch, Logstash, Kibana) and integrate it with Wazuh for advanced log analysis.
|
||||
3. Create dashboards in Kibana to visualize and analyze data from cloud services.
|
||||
|
||||
**Learning Outcome:** Gain insights into how Wazuh can be used for monitoring cloud environments and the integration with Elastic Stack for log management.
|
||||
|
||||
These labs offer a comprehensive learning path from basic setup to advanced usage and integration of Wazuh in a secure, virtualized environment. Working through these exercises will build a solid foundation in security monitoring, threat detection, and automated response strategies.
|
||||
230
tech_docs/networking/cybersecurity_getting_started.md
Normal file
230
tech_docs/networking/cybersecurity_getting_started.md
Normal file
@@ -0,0 +1,230 @@
|
||||
# Building a Cybersecurity Lab with Docker and Active Directory Integration
|
||||
|
||||
## Introduction
|
||||
This guide provides a comprehensive walkthrough for creating an advanced cybersecurity lab environment using Docker and Docker Compose, integrated with a `homelab.local` Active Directory domain. The lab is designed to offer a flexible, scalable, and easily manageable platform for cybersecurity professionals and enthusiasts to practice, experiment, and enhance their skills in various security domains.
|
||||
|
||||
## Lab Architecture
|
||||
The lab architecture consists of the following key components:
|
||||
1. **Learning Paths**: The lab is organized into distinct learning paths, each focusing on a specific cybersecurity domain, such as network security, web application security, incident response, and malware analysis. This structure enables targeted skill development and focused experimentation.
|
||||
|
||||
2. **Docker Containers**: Each learning path is implemented using Docker containers, providing isolated and reproducible environments for different security scenarios and tools. Containers ensure efficient resource utilization and ease of management.
|
||||
|
||||
3. **Docker Compose**: Docker Compose is employed for orchestrating and managing the containers within each learning path. It allows for defining and configuring multiple services, networks, and volumes, simplifying the deployment and management of complex security environments.
|
||||
|
||||
4. **Active Directory Integration**: The lab is integrated with a `homelab.local` Active Directory domain, enabling centralized user and resource management. This integration provides a realistic enterprise network simulation and allows for practicing security scenarios in a controlled Active Directory environment.
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Host Machine] --> B[Docker]
|
||||
B --> C[Network Security]
|
||||
B --> D[Web Application Security]
|
||||
B --> E[Incident Response and Forensics]
|
||||
B --> F[Malware Analysis]
|
||||
|
||||
G[homelab.local] --> H[Active Directory Integration]
|
||||
H --> B
|
||||
```
|
||||
|
||||
## Lab Setup
|
||||
To set up the cybersecurity lab, follow these step-by-step instructions:
|
||||
|
||||
### Prerequisites
|
||||
- A host machine or dedicated server with sufficient resources (CPU, RAM, storage) to run multiple Docker containers.
|
||||
- Docker and Docker Compose installed on the host machine.
|
||||
- Access to the `homelab.local` Active Directory domain and its resources.
|
||||
|
||||
### Step 1: Active Directory Integration
|
||||
1. Ensure that the `homelab.local` Active Directory domain is properly set up and accessible from the host machine.
|
||||
2. Create the necessary user accounts, security groups, and organizational units (OUs) within the Active Directory domain to mirror a realistic enterprise environment.
|
||||
|
||||
### Step 2: Docker and Docker Compose Setup
|
||||
1. Install Docker and Docker Compose on the host machine following the official documentation for your operating system.
|
||||
2. Verify the successful installation by running `docker --version` and `docker-compose --version` in the terminal.
|
||||
|
||||
### Step 3: Learning Paths Structure
|
||||
1. Create a dedicated directory for each learning path on the host machine, such as `network-security`, `web-app-security`, `incident-response`, and `malware-analysis`.
|
||||
2. Within each learning path directory, create a `Dockerfile` that defines the container environment, including the necessary tools, dependencies, and configurations specific to that learning path.
|
||||
3. Create a `docker-compose.yml` file in each learning path directory to define the services, networks, and volumes required for that specific path.
|
||||
|
||||
### Step 4: Configuration and Deployment
|
||||
1. Customize the `Dockerfile` for each learning path, specifying the base image, installing required packages, and configuring the environment variables and settings.
|
||||
2. Modify the `docker-compose.yml` file for each learning path, defining the services, networks, and volumes necessary for the specific security scenario or tool.
|
||||
3. Use Docker Compose to build and deploy the containers for each learning path by running `docker-compose up -d` in the respective directory.
|
||||
|
||||
### Step 5: Central Management
|
||||
1. Create a central `docker-compose.yml` file at the root level of the lab directory to manage and orchestrate all the learning path containers collectively.
|
||||
2. Consider using tools like Portainer or Rancher for a web-based GUI to manage and monitor the Docker containers, networks, and volumes across the entire lab.
|
||||
|
||||
## Cybersecurity Learning Paths
|
||||
The lab provides the following learning paths to cover various aspects of cybersecurity:
|
||||
|
||||
### 1. Network Security
|
||||
- **Packet Analysis**: Utilize tools like Wireshark and tcpdump to capture and analyze network traffic, identify anomalies, and detect potential security threats.
|
||||
- **Firewall Configuration**: Configure and manage firewalls using tools like iptables and pfsense to control network traffic, implement access controls, and enforce security policies.
|
||||
- **Intrusion Detection and Prevention**: Deploy and configure intrusion detection systems (IDS) and intrusion prevention systems (IPS) using tools like Snort and Suricata to monitor network traffic and detect and prevent malicious activities.
|
||||
- **VPN and Secure Communication**: Set up and configure virtual private networks (VPNs) using OpenVPN or WireGuard to establish secure communication channels between different network segments and remote locations.
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Network Security] --> B[Packet Analysis]
|
||||
A --> C[Firewall Configuration]
|
||||
A --> D[Intrusion Detection and Prevention]
|
||||
A --> E[VPN and Secure Communication]
|
||||
|
||||
B --> B1[Wireshark]
|
||||
B --> B2[tcpdump]
|
||||
|
||||
C --> C1[iptables]
|
||||
C --> C2[pfsense]
|
||||
|
||||
D --> D1[Snort]
|
||||
D --> D2[Suricata]
|
||||
|
||||
E --> E1[OpenVPN]
|
||||
E --> E2[WireGuard]
|
||||
```
|
||||
|
||||
### 2. Web Application Security
|
||||
- **Vulnerability Assessment**: Perform web application vulnerability scanning and assessment using tools like OWASP ZAP, Burp Suite, and Nikto to identify common web vulnerabilities such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF).
|
||||
- **Penetration Testing**: Conduct in-depth penetration testing on web applications using tools and frameworks like Metasploit, sqlmap, and BeEF to identify and exploit vulnerabilities, and assess the application's resilience to attacks.
|
||||
- **Web Application Firewall (WAF)**: Configure and deploy WAFs using tools like ModSecurity and NAXSI to protect web applications from common attacks, enforce security rules, and monitor web traffic for suspicious activities.
|
||||
- **API Security**: Test and secure RESTful APIs using tools like Postman and Swagger to validate API functionality, authentication, authorization, and input validation.
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Web Application Security] --> B[Vulnerability Assessment]
|
||||
A --> C[Penetration Testing]
|
||||
A --> D[Web Application Firewall]
|
||||
A --> E[API Security]
|
||||
|
||||
B --> B1[OWASP ZAP]
|
||||
B --> B2[Burp Suite]
|
||||
B --> B3[Nikto]
|
||||
|
||||
C --> C1[Metasploit]
|
||||
C --> C2[sqlmap]
|
||||
C --> C3[BeEF]
|
||||
|
||||
D --> D1[ModSecurity]
|
||||
D --> D2[NAXSI]
|
||||
|
||||
E --> E1[Postman]
|
||||
E --> E2[Swagger]
|
||||
```
|
||||
|
||||
|
||||
### 3. Incident Response and Forensics
|
||||
- **Incident Response Planning**: Develop and practice incident response procedures using the lab environment to simulate security incidents, test incident response plans, and improve incident handling capabilities.
|
||||
- **Log Analysis**: Collect and analyze system and application logs using tools like ELK stack (Elasticsearch, Logstash, Kibana) and Splunk to identify security events, detect anomalies, and investigate incidents.
|
||||
- **Memory Forensics**: Perform memory forensics on compromised systems using tools like Volatility and Rekall to analyze memory dumps, identify malicious processes, and extract valuable artifacts for incident investigation.
|
||||
- **Network Forensics**: Conduct network forensics using tools like NetworkMiner and Xplico to analyze network traffic captures (PCAP files), reconstruct network events, and investigate network-based attacks.
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Incident Response and Forensics] --> B[Incident Response Planning]
|
||||
A --> C[Log Analysis]
|
||||
A --> D[Memory Forensics]
|
||||
A --> E[Network Forensics]
|
||||
|
||||
C --> C1[ELK Stack]
|
||||
C --> C2[Splunk]
|
||||
|
||||
D --> D1[Volatility]
|
||||
D --> D2[Rekall]
|
||||
|
||||
E --> E1[NetworkMiner]
|
||||
E --> E2[Xplico]
|
||||
```
|
||||
|
||||
### 4. Malware Analysis
|
||||
- **Static Analysis**: Perform static analysis on malware samples using tools like IDA Pro, Ghidra, and Radare2 to analyze malware code, identify suspicious functions, and understand the malware's behavior without executing it.
|
||||
- **Dynamic Analysis**: Execute malware samples in isolated containers using tools like Cuckoo Sandbox and REMnux to observe the malware's behavior, analyze its interactions with the system and network, and identify its functionality and persistence mechanisms.
|
||||
- **Reverse Engineering**: Apply reverse engineering techniques using tools like x64dbg and OllyDbg to disassemble and debug malware binaries, understand their internal workings, and identify obfuscation or anti-analysis techniques.
|
||||
- **Malware Dissection**: Dissect and analyze different types of malware, such as ransomware, trojans, and botnets, to understand their infection vectors, command and control (C2) communication, and impact on infected systems.
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Malware Analysis] --> B[Static Analysis]
|
||||
A --> C[Dynamic Analysis]
|
||||
A --> D[Reverse Engineering]
|
||||
A --> E[Malware Dissection]
|
||||
|
||||
B --> B1[IDA Pro]
|
||||
B --> B2[Ghidra]
|
||||
B --> B3[Radare2]
|
||||
|
||||
C --> C1[Cuckoo Sandbox]
|
||||
C --> C2[REMnux]
|
||||
|
||||
D --> D1[x64dbg]
|
||||
D --> D2[OllyDbg]
|
||||
```
|
||||
## Example Scenarios
|
||||
To demonstrate the practical applications of the cybersecurity lab, consider the following example scenarios:
|
||||
|
||||
### Scenario 1: Ransomware Attack Simulation
|
||||
Objective: Simulate a ransomware attack and practice incident response procedures.
|
||||
|
||||
Steps:
|
||||
1. Set up a vulnerable Windows server container in the lab environment.
|
||||
2. Create a simulated user environment with sample files and documents.
|
||||
3. Deploy a controlled ransomware sample or a ransomware simulator within the container.
|
||||
4. Monitor the network traffic and analyze the ransomware's behavior using tools like Wireshark and Snort.
|
||||
5. Implement containment measures, such as isolating the infected container and blocking malicious traffic.
|
||||
6. Perform memory forensics on the affected system to identify the encryption process and extract relevant artifacts.
|
||||
7. Develop and test a recovery plan, including data restoration from backups and system hardening measures.
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Vulnerable Windows Server Container] --> B[Deploy Ransomware]
|
||||
B --> C[Monitor Network Traffic]
|
||||
C --> D[Implement Containment Measures]
|
||||
D --> E[Perform Memory Forensics]
|
||||
E --> F[Develop Recovery Plan]
|
||||
F --> G[Restore Data and Harden System]
|
||||
```
|
||||
### Scenario 2: Web Application Penetration Testing
|
||||
Objective: Conduct a penetration test on a vulnerable web application to identify and exploit vulnerabilities.
|
||||
|
||||
Steps:
|
||||
1. Deploy a purposefully vulnerable web application, such as OWASP Juice Shop or DVWA, in a container.
|
||||
2. Perform reconnaissance to gather information about the application's functionality and potential attack surfaces.
|
||||
3. Conduct vulnerability scanning using tools like OWASP ZAP and Burp Suite to identify common web vulnerabilities.
|
||||
4. Attempt to exploit the identified vulnerabilities, such as SQL injection or XSS, to gain unauthorized access or extract sensitive data.
|
||||
5. Document the findings, including the steps taken, vulnerabilities discovered, and the potential impact of each vulnerability.
|
||||
6. Provide recommendations for remediation and security best practices based on the penetration testing results.
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Deploy Vulnerable Web Application] --> B[Perform Reconnaissance]
|
||||
B --> C[Conduct Vulnerability Scanning]
|
||||
C --> D[Exploit Identified Vulnerabilities]
|
||||
D --> E[Document Findings]
|
||||
E --> F[Provide Remediation Recommendations]
|
||||
```
|
||||
### Scenario 3: Malware Analysis and Reverse Engineering
|
||||
Objective: Analyze a malware sample to understand its behavior and develop detection and mitigation strategies.
|
||||
|
||||
Steps:
|
||||
1. Obtain a malware sample from a trusted source or create a custom malware binary for analysis.
|
||||
2. Perform static analysis on the malware sample using tools like IDA Pro or Ghidra to examine its code structure and identify suspicious functions.
|
||||
3. Conduct dynamic analysis by executing the malware in an isolated container and monitoring its behavior using tools like Process Monitor and Wireshark.
|
||||
4. Analyze the malware's interactions with the file system, registry, and network to understand its functionality and persistence mechanisms.
|
||||
5. Reverse engineer the malware using a debugger like x64dbg to understand its internal logic and identify any obfuscation techniques.
|
||||
6. Develop YARA rules or other detection signatures based on the identified characteristics of the malware.
|
||||
7. Propose mitigation strategies, such as network segregation, application whitelisting, and endpoint protection, to defend against the analyzed malware.
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Obtain Malware Sample] --> B[Perform Static Analysis]
|
||||
B --> C[Conduct Dynamic Analysis]
|
||||
C --> D[Analyze Malware Interactions]
|
||||
D --> E[Reverse Engineer Malware]
|
||||
E --> F[Develop Detection Signatures]
|
||||
F --> G[Propose Mitigation Strategies]
|
||||
```
|
||||
## Conclusion
|
||||
The cybersecurity lab setup described in this guide provides a comprehensive and flexible environment for practicing and developing a wide range of cybersecurity skills. By leveraging Docker and Active Directory integration, the lab offers a realistic and manageable platform for simulating various security scenarios, analyzing threats, and testing defense mechanisms.
|
||||
|
||||
Through the different learning paths and example scenarios, readers can gain hands-on experience in network security, web application security, incident response, forensics, and malware analysis. The lab environment enables readers to explore and experiment with industry-standard tools and techniques, enhancing their practical skills and understanding of real-world cybersecurity challenges.
|
||||
|
||||
By following the step-by-step instructions and best practices outlined in this guide, readers can build a robust and customizable cybersecurity lab that adapts to their learning objectives and evolving security landscape. The modular nature of the lab allows for easy expansion and integration of additional security tools and scenarios as needed.
|
||||
|
||||
Remember to continuously update and refine the lab environment, stay informed about the latest security threats and techniques, and engage with the cybersecurity community to share knowledge and collaborate on new challenges.
|
||||
|
||||
Happy learning and secure coding!
|
||||
420
tech_docs/networking/firewalls.md
Normal file
420
tech_docs/networking/firewalls.md
Normal file
@@ -0,0 +1,420 @@
|
||||
|
||||
|
||||
---
|
||||
|
||||
Certainly! Let's consider a more complex, real-world enterprise scenario and compare the configuration steps for Palo Alto Networks and Fortinet FortiGate firewalls.
|
||||
|
||||
Scenario:
|
||||
- The enterprise has multiple web servers hosting different applications, each requiring inbound HTTPS access (port 443) from specific source networks.
|
||||
- The web servers are located in a DMZ network (192.168.10.0/24) behind the firewall.
|
||||
- The firewall should perform NAT to translate public IP addresses to the respective web servers' private IP addresses.
|
||||
- The firewall should enforce security policies to inspect HTTPS traffic for potential threats and apply application-specific rules.
|
||||
|
||||
Solution 1: Palo Alto Networks
|
||||
|
||||
Step 1: Configure NAT rules for each web server.
|
||||
```
|
||||
set rulebase nat rules
|
||||
set name "NAT_Web_Server_1"
|
||||
set source any
|
||||
set destination <public_IP_1>
|
||||
set service any
|
||||
set translate-to <web_server_1_private_IP>
|
||||
|
||||
set rulebase nat rules
|
||||
set name "NAT_Web_Server_2"
|
||||
set source any
|
||||
set destination <public_IP_2>
|
||||
set service any
|
||||
set translate-to <web_server_2_private_IP>
|
||||
```
|
||||
|
||||
Step 2: Create security zones and assign interfaces.
|
||||
```
|
||||
set network interface ethernet1/1 layer3 interface-management-profile none zone untrust
|
||||
set network interface ethernet1/2 layer3 interface-management-profile none zone dmz
|
||||
set zone dmz network layer3 [ ethernet1/2 ]
|
||||
```
|
||||
|
||||
Step 3: Define security policies for each web server.
|
||||
```
|
||||
set rulebase security rules
|
||||
set name "Allow_HTTPS_Web_Server_1"
|
||||
set from untrust
|
||||
set to dmz
|
||||
set source <allowed_source_network_1>
|
||||
set destination <public_IP_1>
|
||||
set application ssl
|
||||
set service application-default
|
||||
set action allow
|
||||
set profile-setting profiles virus default spyware default vulnerability default url-filtering default
|
||||
|
||||
set rulebase security rules
|
||||
set name "Allow_HTTPS_Web_Server_2"
|
||||
set from untrust
|
||||
set to dmz
|
||||
set source <allowed_source_network_2>
|
||||
set destination <public_IP_2>
|
||||
set application ssl
|
||||
set service application-default
|
||||
set action allow
|
||||
set profile-setting profiles virus default spyware default vulnerability default url-filtering default
|
||||
```
|
||||
|
||||
Step 4: Configure SSL decryption and inspection.
|
||||
```
|
||||
set rulebase decryption rules
|
||||
set name "SSL_Inspect_Web_Servers"
|
||||
set action no-decrypt
|
||||
set source any
|
||||
set destination [ <public_IP_1> <public_IP_2> ]
|
||||
set service ssl
|
||||
```
|
||||
|
||||
In this Palo Alto Networks solution, NAT rules are configured for each web server to translate the public IP addresses to their respective private IP addresses. Security zones are created, and interfaces are assigned to segregate the untrust (Internet-facing) and DMZ networks. Security policies are defined for each web server, specifying the allowed source networks, destination IP addresses, and applications (SSL). The policies also apply default security profiles for threat prevention. SSL decryption rules are configured to inspect the HTTPS traffic for potential threats.
|
||||
|
||||
Solution 2: Fortinet FortiGate
|
||||
|
||||
Step 1: Configure firewall addresses for the web servers.
|
||||
```
|
||||
config firewall address
|
||||
edit "Web_Server_1"
|
||||
set subnet 192.168.10.10/32
|
||||
next
|
||||
edit "Web_Server_2"
|
||||
set subnet 192.168.10.20/32
|
||||
next
|
||||
end
|
||||
```
|
||||
|
||||
Step 2: Configure virtual IPs (VIPs) for each web server.
|
||||
```
|
||||
config firewall vip
|
||||
edit "VIP_Web_Server_1"
|
||||
set extip <public_IP_1>
|
||||
set mappedip "Web_Server_1"
|
||||
set extintf "port1"
|
||||
set portforward enable
|
||||
set extport 443
|
||||
set mappedport 443
|
||||
next
|
||||
edit "VIP_Web_Server_2"
|
||||
set extip <public_IP_2>
|
||||
set mappedip "Web_Server_2"
|
||||
set extintf "port1"
|
||||
set portforward enable
|
||||
set extport 443
|
||||
set mappedport 443
|
||||
next
|
||||
end
|
||||
```
|
||||
|
||||
Step 3: Create firewall policies for each web server.
|
||||
```
|
||||
config firewall policy
|
||||
edit 1
|
||||
set name "Allow_HTTPS_Web_Server_1"
|
||||
set srcintf "port1"
|
||||
set dstintf "dmz"
|
||||
set srcaddr <allowed_source_network_1>
|
||||
set dstaddr "VIP_Web_Server_1"
|
||||
set action accept
|
||||
set service "HTTPS"
|
||||
set ssl-ssh-profile "deep-inspection"
|
||||
set nat enable
|
||||
next
|
||||
edit 2
|
||||
set name "Allow_HTTPS_Web_Server_2"
|
||||
set srcintf "port1"
|
||||
set dstintf "dmz"
|
||||
set srcaddr <allowed_source_network_2>
|
||||
set dstaddr "VIP_Web_Server_2"
|
||||
set action accept
|
||||
set service "HTTPS"
|
||||
set ssl-ssh-profile "deep-inspection"
|
||||
set nat enable
|
||||
next
|
||||
end
|
||||
```
|
||||
|
||||
Step 4: Configure SSL deep inspection.
|
||||
```
|
||||
config firewall ssl-ssh-profile
|
||||
edit "deep-inspection"
|
||||
set comment "SSL deep inspection"
|
||||
set ssl inspect-all
|
||||
set untrusted-caname "Fortinet_CA_SSL"
|
||||
next
|
||||
end
|
||||
```
|
||||
|
||||
In the Fortinet FortiGate solution, firewall addresses are defined for each web server. Virtual IPs (VIPs) are configured to map the public IP addresses to the respective web server addresses and specify the port translation. Firewall policies are created for each web server, allowing HTTPS traffic from specific source networks to the corresponding VIPs. The policies also enable NAT and apply an SSL deep inspection profile to examine the encrypted traffic for threats.
|
||||
|
||||
Comparison:
|
||||
Both Palo Alto Networks and Fortinet FortiGate offer robust security features and granular control for managing inbound HTTPS traffic in an enterprise environment. However, there are differences in their configuration approaches and terminology.
|
||||
|
||||
Palo Alto Networks uses a zone-based approach, where security zones are created, and interfaces are assigned to them. NAT rules and security policies are configured separately, allowing for more flexibility and control over traffic flows. Palo Alto Networks also provides a comprehensive set of security profiles for threat prevention.
|
||||
|
||||
Fortinet FortiGate, on the other hand, uses a more integrated approach with firewall addresses, VIPs, and firewall policies. VIPs combine the NAT configuration with the firewall rules, simplifying the setup. Firewall policies define the allowed traffic flow and include security features like SSL deep inspection.
|
||||
|
||||
Both firewalls offer advanced security features, such as SSL decryption and inspection, to detect and prevent threats in encrypted traffic. They also provide granular control over source and destination networks, applications, and services.
|
||||
|
||||
When choosing between Palo Alto Networks and Fortinet FortiGate for an enterprise environment, factors like the organization's security requirements, existing network infrastructure, ease of management, and integration with other security tools should be considered.
|
||||
|
||||
In summary, this real-world enterprise scenario demonstrates the configuration steps for allowing inbound HTTPS traffic to multiple web servers using Palo Alto Networks and Fortinet FortiGate firewalls. While both firewalls provide comprehensive security features, their configuration approaches and terminology differ, reflecting their unique architectures and philosophies.
|
||||
|
||||
---
|
||||
|
||||
Certainly! Here's a reference guide for how each OEM (Cisco ASA, Fortinet FortiGate, Palo Alto Networks, and Cisco Meraki MX) performs the core firewall tasks (traffic filtering, NAT, VPN, and threat prevention) via CLI:
|
||||
|
||||
1. Traffic Filtering
|
||||
a. Cisco ASA:
|
||||
- Configure access-list: `access-list <ACL_name> <line_number> <permit/deny> <protocol> <source_IP> <source_mask> <destination_IP> <destination_mask>`
|
||||
- Apply access-list to interface: `access-group <ACL_name> <in/out> interface <interface_name>`
|
||||
|
||||
b. Fortinet FortiGate:
|
||||
- Configure firewall policy: `config firewall policy`
|
||||
- Set policy details: `edit <policy_id>`, `set srcintf <source_interface>`, `set dstintf <destination_interface>`, `set srcaddr <source_address>`, `set dstaddr <destination_address>`, `set service <service_name>`, `set action <accept/deny>`
|
||||
|
||||
c. Palo Alto Networks:
|
||||
- Configure security rule: `set rulebase security rules`
|
||||
- Set rule details: `set name <rule_name>`, `set from <source_zone>`, `set to <destination_zone>`, `set source <source_address>`, `set destination <destination_address>`, `set service <service_name>`, `set action <allow/deny>`
|
||||
|
||||
d. Cisco Meraki MX (via Dashboard):
|
||||
- Configure firewall rule in the Meraki Dashboard:
|
||||
- Navigate to Security & SD-WAN > Configure > Firewall
|
||||
- Click "Add a Rule" and set the rule details (source, destination, service, action)
|
||||
|
||||
2. Network Address Translation (NAT)
|
||||
a. Cisco ASA:
|
||||
- Configure static NAT: `nat (<inside_interface>,<outside_interface>) source static <local_IP> <global_IP>`
|
||||
- Configure dynamic NAT: `nat (<inside_interface>,<outside_interface>) source dynamic <local_network> <global_IP_pool>`
|
||||
|
||||
b. Fortinet FortiGate:
|
||||
- Configure SNAT: `config firewall ippool`, `edit <ippool_name>`, `set startip <start_IP>`, `set endip <end_IP>`
|
||||
- Apply SNAT to policy: `config firewall policy`, `edit <policy_id>`, `set ippool enable`, `set poolname <ippool_name>`
|
||||
|
||||
c. Palo Alto Networks:
|
||||
- Configure NAT rule: `set rulebase nat rules`
|
||||
- Set rule details: `set name <rule_name>`, `set source <source_zone>`, `set destination <destination_zone>`, `set service <service_name>`, `set source-translation dynamic-ip-and-port <interface_name> <IP_address>`
|
||||
|
||||
d. Cisco Meraki MX (via Dashboard):
|
||||
- Configure NAT in the Meraki Dashboard:
|
||||
- Navigate to Security & SD-WAN > Configure > NAT
|
||||
- Click "Add a Rule" and set the rule details (source, destination, service, translation type)
|
||||
|
||||
3. Virtual Private Network (VPN)
|
||||
a. Cisco ASA:
|
||||
- Configure IKEv1 policy: `crypto ikev1 policy <priority>`, `authentication pre-share`, `encryption <encryption_algorithm>`, `hash <hash_algorithm>`, `group <DH_group>`, `lifetime <seconds>`
|
||||
- Configure IPsec transform set: `crypto ipsec transform-set <transform_set_name> <encryption_algorithm> <authentication_algorithm>`
|
||||
- Configure tunnel group: `tunnel-group <peer_IP> type ipsec-l2l`, `tunnel-group <peer_IP> ipsec-attributes`, `pre-shared-key <key>`
|
||||
- Configure crypto map: `crypto map <map_name> <priority> ipsec-isakmp`, `set peer <peer_IP>`, `set transform-set <transform_set_name>`, `set pfs <DH_group>`, `match address <ACL_name>`
|
||||
|
||||
b. Fortinet FortiGate:
|
||||
- Configure Phase 1 (IKE): `config vpn ipsec phase1-interface`, `edit <tunnel_name>`, `set interface <interface_name>`, `set remote-gw <peer_IP>`, `set proposal <encryption_algorithm>-<authentication_algorithm>-<DH_group>`
|
||||
- Configure Phase 2 (IPsec): `config vpn ipsec phase2
|
||||
|
||||
-interface`, `edit <tunnel_name>`, `set phase1name <phase1_tunnel_name>`, `set proposal <encryption_algorithm>-<authentication_algorithm>-<DH_group>`
|
||||
- Configure firewall policy for VPN: `config firewall policy`, `edit <policy_id>`, `set srcintf <source_interface>`, `set dstintf <destination_interface>`, `set srcaddr <source_address>`, `set dstaddr <destination_address>`, `set action ipsec`, `set schedule always`, `set service ANY`, `set inbound enable`, `set outbound enable`
|
||||
|
||||
c. Palo Alto Networks:
|
||||
- Configure IKE gateway: `set network ike gateway <gateway_name>`, `set address <peer_IP>`, `set authentication pre-shared-key <key>`, `set local-address <interface_name>`, `set protocol ikev1`
|
||||
- Configure IPsec tunnel: `set network tunnel ipsec <tunnel_name>`, `set auto-key ike-gateway <gateway_name>`, `set auto-key ipsec-crypto-profile <profile_name>`
|
||||
- Configure IPsec crypto profile: `set network ipsec crypto-profiles <profile_name>`, `set esp encryption <encryption_algorithm>`, `set esp authentication <authentication_algorithm>`
|
||||
- Configure security policy for VPN: `set rulebase security rules`, `set name <rule_name>`, `set from <source_zone>`, `set to <destination_zone>`, `set source <source_address>`, `set destination <destination_address>`, `set application any`, `set service any`, `set action allow`, `set profile-setting profiles spyware <anti_spyware_profile> virus <anti_virus_profile>`
|
||||
|
||||
d. Cisco Meraki MX (via Dashboard):
|
||||
- Configure site-to-site VPN in the Meraki Dashboard:
|
||||
- Navigate to Security & SD-WAN > Configure > Site-to-site VPN
|
||||
- Click "Add a peer" and set the peer details (peer IP, remote subnet, pre-shared key)
|
||||
- Configure the local networks to be advertised
|
||||
- Configure client VPN (L2TP over IPsec) in the Meraki Dashboard:
|
||||
- Navigate to Security & SD-WAN > Configure > Client VPN
|
||||
- Enable client VPN and set the authentication details (pre-shared key, client IP range)
|
||||
|
||||
4. Threat Prevention
|
||||
a. Cisco ASA with FirePOWER Services:
|
||||
- Configure access control policy: `access-control-policy`, `edit <policy_name>`, `rule add <rule_name>`, `action <allow/block>`, `source <source_network>`, `destination <destination_network>`, `port <port_number>`, `application <application_name>`, `intrusion-policy <intrusion_policy_name>`, `file-policy <file_policy_name>`, `logging <enable/disable>`
|
||||
|
||||
b. Fortinet FortiGate:
|
||||
- Configure antivirus profile: `config antivirus profile`, `edit <profile_name>`, `set comment <description>`, `set inspection-mode <proxy/flow-based>`, `set ftgd-analytics <enable/disable>`
|
||||
- Configure IPS sensor: `config ips sensor`, `edit <sensor_name>`, `set comment <description>`, `set block-malicious-url <enable/disable>`, `set extended-log <enable/disable>`
|
||||
- Apply antivirus and IPS profiles to firewall policy: `config firewall policy`, `edit <policy_id>`, `set av-profile <antivirus_profile_name>`, `set ips-sensor <ips_sensor_name>`
|
||||
|
||||
c. Palo Alto Networks:
|
||||
- Configure antivirus profile: `set deviceconfig system profiles anti-virus <profile_name>`, `set threat-prevention packet-capture <enable/disable>`, `set action <default/allow/alert/block/drop>`
|
||||
- Configure anti-spyware profile: `set deviceconfig system profiles spyware <profile_name>`, `set threat-prevention packet-capture <enable/disable>`, `set action <default/allow/alert/block/drop>`
|
||||
- Configure vulnerability protection profile: `set deviceconfig system profiles vulnerability <profile_name>`, `set threat-prevention packet-capture <enable/disable>`, `set action <default/allow/alert/block/drop/reset-both/reset-client/reset-server>`
|
||||
- Attach profiles to security policy: `set rulebase security rules`, `set name <rule_name>`, `set profile-setting profiles spyware <anti_spyware_profile> virus <anti_virus_profile> vulnerability <vulnerability_protection_profile>`
|
||||
|
||||
d. Cisco Meraki MX (via Dashboard):
|
||||
- Configure threat protection in the Meraki Dashboard:
|
||||
- Navigate to Security & SD-WAN > Configure > Threat Protection
|
||||
- Enable intrusion detection and prevention (IDS/IPS) and set the security level
|
||||
- Enable advanced malware protection (AMP) and set the detection and blocking options
|
||||
- Configure URL filtering and set the content categories to be blocked
|
||||
|
||||
This reference guide provides a high-level overview of how to configure core firewall tasks using the CLI for each OEM. Keep in mind that the exact commands and syntax may vary depending on the specific device model and software version. It's always recommended to refer to the official documentation and command references provided by the respective vendors for the most accurate and up-to-date information.
|
||||
|
||||
Introduction
|
||||
|
||||
Firewalls are essential components of network security, serving as the first line of defense against external threats and unauthorized access. They enforce security policies by controlling the flow of network traffic based on predefined rules and criteria. The effectiveness and functionality of a firewall depend heavily on how it implements key features such as traffic filtering, Network Address Translation (NAT), Virtual Private Network (VPN), and threat prevention.
|
||||
|
||||
Traffic filtering is the foundation of firewall functionality. It involves inspecting incoming and outgoing network packets and making decisions based on factors like source and destination IP addresses, ports, protocols, and application-level data. Firewalls use various techniques for traffic filtering, such as stateful inspection, which maintains the state of network connections and allows for more granular control. According to a 2021 report by Grand View Research, the global network security firewall market size was valued at USD 4.3 billion in 2020 and is expected to grow at a compound annual growth rate (CAGR) of 12.1% from 2021 to 2028, highlighting the importance of effective traffic filtering in modern networks.
|
||||
|
||||
Network Address Translation (NAT) is a critical feature that allows firewalls to mask the internal network structure and conserve public IP addresses. NAT enables multiple devices on a private network to share a single public IP address, enhancing security and simplifying network configuration. Firewalls support different types of NAT, such as static NAT, dynamic NAT, and Port Address Translation (PAT). A study by Cisco found that NAT can help organizations save up to 50% on public IP address costs while improving network security and manageability.
|
||||
|
||||
Virtual Private Network (VPN) capabilities are essential for securing remote access and enabling secure communication between disparate network segments. Firewalls support various VPN technologies, such as IPsec, SSL/TLS, and PPTP, each with its own advantages and trade-offs. According to a 2021 report by Global Market Insights, the global VPN market size exceeded USD 30 billion in 2020 and is projected to grow at a CAGR of over 15% from 2021 to 2027, driven by the increasing demand for secure remote access solutions.
|
||||
|
||||
Threat prevention is an increasingly important aspect of modern firewalls, as they evolve beyond simple packet filtering to become comprehensive security gateways. Firewalls employ various techniques to detect and block advanced threats, such as intrusion prevention systems (IPS), malware scanning, URL filtering, and sandboxing. A 2021 report by MarketsandMarkets projects that the global threat intelligence market size will grow from USD 11.6 billion in 2021 to USD 15.8 billion by 2026, at a CAGR of 6.3%, underlining the importance of robust threat prevention capabilities in firewalls.
|
||||
|
||||
In the following sections, we will examine how four leading firewall vendors—Cisco ASA, Fortinet FortiGate, Palo Alto Networks, and Cisco Meraki MX—implement these core functionalities. By delving into the technical specifics and underlying mechanisms of each solution, this comparative analysis aims to provide a comprehensive understanding of their capabilities, strengths, and differences. This knowledge is crucial for organizations seeking to make informed decisions when selecting and configuring firewall solutions to align with their specific security requirements and network architectures.
|
||||
|
||||
---
|
||||
|
||||
You're right in observing that fundamentally, all firewall platforms—whether Cisco ASA, Fortinet FortiGate, Palo Alto Networks, Cisco Meraki MX, or others—serve the same core purpose: to protect networks by managing and controlling the flow of traffic based on defined security rules. They achieve these objectives through mechanisms that might differ in terminology or implementation details but ultimately perform similar functions. Here’s a simplified abstraction of how these firewalls operate, focusing on their common functionalities:
|
||||
|
||||
### Core Functions of Firewalls:
|
||||
1. **Traffic Filtering:** All firewall technologies employ some form of traffic filtering, whether they're using ACLs (Access Control Lists), security policies, or unified threat management rules. They decide whether to block or allow traffic based on source and destination IP addresses, port numbers, and other protocol-specific characteristics.
|
||||
|
||||
2. **Network Address Translation (NAT):** This is a universal feature across firewalls used to mask the internal IP addresses of a network from the external world. The terminology and specific capabilities (like static NAT, dynamic NAT, PAT) might vary, but the fundamental purpose remains to facilitate secure communication between internal and external networks.
|
||||
|
||||
3. **VPN Support:** Virtual Private Networks (VPNs) are supported by all major firewall platforms, though the implementations (IPSec, SSL VPN, etc.) and the specific features (like remote access VPN and site-to-site VPN) might differ. The end goal is to securely extend a network’s reach over the internet.
|
||||
|
||||
4. **User and Application Control:** Modern firewalls go beyond traditional packet filtering by integrating user and application-level visibility and control. Technologies like Palo Alto’s App-ID and User-ID or similar features in other platforms enable more granular control based on application traffic and user identity, respectively.
|
||||
|
||||
5. **Threat Prevention:** Firewalls are increasingly incorporating integrated threat prevention tools that include IDS/IPS (Intrusion Detection and Prevention Systems), anti-malware, and URL filtering. These features help to identify and mitigate threats before they can penetrate deeper into the network.
|
||||
|
||||
### Terminology Differences:
|
||||
- **Cisco ASA** might refer to its filtering mechanism as access groups and ACLs, whereas **Palo Alto** would discuss it in terms of security policies that integrate with application and user IDs.
|
||||
- **Fortinet** integrates NAT within their security policies, making it a bit more straightforward in terms of policy management, compared to **Cisco ASA**, where NAT and security policies might be configured separately.
|
||||
- **Palo Alto** and **Fortinet** emphasize application-level insights and controls, using terms like App-ID and NGFW (Next-Generation Firewall) features, which might not be explicitly named in the simpler, more traditional configurations of older Cisco ASA models.
|
||||
|
||||
Despite these differences in terminology and certain proprietary technologies, the underlying principles of how these firewalls operate remain largely consistent. They all aim to secure network environments through a combination of packet filtering, user and application control, and threat mitigation techniques, adapting these basic functions to modern network demands and threats in slightly different ways to cater to various organizational needs.
|
||||
|
||||
---
|
||||
|
||||
### Introduction
|
||||
Choosing the right firewall solution is crucial for protecting an organization's network infrastructure. Firewalls not only block unauthorized access but also provide a control point for traffic entering and exiting the network. This comparative analysis examines Cisco ASA, Fortinet FortiGate, and Palo Alto firewalls, focusing on their approaches to firewall policy and NAT configurations, helping organizations select the best fit based on specific needs and network environments.
|
||||
|
||||
### Firewall Policy Configuration
|
||||
#### **Cisco ASA**
|
||||
- **Approach**: Utilizes access control lists (ACLs) and access groups for detailed traffic management.
|
||||
- **Key Features**: High granularity allows for precise control, which is essential in complex network setups needing stringent security measures.
|
||||
|
||||
#### **Fortinet FortiGate**
|
||||
- **Approach**: Adopts an integrated policy system that combines addresses, services, and actions.
|
||||
- **User Experience**: Simplifies configuration, making it suitable for environments that require quick setup and changes.
|
||||
|
||||
#### **Palo Alto Networks**
|
||||
- **Approach**: Employs a comprehensive strategy using zones and profiles, focusing on controlling traffic based on applications and users.
|
||||
- **Key Features**: Includes User-ID and App-ID technologies that enhance security by enabling policy enforcement based on user identity and application traffic, ensuring that security measures are both stringent and adaptable to organizational needs.
|
||||
|
||||
### NAT Configuration
|
||||
#### **Overview**
|
||||
Network Address Translation (NAT) is crucial for hiding internal IP addresses and managing the IP routing between internal and external networks. It is a fundamental security feature that also optimizes the use of IP addresses.
|
||||
|
||||
#### **Cisco ASA**
|
||||
- **Flexibility**: Offers robust options for static and dynamic NAT, catering to complex network requirements.
|
||||
|
||||
#### **Fortinet FortiGate**
|
||||
- **Integration**: Features an intuitive setup where NAT configurations are integrated within firewall policies, facilitating easier management and visibility.
|
||||
|
||||
#### **Palo Alto Networks**
|
||||
- **Innovation**: Provides versatile NAT options that are tightly integrated with security policies, supporting complex translations including bi-directional NAT for detailed traffic control.
|
||||
|
||||
### Comparative Summary
|
||||
#### **Performance and Scalability**
|
||||
- **Cisco ASA** is known for its stability and robust performance, handling high-volume traffic effectively.
|
||||
- **Fortinet FortiGate** and **Palo Alto Networks** both excel in environments that scale dynamically, offering solutions that adapt quickly to changing network demands.
|
||||
|
||||
#### **Integration with Other Security Tools**
|
||||
- All three platforms offer extensive integrations with additional security tools such as SIEM systems, intrusion prevention systems (IPS), and endpoint protection, enhancing overall security architecture.
|
||||
|
||||
#### **Cost and Licensing**
|
||||
- **Cisco ASA** often involves a straightforward, albeit sometimes costly, licensing structure.
|
||||
- **Fortinet FortiGate** typically provides a cost-effective solution with flexible licensing options.
|
||||
- **Palo Alto Networks** may involve higher costs but justifies them with advanced features and comprehensive security coverage.
|
||||
|
||||
### Conclusion
|
||||
Selecting the right firewall is a pivotal decision that depends on specific organizational requirements including budget, expected traffic volume, administrative expertise, and desired security level. This analysis highlights the distinct capabilities and configurations of Cisco ASA, Fortinet FortiGate, and Palo Alto Networks, guiding organizations towards making an informed choice that aligns with their security needs and operational preferences.
|
||||
|
||||
---
|
||||
|
||||
### 4. Cisco Meraki MX
|
||||
- **Models Covered**: Meraki MX64, MX84, MX100, MX250
|
||||
- **Throughput**:
|
||||
- **Firewall Throughput**: Up to 4 Gbps
|
||||
- **VPN Throughput**: Up to 1 Gbps
|
||||
- **Concurrent Sessions**: Up to 2,000,000
|
||||
- **VPN Support**:
|
||||
- **Protocols**: Auto VPN (IPSec), L2TP over IPSec
|
||||
- **Remote Access VPN**: Client VPN (L2TP over IPSec)
|
||||
- **NAT Features**:
|
||||
- **1:1 NAT, 1:Many NAT**
|
||||
- **Port forwarding, and DMZ host**
|
||||
- **Security Features**:
|
||||
- **Threat Defense**: Integrated intrusion detection and prevention (IDS/IPS)
|
||||
- **Content Filtering**: Native content filtering, categories-based
|
||||
- **Access Control**: User and device-based policies
|
||||
- **Deployment**:
|
||||
- **Cloud Managed**: Entirely managed via the cloud, simplifying large-scale deployments and remote management.
|
||||
- **Zero-Touch Deployment**: Fully supported
|
||||
- **Special Features**:
|
||||
- **SD-WAN Capabilities**: Advanced SD-WAN policy-based routing integrates with auto VPN for dynamic path selection.
|
||||
|
||||
### 5. SELinux (Security-Enhanced Linux)
|
||||
- **Base**: Linux Kernel modification
|
||||
- **Main Use**: Enforcing mandatory access controls (MAC) to enhance the security of Linux systems.
|
||||
- **Operation Mode**:
|
||||
- **Enforcing**: Enforces policies and denies access based on policy rules.
|
||||
- **Permissive**: Logs policy violations but does not enforce them.
|
||||
- **Disabled**: SELinux functionality turned off.
|
||||
- **Security Features**:
|
||||
- **Type Enforcement**: Controls access based on type attributes attached to each subject and object.
|
||||
- **Role-Based Access Control (RBAC)**: Users perform operations based on roles, which govern the types of operations allowable.
|
||||
- **Multi-Level Security (MLS)**: Adds sensitivity labels on objects for handling varying levels of security.
|
||||
- **Deployment**:
|
||||
- **Compatibility**: Compatible with most major distributions of Linux.
|
||||
- **Management Tools**: Various tools available for policy management, including `semanage`, `setroubleshoot`, and graphical interfaces like `system-config-selinux`.
|
||||
- **Advantages**:
|
||||
- **Granular Control**: Provides very detailed and customizable security policies.
|
||||
- **Audit and Compliance**: Excellent support for audit and compliance requirements with comprehensive logging.
|
||||
|
||||
Here are the additional fact sheets for AppArmor, a Linux security module, and typical VPN technologies used within Linux environments:
|
||||
|
||||
---
|
||||
|
||||
### 6. AppArmor (Application Armor)
|
||||
- **Base**: Linux Kernel security module similar to SELinux
|
||||
- **Main Use**: Provides application security by enabling administrators to confine programs to a limited set of resources, based on per-program profiles.
|
||||
- **Operation Mode**:
|
||||
- **Enforce Mode**: Enforces all rules defined in the profiles and restricts access accordingly.
|
||||
- **Complain Mode**: Does not enforce rules but logs all violations.
|
||||
- **Security Features**:
|
||||
- **Profile-Based Access Control**: Each application can have a unique profile that specifies its permissions, controlling file access, capabilities, network access, and other resources.
|
||||
- **Ease of Configuration**: Generally considered easier to configure and maintain than SELinux due to its more straightforward syntax and profile management.
|
||||
- **Deployment**:
|
||||
- **Compatibility**: Integrated into many Linux distributions, including Ubuntu and SUSE.
|
||||
- **Management Tools**: `aa-genprof` for generating profiles, `aa-enforce` to switch profiles to enforce mode, and `aa-complain` to set profiles to complain mode.
|
||||
- **Advantages**:
|
||||
- **Simplicity and Accessibility**: Less complex than SELinux, making it more accessible for less experienced administrators.
|
||||
- **Flexibility**: Offers effective containment and security without the extensive configuration SELinux may require.
|
||||
|
||||
### 7. Linux VPN Technologies
|
||||
- **Common Solutions**:
|
||||
- **OpenVPN**: A robust and highly configurable VPN solution that uses SSL/TLS for key exchange. It is capable of traversing network address translators (NATs) and firewalls.
|
||||
- **WireGuard**: A newer, simpler, and faster approach to VPN that integrates more directly into the Linux kernel, offering better performance than older protocols.
|
||||
- **IPSec/L2TP**: Often used in corporate environments, IPSec is used with L2TP to provide encryption at the network layer.
|
||||
- **Throughput and Performance**:
|
||||
- **OpenVPN**: Good performance with strong encryption. Suitable for most consumer and many enterprise applications.
|
||||
- **WireGuard**: Exceptional performance, particularly in terms of connection speed and reconnection times over mobile networks.
|
||||
- **Security Features**:
|
||||
- **OpenVPN**: High security with configurable encryption methods. Supports various authentication mechanisms including certificates, pre-shared keys, and user authentication.
|
||||
- **WireGuard**: Uses state-of-the-art cryptography and aims to be as easy to configure and deploy as SSH.
|
||||
- **Deployment**:
|
||||
- **Configuration**: Both OpenVPN and WireGuard offer easy-to-use CLI tools and are supported by a variety of GUIs across Linux distributions.
|
||||
- **Compatibility**: Supported across a wide range of devices and Linux distributions.
|
||||
- **Advantages**:
|
||||
- **OpenVPN**: Wide adoption, extensive documentation, and strong community support.
|
||||
- **WireGuard**: Modern cryptographic techniques, minimalistic design, and kernel-level integration for optimal performance.
|
||||
49
tech_docs/networking/home_network.md
Normal file
49
tech_docs/networking/home_network.md
Normal file
@@ -0,0 +1,49 @@
|
||||
To provide a comprehensive turnkey solution for a power user's home network leveraging OPNsense with zero-trust principles, VLAN segmentation, and advanced WAN management, we'll break down the network architecture into a detailed plan. This plan includes VLAN allocation, device roles, and how traffic is managed across WAN links.
|
||||
|
||||
### Network Overview:
|
||||
|
||||
- **WAN Links**:
|
||||
- **WAN1 (Comcast)**: Primary internet connection, suitable for sensitive or work-related traffic. Limited by a data cap.
|
||||
- **WAN2 (T-Mobile 5G)**: Secondary internet connection, unlimited data but CGNAT. Ideal for high-bandwidth or background tasks.
|
||||
|
||||
- **VLANs & Segmentation**:
|
||||
- **VLAN 10 - Management**: For network infrastructure devices (switches, APs, OPNsense management).
|
||||
- **VLAN 20 - Work & Personal**: For personal computers, workstations, and laptops.
|
||||
- **VLAN 30 - IoT Devices**: For smart home devices, like smart bulbs, thermostats, and speakers.
|
||||
- **VLAN 40 - Entertainment**: For streaming devices, gaming consoles, and smart TVs.
|
||||
- **VLAN 50 - Guests**: For guests' devices, providing internet access with isolated access to local resources.
|
||||
|
||||
- **Special Configurations**:
|
||||
- **802.1x Authentication**: Enabled on VLAN 20 for secure access.
|
||||
- **VPN & SOCKS5**: Configured for selective routing of traffic from VLAN 20 and 40 through NordVPN or a SOCKS5 proxy.
|
||||
|
||||
### Network Diagram:
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
Comcast(WAN1 - Comcast) -->|Primary| OPNsense
|
||||
TMobile(WAN2 - T-Mobile 5G) -->|Secondary| OPNsense
|
||||
OPNsense -->|Management VLAN10| SwitchAP[Switch & APs]
|
||||
OPNsense -->|Work/Personal VLAN20| PC[PCs/Laptops]
|
||||
OPNsense -->|IoT VLAN30| IoT[Smart Devices]
|
||||
OPNsense -->|Entertainment VLAN40| TV[Streaming/Consoles]
|
||||
OPNsense -->|Guest VLAN50| Guests[Guest Devices]
|
||||
PC -->|VPN/SOCKS5| Cloud[VPN & SOCKS5]
|
||||
TV -->|VPN| Cloud
|
||||
```
|
||||
|
||||
### Device Roles and Policies:
|
||||
|
||||
- **Management (VLAN 10)**: Secure VLAN for managing networking equipment. Access restricted to network administrators.
|
||||
- **Work & Personal (VLAN 20)**: High-priority VLAN for workstations and personal devices. Protected by 802.1x authentication. Selected traffic routed through VPN or SOCKS5 for privacy or geo-restrictions.
|
||||
- **IoT Devices (VLAN 30)**: Isolated VLAN for IoT devices to enhance security. Internet access allowed, but access to other VLANs restricted.
|
||||
- **Entertainment (VLAN 40)**: Dedicated VLAN for entertainment devices. Selected traffic can be routed through VPN for content access or privacy.
|
||||
- **Guests (VLAN 50)**: VLAN for guest devices, providing internet access only with no access to the internal network.
|
||||
|
||||
### Policies:
|
||||
|
||||
- **Traffic Shaping & QoS**: Implemented on VLAN 20 and 40 to prioritize critical traffic (e.g., work-related applications, streaming).
|
||||
- **Intrusion Detection & Prevention**: Enabled network-wide with tailored rules for IoT and guest VLANs to prevent unauthorized access and mitigate threats.
|
||||
- **Multi-WAN Rules**: IoT and guest traffic primarily routed through WAN2 (T-Mobile 5G) to conserve WAN1 (Comcast) bandwidth under the data cap.
|
||||
|
||||
This plan provides a solid foundation for a secure, segmented home network, incorporating zero-trust principles and advanced routing to manage traffic across multiple WAN links effectively. It's customizable based on specific devices, user needs, and network policies, offering a starting point for a sophisticated home networking setup.
|
||||
118
tech_docs/networking/vpn-torrent.md
Normal file
118
tech_docs/networking/vpn-torrent.md
Normal file
@@ -0,0 +1,118 @@
|
||||
1. **Volume Paths:** Make sure the paths specified in the `volumes` sections are correct and accessible by Docker. These paths are where your configuration, downloads, and other data will be stored.
|
||||
|
||||
2. **Network Mode:** You've correctly set the network mode of the dependent services (`qbittorrent`, `jackett`, `sonarr`, `prowlarr`) to `service:gluetun`. This ensures that they use the VPN connection established by the `gluetun` service.
|
||||
|
||||
3. **Environment Variables:**
|
||||
- `VPN_SERVICE_PROVIDER`, `VPN_TYPE`, and related settings in `gluetun` should be correctly configured for your VPN provider.
|
||||
- Replace `<YOUR_PRIVATE_KEY>` with your actual WireGuard private key.
|
||||
- `PUID` and `PGID` should match your user ID and group ID on the host system.
|
||||
|
||||
4. **Ports:** Ensure that the ports you've exposed are open and not being used by other services on your host system. This is important for accessing the web UIs of the respective services.
|
||||
|
||||
5. **Time Zone:** You've set the time zone for most services to `Etc/UTC`. Ensure this is what you intend, or adjust it to your local time zone.
|
||||
|
||||
6. **Restart Policy:** You've set a restart policy for each service, which is good for ensuring they automatically restart in case of a crash or after a reboot.
|
||||
|
||||
7. **Service Dependencies:** The `depends_on` section for services like `qbittorrent` is correctly set to depend on `gluetun`. This ensures `gluetun` starts before them.
|
||||
|
||||
8. **Configuration and Data Persistence:** Your setup indicates that configuration and data will be persisted on the host file system in the `/home/ubuntu/docker/arr-stack/` directory. This is good practice for data persistence.
|
||||
|
||||
Before deploying, make sure to replace any placeholders (like `<YOUR_PRIVATE_KEY>`) with actual values. Once everything is set up, you can start your Docker Compose stack with:
|
||||
|
||||
```bash
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
This command will start all services in the background. You can then access the web interfaces of qBittorrent, Jackett, Sonarr, and Prowlarr through the respective ports you've configured.
|
||||
|
||||
```yaml
|
||||
---
|
||||
version: "3"
|
||||
services:
|
||||
gluetun:
|
||||
image: qmcgaw/gluetun
|
||||
container_name: gluetun
|
||||
# line above must be uncommented to allow external containers to connect.
|
||||
# See https://github.com/qdm12/gluetun-wiki/blob/main/setup/connect-a-container-to-gluetun.md#external-container-to-gluetun
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
devices:
|
||||
- /dev/net/tun:/dev/net/tun
|
||||
ports:
|
||||
- 6881:6881
|
||||
- 6881:6881/udp
|
||||
- 8085:8085 # qbittorrent
|
||||
- 9117:9117 # Jackett
|
||||
- 8989:8989 # Sonarr
|
||||
- 9696:9696 # Prowlarr
|
||||
volumes:
|
||||
- /home/ubuntu/docker/arr-stack:/gluetun
|
||||
environment:
|
||||
# See https://github.com/qdm12/gluetun-wiki/tree/main/setup#setup
|
||||
- VPN_SERVICE_PROVIDER=nordvpn
|
||||
- VPN_TYPE=wireguard
|
||||
# OpenVPN:
|
||||
# - OPENVPN_USER=
|
||||
# - OPENVPN_PASSWORD=
|
||||
# Wireguard:
|
||||
- WIREGUARD_PRIVATE_KEY=<YOUR_PRIVATE_KEY> # See https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/nordvpn.md#obtain-your-wireguard-private-key
|
||||
- WIREGUARD_ADDRESSES=10.5.0.2/32
|
||||
# Timezone for accurate log times
|
||||
- TZ=Europe/London
|
||||
# Server list updater
|
||||
# See https://github.com/qdm12/gluetun-wiki/blob/main/setup/servers.md#update-the-vpn-servers-list
|
||||
- UPDATER_PERIOD=24h
|
||||
qbittorrent:
|
||||
image: lscr.io/linuxserver/qbittorrent
|
||||
container_name: qbittorrent
|
||||
network_mode: "service:gluetun"
|
||||
environment:
|
||||
- PUID=1000
|
||||
- PGID=1000
|
||||
- TZ=Europe/London
|
||||
- WEBUI_PORT=8085
|
||||
volumes:
|
||||
- /home/ubuntu/docker/arr-stack/qbittorrent:/config
|
||||
- /home/ubuntu/docker/arr-stack/qbittorrent/downloads:/downloads
|
||||
depends_on:
|
||||
- gluetun
|
||||
restart: always
|
||||
jackett:
|
||||
image: lscr.io/linuxserver/jackett:latest
|
||||
container_name: jackett
|
||||
network_mode: "service:gluetun"
|
||||
environment:
|
||||
- PUID=1000
|
||||
- PGID=1000
|
||||
- TZ=Etc/UTC
|
||||
- AUTO_UPDATE=true #optional
|
||||
- RUN_OPTS= #optional
|
||||
volumes:
|
||||
- /home/ubuntu/docker/arr-stack/jackett/data:/config
|
||||
- /home/ubuntu/docker/arr-stack/jackett/blackhole:/downloads
|
||||
restart: unless-stopped
|
||||
sonarr:
|
||||
image: lscr.io/linuxserver/sonarr:latest
|
||||
container_name: sonarr
|
||||
network_mode: "service:gluetun"
|
||||
environment:
|
||||
- PUID=1000
|
||||
- PGID=1000
|
||||
- TZ=Etc/UTC
|
||||
volumes:
|
||||
- /home/ubuntu/docker/arr-stack/sonarr/data:/config
|
||||
- /home/ubuntu/docker/arr-stack/sonarr/tvseries:/tv #optional
|
||||
- /home/ubuntu/docker/arr-stack/sonarr/downloadclient-downloads:/downloads #optional
|
||||
restart: unless-stopped
|
||||
prowlarr:
|
||||
image: lscr.io/linuxserver/prowlarr:latest
|
||||
container_name: prowlarr
|
||||
network_mode: "service:gluetun"
|
||||
environment:
|
||||
- PUID=1000
|
||||
- PGID=1000
|
||||
- TZ=Etc/UTC
|
||||
volumes:
|
||||
- /home/ubuntu/docker/arr-stack/prowlarr/data:/config
|
||||
restart: unless-stopped
|
||||
```
|
||||
Reference in New Issue
Block a user