This document discusses using SSH to create secure tunnels through firewalls and between mutually firewalled hosts in 3 main ways:
1) Dynamic port forwarding with SOCKS allows flexible forwarding of any protocol by redirecting destination addresses. This gets around limitations of static port forwarding.
2) "Gateway cryptography" creates an independent encrypted path between client and server by using remote port forwarding to bypass firewall restrictions and authenticate separately.
3) SLIRP/PPTP over SSH can provide a user-mode VPN by forwarding SLIRP or PPTP encapsulated in SSH, without requiring root on both sides. This allows Windows clients to connect remotely through bastion hosts.
Using Secure Shell on Linux: What Everyone Should KnowNovell
Secure Shell, or SSH, is a network protocol that allows data to be exchanged over a secure channel. SSH is much more than just data being passed over the wire. SSH can be used to tunnel traffic and specific ports or applications across multiple servers. SSH is a must for anyone using Linux. If you haven't used SSH, then you have not used Linux!
This session is designed for all technical staff or decision makers curious about great Linux tools and making access to Windows services, remote desktops and remote servers easier and less complicated. During this session, we will demonstrate techniques to tunnel RDP sessions, SOAP sessions and HTTP sessions between remote systems.
Overview of the SSH protocol.
SSH (Secure SHell) is a secure replacement for TELNET, rcp, rlogin, rsh (for login, remote execution of
commands, file transfer).
Security-wise SSH provides confidentiality (nobody can read the message content), integrity (guarantee that data is unaltered in transit) and authentication (of client and server). This provides protection against many of the possible attack vectors like IP spoofing, DNS spoofing, Password interception and eavesdropping.
SSH exists in 2 versions. SSH-2 fixes some of the shortcomings of SSH-1 so it should be used in place of SSH-1.
SSH also comes with features that in itself raise security concerns like tunneling and port forwarding.
Slides from a presentation I gave on SSH. Covers basics of ssh, password|keys|host-based authentication, agent/key forwarding, configuration files (global and user-specific), local/remote port forwarding, scp, rsync, and briefly mentions git's support.
Using Secure Shell on Linux: What Everyone Should KnowNovell
Secure Shell, or SSH, is a network protocol that allows data to be exchanged over a secure channel. SSH is much more than just data being passed over the wire. SSH can be used to tunnel traffic and specific ports or applications across multiple servers. SSH is a must for anyone using Linux. If you haven't used SSH, then you have not used Linux!
This session is designed for all technical staff or decision makers curious about great Linux tools and making access to Windows services, remote desktops and remote servers easier and less complicated. During this session, we will demonstrate techniques to tunnel RDP sessions, SOAP sessions and HTTP sessions between remote systems.
Overview of the SSH protocol.
SSH (Secure SHell) is a secure replacement for TELNET, rcp, rlogin, rsh (for login, remote execution of
commands, file transfer).
Security-wise SSH provides confidentiality (nobody can read the message content), integrity (guarantee that data is unaltered in transit) and authentication (of client and server). This provides protection against many of the possible attack vectors like IP spoofing, DNS spoofing, Password interception and eavesdropping.
SSH exists in 2 versions. SSH-2 fixes some of the shortcomings of SSH-1 so it should be used in place of SSH-1.
SSH also comes with features that in itself raise security concerns like tunneling and port forwarding.
Slides from a presentation I gave on SSH. Covers basics of ssh, password|keys|host-based authentication, agent/key forwarding, configuration files (global and user-specific), local/remote port forwarding, scp, rsync, and briefly mentions git's support.
Shell is a protocol that provides authentication, encryption and data integrity to secure network communications. Implementations of Secure Shell offer the following capabilities: a secure command-shell, secure file transfer, and remote access to a variety of TCP/IP applications via a secure tunnel. Secure Shell client and server applications are widely available for most popular operating systems.
Joseph Salowey, Tableau Software
Transport Layer Security (TLS) 1.3 is almost here. The protocol that protects most of the Internet secure connections is getting the biggest ever revamp, and is losing a round-trip. We will explore differences between TLS 1.3 and previous versions in detail, focusing on the performance and security improvements of the new protocol as well as some of the challenges we face around securely implementing new features such as 0-RTT resumption.
Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. This presentation is made as an assignment during our university course.
Shell is a protocol that provides authentication, encryption and data integrity to secure network communications. Implementations of Secure Shell offer the following capabilities: a secure command-shell, secure file transfer, and remote access to a variety of TCP/IP applications via a secure tunnel. Secure Shell client and server applications are widely available for most popular operating systems.
Joseph Salowey, Tableau Software
Transport Layer Security (TLS) 1.3 is almost here. The protocol that protects most of the Internet secure connections is getting the biggest ever revamp, and is losing a round-trip. We will explore differences between TLS 1.3 and previous versions in detail, focusing on the performance and security improvements of the new protocol as well as some of the challenges we face around securely implementing new features such as 0-RTT resumption.
Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. This presentation is made as an assignment during our university course.
For the Greater Good: Leveraging VMware's RPC Interface for fun and profit by...CODE BLUE
Virtual machines play a crucial role in modern computing. They often are used to isolate multiple customers with instances on the same physical server. Virtual machines are also used by researchers and security practitioners to isolate potentially harmful code for analysis and review. The assumption being made is that by running in a virtual machine, the potentially harmful code cannot execute anywhere else. However, this is not foolproof, as a vulnerability in the virtual machine hypervisor can give access to the entire system. While this was once thought of as just hypothetical, two separate demonstrations at Pwn2Own 2017 proved this exact scenario.
This talk details the host-to-guest communications within VMware. Additionally, the presentation covers the functionalities of the RPC interface. In this section of the presentation, we discuss the techniques that can be used to record or sniff the RPC requests sent from the Guest OS to the Host OS automatically. We also demonstrate how to write tools to query the RPC Interface in C++ and Python for fuzzing purposes.
Finally, we demonstrate how to exploit Use-After-Free vulnerabilities in VMware by walking through a patched vulnerability.
Usually we launch hundreds of instances in AWS for day to day work. As long as they are accessible from our hosts (probably a RHEL or Ubuntu or your own mac), we are good to go. But there are some instances where you might get a patch from IT for your host. Once you apply the patch, you realize that you are unable to access your AWS instances anymore. And your IT team doesn't have any clue on what happened. You contact AWS support, and they say it all looks good. So how do you proceed from this scenario? Where to start and what to do. This talk goes through all the steps starting with most basic checks all the way to updating the crypto key exchange algorithms on your host.
Shameful secrets of proprietary network protocolsSlawomir Jasek
There is a big bunch of tools offering HTTP/SSL traffic interception. However, when it comes to penetration tests of specialized embedded software or thick clients, we often encounter proprietary protocols with no documentation at all. Binary TCP connections, unlike anything, impossible to be adapted by a well-known local proxy. Without disassembling the protocol, pentesting the server backend is very limited. Though, based on our experience, it very often hides a shameful secret - completely unsecured mechanisms breaking all secure coding practices.
To demonstrate, we will show a few case-studies - most interesting examples from real-life industry software, which in our opinion are a quintessence of "security by obscurity". We will challenge the security of proprietary protocols in pull printing solutions, FOREX trading software, remote desktops and home automation technologies.
25 years of firewalls and network filtering - From antiquity to the cloudshira koper
The first commercial firewall shipped in 1992. 25 years later the firewall is still the core building block of enterprises’ security infrastructures. Please join Prof. Avishai Wool, AlgoSec’s CTO, for an educational webinar on the history of the firewall. He will take you through a riveting 25-year journey of the evolution of the firewall - from the ancient world of the host-based firewalls of the 90s, to today’s cloud-based firewalls, and will explain how each type of firewall works, its advantages and limitations, and provide some tips and best practices for effective network filtering.
In this highly informational, and entertaining webinar Professor Wool will cover:
• The Early 90s: Host vs. Network
• Late 90s: Keeping State
• 2003: Zone-Based firewalls
• 2010: Next-Gen firewalls
• 2015: Virtualized and cloud firewalls
The Slides deck contains Network penetration testing requirements & Tools used in real world pentesting. For Demo purposes, I had used a vulnhub machine called Metasploitable 2 for testing purposes. Looking into various Ports and Services Vulnerabilities using Kali open source tools.
Introducing bastion hosts for oracle cloud infrastructure v1.0maaz khan
Bastion hosts leverage easy and secure connectivity from your On-premise to OCI regions. They are created in Public subnet with a Public IP. They secure hosts like db and applications servers in private subnet using a multi-tiered approach. They can be very effective for customers who are reluctant initially to use IPSec VPN or FastConnect to connect to OCI but still want to have POC done with their on-premise data.
This presentation will cover following -
1. Introduction to Bastion Hosts
2. Securing connectivity between bastion hosts and On-premise connectivity.
3. Securing Bastion hosts on public network to safeguard cloud resources.
4. Alternatives to Bastion hosts.
Docker Networking - Current Status and goals of Experimental NetworkingSreenivas Makam
This slidedeck covers overview of Docker Networking as of Docker 1.8, drawbacks of current Docker Networking and goals of Docker Experimental Networking.
Nagios Conference 2013 - Leland Lammert - Nagios in a Multi-Platform EnviornmentNagios
Leland Lammert's presentation on Nagios in a Multi-Platform Enviornment.
The presentation was given during the Nagios World Conference North America held Sept 20-Oct 2nd, 2013 in Saint Paul, MN. For more information on the conference (including photos and videos), visit: http://go.nagios.com/nwcna
2. Summary
• This is not how to crack SSH. This is
SSH on crack.
• 1) How to get there from here
• 2) What to do once you get there
• 3) Making getting there easier
3. Gateway Cryptography
Methodology
• Basic Philosophy For End To End Security
– Step 1: Create a valid path from client to server
– Step 2: Independently authenticate and encrypt
over this new valid path
– Step 3: Forward services over the independent
link
• Pragmatic Law: If it isn’t usable, nobody
uses it.
4. The Basics
• Bringing people up to speed
– This is not another talk about the wonders of a simple
local port forward
• What OpenSSH does
– Forwards a shell (w/ transparent X support)
– Forwards a single command (with full stdio)
– Forwards a single TCP port
• “All SSH forwards are non-exclusive and non-
transparent figments of userspace”
5. SSH under Windows
• 1) Install Cygwin from www.cygwin.com
• 2) Create a shortcut to rxvt
– C:cygwinbinrxvt.exe -rv -sl 20000 -fn
“Courier-12" -e /usr/bin/bash
• bash doesn’t work under whistler yet, so use zsh if you want to
retain your tab-completion sanity
• 3) Finally enjoy a usable Unix environment under
Win32
• Everything in this talk is cross platform, as long as
you’ve made Windows cross to another platform
7. Forwarding Commands
• ssh user@host ls
ssh –t user@host top
• Fully 8 bit clean for most commands,
supports (unclean) TTYs for anything that
wants to redraw screen (like top) using –t
• Full STDIO(stdin/stdout/stderr) support
– Allows pipelines across multiple systems
8. Command Forwarding:
CD Burning Over SSH
• mkisofs reads in files and spits out a burnable
image
• cdrecord burns the image.
– Find out the SCSI ID of your burner
cdrecord -scanbus
– Normal CD Burning
mkisofs –JR files | cdrecord dev=#,#,# speed=# -
– Remote CD Burning
mkisofs –JR files | ssh user@host cdrecord dev=#,#,# speed=# -
– Remote CD Burning From Windows
mkisofs.exe –JR files | ssh.exe user@host cdrecord dev=#,#,#
speed=# -
– Remote CD Burning From Windows For Users
• Right Click On Files/Directories, Click Send To, Click CDR.
– Under development; trivial to write
9. Command Forwarding:
File Transfer w/o SCP
• # GET
alicehost$ ssh alice@bobhost “cat file” > file
# PUT
falicehost$ cat file > ssh alice@bobhost “cat > file”
# LIST
alicehost$ ssh alice@bobhost “ls”
# MGET
alicehost$ ssh alice@bobhost “tar -cf - /etc” | tar -xf –
# RESUME GET
alicehost$ ssh alice@bobhost “tail –c 231244 file” >> file
• Planning on implementing SFTP using nothing
more than these commands
– SCP is just annoying me more and more, though the
syntax is temporarily more convenient
– Interesting possibilities through tunneling dd
10. Forwarding Ports
• ssh user@host -L8000:127.0.0.1:80
ssh user@host -R80:127.0.0.1:8000
• Separates into “listener” vs. “location”
– If local listens, the destination is relative to the
remote location
– If remote listens, the destination is relative to
the local location
11. Limitations on Port Forwards
• By default, only the systems directly
hosting the listener can connect to it
– Local forwards can be made public using the –g
option, but remote “gateway ports” must be
enabled using GatewayPorts Yes
• Destination locations are unrestricted
12. Accessing a Port Forward
• Application Layer
– Connect Directly to 127.0.0.1 or “localhost”
• Operating System Layer (“systemspace”)
– Pre-empt DNS lookup in hosts file
• Unix: /etc/hosts
• Win95: windowshosts
• WinNT: WINNTsystem32driversetchosts
• All forwards must be preannounced, and share the
same IP (127.0.0.1)
13. Problem:
Static Forwards Are Inflexible
• Work decently only when:
– Each port is only used once
• Passes:
– Mail(smtp, pop3, imap)
– Simple Web(HTTP)
• Fails:
– Web Surfing Multiple Sites (HTTP)
– P2P File Transfer(Napster, Gnutella),
– Ports are predictable in advance
• Fails miserably
– FTP, both Active and Passive
14. Solution:
Dynamic Forwarding w/ SOCKS
• ssh user@host -D1080
• SOCKS4/5: An in-band protocol header,
nothing more, that allows the client to very
quickly tell a proxy server where its actual
destination was
• SOCKS4 is extraordinarily simple
– ~9 bytes from Client, 8 byte response, and the client
has informed the “proxy” where it actually wants to go!
– “Library Preloads” are excessive
• The idea: Run a trivial SOCKS daemon in the ssh
client; use it to redirect the destination of each
channel.
15. Dynamic Forwarding:
Application Support
• Most major Windows applications support
SOCKS proxies directly
– Internet Explorer, CuteFTP, IM Clients, P2P
Clients(Napster, Gnutella)
– Dialpad (Voice over IP to a telephone for free over
SSH!)
• SocksCap32 can be used to “Socksify” remaining
apps on Windows
– Outlook Express, LeechFTP, Media Player, etc.
• Unix applications can be reasonably socksified too
16. Dynamic Forwarding:
Faults In The Hack
• No Network Isolation
– Though this, of course, is “trusting the client”,
there’s still value in a client itself volunteering
to ignore all communications not through the
VPN “solution”.
• No Unified Configuration and Management
Interface
– Fixable, should this become popular.
17. Dynamic Forwarding:
THE BIG PROBLEM
• Server Freeze
• Most SSH servers will temporarily block(lock up)
if you attempt to open a channel to a host that
either doesn’t exist or cannot be resolved
• General purpose solutions to this get…ugly.
– OpenSSH has fewer problems in this arena
• OpenSSH has no inherent SOCKS client
support – cannot easily connect to dynamic
port forwards
18. ProxyCommand:
Blind Proxying w/ SSH
• ssh -o 'ProxyCommand arbitrary_tool proxy %u %h %p'
user@10.1.0.1
• A ProxyCommand is an arbitrary tool that, after it
finishes executing, leads to an 8 bit clean path to
an SSH daemon
– OpenSSH's excuse for SOCKS support :-)
– Tool for creating a valid path via an arbitrary command
– host$ nc ssh_server 22 #see the banner
SSH-1.99-OpenSSH_2.9p1
host$ arbitrary_tool proxy user ssh_server port
SSH-1.99-OpenSSH_2.9p1
• Allows end-to-end crypto through any 8bit clean
link
19. Wire Mode:
Facilitating Self-Proxying SSH
• ssh user@proxy -Whost:22
• ProxyCommand needs an 8 bit path
• SSH exists to provide 8 bit paths
– Correct Method: Open a local port forward, use
glue code to directly connect it to ttyless stdio
code
– Cheap Hack Method: Translate –Whost:22 into
“nc host 22”
20. Using netcat-based Wire Mode
• ssh -o 'ProxyCommand ssh user@proxy "nc %h %p"'
user@server
• Completely unusable
• Alternative Syntax Under Development
– ssh –B proxy user@server
– ssh proxy/user@server
• Competes with:
– ssh user@proxy
proxy$ ssh user@server
• The PROXY authenticates
• The PROXY decrypts
• The PROXY is Internet accessible
• When the PROXY gets hacked, the network is toast.
21. No Internet Accessible Bastion
Proxy: Now What?
• server$ ssh user@client -R2022:127.0.0.1:22
client$ ssh user@127.0.0.1 -o "HostKeyAlias
server" -L8000:www-internal:80
or (in upcoming builds, hopefully)
client$ ssh user@proxy/2022
-L8000:www-internal:80
• Step 1: Create a valid path from client to server
– Use a remote port forward
• Outgoing in the context of the firewall
• Incoming in the context of the client
• Step 2: Independently authenticate and encrypt
over this new valid path
– Remotely Forward SSHD, not Web etc.
• Step 3: Forward services over the independent link
22. Theory And Dire Warning
• Turns inability to trust into irrelevancy of trust
– Negative: “You can’t trust the addresses of x, y, or z!”
– Positive: “It doesn’t matter if you think you’re talking
to the addresses of x, y, or z.”
• MUST CHECK HOSTKEY – it’ll work even if
you don’t
– Either use ‘HostKeyAlias’ or use the new concentrated
syntax (not out yet)
23. Cross-Connecting Mutually
Firewalled Hosts
• server$ ssh proxyuser@proxy
-R2022:127.0.0.1:22
client$ ssh -o 'ProxyCommand ssh
proxyuser2@proxy “nc 127.0.0.1 2022”’
user@server -L8000:www-internal:80
or in my syntax
client$ ssh proxyuser2@proxy/2022 user@server
-L8000:www-internal:80
• Step 1: Create a valid path from client to server
– Server can’t directly connect to client anymore
• Who said the server needs to be directly connected
to the client?
• Server and Client both use outgoing links
– Instead of the client connecting to its own port 2022, it
connects through a remote host’s 2022
• That’s the only thing different.
24. Fixing Port Forwards:
Defaults
• ssh -L143 -> ssh -L143:127.0.0.1:143
ssh –Lfoo:80 -> ssh –L80:foo:80
ssh –L2022:foo -> ssh –L2022:foo:22
• Begin with a default of 22:127.0.0.1:22, do some
moderately painful string parsing in C, and
actually end up with a decently compressed syntax
• Would forwarding ranges be useful, i.e.
ssh -L7000-7020 ? Still deciding.
25. Expanding Escape Syntax
• noname# ~?
Supported escape sequences:
~. - terminate connection
~R - Request rekey (SSH protocol 2 only)
~^Z - suspend ssh
~# - list forwarded connections
~& - background ssh (when waiting for connections to
terminate)
~? - this message
~~ - send the escape character by typing it twice
(Note that escapes are only recognized immediately after
newline.)
• Eventual goal: Port both ssh_config syntax and
ssh command line syntax to the escape character
mode
– Allow on-demand things like activation of X
forwarding
26. Secure SU:
The Battle Against Direct Root
• Most “security gurus” will decry direct root login
– Holdover from the battle against admins doing
everything as root
– SU is a painless enough context switch
• If it hurts to switch, people will just do it all as root
– Advantages to being forced to switch accounts
• Inertia
• Emotion – significance of the action is emphasized
• Accounting – logs show who used root
– Even though it essentially reduces the security of the
root account to the security of the Alice account, even
OpenBSD (2.7, at least) still exhorts users not to ssh
directly to root, and instead to use SU.
27. Secure SU:
The Near-Perfect Compromise
• alicehost$ ssh alice@bobhost -t “su –l root”
or in my syntax
ssh alice+root@bobhost
• SSHD creates a secure execution environment
when commands are explicitly specified
– Shell configuration files not loaded
– su, as a setuid app, can’t generally be traced by
ordinary users
• User logs in as normal, is safely prompted for the
root password, gets a root shell without having to
“slum” in through insecure space
28. Secure SU:
Developing: Individuated Root
• Individual Public Keys For Root Access
– Nobody learns root password
• authorized_keys contains list of identities allowed to connect
as root to the system
– SSHD modified to log who connected to root
– Scales to multiple security-critical accounts
• Root can modify its own authorized_keys, but other accounts
could have root owned, root readable authorized_keys files.
• Individual Root Accounts
– Multiple accounts all set to same UID, but with
different passwords
• Alice_Root, Bob_Root, etc.
– Really only works for root
29. SLIRP/PPTP over SSH:
Starting with PPPD
• PPPD: Standard Unix PPP Server
– Generally creates an interface on its host called ppp#
– Sets up a bidirectional route—works as an
infrastructure-level datapath
– Addressing can be manually or automatically
negotiated
– Standard Dialup Protocol
• Command Forwarding allows remote PPPD to
cleanly talk to local PPPD, thus creating a Host-
To-Host VPN between two hosts
– Requires root on both
– “PPP over SSH”
30. SLIRP/PPTP over SSH:
SLIRPing a way
• SLIRP: User Mode NAT
– Written around 1995
– Amazingly useful to this day—doesn’t require root!
– Converts any 8 bit clean shell into a PPP server, NATs
the incoming TCP/UDP/ICMP and opens the necessary
sockets on the shell server
– Command Forwarding SLIRP instead of PPPD into
local PPPD requires root on only one host, but only the
host running PPPD gets an OS-level route
• Useful, but dangerous--but you’re trusting the server not to
replace SLIRP with a hacked version that gives them a path
back through your ready-and-willing PPPD.
31. SLIRP/PPTP over SSH:
PPP over PPTP
• PPTP: Point to Point Protocol
– Encapsulates PPP(Layer 2) inside of a GRE(Layer 3)
Tunnel, allowing TCP/UDP/ICMP(Layer 4) traffic to
pass
• Also uses 1731/TCP to initialize link
• Try not to wrap your brain around this
– Created by Microsoft as a VPN Solution
• Version one was…infamously flawed. Version two is
somewhat better, but not widely trusted.
• Client ships with and is integrated into Windows 98/Me/2000
– Stable Interface
– Network Isolation
– Good UI
– SSH cannot forward GRE internally
32. SLIRP/PPTP over SSH:
PoPToP Puts It Together
• PoPToP: Unix PPTP Daemon
– Implements GRE encapsulation only
• Doesn’t re-implement PPP!
• Executes PPPD or SLIRP inside of GRE
• Who says the daemon needs to be local?
• End Result
– Windows 98 connects to user bastion host using PPTP
– PoPToP strips GRE header, goes to execute PPP
daemon
– SSH cleanly forwards a SLIRP command run as a user
on a remote bastion host into PoPToP
– Windows 98 isolates itself and experiences remote
33. SLIRP/PPTP over SSH:
HowTo
• The really lazy way
– Used when source is closed but the binary app shells
out to some external binary
– Really really lazy for PoPToP because it’s open source
– mv /usr/bin/slirp slirp_binary
echo ‘#!/bin/sh’ >> /usr/bin/slirp
echo ‘ssh user@host slirp_binary’ >>
/usr/bin/slirp;
• The less lazy way
– Modify PoPToP to execute ‘ssh user@host slirp’
instead of ‘slirp’;
– Should be noted that there’s *no* authentication to this
link inside the PPTP network
34. The Link Crypto Problem
• Link Based Systems: SSH, SSL, SCH(Spiffy
Custom Hardware)
– All have decryption key available on other side of link
• Corollary: Decryption key available on linked host
– All decrypt immediately
• Reality: Almost never re-encrypted
• File Based Systems: GPG
– Can, but often don’t segment ability to encrypt from
ability to decrypt
35. Quick File Crypto Tip 1:
Locked Drops
• Public/Private Encryption
– AKA Asymmetric
– Anyone can encrypt, only you can decrypt
• Storage Purposes
– Any machine can encrypt data, but only a limited set of
systems can decrypt it
• Hosts send data to a backup server that never receives the
encryption key
• Clients send encrypted logs to a server through insecure
network; decryption key is stored on a central server far
behind the network
• Database stores credit card numbers in encrypted form,
decryption occurs in the administrator’s client one at a time
36. Quick File Crypto 2:
Dynamic Rekeying (DROP)
• Damage of a key compromise tied to how much
useful information can be decrypted with that key
• Changing keys restricts the damage of a key
compromise, but increases risk that a bad key will
be used
• Using a long term identity key to sign short term
encryption keys limits damage of key update
while providing Forward Secrecy
37. Conclusion
• ssh is powerful
• ssh is flexible
• ssh is fun.
• gpg is cool too
• any questions? any requests? bueller?