ゼロトラストの未来とSASEの現在今すぐ登録

閉める
閉める
  • セキュリティサービスエッジ製品 シェブロン

    高度なクラウド対応の脅威から保護し、あらゆるベクトルにわたってデータを保護

  • Borderless SD-WAN シェブロン

    すべてのリモートユーザー、デバイス、サイト、クラウドへ安全で高性能なアクセスを提供

  • Secure Access Service Edge シェブロン

    Netskope SASE は、クラウドネイティブで完全に統合された単一ベンダーの SASE ソリューションを提供します。

未来のプラットフォームはNetskopeです

インテリジェントセキュリティサービスエッジ(SSE)、クラウドアクセスセキュリティブローカー(CASB)、クラウドファイアウォール、セキュアウェブゲートウェイ(SWG)、およびZTNAのプライベートアクセスは、単一のソリューションにネイティブに組み込まれており、セキュアアクセスサービスエッジ(SASE)アーキテクチャへの道のりですべてのビジネスを支援します。

製品概要はこちら
Netskopeの動画
Next Gen SASE Branch はハイブリッドである:接続、保護、自動化

Netskope Next Gen SASE Branchは、コンテキストアウェアSASEファブリック、ゼロトラストハイブリッドセキュリティ、 SkopeAI-Powered Cloud Orchestrator を統合クラウド製品に統合し、ボーダレスエンタープライズ向けに完全に最新化されたブランチエクスペリエンスを実現します。

Next Gen SASE Branchの詳細はこちら
オープンスペースオフィスの様子
SASEアーキテクチャの設計 For Dummies

SASE設計について網羅した電子書籍を無償でダウンロード

電子書籍を入手する
セキュアアクセスサービスエッジ(SASE)アーキテクチャの採用

Netskope NewEdgeは、世界最大かつ最高のパフォーマンスのセキュリティプライベートクラウドであり、比類のないサービスカバレッジ、パフォーマンス、および回復力を顧客に提供します。

NewEdgeの詳細
NewEdge
明日に向けたネットワーク

サポートするアプリケーションとユーザー向けに設計された、より高速で、より安全で、回復力のあるネットワークへの道を計画します。

ホワイトペーパーはこちら
明日に向けたネットワーク
Netskope Cloud Exchange

Netskope Cloud Exchange (CE) は、セキュリティポスチャに対する投資を活用するための強力な統合ツールを提供します。

Cloud Exchangeについて学ぶ
Netskopeの動画
最小の遅延と高い信頼性を備えた、市場をリードするクラウドセキュリティサービスに移行します。

NewEdgeの詳細
山腹のスイッチバックを通るライトアップされた高速道路
アプリケーションのアクセス制御、リアルタイムのユーザーコーチング、クラス最高のデータ保護により、生成型AIアプリケーションを安全に使用できるようにします。

生成AIの使用を保護する方法を学ぶ
ChatGPTと生成AIを安全に有効にする
SSEおよびSASE展開のためのゼロトラストソリューション

ゼロトラストについて学ぶ
大海原を走るボート
NetskopeがFedRAMPの高認証を達成

政府機関の変革を加速するには、Netskope GovCloud を選択してください。

Netskope GovCloud について学ぶ
Netskope GovCloud
  • リソース シェブロン

    クラウドへ安全に移行する上でNetskopeがどのように役立つかについての詳細は、以下をご覧ください。

  • ブログ シェブロン

    Netskopeがセキュリティサービスエッジ(SSE)を通じてセキュリティとネットワークの変革を可能にする方法を学びましょう。

  • イベント&ワークショップ シェブロン

    最新のセキュリティトレンドを先取りし、仲間とつながりましょう。

  • 定義されたセキュリティ シェブロン

    サイバーセキュリティ百科事典、知っておくべきすべてのこと

「セキュリティビジョナリー」ポッドキャスト

ビスケットではなくクッキー
司会のエミリー・ウェアマスが、専門家のデビッド・フェアマン氏とゾハール・ホッド氏と対談し、インターネットクッキーの過去、現在、未来について語ります。

ポッドキャストを再生する
ポッドキャスト:ビスケットではなくクッキー
最新のブログ

Netskopeがセキュリティサービスエッジ(SSE)機能を通じてゼロトラストとSASEの旅を可能にする方法。

ブログを読む
日の出と曇り空
SASE Week 2023年:SASEの旅が今始まります!

第4回 SASE Weekのリプレイセッション。

セッションの詳細
SASE Week 2023
セキュリティサービスエッジとは

SASEのセキュリティ面、ネットワークとクラウドでの保護の未来を探ります。

セキュリティサービスエッジの詳細
4方向ラウンドアバウト
私たちは、お客様が何にでも備えることができるように支援します

お客様を見る
窓の外を見て微笑むメガネをかけた女性
Netskopeの有能で経験豊富なプロフェッショナルサービスチームは、実装を成功させるための規範的なアプローチを提供します。

プロフェッショナルサービスについて学ぶ
Netskopeプロフェッショナルサービス
Netskopeコミュニティは、あなたとあなたのチームが製品とプラクティスからより多くの価値を引き出すのに役立ちます。

Netskopeコミュニティに移動
Netskope コミュニティ
Netskopeトレーニングで、デジタルトランスフォーメーションの旅を保護し、クラウド、ウェブ、プライベートアプリケーションを最大限に活用してください。

トレーニングと認定資格について学ぶ
働く若い専門家のグループ
  • 会社概要 シェブロン

    クラウド、データ、ネットワークセキュリティの課題に対して一歩先を行くサポートを提供

  • Netskopeが選ばれる理由 シェブロン

    クラウドの変革とどこからでも機能することで、セキュリティの機能方法が変わりました。

  • リーダーシップ シェブロン

    Netskopeの経営陣はお客様を成功に導くために全力を尽くしています。

  • パートナー シェブロン

    私たちはセキュリティリーダーと提携して、クラウドへの旅を保護します。

データセキュリティによる持続可能性のサポート

Netskope は、持続可能性における民間企業の役割についての認識を高めることを目的としたイニシアチブである「ビジョン2045」に参加できることを誇りに思っています。

詳しくはこちら
データセキュリティによる持続可能性のサポート
Highest in Execution. Furthest in Vision.

ネットスコープは2023年Gartner®社のセキュリティ・サービス・エッジ(SSE)のマジック・クアドラント™でリーダーの1社として評価されました。

レポートを読む
ネットスコープは2023年Gartner®社のセキュリティ・サービス・エッジ(SSE)のマジック・クアドラント™でリーダーの1社として評価されました。
思想家、建築家、夢想家、革新者。 一緒に、私たちはお客様がデータと人々を保護するのを助けるために最先端のクラウドセキュリティソリューションを提供します。

当社のチーム紹介
雪山を登るハイカーのグループ
Netskopeのパートナー中心の市場開拓戦略により、パートナーは企業のセキュリティを変革しながら、成長と収益性を最大化できます。

Netskope パートナーについて学ぶ
色々な若い専門家が集う笑顔のグループ

It’s All About Access: Remote Access Statistics for Public Cloud Workloads

Oct 06 2020

Introduction

The more things change, the more they stay the same.

In the recent Equinix breach in September 2020, 74 RDP servers were exposed to the Internet. Any publicly exposed ports are a risk but remote access protocols such as RDP have had their share of critical vulnerabilities (e.g., BlueKeep in 2019).

In this blog, we will look at remote access statistics of public cloud workloads based on 287,877 compute instances across 327 anonymized production environments in AWS, Google Cloud, and Azure. The focus will be on a few common ports/protocols used for remote access or management of workloads, namely: SSH, RDP, and to a lesser extent, VNC.

What we will find is that:

  • Direct Access is Still Very Common
    Direct access to compute instances is still very common (35-85%+ of public workloads depending upon cloud provider environment)—allowing inbound traffic to ports from public CIDRs for SSH/RDP. Although this finding is not necessarily surprising, the high percentage of workloads is, from 35% up to 85%. Unsurprisingly, SSH is the most common due to the popularity of Linux workloads, followed by RDP, then VNC.
  • Broad Internet Exposure is Alarmingly Common
    Additionally, a fair number of network configurations allow broad source IP CIDRs to access these same ports (SSH/RDP) e.g. from the entire public Internet (0.0.0.0/0). Over 13% of AWS public instances allow inbound access to All Destination Ports from any public Internet address, 71% of AWS public instances allow SSH from any public Internet address, and 14% of AWS public instances allow RDP from any public Internet IP address.
  • Better Secure Access Alternatives Not Deployed
    The implication from the above is that better secure access alternatives from the cloud service providers or other vendors are not being deployed. These alternatives are more secure than direct access or bastion hosts in almost every area (credential/key management, authorization, auditing, protocol/port attack surface, protocol vulnerabilities) and are referenced later in this blog.

Direct remote access

To identify direct access, we looked at public compute instances (with at least one assigned public IP address) that have a network security group or firewall ruleset that allows inbound traffic to a port range that included any of: 22 (SSH), 3389 (RDP), or 3800/3900 (VNC) and from a public source IP range. We counted separately the All Port range (0-65535).

We might guess that remote access directly to public instances is still common in the cloud, but the frequency of occurrence is eye-opening:

  • In AWS, out of 6,597 public EC2 instances, 16% allowed inbound traffic to All Ports, 36% to SSH, 8% to RDP, 1% to VNC.
Bar graph showing AWS public compute instances of remote access
  • In GCP, out of 5,675 public compute instances, 55% allowed inbound traffic to All Ports, 88% to SSH, 85% to RDP, and 1% to VNC.
Bar graph showing GCP public compute instances of remote access
  • In Azure, out of 15,432 public compute instances, 53% allowed inbound traffic to SSH.
Bar graph showing Azure public compute instances of remote access

As we can see, direct inbound access from the Internet to public compute instances is very common, regardless of cloud service provider. This reflects bad security practices since there are better alternatives mentioned below.

In addition, allowing traffic to all All Destination Ports (0-65535) is commonly found in AWS (16%) and GCP (55%) public compute instances. Overly broad port access only increases the risk of port scans and exploits of other services running on the compute instances that normally should not be exposed to the Internet.

Internet exposure

In the inbound traffic rules and data above, narrow IP allow lists restricting traffic from a single IP address (/32) would normally mitigate some of the risks above. To provide more context, we break down the source IP ranges for these same public instances and protocols. Since VNC counts were negligible, we will focus on SSH and RDP.

We see that there are a significant number of compute instances with networking rules allowing traffic from any public Internet address

  • In AWS, out of 1,054 public compute instances allowing All Destination Ports, more than 15% (161) of these can be scanned/attacked from any public IP address. For those instances allowing SSH, more than 36% (859) are reachable from any public IP address. And for RDP, more than 30% (166) of the compute instances are reachable from any public IP address.
Bar graph showing CIDR distribution of AWS remote access
Table showing values used to create bar graph of CIDR distribution of AWS remote access
  • In GCP, similarly, more than 44% of the compute instances have rules allowing inbound traffic from any public Internet address to All Destination Ports. Instances allowing SSH are minimally exposed to the whole Internet (only .5%). But for those instances allowing RDP, more than 50% are reachable from any Internet address.
Bar graph showing CIDR distribution of GCP remote access
Table showing values used to create bar graph of CIDR distribution of AWS remote access
  • In contrast, the Azure compute instances in this dataset have tighter network controls. All Destination Ports, RDP and VNC were tightly restricted, and out of the 8,128 instances allowing SSH and the one instance allowing RDP, all (100%) of the instances were restricted to traffic from a single source IP address (/32).
Bar graph showing CIDR distribution of Azure remote access
Table showing values used to create bar graph of CIDR distribution of Azure remote access

Conclusions

In the above environments, there are clearly some security concerns:

  • Compute Instances: A significant number of public compute instances allow direct remote access to either SSH or RDP from the Internet. This ranges from more than 40% of public instances in AWS, 50% in Azure, and more than 85% in GCP that allow this traffic.
  • Ports Exposed: It is not only the number of instances, but the number of ports exposed in each instance. In AWS, 16% (1,054) of the public compute instances have All Destination Ports open to inbound traffic from the Internet, and in GCP, more than 55% (3,136) expose All Ports as well.
  • Internet Exposure: Additionally, the breadth of source IP ranges that are allowed to contact compute instances is overly broad. In AWS, 15% up to 36% of the public compute instances expose All Ports, SSH, or RDP to the entire Internet. in GCP, 44% to 51% expose All Ports or RDP similarly.
  • Protocol Vulnerabilities: There is more risk due to multiple protocols e.g. SSH and RDP and VNC. Hardening practices differ, and it’s more difficult to manage access consistently due to differences in authentication (keys/AD/password), authorization (AD/OS-level), logging (different local logs). In addition, all three protocols (SSH, RDP, VNC) have had numerous vulnerabilities and CVEs such as RDP BlueKeep etc. In addition, there are specific attacks such as SSH multiplexing that are protocol dependent.

Fortunately, there are several, relatively simple measures that can be taken to reduce these risks:

  • Audit/Configuration Checks: Compute instances and their security groups or firewall rules can be regularly audited for insecure settings, such as All Destination Ports allowed or overly broad Source IP CIDR ranges including 0.0.0.0/0. This can be done DIY with API/CLI scripts or with commercial offerings such as Netskope for AWS, Azure, and GCP

Data analysis and methodology

The analysis presented in this blog post is based on anonymized usage data collected by the Netskope Security Cloud platform relating to a subset of Netskope customers with prior authorization.

A compute instance was determined to be public if the instance had an assigned public IP address. Network routability or other intervening controls were not considered.

Protocols were inferred from common default ports for the major remote access protocols (SSH = tcp/22, RDP = tcp/udp/3389, VNC = tcp 3800/3900). Compute instances that allowed All Destination Ports (0-65535) were counted once only, while double-counting among protocols were allowed especially if ranges were used (e.g. allowed destination port range: 0-5000 would count for both SSH, RDP, and VNC).

author image
Jenko Hwong
Jenko has 15+ years of experience in research, product management, and engineering in cloud security, AV/AS, routers/appliances, threat intel, Windows security, vulnerability scanning and compliance. At Netskope, he researches new cloud attacks.

Stay informed!

Subscribe for the latest from the Netskope Blog