Category: Security

NATとSTUN・TURNサーバー

WebRTC通信
– Peer to Peer、ブラウザ間で直接通信
– UDP/IPを使用、オーバーヘッドが少ない
– 鍵交換で暗号化通信を行う
-> 相手のIPアドレス、動的なUDPポート番号を知る必要がある
-> 通信経路の仕組みがInteractive Connectivity Establishment、その候補がICE Candidate
–> NATを通過するためのSTUNサーバから取得したポートマッピング
–> Firewallを越えるための、TURNによるリレーサーバーを介した中継通信
–> このやりとりをシグナリングと言う。WebSocketなど複数の方法がある
-> 複数人通信の場合には、それぞれのユーザとSDP/IPのconnectionをつくる必要がある

NATとは
　グローバルIPとローカルのネットワークIPとの変換
　複数のPC/デバイスが同時に通信できるよう、ポートマッピングによるポート変換
　→ブラウザはローカルのIP、UDPポートはわかるが、グローバルのIP、UDPはわからない
　→→Peer to Peerはグローバルの情報を交換する必要がある

STUN(Session Traversal Utilities for NATs)
NATで変換されたIP/UDPを外のSTUNサーバーから教えてもらう
→グローバル情報をシグナリングサーバーけいゆうで相手に渡す
STUNサーバーはGoogleのstun.l.google.com:19302など

TURN(Traversal Using Relays around NAT)
ストリームデータの受け渡しにリレーする
TURNサーバが入ると厳密にはPeer to Peerではなくなる
データのデコード、エンコードは行わないので、ネットワーク負荷が高くなる

あれ、Bitcoinって、P2Pだけど、STAN, TURN使ってるんだっけ？
否、BitcoinはTCP😂

nonce

暗号学では、一度しか使わないランダムな数値の事をnonceと呼ぶ
メッセージにnonceを追加した上で、そのハッシュ値を計算し、メッセージとハッシュ値を公開した場合、nonceを知っている者だけしかハッシュ値を計算できない
ビットコインのマイニングは、nonceを変更しながらブロックのデータのハッシュ値を繰り返し計算する
ターゲットよりも小さいハッシュ値を最初に得たものが勝利者となる
ハッシュチェーンの一つにマークル木がある
SHA-256とRIPEMD-160をハッシュ関数として標準利用、SHA-1の衝突耐性は失われている

暗号鍵と公開鍵の作成

require 'ecdsa'
require 'securerandom'

group = ECDSA::Group::Secp256k1
n = group.order

private_key = 1 + SecureRandom.random_number(n-1)

# print private_key

pubKey = group.generator.multiply_by_scalar(private_key)
print pubKey.x
print pubKey.y

vagrant@vagrant-ubuntu-trusty-64:~/bitcoin$ ruby main.rb
7200274859625909218305600661424454855533433802141920888525182327364340449554183445379063984485161576009152500901248299335294365713023890298728510086562018

ECDSA

ECDSA(Elliptic Curve Digital Signature Algorithm)
楕円曲線デジタル署名アルゴリズム
ビットコインの電子証明などに利用されている
ECDSAは公開鍵の暗号化技術の名前
RSAに比べ約1/10のコンパクトな容量

require 'ecdsa'
require 'securerandom'

group = ECDSA::Group::Secp256k1
n = group.order

private_key = 1 + SecureRandom.random_number(n-1)

print private_key

vagrant@vagrant-ubuntu-trusty-64:~/bitcoin$ ruby main.rb
106515493506888278075922016172190811663525618981292515102301206639235796458599

ビットコインの暗号技術

OpenSSL
-> インターネット上で標準的に利用される暗号通信プロトコルであるSSLおよびTLSの機能を実装したオープンソースライブラリ

require 'openssl'

data = '*secret data*'

key = 'a' * 32
iv = 'i' * 16

enc = OpenSSL::Cipher.new('AES-256-CBC')
enc.encrypt
enc.key = key
enc.iv = iv
encrypted_data = enc.update(data) + enc.final
# print encrypted_data

dec = OpenSSL::Cipher.new('AES-256-CBC')
dec.decrypt
dec.key = key
dec.iv = iv 
decrypted_data = dec.update(encrypted_data) + dec.final
print decrypted_data

vagrant@vagrant-ubuntu-trusty-64:~/bitcoin$ ruby main.rb
5????
g`??Ա?

vagrant@vagrant-ubuntu-trusty-64:~/bitcoin$ ruby main.rb
*secret data*

IntelのIvy Bridge以降のCPUやRaspberry Pi, Apple A7以降のプロセッサには、熱雑音を利用して物理的に乱数を発生させるハードウェア乱数生成器が備わっている

rubyの安全な乱数: securerandom

require 'securerandom'
hex = SecureRandom.hex(32)
print hex

vagrant@vagrant-ubuntu-trusty-64:~/bitcoin$ ruby main.rb
1fbd11b0d5588de19571e3679ee86387d2449b6d376f6211498e4dbd2557fabd

ipa RSSを取得

<?php 
$target_day = date('Y/m/d', strtotime('-1 day'));
$xml = "https://jvndb.jvn.jp/ja/rss/jvndb_new.rdf";

$xmlData = simplexml_load_file($xml);
foreach ($xmlData->item as $entry){
  $dc = $entry->children('http://purl.org/dc/elements/1.1/');
  $day = date('Y/m/d', strtotime($dc->date));
  if($day == $target_day){
      $string.= date('Y/m/d h:i', strtotime($dc->date))."<br>";
      $string.= $entry->title."<br>";
      $string.= $entry->link."<br>";
  }
}
?>
<html>
<body>
	<?php echo $string; ?>
</body>
</html>

OK、次はslack webhook

ipa 脆弱性情報

脆弱性情報をcronで毎日取得したい。
ソースはipa(情報処理推進機構)
https://www.ipa.go.jp/secuirty/rss/alert.rdf

中身がどうなっているかというと、itemの中は、title, link, dc:creator, dc:dateの4つだ。creatorは全部ipaだから、title,link,dateだけでいいか。

 <item rdf:about="https://www.ipa.go.jp/security/ciadr/vul/20190717-jre.html">
  <title>Oracle Java の脆弱性対策について(CVE-2019-7317等)</title>
  <link>https://www.ipa.go.jp/security/ciadr/vul/20190717-jre.html</link>
  <dc:creator>情報処理推進機構（IPA）</dc:creator>
  <dc:date>2019-07-17T12:00:00+09:00</dc:date>
 </item>

Hoot24

Hoot24とは？
->「HOOT24」とはサイトロック社とクラメソで提供する、24時間365日AWS環境（EC2, ELB, RDS）の”有人”監視サービス

１）「AWS環境の監視体制」をご提供：お客様側で監視サーバーの準備が不要。必要なものは最小限のIAM権限とIPアクセス許可のみ
２）「通知手段の選択」をご提供：有人監視であることにより、「電話連絡」という手段が選択できる
３）「自動障害対応」をご提供：監視項目ごとに対応を決めることができる。インスタンス再起動などの個別アクションも指定可能
４）「監視設定の支援」をご提供：弊社オペレーションチームのサポートにより、容易に監視設定ができる

ref: https://dev.classmethod.jp/etc/cm-hoot24-intro/

有人の電話連絡といっても、まぁ、システムの稼働状況によるでしょう。
休日や深夜帯にユーザーが使用しなければ、そこまで優先度は高くないですが、深夜や営業時間外でも稼働が必須の場合は、重宝されそうですね。
クラメソの監視とのことですが、他のサービスの対応を見ていると、なんとなく、これも良さそうには見えますね。

WhiteListing

Whitelisting is one of the methods used to filter email and websites.
While the blacklisting method creates a list of dangerous users and websites, the whitelisting method creates a list of targets for which safety has been confirmed and excludes others. While it is possible to cut off dangerous objects completely, the contents of the list is arbitrary and limited to a part of safe objects, and it has the disadvantage of losing the user’s convenience.

AWS firewall manager

AWS Firewall Manager is a security management service that makes it easy to configure and manage AWS WAF rules centrally across multiple customers’ accounts and applications. With the Firewall Manager, you can easily roll out the AWS WAF rules for the Application Load Balancer and Amazon CloudFront distributions across many AWS Organizations accounts. In addition, every time a new application is created, Firewall Manager makes it easy for new applications and resources to meet compliance with common security rules from day one. Now that you have a consistent set of firewall rules across the Application Load Balancer and Amazon CloudFront infrastructure, hierarchically build firewall rules, create security policies, and get single service to apply them.


1. Name web ACL
2. Create condition
– IP match condition
– String match condition, bad bot user agent
– SQL injection match condition, sqli checks
3. Create rules
4. Review and create

Certificate and Key Store

A public key certificate, also called an electronic or identity certificate, contains a public key consisting of a public / private key pair, as well as other metadata (such as name and location) that identify the owner of the key. The certificate owner also owns the corresponding private key.

When you sign the APK, the signing tool attaches a public key certificate to the APK. The same is true if you signed the app bundle. A public key certificate acts as “fingerprint” that uniquely associates an APK or app bundle with the owner and the corresponding private key. This will allow Android to verify that subsequent app updates are genuine and have been released by the original author. The key used to create this certificate is called the app signing key.

A keystore is a binary file that contains one or more private keys. In order to allow users to install new versions as app updates, all apps must use the same certificate throughout the usage period.