Search This Blog

Showing posts with label SSH. Show all posts
Showing posts with label SSH. Show all posts

Saturday, 8 November 2014

Risk reduction through Jump Servers



A common practice in today's data centers is to allow Systems Administrators Remote Desktop  (RDP) or Secure Shell (SSH) access to the servers they are administrating, directly from their desktops.  Regardless of where they are located!

Although restricting Lateral access between servers is quite easily achieved through group policy on Windows, or source whitelisting local firewall rules for both Windows and UNIX/Linux, these are not enabled by default. Typically, even with network segmentation and access control lists, is is possible to jump from server to server unhindered, by simply having access to the appropriate credentials. 



Both the Target Breach, and the Home Depot Breach were initiated by a compromised business partner with access to internal resources.  Those accounts were used to assess the network topology and browse the corporate directories to find more privileged accounts. Once inside, these credentials could be used to log onto servers within the environment in search of information or more credentials to abuse. The attacker could, over time, hop from server to server essentially unnoticed.




Restricting Lateral Access within your Network
The concept of a "jump" server has been around for decades, but is rarely in use or enforced.  One popular use of jump servers is to restrict access into a DMZ. This allows administrative control of servers in the DMZ to be regulated and audited as per compliance rules.


In Microsoft Technet's  "Implementing Secure Administrative Hosts", they state: 
Secure administrative hosts are workstations or servers that have been configured specifically for the purposes of creating secure platforms from which privileged accounts can perform administrative tasks in Active Directory or on domain controllers, domain-joined systems, and applications running on domain-joined systems. In this case, “privileged accounts” refers not only to accounts that are members of the most privileged groups in Active Directory, but to any accounts that have been delegated rights and permissions that allow administrative tasks to be performed.
.......

Although the “most privileged” accounts and groups should accordingly be the most stringently protected, this does not eliminate the need to protect any accounts and groups to which privileges above those of standard user accounts have been granted.

A secure administrative host can be a dedicated workstation that is used only for administrative tasks, a member server that runs the Remote Desktop Gateway server role and to which IT users connect to perform administration of destination hosts, or a server that runs the Hyper-V® role and provides a unique virtual machine for each IT user to use for their administrative tasks. In many environments, combinations of all three approaches may be implemented.

So... restrict access to servers, specifically for anyone with privileges above a basic user. 
I can't argue with that at all... 


Enter CyberArk's Next Generation Jump Server

More than just a jump server from which to initiate RDP or SSH sessions, CyberArk has added Privileged Session Management to monitor and record all access through the jump server. The tightly integrated SSH proxy is context aware, and can be configured to look for anomalous behavior.  Not only can you control "who" has access to "what" through the jump server, but you can alert on suspicious or anomalous activity within those sessions.  Both secure RDP to Windows servers, as well as SSH to UNIX/Linux/Network appliances are managed via Privileged Session Manager on the jump server.  

The jump server can now be used to isolate your server environment from  your workstation endpoints, and provide real-time visibility into administrative access.  Without adding agents to the servers being administered, you can use workflows to augment authentication and authorization, and monitor access at a granular level, recording all activities for future playback and potential audit attestation.

Integrate this service with their Enterprise Password Vault, and you have significantly reduced privilege escalation from your threat landscape.



Rogue or Malicious Administrator
Many companies, small and large alike, allow almost unrestricted access to the data center servers for administrator, both from within the local network, and over VPN. The excuse being that this is required in case of a emergency.

This excessive access allows anyone authenticated, malicious or otherwise, to jump laterally from server to server.  The Target Breach, in particular is known to have accommodated it's attackers by allowing a credentialed account in the Business Partner network to access servers in the core data center, and ultimately get on to the Point-of-Sale systems.  Restricting this lateral access by enforcing the use of jump servers would not totally remove the Rogue Administrator threat, however all access through the server would be monitored and recorded.  Any administrative commands/requests/activities that were deemed anomalous by predefined security policies could be blocked and/or alerted on.


Malware Mitigation
By allowing lateral access between servers, an infected server could act to propagate malicious code to its peers. Most Advanced Persistent Threats rely on the ability to see peer servers laterally and scan them for exploitable opportunities.  With jump servers in place, and lateral access removed through policy, malicious actors and malware alike will not be able to propagate without going through the jump server and being seen/alerted/blocked.


Pass the Hash
One of the techniques typical of a APT is the “Pass the Hash” attack, where the invader captures account logon credentials in the form of a cached password "hash" on one machine and then use them to authenticate to another machine.  This little known exposure has been around for a couple decades, but has become an industry favorite among cyber criminals.  By enforcing all server remote administration through the jump servers, this method of subversion is eliminated.

Don't be the next headline.  Choosing either CyberArk's suite of Privileged Access and Session Management tools or another Remote Access Gateway product will significantly reduce your threat landscape and allow you to sleep more easily.


References:

CyberArk: Are You Ready to Take the Next Jump? Secure your IT Environment with Next Gen Jump Servers
Privileged Accounts at Root of Most Data Breaches
http://en.wikipedia.org/wiki/Pass_the_hash
SANS: Pass-the-hash attacks: Tools and Mitigation
Microsoft: Defending Against Pass-the-Hash Attacks
CyberArk Launches Enhanced “CyberArk DNA” to Detect Pass-the-Hash Vulnerabilities
NSA: Reducing the Effectiveness of Pass-the-Hash 
The World's #1 Cyber Security Risk - Active Directory Privilege Escalation
IT World Canada: Early lessons from the Target breach
IT World Canada: Hacking of HVAC supplier led to Target breach: Report
IT World: Home Depot says attackers stole a vendor's credentials to break in
Cisco: Putting a Damper on ‘Lateral Movement’ due to Cyber-Intrusion  
Trend Micro: How Do Threat Actors Move Deeper Into Your Network? 
Prevent Lateral Movement With Local Accounts (Windows) 
Lateral Movement: No Patch for Privilege Escalation 
Intel: Achieving PCI DSS compliance when managing retail devices with Intel® vPro™ technology 
Techrepublic: Jump boxes vs. firewalls 
Microsoft: Implementing Secure Administrative Hosts 
CyberArk: Privileged Session Manager 
ITWorld Canada: The 10 Step Action Plan - Building Your Custom Defense Against Targeted Attacks and Advanced Persistent Threats

Wednesday, 22 October 2014

CyberArk positioned to lead Industry in SSH key management practice

CyberArk, best known for it's Privileged Password Vault, and recent IPO success story has just announced a new product set.  At the 2014 CyberArk Customer Event held in Boston this week, they announced their new SSH key manager. (October 21st 2014)



"The CyberArk SSH Key Manager is designed to securely store, rotate and control access to SSH keys to prevent unauthorized access to privileged accounts."
Extending their already successful Enterprise Vault Infrastructure, CyberArk protects SSH keys with the highest level of security and granular control. Keys in the vault are encrypted, and managed in a fashion not unlike their Password Management Infrastructure.  Integrating SSH keys into this platform creates a one-stop-shop for Privileged Access Management on both Windows and UNIX/Linux platforms.



In January of 2013, CyberArk added Privileged Session Management for UNIX and Linux systems to their growing arsenal of Privileged Management tools. This led me to blog about the requirement to Treat Your Key Pairs Like Passwords!  It looks like they were listening...

Up until this week, there was only SSH.COM, with their Universal SSH Key Manager, and Venafi, with their Trust Authority SSH manager. 

 With the announcement of CyberArk's new SSH key manager, we now have an Enterprise holistic approach to Privileged User Account Management across the network.


References:
CyberArk: SSH Key Manager
Infosec Musings: Treat Your Key Pairs Like Passwords!
http://security-musings.blogspot.ca/2013/01/privileged-identity-management-make.html
http://www.cyberark.com/resource/isolation-control-monitoring-next-generation-jump-servers/
http://en.wikipedia.org/wiki/Privileged_Identity_Management
http://www.cyberark.com/esg-validating-privileged-account-security-while-validating-cyberark
IDC: A Gaping Hole in Your Identity and Access Management Strategy: Secure Shell Access Controls 
Networkworld: SSH key mismanagement and how to solve it 



Monday, 7 July 2014

FTP, SFTP, FTPS? What's the difference, and how the !@#$ do I secure them?

File Transfer (FTP) may be the single most insecure piece of infrastructure that any corporation has.  It's roots date back to the early 70's before encryption and transport security were of great concern. 

Many common malware attacks rely on unsecured FTP services within a company to stage and exfiltrate sensitive corporate data to unknown third parties.


There is little excuse for a company to be running vanilla FTP either inside their data center or especially over the Internet.  Secure file transfer protocols and standards have been around and fully supported SINCE THE TURN OF THE CENTURY!!!
 From the Tibco report: Understanding the Impact an FTP Data Breach Can Have on Your Business
"...what about the threat information contained on an unsecured
FTP server could pose to a business like yours? Consider a few other recent FTP
exposures:
  • CardSystems, who processed credit card transactions for nearly 120,000 merchants totaling more than $18 billion annually, were essentially forced out of business after 40 million identities were exposed. Amex and Visa told CardSystems that they would no longer do business with the company.
  • 54,000 records were stolen from Newcastle City Council
  • An unsecured document was exposed on the New Mexico Administrative Office of the Courts FTP server; it contained names, birth dates, SSNs, home addresses and other personal information of judicial branch employees.
  • The Hacker Webzine reports that Fox News had an exposed FTP connection linking out to Ziff Davis.
  • The personal information of uniformed service members and their family members were exposed on an FTP server while being processed by major Department of Defense (DoD) contractor SAIC. As many as 867,000 individuals may have been affected."

 
Lets take a minute to discuss the legacy FTP system, it's derivative FTPS, and the completely different SFTP.

FTP  (Do not use this EVER!)
The FTP (File Transfer Protocol) protocol was documented in 1971 as  RFC 114 and eventually evolved into RFC 959 , the FTP standard that all systems use today. It has been the workhorse of most corporate file transfer systems in production.

All current Server Operating Systems, whether Windows, Unix, Linux, MAC, or Mainframe come with a variant of an FTP service following RFC 959.
There are VERY many FTP client applications available for each and every Desktop, Laptop, Tablet and smartphone in existence, also complaint with RFC 959.    
(Did I mention that there is no reason in this day and age to use vanilla FTP, EVER?)

FTPS
Once companies and security consultants  realized the great risk that FTP exhibits by sending corporate data "in the clear" over the network, they proposed RFC 2228 (in 1997) to protect FTP data in transit using SSL encryption.  Aside from transport encryption the service is identical to FTP.  

FTPS transport encryption comes in two flavors Implicit, and ExplicitImplicit FTPS (Now pretty much obsolete) establishes an SSL or TLS session prior to exchanging data, over TCP ports 989(data)/990(control).  Explicit FTPS, the more common of the two, can use a single port for both encrypted and unencrypted data transfer.  The client initially establishes an unencrypted session, and if SSL/TLS is required, an AUTH TLS or AUTH SSL command is issued by the client to secure the control channel before sending credentials.

And then there's....

SFTP
Although regularly  confused with FTPS, SFTP is actually an application in the  SSH  protocol suite.  RFC4253 "The Secure Shell (SSH) Transport Layer Protocol"  defines the security model of this Secure File Transfer Protocol.   Whereas FTPS relies on SSL (X.509) Certificates with their associated PKI requirements to secure the session, SFTP uses Diffie-Hellman Key Exchange to manage an asymmetric pair of keys to secure the session. All UNIX based systems (Including MAC, Linux, and Mainframe) come with SSH preinstalled.   There are many variants available for Windows as well.



Both SFTP and FTPS are fully scriptable (ie: support automation). Either one is acceptable, depending on the application, and Operating System at hand.

Up to this point, we've discussed securing the Data Transport, or "Data in Motion", but what about securing the "Data at Rest"?  How do we secure the file transfer directory structure?

In simplest terms, strong user/group access controls are required on FTP service directory structure.  I'm going to link to some vendor recommendation sites here:

Disable Anonymous FTP!  Sorry, but you should know who is connecting to your file server.


But, for the best level of security
run SFTP (ok, even FTPS) inside a chroot jail or sandbox

In the UNIX world (Including MAC, Linux, Mainframe), a chroot is a virtual filesystem that can be associated with a specific service, in this case SFTP.  A new protected replica of the OS folders and files relevant to running that service are created, and all files uploaded/downloaded via this service reside inside the protection of the "jail"

In Windows, the practice is typically called "Sandboxing" or Application Virtualization:
    (excerpt from Microsoft: Transform applications into managed services )
"In a physical environment, every application depends on its OS for a range of services, including memory allocation, device drivers, and much more. Incompatibilities between an application and its operating system can be addressed by either server virtualization or presentation virtualization; but for incompatibilities between two applications installed on the same instance of an OS, you need Application Virtualization.  "



And last but CERTAINLY not least:   Scan your network for rogue FTP services (Both Data Center as well as Workstation space) regularly (FREQUENTLY), find them physically, and shut them down!



References:
EITF.ORG: RFC913 - Simple File Transfer Protocol
EITF.ORG: RFC914 - A File Transfer Protocol
EITF.ORG: RFC959 - FILE TRANSFER PROTOCOL (FTP)
EITF.ORG: RFC2228 - FTP Security Extensions
IETF.ORG: secsh-filexfer (SFTP)
IETF.ORG: How to Use Anonymous FTP   -- DON'T!

IANA.ORG: Service Name and Transport Protocol Port Number Registry

TIBCO: Understanding the Impact an FTP Data Breach Can Have on Your Business
Understanding Key Differences Between FTP, FTPS and SFTP
SFTP versus FTPS – What is the best protocol for secure FTP? 
What’s the Difference? FTP, SFTP, and FTP/S 
Filezilla: SFTP specifications
http://winscp.net/eng/docs/ftps 
Using FTP? Know the Risks
wikipedia.org: Public key infrastructure 
SANS: Clear Text Password Risk Assessment Documentation
SFTP chroot 
https://wiki.archlinux.org/index.php/Change_Root
http://www.unixwiz.net/techtips/chroot-practices.html 
Oracle: Configuring and Using Chroot Jails
Winquota: Winjail 
Microsoft: Application Virtualization 


Friday, 8 February 2013

Treat Your Key Pairs Like Passwords!

I just had this conversation with a friend, and decided to pull this old blog over to here to stir some discussion...


We have all been taught the Best Practices for Password Management.  There is no shortage of publications providing guidance on password management.

  1. Don't use Personally Identifiable Information (PII) in your password
  2. Don't use any word that can be found in the dictionary 
  3. Create passwords at with at least eight characters
  4. Change your critical passwords on a regular basis (although this theory is being challenged)
So why do we not have these same discussions around Certificate or Key Pair Management?
(This is not a trainer on cryptography, but rather a discussion on proper management) 

These provide similar functionality as a username/password.  They provide authority as to who you are, to the system you are communicating with. They also provide the user with a sense of security/confidentiality.

However, keypairs and certificates, like passwords, can be compromised!   Even the mighty RSA SecureID is not impervious to attack.

 Typically, ssh keys are used to automate authentication to a host. That said, according to ssh.com
 "About 10 percent of all SSH user keys provide root access, creating a major security and compliance issue"

Many administrators use the same keys across multiple hosts. Similar to using the same password, this could be an issue when that key is compromised.  These very people are also the ones who have sudo access to privileged resources. A compromised machine could be silently used for a man in the middle attack.


I suggest that we need to start managing keypairs and certificates in a similar fashion to passwords.


Keypair  best practices:
  1. Create a corporate policy for Keypairs and Certificates!
  2. Treat your passphrase as you would a regular password (rules above)
  3. Use different keypairs for critical systems, privileged access, and regular access
  4. Do not share your private key with anyone.... ANYONE
  5. Change your keypairs on a regular basis (maybe not as frequent as passwords, but...)
Beyond simply managing your current keypairs and certificates, you should do a discovery to see how many stagnant or unused keypairs are in your environment.   Both Venafi and SSH.Com have discovery tools that will assist in identifying how prevalent keys and certificates are within your environment.  They will scan your network, and catalog existing SSL certificates and assymetric keys, providing pertinent information regarding expiry, ownership, strength, etc...
There are many companies in the marketplace that provide x.509 / SSL Certificate discovery and management, but few have stepped up yet for managing those critical ssh/and pgp keypairs.  

Ok, I've started the discussion...  let's talk... 
   This document presents current recommended practice for managing SSH
   user keys for automated access.  It provides guidelines for
   discovering, remediating, and continuously managing SSH user keys and
   other authentication credentials.

 Resources: