読者です 読者をやめる 読者になる 読者になる

2016年をふりかえって

こんばんは。 なつよです。

@infragirl755 のTwitterを2015年9月1日に開始して、約1年3ヶ月経過しました。 特に今年1年でいろいろな動きがありましたので、2016年の振り返り記事を書こうと思います。

では、1月から順番に振り返っていきます。

今年を振り返って

1月は、BINDの脆弱性対応の記事を書きました。 infragirl.hatenablog.jp

BINDについてぐぐってみると、「BINDは脆弱性が多い!」とか「BINDによるDNSサーバの構築手順」といった記事はよく見ます。 しかし、「BINDの脆弱性対応をするために人間はどう動くべきか?」という、運用にかかわる人間の心構えや行動指針に関する記事は見つけられません。それなら自分で書いてみるか、と思い投稿しました。

結果、Twitterはてなブックマークで沢山のリアクションをいただきました。

特にTwitterでは「ここの文章はこう治したほうがいいよ」「こういう手順を書いてみたよ」という具体的な指摘をいただきました。

投稿してしばらくはボコボコに叩かれるかと思ってどきどきしていたので、 SNSでのリアクションやわかりやすい指摘をいただけたことは本当にうれしかったです。

2月は、はじめてインフラガールの漫画を投稿しました。

漫画なんて描いた事なかったから、何時間もかかりました。 漫画家さんってすげぇと何回思ったことか・・・

結果、Twitterで100を超えるRTをしていただき、リプライでも「私もこうなったことあります」とか「おもしろい」というコメントを もらえてめちゃくちゃうれしかったです。

3月から4月は、セキュリティスペシャリストを受験が迫っていたので、 勉強漬けだった気がします。

infragirl.hatenablog.jp

「どうせ受けるなら1発で受かってやる!」と気合を入れて勉強していましたが、まさか本当に受かると思っていなかったので・・・会社で机の周りの人にかたっぱしから自慢しました。なんてウザイやつなんだ・・・。

5月はRTX1100買ったりいろいろ妄想したり・・・・

6月はDNS Summer Day 2016に行きました。 infragirl.hatenablog.jp

技術書典にも行きました。 infragirl.hatenablog.jp

思えばこの2つのイベントが、今年の転換期でした。

DNS Summer Day 2016に行って、沢山の方と話しました。 知り合った方もTwitterでフォローさせていただきました。 タイムラインがすごく充実しています。ありがたいです!

7月~10月は、ブログではたいした更新をしていないですね・・・。 二輪免許を取りに自動車学校に行って、引越しもしてたんだっけ。( ゚д゚)ウム

11月は、Redmineの月でした。 会社でも使い始め、プライベートでもVPSかけて構築してみました。 infragirl.hatenablog.jp

この記事のあと、オレオレ証明書https化しようとして いろいろおかしくなり復旧できなくなりました。ちーん。 現在はBacklogというサービスを利用しています。快適です。

・・・そこはエンジニアとしてなおさんかい!( ‘д‘⊂彡☆))Д´) パーン

12月はシス管系女子のアドベントカレンダーの記事をかきました。 infragirl.hatenablog.jp

みんとちゃん書くのすっごい楽しかった!!!

こうしてみると、今年はけっこういろんなことしてるんですね。

来年は・・・

2016年は、たくさんの方と知り合うことができました。

普段のツイートから興味を持ってくださった方、へたくそまんがから興味を持ってくださった方、 ブログ記事から興味を持ってくださった方DNS Summer Day 2016で知り合った方、技術書典で知り合った方・・・

いろんな方たちと相互フォローになって、タイムラインが充実しました。 そして、沢山の情報が流れてくるようになりました。

「あっ!これ気になる!」「これこないだ仕事で悩んだやつだ!」と何回思ったかわかりません。 「あれもやりたい!」「これも勉強したい!」とやりたいことがあふれ、何から手をつけていいかわからない状態に・・・。

2016年はDNSの勉強がぜんぜんできなかったので RFC1034の読破を目指したいです。

こないだもちょっとやったけど、絵に描きながら読むのが 一番頭に入る気がします。

そして、インフラ女子あるある漫画をもっと描きたいです。

f:id:okisan2:20161230230552j:plain

皆さん、よいお年を!

シス管系女子を読むべきなのは誰か?

書庫

おはこんばんにちは。
シス管系女子のアドベントカレンダー、12月9日分として投稿させていただくことになりました。
www.adventar.org

今回は、ファンアートともに、
「シス管系女子を読むべきなのは誰か?」をテーマに
書いていこうと思います。

まず最初に、わたしとシス管系女子との出会いから説明させてください。

わたしとシス管系女子との出会い

私とみんとちゃんとの出会いは、確か2~3年前ぐらいだったか・・・。
確か、「もっと複雑な条件でファイルを探したい」(単行本2巻第11話)
の回だったかと思います。findコマンドを使えば、複雑な条件を組み合わせてファイルを検索できる、というあらすじです。

当時の私はLinuxサーバの管理者として配属されたものの、
Linuxサーバなんて学生時代触ったことがなかったし、本番環境を触るのに楽しむ余裕などなく、黒い画面におびえる日々でした。

そんな自分を打破したく手に取ったのが「日経Linux」でした。
みんとちゃんみたいなかわいい女の子がfindコマンドを使いこなす姿に驚きました。
当時、私の部署には同年代の女性インフラエンジニアがいなかったため、みんとちゃんに親近感を感じました。

大野さんからレクチャーされ、コマンドの便利さに驚く姿、「もうだめだーーー!」と頭を抱える姿、
結局二度手間でがっくりする姿を見て、「CLIに戸惑っていいんだ、悩んでいいんだ」といわれた気がして、気が楽になったのを覚えています。

今年の6月に技術書典でPiro先生にサインをもらえたのはうれしかった(・∀・)
infragirl.hatenablog.jp

シス管系女子を読むべきなのは誰か?

さて本題に入ります。
結論を言うと、Linuxサーバを管理する立場になったものの、どんなコマンドを使っていいかわからずググっちゃう人」だと思います。

・・・・え?そりゃそうだろって?( ゚д゚)

なぜそう思ったか書いていきますね。

Twitterではたまに書いてるんですが、つい最近後輩インフラボーイが配属されまして、私がOJTをしています。
Linuxの経験は1年ほどで、「やりたいことがあっても、どんなコマンドが適切かわからない」状態なんですね。

そういうときに彼はとりあえずぐぐっちゃうんです。
そんで、ぐぐったのと実際のサーバでの結果が違っちゃったりして「????」ってなっちゃうんですよね・・・。

わかる、わかるよ。
私もね、そんな時期、とりあえずぐぐってたよ( ;∀;)
そんで、思い通りの結果が得られなくて、先輩に泣きついてたよ。
「man見てやらないとだめだよ」って良く言われたっけ・・・。

ぐぐること自体はだめじゃないんですよ。
でも、かならず自分が思う結果が得られるかどうかはわからないし、それが正しいかもわからないんですよね。
そういう判断ができないうちは、やっぱりお金を払ってでも本で勉強するべきだと思います。

※その後、彼にはポケットリファレンスを渡しました。
 それでもだめならmanを読んで、もうお手上げなら声かけてって言っておきました。

そういう中で、シス管系女子って「どんな問題を解決したいときにこのコマンドが役に立つか」っていうことを「漫画形式で気張らずに読める」とても良い教科書だと思うんです。

普段から読んでおいて、いざそういう場面にでくわしたら
「あれ・・・こういう場面見たことある・・・そうか、みんとちゃんがやってた気がするわ」って思い出して対処の道筋を立てられます。

実際、わたしも「これシス管系女子で見たやつだ・・・!」って場面が何回かありましたw

「最初の1歩を踏み出すための本」ではないけど、「システム管理者として歩き出した人の手を引いてあげる」という意味では
最適な本ではないかと思います。

さいごに

ファンアートです!
Piro先生、3巻楽しみにしてます。これからもがんばってください~!

f:id:okisan2:20161207222048p:plain

RFC1034を読むよ(2.1.The history of domain namesから)

DNS RFC1034読破計画

おはこんばんにちは。
前回の続きです。

infragirl.hatenablog.jp

RFC952が「各自FTPで取りにきてね」という内容に対して、RFC953は「プログラム作って各自取りにきてね」という内容なのでしょうか。

2つとも1985年の10月みたいだし、なんでわざわざ2つに分けたんだろう・・・(;´Д`)
2つとも読み進めたらわかるんですかね。

でも、1034のほうが気になるからそっち先に読み進めてます。
ただ訳文を見るだけじゃなくて、英語もみたほうがいいといわれたので、
最初に英文を訳してから、答えあわせとして日本語訳を見ていくことにしました。


1. STATUS OF THIS MEMO
このメモの状態

This RFC is an introduction to the Domain Name System (DNS), and omits
many details which can be found in a companion RFC, "Domain Names -
Implementation and Specification" [RFC-1035]. That RFC assumes that the
reader is familiar with the concepts discussed in this memo.

知ることができるRFCの仲間の沢山の詳細については省略します。
ドメインネームの実行と仕様について(RFC1035)」。
このRFCは当然、読み手に親しみやすく、このメモのコンセプトについて討議されていることがよく知られている。

omits:省略
details:詳細
companion:仲間
Implementation:実行、履行
Specification:仕様
assumes:当然だと思う
familiar:よく知られている、親しみやすい
discussed:討議されている

The impetus for the development of the domain system was growth in the
Internet:

impetus :刺激、推進力
インターネットの成長がドメインシステムの発達の推進力であった。

Host name to address mappings were maintained by the Network
Information Center (NIC) in a single file (HOSTS.TXT) which
was FTPed by all hosts [RFC-952, RFC-953].The total network

訳: すべてのネットワークにおいて、ホストネームのアドレス変換はマッピングされていました、それはすべてのホストがネットワークインフォメーションセンターの中にあるHOSTS.TXTをFTPで維持されていました。

maintain:維持される、保全する

ぬ~ん
寝ます。

RFC1034を読みはじめた(数ヶ月ぶり2回目)

DNS RFC1034読破計画

おはこんばんにちは。
好きな本を好きなだけ買ってほくほくのなつよさんです。
カフェちゃんとブレークタイムを読んで、今日もコーヒーがうまい( ^ω^ )


Twitterで「DNSわからん」ってつぶやきまくっていたら、「RFC読まないと理解できないよ」と聞きまして
前野さん(@beyondDNS)訳のRFC1034を読んでみることにしました。

DNS/RFC/1034 - moin.qmail.jp


そして・・・

読んでもちっともわからなかったです。
これは日本語???日本語なんだけど何が書いてあるのかわからないんです。
何がわからないかもわからなかったです。

なるほど絵に描けばいいのか。


描いた。


そして悟った。


このへんを眺めながらARPANETの成り立ちを調べました。

インターネット歴史年表 - JPNIC


ARPANETが始まったのが1969年らしい。
RFC1034が公開されるよりも18年も前だった。

18年間もなにしとったん・・?


RFC1034よりも前のRFCがあるらしい。
そういえば、DNSができる前はHOSTS.TXTを各自FTPで取りにいっていたって、
どこかで聞いた事がある。

そういえば、どこかでRFCの系統図を公開されていたのを見た気がする・・・。

※滝澤さん(@ttkzw)のサイトから引用させていただきました。ありがとうございます。
Diagram of the descent of DNS RFCs – ttkzw's site

むちゃくちゃデカイ(゚д゚)!

どうやら、DNSのベースになった一番ねっこのRFCは226のようなので、
ぐぐってみました。


最初のHOSTS.TXT(アドレスと名前の変換テーブル)はたったの20行だったんですね・・・。


ここまで調べてやっとRFC1034に戻ります。
※下の文は、前野さん訳より引用させていただきました。ありがとうございます。
DNS/RFC/1034/2 - moin.qmail.jp

「かつてはホスト名をアドレスに変換するのには、
ネットワーク情報センター(NIC)で管理されるひとつのファイル(HOSTS.TXT) を各ホストがFTPで取り出して使うという方法で行なわれていた [RFC-952,RFC-953]。 この方法だと新版を配るのに必要な全ネットワークバンド幅資源は ネットワーク上のホスト数の 2 乗に比例するので、 多段の FTP を使ってさえ、NIC ホストの FTP 負荷はかなり のものであった。 ホスト数の爆発的増加は悪い状況を示していた。 」

文中に出てきた、RFC-952を読んでみました。
最初は、FTPでこのホストで、IDとパスワードはこれで・・・って言う話で、
その後はHOSTS.TXTの体裁の話かな?


あとでRFC-953も読んでみようと思います。
とりあえず今日はここまで。

OpenSSL脆弱性対応手順まとめ

おはこんばんにちは。

OpenSSLさんがまた脆弱性ですって(´・ε・`)?

JVNVU#92930223: OpenSSL に複数の脆弱性

私の中ではBINDさんの次に多い印象があります。

BINDの脆弱性対応手順をまとめたのにならって、今回はOpenSSLバージョンをまとめてみますね。

infragirl.hatenablog.jp

 1.OpenSSLの脆弱性の発表をキャッチする

本家が情報をわかりやすく出してくれてるようです。

脆弱性がアナウンスされた時https://twitter.com/ha4gu/status/750102197174607872の一次ソース「Security Advisory」はここですね。

ここのRSSが見つけられない…。

https://www.openssl.org/news/newslog.html

過去の脆弱性情報がまとまってるページもあるんですね。

/news/vulnerabilities.html

 

OpenSSLに限ったことではないですが、CVE,JPCERT/CC,JVNも要チェックですね!

私はNVDとかもたまに見るんですけど、JVNと微妙にCVSSスコアが違ってたりするので基本はJVNを信用してます( ´ω`)

 

あと、OpenSSLのBlogにけっこう書いてたりすることがあるようで・・・

www.openssl.org

脆弱性情報出た後にOpenSSL本家からアップデートが出なくて、

「これいつでるのかなぁ・・・」ってウジウジしてたら

「ブログに書いてあるよ」と教えていただいたことがあり、その時からBlogも見るようにしてます。

 一次ソースのチェックは大事ですね( +・`ω・)b

 

  2.自分の管轄内のOpenSSLのバージョンを調べる

バージョンを出すだけなら・・・

$ dpkg -l | grep openssl

yum list installed | grep openssl

最近知ったんですがCent OSだとアップデート可能なら黄色くなってくれるそうですね。便利(゚д゚)!

 

パッケージを使っていなくてもopensslコマンドで

バージョンを確認することができます。

$openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

 

でも・・・

それ本当に今使っているOpenSSLのバージョンなんでしょうか?

もしかしたら後からソースインストールしてるのかも!!!

ギャアァァァァ━━━━━━(|||゚Д゚)━━━━━━!!!!!!

 

lsofコマンド(どのプロセスがどのファイルを開いているのか

わかるコマンド)でopensslのライブラリを開いているプロセスを見つけましょう。

# lsof | grep ssl

・・・

fail2ban-  2565                root  mem       REG              253,4    449880    4680996/usr/lib64/libssl.so.1.0.1e

 

これで新しいほうを参照してたらOKです。

古いほうを参照してたらアップデートしてあげましょう。4へ続く。

 

ちなみに現在のstableバージョンは1.0.2系で、1.0.1系はセキュリティ上のバグ修正しかしていないんですって。

そんで、1.0.1系のサポートは2016/12/31までですって。

( ゚д゚)ナンデスト!

ソース:https://www.openssl.org/source/

   3.アップデートするかどうかを決める

BINDのときとほとんど同じことを言いますが・・・

これは、環境によって異なるのでなんとも言えない(´・ω・`)ショボーン

あとは以下の観点から判断しています。

・対象のサーバが外に出ているかどうか

→FWで守られているかどうか。外に出ているものであれば、一刻も早く対処しないといけないです。リモートで攻撃可能な脆弱性だといつ攻撃を受けるかわかりませんし。

脆弱性によって受ける影響が大きいかどうか

→これも環境によりけりですね。でも、SSLって大事な情報を守るために使われているものですし、本来守られているべきのものが情報漏えいの脆弱性あり!といわれたら

私なら最優先でアップデートかけちゃうと思います。サービス停止の脆弱性とかだとどうかな。でも、SSL使うようなサービスって大事なやり取りばかりですよね・・・。

 基本的には脆弱性にはすべて対応すべきだと思っています。ただし、実際に対応するかどうかは実際の環境や、対応にかかる工数とリスクを天秤にかけて、上司や客先と相談して判断しています。

  4 .OpenSSLをアップデートする

パッケージならアップデートしてあげればOKですね。

アップデート後は、OpenSSLのライブラリを参照しているプロセスが

本当に新しいライブラリを参照しているかlsofコマンドで確認してあげてください。

必要に応じてプロセスのサービスも再起動しましょう。

 

Σ(゚д゚) エッ!? OSがサポート切れ?パッケージが提供されない?

<丶´Д`>ゲッソリ しますね。

 

OpenSSLのサイトからソースをインストールしましょう。

そんで、opensslのライブラリを参照しているプロセスが、新しいバージョンのライブラリを参照するようにがんばりましょう。

(サービス再起動でそううまいこといってくれなくて、筆者はソースapacheのconfigureからやり直したことがあります。超めんどくさかった)

ソースからアップデートの方法については、参照するプロセスによって

大きく違いそうですし、筆者はapacheしかやったことないので割愛します。

 

ながくなりましたが私はこんな感じでOpenSSL脆弱性対応をしています。

間違いやこうしたらいいよ!という意見などありましたら@infragirl755までリプライいただけると幸いです。

 

2016/11/29 追記

このエントリを見た方が、この件についてより掘り下げたブログ記事を書いてくださいました。

 

OpenSSLに限らず、パッケージ管理についてどう付き合って行くべきかという視点で書かれており、とてもためになる記事でした( •̀ᄇ• ́)ﻭ✧

 

お兄様さん‪(@phase_d ‬)ありがとうございました!

 

さくらのVPSでRedmineを構築してみました

自宅redmine

おはこんばんにちは。

突然ですがさくらのVPSRedmineを構築しました。

 

理由は以下のとおりです。

 お金関係のタスクって自分ではしっかり管理してたつもりだったんです。

それを忘れたのがショックで・・・。

会社でRedmine使い始めたので、家でも使いたいなぁと思って・・・。

https://twitter.com/infragirl755/status/799864684727783425

 

さくらのVPSの一番安いプラン契約しました。月額685円なんて安いですねぇ(´∀`*)

 最初からrootログインできるようになっててびびった。

あとループバックオンリーでpostfix動いてたのはCentOS7の親切なのかしら・・・?

systemd?会社でdebian8触ってるしいけるやろ、と何も考えずにCentOS7にしました。

あとからFirewalldで苦しむとも知らずに・・・ふっε- (´ー`*)

 

とりあえずやったこと

iptablesコマンドで必要なポートだけ空ける

(これ意味あったのかな・・?後からFirewalldだと気づいた)

・rootユーザと一般ユーザの作成

sshでrootログインできなくする

sshの鍵認証を設定し、鍵認証を強制する設定を入れる

・fail2banでsshポートの設定する

・logrotateの設定を見る(とりあえず一通り設定されているようだからこのまま)

・bitnamiインストーラを使ってredmineのインストール

→めちゃくちゃ簡単でびびった。

iptablesではなくfirewalldだと気づく

 

redmineでユーザ作成

redmineのサーバ用のAレコードを登録

・redminePMのインストールと動作確認

・backlogsプラグインを入れようとして挫折中

rubyのgemとかnokogiriとかわけわかめで(´・ω・`)ショボーン

 

とりあえずredmineが動くようにはなりました。

会社でbacklogsプラグインで慣れちゃったからこれ使いたいん

だけどな・・・。

家使いでredmineつかってて、こういう運用してるよ!って方が

いたら教えていただきたいです。

(チケットの種類とかサブプロジェクトの粒度とか・・・)

さくらのVPSの最小スペックですが、今のところ問題なさそうです。今後使い込んだらしんどくなってくるのかな。

 

これからどんどん使い込むぞ~。

 

変なメールが届いた話

お疲れ様です。ナツヨです。

最近は引っ越しや二輪教習に登山でスラッシングしそうです。

ほど自業自得なんですが(; ・`д・´)

 

今日は、twitterでもちょいちょい言っているメールの話です。

プライベートのメールでは、natsuyo.netを取得して、さくらのメールサービスを利用しております。

 

先日変なメールが届きました。

 

スクロールすると添付ファイルがくっついていたので、

身に覚えのない+添付=SPAM!!?!? と思いこんでおりました。

 

フォロワーさんから沢山突っ込まれました。

 

 

 

英語はきちんと読まないとだめですね・・・(-"-;A ...

メール文に「host name lookup failure」とありますし、support.xxx.jpが

名前解決できずに滞留しているようですね。

 

メールは3通届いていて、1通目の時間帯を確認すると20:42:25

そういえば、山小屋の予約メールを出した時間帯です。

 

山小屋のサイトを確認すると、気になる一文が…

 

山小屋のメールシステムに何が…(*_*;

ちなみに、予約確認のメールはきちんと返ってきましたよ。謎い。

 メールの件名でぐぐってみると、同じようなメールが届いた人がたくさんいるようでした。IPアドレスwhois引いてみた結果SAKURA Internet Inc.ですし

確かにさくらから届いたメールのようです。

 

となると、気になるのは、山小屋のメールシステム。

ドメインはmopera.netで、ぐぐってみるとドコモのISPのようですね。

山小屋だしモバイルルータを使っているのかもしれませんね。

 

ISPについてくるメールアドレスだとしても、名前解決できないのは意味不明だし、

途中でsupport.xxx.jpっていうものが出てくるのもよくわからないし(-_-;)

 

xxx.jpのドメインの持ち主をwhoisで確認してみると…

Domain Information: [ドメイン情報]
[Domain Name]                   XXX.JP

[登録者名]                      辻村 晃
[Registrant]                    Tsujimura,Akira

[Name Server]                   delta1.xxx.ne.jp
[Name Server]                   ns6-tk02.ocn.ad.jp
[Signing Key]                   

[登録年月日]                    2001/03/26
[有効期限]                      2017/03/31
[状態]                          Active
[最終更新]                      2016/04/01 01:05:13 (JST)

Contact Information: [公開連絡窓口]
[名前]                          フューチャリズムワークス ドメインサービス
[Name]                          Futurismworks Domain Service
[Email]                         jp-domain@futurism.ws
[Web Page]                       
[郵便番号]                      151-0053
[住所]                          東京都渋谷区代々木
                                2-11-2 由井ビル5F
[Postal Address]                2-11-2-5F, Yoyogi,
                                Shibuya-ku,
                                Tokyo 151-0053, Japan
[電話番号]                      03-5302-1699
[FAX番号]                       03-5302-1698

ぐぐってみると、レンタルサーバ屋さんらしいけど…。

 

support.xxx.jpのMXを引いてみるとSERVFAILになる(*_*;

これが原因かな?

使用したサイト:

nslookup(dig)テスト【DNSサーバ接続確認】

f:id:okisan2:20160811215025p:plain

 

xxx.jpのドメイン自体が存在していても、サブドメインのMXレコードが存在しない場合はNXDOMAINになるもんじゃないのか・・・?

例:yahoo.comのでたらめなサブドメインのMXを引いてみた場合

f:id:okisan2:20160811215240p:plain

 

modera.netとxxx.jpがどんな関係がもわからん・・・。

modera.netがsupport.xxx.jpを内部で使っているとか?

山小屋の方に伝える義理もないのですが、なんとなくもやもやするのでした。

山小屋に行ったときにkenzanso.jpのドメイン取得と、どこかのメールサービスの契約をおすすめしてみようかしら・・・。