githubで何故かパーミッションエラーになったよ。

$ git push -u origin master
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights

こんな感じ、先日までできてたのに謎でした。で、ネットで検索すると事例は多く、色々設定方法があって各々解決の仕方が違った。で、私も片っ端から真似したけど解決できず。

解決方法は、鍵の作り直しをしたこと。
本家のこのままですね。
https://help.github.com/articles/generating-ssh-keys

Account SettingsのSSH Keysに、いつのまにか二つ鍵が登録されてたので、それをクリアして改めて登録した。
そしたら↑の公式通りの流れになって、

$ git push -u origin master

が、できました。

githubに作ったモノを公開した話。macだよ。

そんな日が来るとか思わなかったんですが、githubにソースを公開しようと思い立ちました。

 

1. githubにアカウントを作る。で、ここなんですが、過去に仕事でアカウントだけは設定したことがあり、細かい事は覚えていない。なので、ネットで調べたけど、そんなことやったのかな？みたいな記憶しかない。

 

2. githubのweb上でレポジトリを作る。これはボタンとかピンと来ないインタフェースだけど、探せばまぁ見つかる。

 

3. 自身のパソコン上にクローンを作って、落としてきたりアップしたりする環境を作る。この部分を理解するために、いくつかのインターネッツを徘徊した(笑)

 

3-1. とりあえず、設置したいところにディレクトリを作るよね。

$ cd *****
$ mkdir github(みたいな)

3-2. 初回ならgit config --globalとかで設定をしておく。アカウントを切り替える場合は、都度叩くみたい。

 

$ git config --global user.name "githubアカウント名"

$ git config --global user.email "githubアカウントメールアドレス"

 

3-3. レポジトリ作ると、強制的にreademe.mdとかできるよね。まずそれを落としてみる。といいますか。レポジトリ一つまるっと落ちてきた。（落ちてきたと言う表現はsvn的でgitは違うけど）

$ git init

すると、以下のような感じになるわなぁ

***/github/レポジトリ名/.git

                                           LICENSE

 

                                           README.md

 

3-4. で、reademe.mdを編集してみる

これはもうエディタでやろうがviでやろうが適当にテスト的なコメントを入れてみた。

 

3-5. 新規ファイルをアップする。

作ったソースを置いてみる。これはfinderとかでコピペするだけ

 

3-6. svnと同じ概念で新規はaddしてからcommitする

 

$ git add *

 

3-7. commitする

 

$ git commit

これはコメント入れる。svnをターミナルでやんのと同じ容量。気のせいかもしれないけど、コメントいれないとコミットできない気がする。わかったらここ更新しとくかも。以下みたいに、何変えて、何新規か分る。

[master num] firest

 2 files changed, num insertions(+)

 

 create mode num 追加したファイル

 

3-8. ここからsvnと違うとこだわな

svnは集約型だけどgitは分散型？だからコミットといっても自分のPC内だけなんで、マスターとかブランチに共有させる必要がある。pushね。

 

$ git push -u origin master

Counting objects: 6, done.

Delta compression using up to 2 threads.

Compressing objects: 100% (4/4), done.

Writing objects: 100% (4/4), num KiB | 0 bytes/s, done.

Total 4 (delta 1), reused 0 (delta 0)

To git@github.com:あなたのアカウント名でしょ/あなたのレポジトリ名でしょ

   num..num  master -> master

 

Branch master set up to track remote branch master from origin.

フォーク？でもしない限りアカウント名と、レポジトリ名は自分のとこだよね。

 

4. githubのweb上で、更新したレポジトリを見てみると、編集や新規追加が行なわれている。

 

5. もしweb上で更新したりしたら、最新の情報を取ってくるよね。

$ git fetch origin

$ git diff origin/master

これでマスターとの差分が見れる。fetchは必要みたい。他にも方法はあるみたいだけど、文字列として記憶しやすいのはこれかな。

んで、問題なければ

$ git pull

マージする場合は...自分一人なんでまずそんな経験しないかな。

 

こんな感じでした。

で、作り終わりかけたところで分りやすいサイト見つけました。

git - 簡単ガイド 猫でもわかるGit 最初の一歩

 

人の事言えないけど、本当に分りやすく書く人と、それ書いて意味あるの？って人いるよね。

OS X Mavericksに無償アップデート

した。とりあえず寝ながら、起きたら残り1分でフリーズしてた。なので、電源落として立ち上げた。すると、アカウント作成になったのでアカウントを作成した。よく分からんが、フリーズしたのが原因だろう。で、既存のアカウントがあるし、それはスルーしてログインしなおす。これでアップデート終了。とりあえず、スマートじゃないけど無事終わった。

 

svnをコマンドラインで使ったら

$ svn up 

 

Agreeing to the Xcode/iOS license requires admin privileges, please re-run as root via sudo.

 

 

こうなった。xcodeでライセンスに同意しろ？みたいにでた。なのでxcodeもアップデートしていたので、xcodeを立ち上げてagreeする。

 

$ svn up 

svn: E155036: Please see the 'svn upgrade' command

 

svn: E155036: Working copy '********************' is too old (format 10, created by Subversion 1.6)

 

次はコレ、svnが1.6だからアップグレードしてよというものっぽい結局rootじゃないとアップフレードできないので

 

 

$ sudo svn upgrade

その後、cleanupとかupとかしてみた。

今回と関係ないけどsudoじゃないと実行できない体になた...

 

レポジトリの.svn配下にある、dbに書き込み権限入れたらrootじゃなくても大丈夫になるっぽい....いや、.svn配下のオーナーがrootなのを自身のアカウントに変えた方がいいわ(sudo chown -R 自分)ね。

postfix スパムに踏み台にされて防いだ後2

その後もスパムにあってるかもしれないと、ログを定期的にみています。それにしても世の中には、踏み台にしようとサーバに日々、アタックされているんですね。こういうのってむやみやたらに怖がっている人が多すぎて、実態の掴めない世界と感じているエンジニアは多いはず。メールサーバは使わないにしても、自分で立ててみた方が身にしみるんじゃないだろうか。

 

前回の「フローコントロール、レートコントロール」について、もうちょっとふみこんで実装を記載します。前紹介したサイトは参考になりますが、古いホームページだからかもしれませんが、イマイチこうしろ！っていう記載の仕方が緩いです。要するにどうするの？って読んでて思っちゃいます。

 

ともあれ、記載はmain.cfの最後当たりに追記します。

vi /etc/postfix/main.cf

 

以下は、HELLOとかいうログをみたことあるかもしれませんが、スパムのアタック目的のHelloコマンドの疎通確認で、ある条件の時にNGを返す処理みたいです。

smtpd_helo_restrictions = reject_invalid_hostname,

                          reject_non_fqdn_hostname,

                          reject_unknown_hostname

 記載の意味は以下、

reject_invalid_hostname: 

HELOコマンドで提供されるホスト名が有効なホスト名でない時拒否 拒否応答コード501

reject_non_fqdn_hostname:

HELOコマンドで提供されるホスト名がRFCで必須とされる完全修飾名の形式でない時、要求を拒否。拒否応答コード504

reject_unknown_hostname:

HELOコマンドで提供されるホスト名がAレコードもMXレコードも無い時要求を拒否。拒否応答コード450(unknown_hostname_reject_codeで指定も)

 

だ、そうです。ただ偽装できるし不十分だって、一般人はHelloしないからHello自体ブロックしてもいい気がするけどメールソフトとかが使うのかね？？

 

つづいて、非凡なアクセスしてくるヤツをブロックする記載

smtpd_client_connection_rate_limit = 3

anvil_rate_time_unit = 60s

 

smtpd_soft_error_limit = 3

smtpd_hard_error_limit = 5

smtpd_error_sleep_time = 20s

 

smtpd_client_message_rate_limit = 6

smtpd_client_recipient_rate_limit = 6

 自分は上記の様にしました。

smtpd_client_connection_rate_limitと、anvil_rate_time_unit：

同一クライアントが60秒間に、3回接続してきたら接続MAXってことでブロックされます。自分しか見ないし、そんなに接続しないし、それ以外はスパム扱いでいいかなと。実際仕事でメールしてても、そのくらいで十二分なはず。

 

smtpd_soft_error_limit、smtpd_hard_error_limit、smtpd_error_sleep_time：

smtpd_soft_error_limitの設定回数だけエラーを時間内にだしたら、スリープ分アカウント停止します。その後もsmtpd_hard_error_limitの設定回数だけエラーを出したら、接続を解除します。時間内というのは「anvil_rate_time_unit = 60s」です。60s設定でスリープも考慮して、smtpd_hard_error_limitに達するのはスパムだけです。

 

smtpd_client_message_rate_limit、smtpd_client_recipient_rate_limit：

60秒間に6通のメールと6箇所宛先におくれるという設定です。

smtpd_client_connection_count_limitなどで、接続数も絞る事ができます。

但しこれ、通常は数字を制限しまくることは難しいです。なぜなら多数にメールを送信するなど、仕事上であるはずだからです。自分は個人なのでここをキュッと絞れば、被害がでても小さく済ます事ができますが...そのため、上のlimit系の方が有効なはずです。

postfix スパムに踏み台にされて防いだ後

防いだには防ぎました。しかしログを見ると、また踏み台にしようとめっちゃログイン失敗を繰り返しまくっていました。

 

これはどうしたものかと思いまして、色々調べたのですが、なかなかシンプルかつ分りやすいサイトって見つからず困りました。

 

xinetdを使う方法が一つ /  二つ

main.cfをさらにセキュアにする方法が一つ / 二つ

 

です。これ、かなり分りやすい記述をしてくれているサイトだと思います。色々見ましたがなかなかどうにも分りにくいサイトが多く...

 

要は、

「xinetに中継させてPOP3を立ち上げて、xinetでIP制限とかしちゃおうぜ」

「スパムリストサイトを照合して、自分オリジナルのも作ってブロックしようよ」

の２ケースですね。

で、さらにはmain.cfで接続制限とかもできるようで、スパムの連チャンが来てもまずは、制限（ブロックではなく制限）させることもできます。アタックされ続ければいずれは破られるパスワードですが、このチャンスを制限することにより、膨大な時間をかけなければ破られなくなりますね。なぜこういう分りやすい説明をするサイトがないのか疑問ですが、googleが上位にヒットさせてないだけかもしれません。

 

あとは、スパム攻撃されている時にメールサーバをひとまず止めますが、特別な止め方がある様です。以前メールのキューを削除しないと起動時に配送されてしまう件を共有しましたが、そもそもキューをクリアする止め方もある様です。

 

postfix abort

 

ですって。ここも分りやすいサイトです。最終更新が古いのがちょっと残念ですが、メールサーバの文明ってその辺で鈍足化してるのかもしれませんね。

 

 

私は、分りやすいサイトに習って、まずはスパムリストに載っているものは拒否する様に設定しました。

vi /etc/postfix/main.cf

smtpd_client_restrictions = permit_mynetworks,

                            reject_rbl_client spamcop.net,

                            reject_rbl_client dynablock.wirehub.net,

                            reject_rbl_client opm.blitzed.org,

                            reject_rbl_client relays.visi.com,

                            reject_rbl_client sbl.spamhaus.org,

                            check_client_access hash:/etc/postfix/reject_client,

                            permit

まぁなんか接続できないdbもあるっぽいけど、それはスルーした。

「/etc/postfix/reject_client」の中に、個人的にログを見てウザいIPを書き込んだ感じ

 

それと念のためにhosts.denyにも書き込みました。inetdは古いシステムでxinetdに変わっているとかあるけど、サーバにファイルは設置されてるし、書き込むだけで機能するとかみたいなんで、おまじないです。

 

あとは、「フローコントロール、レートコントロール」ですね。これは結構重要だと思います。

参考にしたサイトにはデフォルト値が書かれているけど、grepしてもpostfixにそれ系の***.cfの記述はなかった。記述がないとデフォなんでしょうか？なんとも不確定です。と、思いましたが、スパムがanvilと書かれて、ログに引っかかっていたので、そういうもんなんでしょう。

 

攻撃されているうちは、その相手だけをとにかくブロックしたいんですが、その方法は私の検索の仕方が悪いのかほとんどヒットしない...まぁパスワードを難解化して、 「フローコントロール、レートコントロール」の制限に引っかからせれば、そやつ意外も結果的に防衛できるので、それが一番いいってことで落ち着くのかなと思います。

 

しかし、スパム防止の設定いれたら、メールの送受信テストで、送信が特に遅くなったよ、まぁ仕方ないか数秒だし。メールなんてチャットじゃないからね。

ぐぬぬ、postfixで踏み台にされたお話

メールサーバが踏み台にされました。一応ありきたりに設置方法を検索して設定したのですが、はじめてなのが仇になったのか、ログを見る限り踏み台にされています。そこで、困ったのが、踏み台にされたらやることです。今回学んだことをピックアップします。なんせ踏み台防止はあるけど、踏み台にされた時の対処となると、検索にヒットあんまししないんですもの...

 

1.postfixをとりあえず止める

慌てず騒がずメールサーバを止めます。サーバの再起動は不要です。もう慌ててしちゃったかもしれませんね。私がそうでした...再起動してもメールサーバは踏み台なので、アクセスできたらまた踏まれるだけです...またサーバの再起動は他のサービスに影響がでてしまうという2次災害を引き起こしているかもしれません...私は引き起こしました...node.jsが止まってた。

 

2.ログを確認する

ログを見れば、通常送受信しないであろうメアドが見れると思います。そうそれが踏み台にされたってこと。

 

3.ログの見方を学ぶ

そんなに時間はかかりません。ログの見方はここが参考になります。

Postfix のログの見方

で、「LOGIN」がメール処理開始のログ、「status=sent」が送信成功のログ...つまりスパムに加担してしまったって事、陳謝。

tail -10000 /var/log/maillog | grep "LOGIN"

tail -100 /var/log/maillog | grep "sent"

こんな感じで、ログを遡ってgrepかけると分る。

 

4.どのメールアカウントが踏み台にされているか調べる

スパムは必ずといっていい程、届かないメールを送信しまくっています。つまり、お宅から送信されたメールは届けられないよ、という親切な先輩方からのメールがそのアドレス宛に届いているはずです。私はhotmail先輩からメールが一杯届きました。

 

5.そのメルアカのパスワードを変更する

私の場合、緩いパスワードを設定していました...これを気に難解なパスワードに変えました。つっこまれる生き様をすると、神様は見ているんですね。パスワードの変更の仕方は、ここでは記述できません。エンジニアの設定の仕方で各々違うと思う

 

6.メールのキューを確認する

スパムは大量に送信を行うプログラムなので、僅かな時間でもキューが溜まっているはずです。そして、キューは実行待ちのメールなので、postfixを再開した瞬間に送信されてしまいます。なので、キューは削除が必要です。

mailq | head

mailq | tail

mailq | wc -l

上記の様に、キューを確認してみましょう。

 

7.キューの削除

以下が参考になります。私の場合は運用前でしたので、全削除をしました。

[Linux][postfix] postfix にてキューにたまったメールの削除方法

postsuper -d ALL

 

8.postfixを起動しましょう。

それではメールのキューが無いことを確認し、postfixを起動しましょう。

mailq | head

-> Mail queue is empty

/etc/init.d/postfix start

 

9.メールの送受信をテスト

最後に送受信テストです、踏み台にされたメールアカウントのパスワードが変わったので、テストします。他のアカウントもチェックして２重チェックできると尚良いですね。

 

10.メールサーバを立てたら運用期間を設ける

これはスパムに踏み台にされちゃうようなメールサーバなのか逆にスパムにチェックしてもらう方法ですね。こういうのは大事だと思いました。今回初めて個人的に設置しており実運用にいたってなかったのが幸いしました。設置して1ヶ月も経たないで起きた出来事でした。知り合いにはよく「そういう事はあるんだよ」と、聞かされていましたが、舐めていました。ゆとりある運用ならば、メールサーバは新設後2,3ヶ月は本稼働しない方がいいかもしれませんね。

 

11.事故を調査する

これはもうログの見方を覚えれば、ログから事故った時刻と、事故っていた時間が割り出せますね。原因の踏み台アカウントも特定できます。ほんとうにごめんなさいでした。

 

1. 大量にメールを送受信しているアカウントを発見する

tail -20000 /var/log/maillog | grep "sent"

2. そいつのログインアタック受けた形跡を見る例

tail -20000 /var/log/maillog | grep "LOGIN authentication failed"

まぁ、常にログインアタックは受けてるんですけどね。

3. 会社のケースだと参考にならないけどLOGINした形跡をみるコマンド例

tail -20000 /var/log/maillog | grep "Login: user="

これで乗っ取られて、いつログインしたかわかる。

 

うーん、あんましいい説明じゃないけど、意味が分かる人なら上記をこねくり回して探せると思う...

赤字や、コマンドオプションは適度に書き換えてね。ログも、被害大きいと別ファイルにローテートされてる場合があるからね！！