フォワードのメモ
自分のためのメモ。人の役にたつかどうかはまいねいめんデス。
一応いっとくとサッカーとかじゃないです。
sshの中継でhttpsとかを見るはなし。sshのポートフォワードって便利でちょっとコワいっすねって話。
XとY、二つのprivate IPのネットワークがあって、どっちもhttpsやsshで外に出ることはできますが、ゲートウェイのIPとかわかんないデス。
Xが会社のVMware環境で、Yが自宅のVirualBox環境ならアリガチですね(どこが)。
んで、hoge.example.comという自分の自由になるインターネット上のlinux(unix系ならなんデモ)サーバ(たぶん仮想マシン？)があるデス。12ヶ月なら無料枠かもしれませン。
YからXにアクセスしたいけど、勝手に線とかひけないしファイアーウォールもさわれないので無力ですが、sshで外には出れるのであればhogeを使えるよねという？
hogeでwooというuserを作ってno passphraseでssh-keygenするデス。
作ったらwooのid_rsaはコピーしてから消してしまって、id_rsa.pubをauthorized_keysにしてしまう。hogeのsshのポートも22じゃなくするとかSGで工夫するとか微妙な抵抗をするデスね。
Xのどれかの鯖から-Rでhogeに接続。たとえば内部用の串を通すなら
$ ssh -gN -p12345 -i woohoge woo@hoge.example.com -R 0.0.0.0:23456:192.168.0.100:3128
みたいな。
Yの別の場所環境からは
$ ssh -gN -p12345 -i woohoge woo@hoge.example.com
-L8080:hoge.example.com:23456
的な。
hogeではfirewalldとかSGで必要なportをあけとくデス。あと
GatewayPorts yes
にして、あとはswichproxyadvanceでもfoxyproxyでも使ってあげればよいかと。うん、woohogeが共有されてセキュリティが崩壊する未来しかみえないデスね……
暗号化ではなく難読化になル？
ゆってることがわからない風
'A' を 8bit数値の0x41と考えてみる
任意の二つの8bit数のXORが0x41となる組み合わせは基本的に256組あるハズ
これで選択攻撃からはある程度防御(eが最多だとかqの次はほぼuだとか)？
ルールを決めて有効文字と無効文字を定義し有効文字の間には0個以上の無効文字をはさむ。
そうするとエンコード前の文字列は有効文字に限定される……と特にアカウント名は8bitじゃ物足りないかも。unicodeに拡張するかUTF-8として無理矢理処理するかは棚上げしよう(こないだ調べたら shelve(shelf;棚 の動詞)にも棚上げするという意味があってみんな考えることは似てるんだと思った)。
seedの種はdatetime.now()とする(つまりseed()するだけ)。そして有効文字をエンコードし、8bit x 2にすると毎回違うものが生成される(256通り)。その後に0文字以上の無効文字をはさむ。そして次の有効文字をエンコードするを繰りかえす。よってエンコードの結果は毎回異なるし、不定長になる。また、エンコード後の長さが偶数ばかりだとバレる確率が上がりそうなので1/2の確率でムダな1要素(8bit)を付け足す。
これをBase64あたりでエンコードしておく。これをhtpasswd方式で書き込むスクリプトを作る。複数サイトを前提なので、ID, Pass以外もちょっと足しとく。delimiterはURLを入れるかもなので:でなくスペース(' '、%20ね)にする。
#site URL ID PASSWD
google https://map.google.com/ XXXXXXXXX XXXXXXXX
yahoo https://auction.yahoo.com/ XXXXXXXXX XXXXXXXX
ちょっとしたURL変更くらいならテキストエディタで対応できる。
デコーダをどんだけ難読化できるかだなー。スクリプトにはどうしてもgo+rは付けなきゃなので pdb.set_trace() には無力だけど、ちょっとした抑止力くらいにはなる……といいな。
この方式だと別のPCで作成した行をコピペできるのでデコーダが十分難読であればエンコーダは運用管理用のサーバに置く必要がなくなるし。
ん、パスフレーズ生成では無意味なっしー
運用では「下に合わせる」必要がありマス。上から目線の言葉ですみまセンですが、複数レベルの運用メンバーのもっとも初心者に近いヒトたちでもちゃんと動かせる、という程度の意味です。
人を見下している意味ではなく、例えばインフルで39℃の熱がでてウンウン言ってるときに電話かかってきていそぎで対応しなきゃな時は、どんなに優秀な人でもチョーつまんないミスをしがちとかそういう意味も含んでます。
そーゆーことを考えていろんなスクリプトを作ると、いつも困るのがパスワードをどうやって置いておくか、です。
複数のシステムやツールを自動でスクリプトで見にいくことでつまんないミスをゼロに近づけることはデキると思いマス。
しかし、そこにそのままパスワードを書くことはセキュリティ上のリスク。
chmod 4755 したCのプログラムの出力を呼んでくることで、スクリプトから消す方法もありますが、それをコマンドラインから実行できちゃう。
opensslを使うのも、passphraseありにしちゃうと、それをどこかにメモしちゃうし、自動実行に向かない、無しにしちゃうとプレーンテキストでパスワードを書いているよりはマシ程度。あとは大量にあると結構管理がしんどい。
パスワード管理ツールだとシステム依存になってしまう。例えばmac上でスクリプトを実行するなら、実行環境固定になるけどKeyChainが最強ですよね。
…
……
でも、import pdbしてpdb.set_trace()できる人には無意味なので、それができる人は「下に合わせる」場合にはいない、と仮定して買収される可能性のある人を減らすくらいなら可能かもしれない。
AESのパスフレーズを自動生成するの
あるスクリプトの中でどうしてもなにかの共通鍵(Pre shared key)がないと困るんよ、状態での思い付きでつ。
文字列を作るためだけに別に使わないsshkeyを作ります
ssh-keygen -f randomkey
このキーはsshには使いません。スクリプトから読む用です。で、関数を書きますよ。名前はmakerandomkeyとかなっててrandomも使ってますが、同じホスト名で、同じrsakey(id_rsa相当)なら同じ文字列が返ってきます
#!/bin/env python from random import seed as zy yz = 2**5 from socket import gethostname as zz import os, sys import random def makerandomkey(): if zy(sum(map(ord,zz()))): sys.exit(-1) with open("./randomkey", "r") as f: z = ''.join([z.strip().replace(' ','') for z in f.readlines()]) return ''.join([random.choice(z) for y in range(yz)]) if __name__ == "__main__": print(makerandomkey())
こんな感じ?
Python の requests モジュールで内部サイトとかの Insecure Request Warning を出さないようにする
ほぼ、タイトルオンリーですね。
外部公開するはずもない内側の監視サイトなんかでテキトーSSL、または、private ipでアクセスするとcertificate error になる場合とか、requestsでアクセスするとタイトルみたいなWarningがでます。で、回避方法
#!/usr/bin/env python
import requests
from requests.packages.urllib3.exceptions import InsecureRequestWarning
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)
以上です。
awsでSSL
無料使用枠がある期間限定で、できたけど面倒でした。
まず、Certificate Managerにいって証明書リクエストをします。
そして、DNS認証を選び、自分のDNSサーバで指示されたエントリを設定します。
そうするとCertificate Manager に yourdomain.comな証明書ができます
EC2にhost01.yourdomain.comがあるとしたら、EC2のELBからALBを選び、wwwという名前でLBを作ります
そのターゲットグループにhost01を足してALBもターゲットも443でぜんぶ作ります。それで証明書をCertificate Manager のyourdomain.comを選ぶわけです。
ELBができたら、そのawsのちょう長いFQDNを、DNSサーバにコピペ、例えばwwwのCNAMEにします。
Certificate Managerからxxx.crtなどをダウンロードできないのですが、これでSSLアクセスが可能です。
うーん、Let's encryptのほうがいいかもしれない。
