devbattles 登録してみた

devbattles というサービスから招待メールが来たので登録してみた。
http://www.devbattles.com/en/auth/index

ちなみに、メールには
「お前の github 見た。ぜひ使ってくれ」的な事が書いてあった。
(自慢しているつもり。)

おそらく、Program Contest と Stack Overflow と IT エンジニア向け Linkedin を混ぜた SNS を目指しているんだと思う。
「おそらく」と書いたのは、現状ではα版のようで良くわからないから。

日本人からすると、色々とショッキングかもしれない。
僕自身は一般的な日本人に比べてアメリカ人の考え方には慣れているつもりだが、
それでもショッキングだった。

まず、「この段階で一般公開するか!」っていうところ。
履歴書のページなんか、submit ボタンを押しても何の反応もない。
メイン機能の登録フォームが機能していないんだぜ!

働きたい国とか、1個しか選べないし。
至る所で「そんな DB 設計で大丈夫か?」と突っ込みたくなる。

まあ、見た感じ Meteor で作られているっぽい。
(僕が今苦しんでいるやつ。)
DB は MongoDB だろうね。
「MongoDB はフレキシブルだから、DB の初期設計がいい加減でも大丈夫」
程度に考えているんでしょう。

フ、浅はかな。

まあ、登録する方いらっしゃったらコメントでも良いので連絡ください。
お友達になりましょう。
(コメントの閲覧頻度は不定期なのでご容赦を。)

そのセキュリティ対策、意味ないよ

つい最近、
「セキュリティ対策のため、ssh のポートをデフォルトから変更する、ドヤ!」
みたいな記事を読んだ。

でも僕には ssh のポート変更がセキュリティを向上させる場面は思いつかない。
残念だけど、彼の行為は全く意味が無いだろうね。

ポート変更はセキュリティにほとんど影響を与えないし、
あえて言えば、マイナス(セキュリティを弱くする)だろう。

IT セキュリティには
「アタッカーは全てのセキュリティを破る必要は無い」
という大前提がある。

つまり、
システム全体のセキュリティレベルは、その最も低い所で決まる。
個々のセキュリティレベルは、その強さと破られた際の影響で決まる。

で、ssh のポート番号。
お前のシステムではそこがセキュリティレベルの一番低い所なの?

ポート番号を隠すっていう事は、ネットワーク的には外部から通じるんだろうね。
だったら、ポートスキャンすればすぐにバレる。
つまり、「ssh のポート番号を隠す」という対策は極端に弱い。

一方、その影響範囲は普通、無視出来るくらい小さい。
だって、ssh のポートがバレても、アタッカーは何も出来ないから。
パスワードか鍵か知らんが、簡単にはログイン認証が通らないはずだ。

よって、一部の例外を除いて ssh のポート番号はシステム全体のセキュリティレベルに影響を与えない。

じゃあ、「一部の例外って何よ?」っていう話になる。
ぱっと思いつく範囲で言うと、ログイン認証が簡単にできるか、ssh の DOS 攻撃で深刻な影響を受ける場合だ。

いずれにせよ、ポート番号変えている場合じゃないね。

ログイン認証が簡単に出来る?
それって、パスワードが脆弱とか、秘密鍵がどっかで公開されているとか、
そんなとこでしょ?
まずは、そこを何とかしろよ!

SSH の DOS 攻撃で深刻な影響を受ける?
DOS 攻撃が問題になるサーバーはネットワークで守っとけ!

繰り返しになるが、ポート番号の変更なんて超弱い対応方法だ。
そんな超弱い対策に頼らざるを得ないなんて、まずそこがおかしい。

対して、デフォルトポートを変更するっていうのは、実は色々と面倒だったりする。
色々なツールとかセキュリティ対策システムでも、ポートの変更設定を加える必要が有るかもしれない。
そこには一定の工数がかかる。
その工数、もっと大事な所に使えよ。

また、(滅多にないと思うけど、)その設定変更が新しいセキュリティホールや
オペレーションミスを生むかもしれない。

いずれにしても、ポート変更して良いことなんて無いね。

僕は、「デフォルトポートを絶対に変更するな」とは言わない。
ネットワーク的な問題で 80番や 53番を使っている人も居るだろう。
それなら理解できる。
(僕の美学とは反するが)

でも、デフォルトポートを変更はセキュリティ対策にはならない。

今日の僕は少し良いことを書いたので、最後にもう一回記載しておこう。

システム全体のセキュリティレベルは、その最も低い所で決まる。
個々のセキュリティレベルは、その強さと破られた際の影響で決まる。

blog のバックアップ設定

blog のバックアップを設定した。
といっても、mysqldump して s3 にポイするだけだが。

s3curl って便利ね。
「バックアップ」という用途に限って言えば aws client よりもずっと簡単。

ところで、リストアのテストを行っていて気がついたのだけど、wordpress のアップデートが中々の曲者。
管理画面から簡単にできるし、個人ブログの為にいちいちセキュリティアップデート確認するの面倒なので、何も考えずにポチッとやっていた。
でも、バージョンが違うとリストア出来ないではないか!
(いや、別に不思議な仕様では無いけど。)

今にしてバックアップすら行わずにオペレーションを開始した事を激しく後悔しているわけだが、
今後、再インストールとかする時は
wordpress セットアップ -> バージョンアップ -> リストア
という手順になりそう。
バージョンアップの際に「正しいバージョンまで上げる」というのが難点だな。