Home » Posts tagged "ssh" (Page 3)

用 Shodan 掃台...

在「Using Shodan from the Command-Line」這邊看到跟資安有關的工具,然後跑回去研究 Shodan 這個工具。

這是預先掃好的資料庫啊啊啊~

而且還包括了目前已經有的 exploit 可以攻擊的對象?喂喂... (超開心?)

然後 port:22 的結果 (需要登入才能查詢),左邊列出全世界的數量排名,台灣居然是第三名?

一堆 Dropbear 看起來是一堆 WAN interface 對 internet 公開的分享器?我看到這些資料後才能理解,為什麼台灣在全世界跳板比率這麼高 XDDD

然後一如預期的,EC2 一堆機器開放全世界存取 ssh XDDDD

做 Ubuntu 14.04.1 的 VMware Template

公司有買 VMware license,但一直沒研究要如何做一份 VM template 出來,所以花了點時間研究到底怎麼做才會比較好。

這邊提供的方法是為了之後的通用性 (像是之後有可能用 KVM 堆虛擬機),所以不使用 VMware 獨規的設計,因此有些設定需要手動調整。

首先是先生出一台 Ubuntu 14.04.1 的 VM,在裝完基本系統後有些要先處理的:

  • 可以考慮用 DHCP 或是不開啟網路設定,反正不要設固定 IP address,以免同時裝多台機器時發生狀況。
  • 因為是 VMware 裡面,安裝 open-vm-tools 可以省下一些 puppet 安裝的時間。
  • 砍掉 /etc/ssh/ssh_host_*,每台機器的 host key 應該要不一樣。

做好 VM 後轉成 Template,之後每次在 deploy 完、開起來後,還要做這些事情:

  • /etc/hostname/etc/hosts 裡的機器名稱。
  • /etc/network/interfaces 裡的網路設定。
  • dpkg-reconfigure openssh-server 重新產生 SSH host key。

有些參考資料:

過程其實還蠻簡單的,只是有一些眉眉角角的東西要注意...

總算是搞定 Vagrant + Docker...

Docker 最大的好處就是啟動速度,比 VirtualBox 快非常多,但 Vagrant 官方對於 Docker provider 的範例還是太少,踹了老半天才踹出來:

ENV["VAGRANT_DEFAULT_PROVIDER"] = "docker"

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
    config.vm.provider "docker" do |docker, override|
        docker.image = "fgrehm/vagrant-ubuntu:precise"
        docker.has_ssh = true

        override.ssh.port = 22
    end
end

然後用 vagrant up 跑起來,接下來就可以用 vagrant ssh 連進去。

其中 override 是目前的 workaround,可以參考 GitHub 上的「Docker provider: cannot 'vagrant ssh' when not using a Docker host VM · Issue #3799 · mitchellh/vagrant」。

Docker 的 image 不透過 Vagrant 管理,而是 Docker 自己處理。可以用 docker images (列出) 與 docker rmi [repository] (刪除) 操作。

OpenSSH 降低對 OpenSSL 的相依性

這陣子 OpenSSH 的人努力降低對 OpenSSL 的相依性,目前 (2014-04-29 18:01:49 GMT) 已經拔到把 OpenSSL 拔掉後仍然有數個演算法可用 (離可用還是有一段距離):

make compiling against OpenSSL optional (make OPENSSL=no);
reduces algorithms to curve25519, aes-ctr, chacha, ed25519;
allows us to explore further options; with and ok djm

Curve25519 用在 ECDH,而 AES-CTR 與 ChaCha20+Poly1305 用在對稱加密,Ed25519 用在非對稱加密,其中三個剛好是一整套 djb 大全集 XD

不過缺了 RSA 還是有點痛啊,看看會不會實做出來吧?

OpenSSH 安全性問題...

Twitter 上看到 Gasol 轉推的 OpenSSH 安全性問題:「OpenSSH Security Advisory: gcmrekey.adv」。

開頭就直接寫:

If exploited, this vulnerability might permit code execution with the privileges of the authenticated user and may therefore allow bypassing restricted shell/command configurations.

這噴飯了... OpenSSH 的安全性相當強,這次出這種包... XDDD

影響的範圍是 OpenSSH 6.2 與 6.3,並且 OpenSSL 有編 AES-GCM:

OpenSSH 6.2 and OpenSSH 6.3 when built against an OpenSSL that supports AES-GCM.

如果不允許升級到 OpenSSH 6.4,那麼暫時性的解法是不允許 AES-GCM,在 /etc/ssh/sshd_config 內可以設:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

結果 FreeBSD 9.2 看起來在範圍內中槍,先上 workaround 再來等 freebsd-update 提供的修正吧...

掃整個 Internet 的 Port 22...

平常都是掃 Port 80/443,然後就有人跑去掃 Port 22:「We scanned the Internet for port 22」。依照原文說的,這次給的數據只是 60% 的 Internet,其他 40% 的資料有問題,他要再想辦法修...

這是 Top 20 的 unique banner 數據:

 1730887 SSH-2.0-OpenSSH_4.3
 1562709 SSH-2.0-OpenSSH_5.3
 1067097 SSH-2.0-dropbear_0.46
  824377 SSH-2.0-dropbear_0.51
  483318 SSH-2.0-dropbear_0.52
  348878 SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
  327841 SSH-1.99-Cisco-1.25
  320539 SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze3
  318279 SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
  307028 SSH-2.0-ROSSSH
  271614 SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2
  233842 SSH-2.0-OpenSSH_5.1p1 Debian-5
  225095 SSH-2.0-OpenSSH_5.1
  224991 SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901
  213201 SSH-2.0-OpenSSH_4.7
  209023 SSH-2.0-OpenSSH_6.0p1 Debian-4
  195977 SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
  140809 SSH-2.0-dropbear_0.50
  135821 SSH-2.0-OpenSSH
  132351 SSH-2.0-Cisco-1.25

可以看到 OpenSSH 是最大宗,而 dropbear 應該是各種 box 的量撐起來的...

參考維基百科上 OpenSSH 的條目,OpenSSH 的各版本的發行日期分別是:

  • 3.5:2002/10/14 (FreeBSD 4.11)
  • 4.3:2006/02/01
  • 4.7:2007/09/04
  • 5.1:2008/07/21
  • 5.3:2009/10/01
  • 5.4:2010/03/08 (FreeBSD 8.3)
  • 5.5:2010/04/16 (Debian 6)
  • 5.7:2011/01/24
  • 5.8:2011/02/04 (FreeBSD 9.1)
  • 5.9:2011/09/06
  • 6.0:2012/04/22 (Debian 7)
  • 6.1:2012/08/29 (FreeBSD 8.4)

後面的作業系統是就手上有的機器來看,不過 4.3 是最多的是怎麼一回事呢... 作者這樣解釋:

Note that these counts are a bit off. Some networks have a router that forwards all connections of a certain port to a single machine. Maybe "OpenSSH_4.3" is most popular banner, or maybe the national ISP of Elbonia just reroutes all port 22 requests.

所以有可能只是個假象?XD

對稱式加密系統的爆炸歷史 (Authenticated encryption 的問題)

在「Disasters」這邊列了不少對稱式加密系統 (secret-key cryptography) 爆炸的歷史,其中提到了很多 Encrypt 與 MAC 結合時的問題 (Authenticated encryption)。另外 Colin Percival 在 2009 年的時候有寫了一篇為什麼要用 Encrypt-then-MAC 的文章:「Encrypt-then-MAC」,當時 Colin Percival 寫的時候大家還是不能理解,但現在回頭看上面的爆炸歷史應該就清楚很多了 XDDD

SSH 協定是使用 Encrypt-and-MAC (傳輸「密文」與「明文的 MAC 值」)。在 2008 年時 SSH 使用 CBC 模式時會有安全問題:對 128bits CBC mode system (像是 aes128-cbc),任意位置的 32bits 有 2-18 的機會可以解出原文。(CVE-2008-5161,論文是「Plaintext Recovery Attacks Against SSH」)

TLS 1.0 (SSLv3) 使用 MAC-then-Encrypt (傳輸「明文與明文的 MAC 值」加密後的結果)。1999 年就知道這個方法不可靠,不過到了 2011 年時才被拿出來示範,也就是 BEAST attack。(CVE-2011-3389,在 ekoparty Security Conference 上的「表演」:「BEAST: Surprising crypto attack against HTTPS」,連結1連結2)

OpenSSLGnuTLS 所實作的 DTLS 在 2011 年也被炸到,其中 OpenSSL 是 100% plaintext recovery,GnuTLS 是 4%。(CVE-2012-0390,論文是「Plaintext-Recovery Attacks Against Datagram TLS」)

而 Encrypt-then-MAC (傳輸「密文」與「密文的 MAC」) 是三者裡面最不容易出包的作法,而且被證明 Provable security:Encrypt 與 MAC 所用的 crypto system 的安全強度不會因為 Encrypt-then-MAC 而減少。而這也是 IPSec 的作法。

附帶一提,其中 Provable security 這個詞,並非表示「可被證明是安全的」,在「In defense of Provable Security」這篇文章裡有比較完整的說明。通常是指安全強度不會因為這個系統而降低:以 Encrypt-then-MAC 的例子來說,如果 Encrypt 的部份用 DES,或是 MAC 用 CRC32,那麼 Encrypt-then-MAC 並不會提供更強的安全性...

總而言之,MAC-then-Encrypt 與 Encrypt-and-MAC 的方式要小心才能避免各種攻擊 (像是不能用 CBC mode),而 Encrypt-then-MAC 可以讓設計協定的人放鬆到「只要 Encrypt 與 MAC 都夠強」系統就沒問題。在 Authenticated encryption 裡提到的 ISO/IEC 19772:2009 支援六個模式,有些有專利問題,有些演算法看起來就很複雜 (於是就容易出包),其中 Encrypt-then-MAC 看起來是個還不錯的方案...

把 PEM Private Key 檔轉成 SSH Public Key 格式...

RSA 中,單獨靠 Private Key 是無法算出 Public Key 的,不過在 PEM 檔裡因為都有紀錄,所以可以取出:

openssl rsa -in aws.pem -pubout

不過取出的格式需要再轉一次讓 OpenSSH 可以吃:(參考「Convert pem key to ssh-rsa format」這篇的方法)

ssh-keygen -f aws.pub -i -m PKCS8

雖然 ssh-keygen 不接受 - 當 stdin,但可以利用 /dev/stdin 直接串起來:

openssl rsa -in aws.pem -pubout | ssh-keygen -f /dev/stdin -i -m PKCS8

把 SSH 換成 Mosh

Mosh 是一個取代 SSH (OpenSSH) 的工具,官方網站上是這樣介紹:

Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.

Mosh 最大的特性是透過 UDP 加密傳輸 (AES-128 OCB mode),而且不綁定 IP address 後設計出這些特性:

  • 筆電休眠後再打開電腦就可以直接連上。
  • 登入 VPN 造成 IP 改變後也沒關係。

另外 Mosh 模擬了 local echo 機制,就算在 latency 偏高的網路下也還是可以感覺到不錯的反應速度。

不過是到了 1.2 之後支援 --ssh 這個參數才變得好用,在 client 端只要這樣跑 (假設 ssh port 在 1234):

mosh --ssh="ssh -p 1234 -v" gslin@server.example.com --server="env LANG=en_US.UTF-8 mosh-server"

Mosh 就會用 ssh 登入後自動執行 mosh-server 取得 shared key 給 mosh-client 用。如果本來就有使用 public key 機制的話就跟原來沒差了 :p

預設吃 port 60000-61000 其中的一個 UDP port,所以記得開 firewall...

Archives