FIT-HACK活動ブログ

FIT-HACKのメンバーが活動の様子を紹介します!

アクティブラーニングの重要性

どうも、ぶちょーです。

前回はネット面でのコミュニケーションの話をしましたが、今回は実際の勉強会のことをお話します。

現在、毎週月・土曜日にB37教室で情報セキュリティやプログラミング関係の勉強会を実施しています。

登壇者はサークルの幹部だったり、外部から人を呼んだりと様々です。

僕もたまーに前に立って、話すときもあります。

さて、現在の勉強会の内容として、サークル全体として以下のことを心がけるようにしています。

  • 1回聞いただけで全て分かるような内容にしない
  • 議論を行う時間を必ず取ること
  • 挙手ではなく、全員に意見を聞くこと

勉強会の難易度は毎回異なりますが、基本的には大学1年生をターゲットにしているので、それほど難しいことはしていません。

しかし、1回聞いただけで分かるような内容にしてしまうと、わざわざ教室を借りて、実施する必要がありません

なので、だいたい7割から8割の内容を教え、それ以外は個人的に学ぶことでマスターできるように構成しています。多分大学の授業もこんな感じで進めていると思います。

また、一方的に登壇者が話していても疲れますし、聞いている側も飽きてくるので、基本的に議論を行う時間を取っています。また、本学は、大学教育再生加速プログラムの一環としてアクティブラーニングにはかなり力を入れており、勉強会を行っているB37教室もその流れで机やイスが可動式になっていて、グループ学習を行うにはかなり最適です。

www.fit.ac.jp

しかし、コンセントの数が圧倒的に足りないので、大学職員の方でこの記事をご覧になっていたら、今すぐに電源タップを増やしてください。お願いします🙏

ちなみに、このように進めて行った結果なのか分かりませんが、現時点では幽霊部員は誰一人としていません!

今後もサークルという一つのチームを強化するため、頑張っていきます👍

部内CTFのWriteup

どーも、部長です。

先週、後輩(1年)と一緒に徹夜でCTFの問題を作成しました。

最初は僕が後輩にHTMLやPHPを教えていたのですが、どうせならCTFの問題作っちゃえ!という深夜テンション特有のノリで作問しました。

難易度は非常に簡単で、問題を解くというよりは問題から学んで欲しいという意図があります。

なお、問題URLの公開に関しては部内限定なので、ここでは控えさせていただきます。

1. ログインフォーム(仮称)

f:id:fithack:20160913222705p:plain

ヒントなしで余裕で解ける問題ですが、CTF未経験者もいたので、ご親切に付けてあげました。

実際、CTFでログインフォーム関連の問題があったら、9割くらいはユーザー名がadminなことが多いですね。

ということで、ユーザーIDにadminを入力すれば入れます。

パスワードの項目はありますが、実際にはダミーでした!

2.Basic認証(仮)

f:id:fithack:20160913224131p:plain

管理者でログインすると、真の管理画面のリンクが貼ってあるので、飛んでみるとBasic認証がかかっています。

Basic認証に設定する方法としては、Apacheの場合は.htaccessを置く場合が多いですね(nginxやIISだと違うので注意してね)

ということで、一個下のディレクトリに置いてある.htaccessを見てみると、なんと見れちゃう!

そこに書かれてある.htpasswdのパスに従って、.htpasswdの中身を見てみると、ユーザー名とパスワードが平文で書かれてあります。

なので、これを先ほどの認証画面に入力すると、フラグが見つかります。

f:id:fithack:20160913223822p:plain

 

練習がてらに作った問題ですが、案外苦戦している人も見受けられたので、見てて面白かったです。

中にはJohn the ripperやnmapやWiresharkなど、たくさんツールを使っている人もいたので、良いトレーニングになったのではないでしょうか(適当)

LINE+PukiWikiからCybozu Live+Slackに移行した話

どうも、ぶちょーです。

福岡工業大学 ネットワーク競技愛好会はまだ設立して間もないため、非常に小規模なサークルです。

しかし、毎週実施する勉強会ではほとんどの部員が参加してくれ、ネット上でも積極的にコミュニティを行っています。

今回は、主にネット面を中心にお話します。

LINE+PukiWiki

本サークルは設立当初、LINEとPukiWikiを使って、情報共有を行っていましたが、あまり活発ではありませんでした。

その理由として、まずLINEのサークルグループ上から安易に質問がし辛いという点です。

サークルグループは部員全員が参加していて、主にお知らせ目的で動かしていたのですが、なかなか質問できる雰囲気ではなく、僕に個人的に聞きに来る人が多かったです。

また、PukiWikiに関しては、BASIC認証で保護していたのですが、新規部員にパスワードを毎回教えたり、編集する際にPukiWiki記法で記述しないといけないので、そのやり方を教えるのがとても大変でした。

Cybozu Live+Slack

そんな中、6月ごとにCybozu LiveとSlackに移行しました。

Cybozu Liveを導入しようとしたきっかけは、他大学の情報系サークルがCybozu Liveを利用しているとの情報を聞き、早速自分のサークルでも導入しました。

導入してから、今までLINE上で行っていた勉強会の告知等が全てイベントを作成するだけで良くなり、部員側もCybozu Liveのスケジュールから今後のイベントが一目でわかるようになりました。

また、LINEの場合はサークルグループの通知をミュートにする人が多かったのですが、Cybozu Liveではメール通知機能がデフォルトでONになっていて、お知らせを逃すことが少なくなりました。

Slackに関しては、当初は誰も使ってくれなかったのですが、部内で講習会を実施したり、操作マニュアルを作成した結果、今では積極的に利用されています。

また、Slackの中では、様々なチャンネルを作成し、技術的な交流や、質問する人がかなり増えました。

最近ではオフラインCTFにも積極的に挑戦する人が増え、SlackのPrivate Channnelを利用して、チーム内の交流が行なわれているみたいです。

まとめ

Cybozu LiveとSlackの組み合わせは最高だ!

活動報告(8~9月)

どうも、副部長です。以下の内容は、夏期休暇中の活動報告となります。

 

8月

8月の勉強会は、部員の実家への帰省等の予定を考慮し、

自由参加という形での勉強会としました。

 

講義自体は競技プログラミングの内容を扱っていく予定でしたが、私自身の諸事情が

重なってしまい、導入部分(入力値の受け取り)だけの講義となってしまいました。申し訳ありません。

 

また、部長の方から機械学習の講義も行われました。

モノクロ写真をカラー写真にする技術の紹介ということで、実際に自分の環境でそのプログラムを実行するところまでを行いました。

機械学習は様々な知識が必要とされる高度な技術分野ですが、この講義を通して興味を持ってくれたなら幸いです。

 

9月

先日(9月3日)は「もくもくCTF#1」ということで、外部の方も参加できるようにした上でのイベントを企画し、各自で意見の交換を行いながらCTFに取り組みました。

具体的には、同日開催のTokyo Westerns/MMA CTF 2nd 2016に参加する形となりましたが、いかがだったでしょうか。

 

CTFは一人で参加することも可能ですが、チームを組んで参加することによって分野ごとに作業を分担できますし、それぞれの意見や技術の交換を行うことで自分の実力を向上させることにも繋がります。

今後もこういったイベントを開催していこうと思いますので、興味がある方はぜひ参加してみてください。

 

補足

今後の予定ですが、競技プログラミングの勉強会を行っていきたいと思います。

また、9月は外部での勉強会に参加するチャンスです。外部での勉強会に参加登録をしている方は忘れないようにしてください。

SPFの正しい設定方法

どうも、FIT-HACKのネットワーク管理者です。

本サークルの管理しているDNSサーバでは、なりすまし攻撃を防ぐためにSPF(Sender Policy Framework)を設定しています。

 

SPFとは?

送信ドメイン認証のことで、ゾーンファイル内に送信元のIPアドレスを記述しておくことで、正規のメールサーバから送信されているかを判断することができます。

 

設定方法

そのSPFを設定するには、DNSサーバ内にあるゾーンファイルに対して、送信元のIPアドレスを記述する必要があるのですが、設定方法が二通りあります。

1.TXTレコード(Type 16)で記述する場合

2.SPFレコード(Type 99)で記述する場合

これはどちらも正解なのですが、厳密には1番目の方法が推奨されています

ネットワークの六法全集と呼ばれているRFC(Request for Comments)のRFC 4408にはこう書かれています。

3.1.1. DNS Resource Record Types

This document defines a new DNS RR of type SPF, code 99. The format
of this type is identical to the TXT RR [RFC1035]. For either type,
the character content of the record is encoded as [US-ASCII].

It is recognized that the current practice (using a TXT record) is
not optimal, but it is necessary because there are a number of DNS
server and resolver implementations in common use that cannot handle
the new RR type. The two-record-type scheme provides a forward path
to the better solution of using an RR type reserved for this purpose.

An SPF-compliant domain name SHOULD have SPF records of both RRtypes. A compliant domain name MUST have a record of at least one
type. If a domain has records of both types, they MUST have
identical content. For example, instead of publishing just one
record as in Section 3.1 above, it is better to publish:

example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"

 ここでは、SPFの決まり事が書かれているのですが、中身を見てみるとTXTレコードとSPFレコードの両方で記述すべきと書かれています。

RFC 4408が勧告されたのが2006年でしたが、当時はまだSPFレコードに対応するDNSソフトウェアが少なく、多くの人がTXTレコードのみで記述していました

そして、2014年に勧告されたRFC 7208にはこう書かれています。

3.1. DNS Resource Records

SPF records MUST be published as a DNS TXT (type 16) Resource Record(RR) [RFC1035] only. The character content of the record is encoded
as [US-ASCII]. Use of alternative DNS RR types was supported in
SPF's experimental phase but has been discontinued.

In 2003, when SPF was first being developed, the requirements for
assignment of a new DNS RR type were considerably more stringent than
they are now. Additionally, support for easy deployment of new DNS

 ついにTXTレコードのみで記述されなくてはならないとなりました。

 

まとめ

2016年現在でもSPFレコードで記述しているところも少なからず存在しているみたいですが、これから新規で設定する場合はTXTレコードを使うのが賢明でしょう。

 

あとがき

多くの人が使っているであろうBINDさんでは、Ver.9.9.6からRFC 7208に対応しています。

Ver.9.9.6未満でnamed-checkzoneコマンドを利用すると、SPFレコードも書け!と怒られてしまいますが、無視しましょう・・・

今後の予定について

どうも、副部長です。

 

夏休みの勉強会についてですが、下記の内容で勉強会を行います。

 

日程: 毎週月曜・土曜(お盆の13日(土)・15日(月)は休みです。)

時間: 10:00~18:00

講義内容:競技プログラミング

 

なお、帰省等により出席できない場合も考慮して講義を行っていく予定ですので、無理に予定を合わせる必要はありません。

セキュリティの危険性について

どうも、部長です。

近年、セキュリティの脅威はますます増え続けています。

以下は、その脅威を可視化したものです。

セキュリティは、運営側だけではなく、自身で守る必要があります。

最近、あるサービスで流出したパスワードを用いて、他のサービスにログインし、被害を拡大していくという手口が多発しています。

なるべくパスワードは使いまわさず、定期的な変更をオススメします。