こんにちは。 インターンの田邉です。 マネーフォワードのセキュリティを支えている「CISO室」にて、脆弱性診断を担当しています。 この度、社内で脆弱性診断を実施し無事に報告まで終えることができたので、その気づきとまとめを投稿します。 注意！ 脆弱性診断の手法のなかには攻撃行為となるものも含まれています。 自分の管理下にないシステムに対しては脆弱性診断を行わないでください。 インターンをすることになったきっかけ 私は大学で情報セキュリティを専攻しています。 日本で毎年行われているCODE BLUEという情報セキュリティの国際会議に、昨年、学生スタッフとして参加しました。 その時のアフターパーティーで、スポンサー参加していたマネーフォワードの＠ken5scalさんと出会い、マネーフォワードのインターンに誘っていただきました。 脆弱性診断について 脆弱性診断とは？ 「システムに攻撃を行い、悪いと

Config芸人の森永です。 運営メンバーとして参加しているSecurity-JAWSの一員としてJAWS DAYS 2017にて登壇させて頂きましたのでレポートします。 [DeepDive] AWS SECURITY DEATH \m/ ～セキュ鮫様からのお告げ～ by Security-JAWS セッションタイトルはあれですが、至って真面目な内容です。 Security-JAWSの運営メンバーの中から3名が自分の得意な分野のサービスについて話しました。 大喜多→VPC周り 吉江→Shield/WAF周り 森永→Config 最後に Security-JAWSはだいたい3ヶ月毎に活動しています。 次回開催は未定ですが、DoorKeeperのページやTwitterにて告知しますのでぜひご参加下さい。 取りあえずConfig有効化しましょう！！！

以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする

先日、WordPress 4.7 および 4.7.1 における Content Injection の脆弱性が世間を騒がせました。脆弱性が「すでに存在する投稿を上書きする」という内容であるため、脆弱性診断士としてはお客様の環境に試すことが憚られる脆弱性です。しかし、検証を実施した結果、この脆弱性は投稿を実際に上書きをしなくても検出できることがわかりました。そこで今回の投稿では、これから脆弱性診断士を目指す人のことを意識して、この脆弱性の検出手法の解説を通じて「脆弱性診断士として気をつけなければならないこと」や「脆弱性を確認する手法の作成手順」がざっくり伝えられればと考えております。 どういう脆弱性なの？ WordPress 4.7 系から導入された REST API という機能に不備があり、WordPress で作成された Web サイトに投稿されている内容を上書きできるという脆弱性です。

Mackerel について考えない日はないというくらいに Mackerel・Love な僕なわけですが（考えない日はあります）、Mackerel の Web 画面で日頃なにげなく見ている「システムメトリック」、みなさんはどのような意識を持って観察していますでしょうか。 ↑ https://home.a-know.me をホストしているサーバのシステムメトリックのようす。 ここでひとつおさらいをしておくと、「システムメトリック」とは、監視対象のサーバにインストールされた mackerel-agent が、それ単体で収集・投稿するメトリックのことです。一般的な Linux系OS に mackerel-agent をインストールした場合、以下のような項目がシステムメトリックとして Mackerel に投稿されます。 loadavg5 cpu memory disk interface files

果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時

VirtualBoxにCentOSをとりあえずインストール の続き MySQLのバイナリログを見てみる。 MySQLのインストール とりあえずMySQLをインストールする。 $ sudo yum -y install mysql-server $ sudo service mysqld start $ sudo chkconfig mysqld on バイナリログを出力する 今はまだバイナリログは出力されていない。 $ ls /var/lib/mysql/ ib_logfile0 ib_logfile1 ibdata1 mysql mysql.sock test log-binを追加してバイナリログを出力するよう設定する。 $ sudo vi /etc/my.cnf [mysqld] ・・・ log-bin ←追加 $ sudo service mysqld restart バイナリログの

こんにちは。フルスタックエンジニア(自称)の井上です。 今回は、とあるサービスをオンプレミスからAWSに移行した事例をご紹介します。 経緯 リクルートライフスタイルでは、いくつかのオンプレミスおよびクラウド環境からサービスの特性に合わせて適した環境を選択しています。 今回AWSに移行したサービスは、元々新規事業向けに提供されているオンプレミス環境で運用されていました。 しかしサービスの伸長によりトラフィックも増加傾向にあり、近い未来に性能上の問題が発生するのは明らかで、 またサポート体制なども含めたサービスレベルとしても要求されるものと乖離が起き始めていました。 そのような状況で本格的にインフラ移行の検討を開始しました。 移行先の選定 移行先を選定する際、主に以下の点を重視して検討しました。 今後の成長を見越して素早く、かつ継続的にスケールできる 少人数体制でも効率的に運用が可能で、スケー

さくらインターネット Advent Calendar最終日は、硬派にLinuxのメモリに関する基礎知識についてみてみたいと思います。 最近はサーバーを意識せずプログラミングできるようになり、メモリの空き容量について意識することも少なくなりましたが、いざ低レイヤーに触れなければいけないシチュエーションになった際に、OSを目の前に呆然とする人が多いようです。 基本的にLinux のパフォーマンスについて、メモリをたくさんつめばいいとか、スワップさせないほうが良い とか、このあたりは良く知られたことだと思います。 ただ、なんとなく ps コマンドや free コマンド などの結果を見るだけでなく、もう少しメモリのことについて掘り下げてみてみたいと思います。 メモリとキャッシュ Linux におけるメモリの状態を大きく分けると「使用中のメモリ」「キャッシュ」「空きメモリ」「スワップ」の 4 つに分

こんにちは、シニアエンジニアの id:y_uuki です。 はてなのWebオペレーションエンジニア8名が、この1年で対外的にアウトプットした成果物をまとめて紹介します。 座談会 Software Engineering System Engineering 輪読会 その他 あとがき 座談会 今週、Webオペレーションエンジニアの座談会記事を公開しました。技術ブログや技術発表では表現しきれない一人一人の考え方や思いが垣間見えるコンテンツになっていると思います。 Software Engineering Keepalivedのシンタックスチェッカ「gokc」を作った - ゆううきブログ gokcというGoで作られたKeepalivedの設定ファイルのシンタックスチェッカーです。社内で普通に導入しています。 インフラエンジニアがGo言語でオペレーションツールを書くことについて - Hatena

大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「いまさら聞けないLinuxとメモリの基礎＆vmstatの詳しい使い方」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げ

2016/12/27 更新Googleなどの大手IT企業がうるう秒対策済のNTPサーバが公開したため、これを利用する内容などを以下にまとめました。 元旦に実施される うるう秒の対策 まとめ2016/07/08 更新2017/1/1に閏秒の実施が決定されました。対応はこの記事のとおりで問題なさそうです。 2015/06/24 情報追加(2015/06/29 更新)下記の対応に関わるntpdの比較的新しいバージョンにSLEWモードで動作していても、うるう秒が挿入されるバグが発見されました。[redhat] これによりntp-4.2.8p3-RC1以降のバージョンでないとSLEWモードで動作していてもうるう秒が挿入されます。RedHatはntp-4.2.6p5-3.el6_6という対応済みのバージョンを提供しています。Ubuntuでは今日現在12.04LTS, 14.04LTSの２バージョンはパ

こんにちわ。せじまです。 すべての基本は monitoring だと考えてるので、イマドキのウェアラブルデバイスいろいろ買っていろいろ計測してるんですが、最近のデジタルガジェット面白いなぁ２１世紀感パないと感心しまくってる今日このごろです。 ちょうど一年くらい前、 MySQL User Conference Tokyo 2015 で MySQLやSSDとかの話　前編を、 GREE Tech Talk #9 で MySQLやSSDとかの話　後編を、お話させていただきました。 その後どうなったの？ということで、後日談をまとめさせていただきました。（今回はMySQL成分それほどありません） 忙しい人のために三行でまとめると 以前の試みはわりとうまくいきました。 SSDの大容量化がさらに進んでますし、前回の経験を活かして、HDD積んだサーバの構成変更しました。 次のステージとしては、１ラックあたり

この記事は、KUSANAGI Advent Calendar 2016の18日目の記事です。 はじめまして、18日目担当のスズムシです。 自己紹介 企業向け「基幹業務システム」を主に開発しています。 ConoHa VPSリセールパートナーと言う事もあり、Web制作会社様より依頼があれば「KUSANAGI for ConoHa」の環境を提供していたりします。 気にすべきは「最大瞬間風速」 皆さんはサイトの維持管理で何処に一番重点を置くでしょう？ 私の場合、「最大瞬間風速」を重視しています。「最大瞬間風速」とは、通常時のPV以上にアクセスが集中した状態の事です。 「最大瞬間風速」に堪えれないとWebサイトの意味が無いのです。 「最大瞬間風速」に備える サイトのPVを月間で考える方もおられますが、月間PVは「サイトの人気度」を図る尺度として十分でしょうが、「性能」を図る尺度としては不十分だと考え

この記事は、はてなエンジニアアドベントカレンダー2016の12月19日の記事です。 developer.hatenastaff.com 昨日はid:taketo957くんの 10ms以下のレスポンスタイムを支える継続的負荷テスト - taketo957の日記 でした！ Webオペレーションエンジニアのid:masayoshiです。 2016年に入社後、基盤チームとして仮想化、ネットワーク周りを中心に見ています。 さて、この記事ではLinuxのARPの挙動とその挙動から起こった問題を紹介しようと思います。 長々と記事を読みたくない人向けに結論をまとめるとLinuxのARPはTCP通信で使われ続ける限りキャッシュが飛ばないという挙動になるので、複数のL2スイッチにまたがったセグメントや非対称ルーティングをしている場合は気をつけましょうという話が書かれています。 今回紹介する事例自体は別に新規性

Posted 5月 18th, 2015 by codechord. 2 Comments Tweet Tweet 2015/05/18、個人的にどっぷりな、wordpressプラグイン本の著者さんがセッションするということもあり、第41回 WordBench 大阪 「VCCW vs Wocker」に行った議事録と感想。 結論からいって、Dockerについてかなり理解が深まった。 きっかけを与えてくれたWockerの作者のKiteさんにはただただ感謝。 触発されて、今日ずっとDockerfileの書き方しらべてた。 あとは、TDDの必要性だとか、CIの必要性だとかへの理解が深まり、ついでに、OSSの貢献の方法というか考え方だとか、いろいろと参考になった。 本題のテーマはvccw vs wocker。つまり仮想環境を利用しての開発環境についてのセッション。 そのまえに、まずDockerについ

こちらははてなエンジニアアドベントカレンダー 2016の11日目の記事です。 developer.hatenastaff.com 前日は id:Windymelt さんの「趣味のプログラミングから職業としてのプログラミングへ」でした。 windymelt.hatenablog.com 今回はAWSサービスをいくつか触ってみた話について書きたいと思います。 やったこと EC2 インスタンスの作成 VPC VPCの作成 サブネット サブネットの作成 インターネットゲートウェイ インターネットゲートウェイの作成 ルートテーブル ルートテーブルの作成 IAMロール セキュリティグループ セキュリティグループの作成 RDS RDSの作成 ALB ALBの作成 ターゲットグループ ターゲットグループの作成 ヘルスチェック ALB vs. ELB, CLB NAT Gateway NAT Gateway