IEEE802.1x
LANスイッチや無線LANのアクセス・ポイントでユーザーを認証する技術セッションごとに動的に異なる暗号化鍵を用いた暗号化通信を実現する。
知れば知るほど面白くなるIP通信を始めとしたネットワーク技術について。IPv4の仕様策定は僕が生まれた年と同じく1981年。拡張されつづけながらも、今も通信の主役を担いつづけている。
LANスイッチや無線LANのアクセス・ポイントでユーザーを認証する技術セッションごとに動的に異なる暗号化鍵を用いた暗号化通信を実現する。
HTTP通信の内容をチェックしたい場合には、パケットキャプチャソフトという手もあるけど、Proxy型のチェックソフトを使うと便利。今まで使っていたのは、ieHTTPHeadersというソフト。インストールをするとIEの表示 - エクスプローラーバーに追加されて、表示をさせておけば、ブラウジングした際の通信をみることができる。
ただ、IE7では動作しないというか、出てこないので、IE7のHTTP通信を調べたいときには使えない。同僚がいろいろ調べてくれたところ、Fiddler2というのがあるという情報を得たので、紹介したい。
インストールするとIEのツールメニューに出てくる。.NET Frameworkのインストールが必要なので、インストールしていない状態で起動させようとするとエラー(ダイナミックリンクライブラリ mscoree.dll が指定されたパスに見つかりませんでした)が出るので注意したい。
今後、使い勝手などについてレポートしていきたいと思う。
拠点間をVPNで結ぶのであれば、IP-VPNやインターネットVPNがあるが、外出先の端末から社内の環境にVPNを張る場合には、ソフトイーサーなどのソフトウエアによるVPNやAirH"などを用いてインターネットに通信した上で、PPTPを利用できる。
Windows Serverの場合は、PPTPを実現するとき、RRAS(Routing and Remote Access Service)を利用して構築する。この場合には、ライセンスは必要かもしれないがコストはさほどかからない。
詳しくは、検証 VPN実践導入講座が参考になると思う。
ヤマハ製のルータRTXシリーズにてMACアドレスフィルタリングを行うには、Rev.8.03.24以降のファームウェアの適用が必要ですよーというのは、ここに記載があるわけですが、どうやればMACアドレスフィルタリングできるのかがよくわからなかった。
ちなみにRev.8.03.24のリリースノート(リンクがないので分からなかったが、何とか探し出した)には実現するためのコマンドが書いてあったので、以下のとおり書式を記載しておきます。
ethernet filter NUM KIND SRC_MAC [DST_MAC [OFFSET BYTE_LIST]]
http://www.atmarkit.co.jp/news/200706/19/jpnic.html
前々から騒がれていたネタだけど本格的にヤバくなってきたみたい。おそらく資源枯渇が深刻な度合いは石油と同じくらいかもしれない。
石油の代替燃料としてバイオマス燃料の研究が盛んだけどIPアドレスもIPv6という素晴らしい代替案がある。しかしながら、すべてのノードをIPv6にすることはほとんど不可能で、現時点でも、どのキャリアも及び腰。せめて基幹ネットワークだけでももれなく着手しないと。。。
とりあえずは使われてないアドレスを回収して再利用することで延命措置を検討しているらしいけどうまくやらないと経路情報がむやみやたらと増えることになってルータの負荷はあがるだろうし。
そもそも、もう30年立とうとする技術が工夫に工夫されて今でもうまく運用できていることがまず奇跡的なわけだけど、そんな歴史的な賞賛はおいておき、どうやったらIPv6に素早く移行できるかみんなでもっと知恵を絞る必要がありそうだ。
そうしないと家電をネットワークでつないで実現しようとしていることなんていつまで立っても実現できないだろうし。
インターネットをはじめインフラは現在は性悪説で運用されることが当たり前だが、以前は閉ざされたネットワークということもあり性善説で運用されてきた。それはプロトコルの設計にみてとれる。
たとえば、SMTPなんかは認証が存在しない。そもそもスパムメールを送るとかなりすましをするだなんて考慮されてないわけで。
Whoisというドメイン情報の検索サービスがあるが、これはドメイン管理の責任を明確にするためのものだったが、DM送付用の情報源になるなどの問題になり、今や当初の目的を果たせない意味のない運用になっている。
おそらくインターネットは商用利用されることになって利用者が格段に増えて今や無くてはならないインフラになったものの理想と現実のギャップに直面してきたと言える。
これからインターネットはどのように発展していくのだろうか?IPv6によるアドレス空間の無限の広がりから新たな発想によるサービスが生まれるのか、はたまた既存のプロトコルの組み合わせから思いもつかなかった便利なサービスが生まれるのか、はたまた不要なパケットによってトラフィックが埋め尽くされそこから悪循環が生まれてくることの連続なのか・・・
ずいぶん昔に、IPv4バイトのIPアドレス体系をもつのだから、IPv6は6バイトのIPアドレス体系なのかと思ってしまったことがあります。
実際のところIPv4は32ビット=4バイトですが、IPv6は128ビット=16バイトなので、違うなぁという自問自答をした覚えがあります。今こんなことを思っていたらネットワークエンジニア失格ですが。
もうすでに皆さんはご存知かと思いますが、IPv4はInternet Protocol Version4の略であり、IPv6は Version6なのです。
ということはVersion5があり、Version7以降もあるのではないかと思う人は鋭くて、実はIPv9まで存在します。
詳しくは、KyoのCCIE取得日記☆を参照してみてください。
LDAP(えるだっぷ:Lightweight Directory Access Protocol)を利用する際の参考情報
LDAP TCP:389
LDAP over SSL TCP:636
以下は、Active Directoryが利用しているケースがある。
グローバルカタログLDAP TCP:3268
グローバルカタログLDAP over SSL TCP:3269
入社時にもらった名刺が切れてしまって、新しい名刺がきた。新しい名刺にはテクニカルエンジニア(ネットワーク)の文字が印字されている。
お客さんのところに行ってお会いする方が少しでも詳しい人であればいろいろお願いしますよと言われるけど実際のところは不安だらけ。逆にこんな資格はできればない方が良いとさえ思ってしまうくらい。
ネットワークエンジニアに求められるものは、ベンダ系の詳しい知識と障害切り分け能力の大きく分けて2つがある。
というわけでネットワークスペシャリストなんて言う資格は実務ではあまり役には立たない。
まずベンダ系知識については机上の知識ではなく手を動かしてなんぼだし、そのハードウエアがあってこそってことがあるから環境に恵まれなければならない。
障害の切り分けは修羅場を何回くぐっているかの経験とそれによって培われる直感が頼り。マニュアルに従って切り分けることは定石だがそれでは時間がかかりすぎるのだ。
あとネットワークの知識と一言で言っても、小規模なスタティックルーティングからプロバイダが扱うような大規模なダイナミックルーティングまであり、ホントに幅が広い。これを一つの資格にまとめた情報処理推進機構はある意味すごいといえる。
まぁネットワークエンジニアこそハードウエアをさわってなんぼの世界なんでしょうね。
ひとつだけいえることがある。それはインフラの仕事は絶対にやってはいけない。せめて設計のレベルにとどめるべきだ。保守の仕事をしてしまえば休みの日が常に休みでなくなるからだ。怖くてどこにもいけなくなってしまう。
前の会社でデータセンターの選定作業を行ってから早2年、いろんなデータセンターを見て回ったり、今の会社になってからは作業をしたりすることが多いが、実際にデータセンターを選ばなければならなくなったとしたら選ぶポイントはどこにあるのだろうか?
営業トークにごまかされると後々移転せざるを得ないケースもあるので、このドキュメントが何らか役に立てば嬉しい。
まず立地条件。通常はリモートメンテナンスで何とかなる訳なので、言ってしまえばデータセンターの位置はどこでもよいと言うことになる。ただし、致命的な問題が発生しないということはないので、必ず駆けつけできる範囲であることが最低条件。
次に、電源の問題。基本的にこの問題は当たり前だからこそ気づかない部分だ。1ラックあたり何Aまで追加できるのかをチェック。
そして、サポート内容のひとつであるリモートハンド作業。万一リセットを必要とすることがあれば、センターの人にやってもらうしかないが、そのセンターは担当が24時間いるかどうかを確認しておくべき。この部分をすりあわせなかったために痛い思いをしたことがある。ただ24時間常駐していても、対応には10分程度かかるため、ミッションクリティカルなマシンには必ずDRAC(Dell Remote Access Controller)のようなものを入れておくべきだ。
当たり前と思っていることが当たり前でないことはよくあることだ。
最後に空きスペースの問題。今後増設を検討している場合には思い切ってスペースを借りておいた方が無難。何らかによって急にサーバーを増設することになっても対応できないではすまされない。
プライベートIPアドレスとリンクローカルアドレスについて。
RFC1918で規定されているプライベートIPアドレスは以下のとおり。
Class A 10.0.0.0~10.255.255.255
Class B 172.16.0.0~172.31.255.255
Class C 192.168.0.0~192.168.255.255
一方、RFC3330で規定されているリンクローカルアドレスは以下のとおり。
なお、APIPA(Automatic Private IP Addressing)機能により自動的に割り当てられる、
169.254.0.0~169.254.255.255
後者はDHCPで取得できなかったときにこの中からランダムで割り当てることで、DHCPがなくても複数のマシンで通信できるようにする仕組み。計算上では2台で通信する場合には、1/(2562-2)=65,534分の1の確率で重複してしまう。おそらく設定する際には、RARPでIPが存在しないことを確認してから設定するので、そんな心配はいらないわけだが。
Windows XPにオフラインページという概念がある。どうやらWindows98からあるようで、なんのことはないオフラインでもインターネットで取得したページが見れるというただそれだけだ。
ただオフラインページを有効にするとユーザーアカウントをログオフしないと切り替えられないということがあるようで、なぜなのかわからない。
Windows Vistaは標準でIPv6に対応している。XPでもIPv6に対応させることはできたが、コマンドプロンプトでコマンドを入れてインストールして利用する形となっているため標準対応しているとは言いがたかった。
VistaによってOSレベルでのサポートがされることによってIPv6化が一気に進むだろうと多くのメディアは報じている。
しかしながら本当にIPv6化は加速するのだろうか?そもそもIPv6化に熱心なのはアドレス空間が不足しているアジア圏が中心であり、もっぱら日本はその推進役をしているわけだが、他国に目を向ければアメリカをはじめIPv6化の声はまだまだ小さい。
これは歴史的経緯からアメリカを中心にホスト部が24ビットのクラスAや16ビットのクラスBを割り当てられている組織が多く、アドレス枯渇が身近な問題でないことによる。
加えて端末だけIPv6になったところでどうなんだ?ということもある。結局カプセル化して送ることになってしまうので、本当の意味でのアドレス枯渇問題や経路爆発問題が解決されるわけではなく、経路上のすべての機器がIPv6に対応しなければならない。
とはいえ今回のクライアント端末がIPv6に対応することでフルIPv6化の道も開けてきたということになるのだろう。
ヤマハルータのデフォルトMTUはVPN区間とそうでない区間で違っていることをご存知でしょうか?
VPN通信では1280Byte、それ以外は1500Byteになっていて、ICMPパケットを破棄する設定になっていると通信できなくなる問題を引き起こすようです。
ファイルサーバー
|
LAN | MTU1500
|
RTX1100
|
VPN | MTU1280
|
RTX1100
|
LAN | MTU1500
|
クライアント
それは、ファイル共有サービスについてはファイル共有の仕組みが(アプリケーション層で)MTUからTCPヘッダ分である40バイト引いた1460Byteで事前に分割して送信しようとするのですが、パケット分割禁止のフラグをあわせてつけて送ってしまっているために、VPNを構築している区間が通信できず、再送手続きを要求されてしまうようです。(アプリケーション層で分割しないような通常のTCP通信であればルータ間でファイル分割をしなおすだけなので、再送手続きにまでは至らないのです)
このとき、Packet needs to be fragmented but DF set.を送信元に返して、再送を要求しますが、これがICMPなので、経路で破棄されていると通信できなくなってしまうというわけです。
この問題は、Path MTU Discovery Black Hole):RFC2923と呼ばれていて、結構有名な問題のようです。詳しくは@ITをご覧ください。図解入りで詳しく説明されています。
ファイル共有サービスはMicrosoft固有の小さな親切大きなお世話で成りたっているようです(パケット分割をするのはアプリケーション層の仕事ではなく、本来ネットワーク層の仕事だから)
ビット誤りの検出と訂正について
水平パリティ・垂直パリティ
1(奇数)ビットの誤りを検出できる。
巡回冗長検査(CRC)
生成多項式を次数nとするとn以下のバースト誤りを検出できる。
ハミング符号
2ビットの誤り検出機能と、1ビットの誤り訂正機能を持つ。
必要な検査符号ビットをkとすると、(2k-k-1)>=mを満足するmビットまでを送付できる。
4ビットを送りたい場合は
2k-k-1>=4
2k>=5+k
k>=log2(5+k)
k>=3となり、検査符号ビットには3ビット必要となる。
Winnyなどを通じて感染する暴露ウイルスによる情報漏洩は後を絶たない。企業において情報漏洩は信頼の低下をはじめ、損害は計り知れないだけに、対策には十分な時間とコストをかけたいもの。
セキュアネットワークの基本は、必要なソフトウエアの通信だけを許可するというものだが、それだけでは不十分な可能性がある。それは、暴露ウイルスが、必要とされるソフトウエアの通信かのように振舞って(たとえば、80番ポート宛に通信をする)情報漏洩をさせる可能性があるからだ。
これを防ぐためには、(従業員が使用するパソコンを含め)基本的に信頼していないホストが外部と直接通信しないようにすれば良い。
多くの企業で推奨される通信
TCP 80, 443番ポート
Webを閲覧するためには必要不可欠なポート これはProxyサーバーを立て、Proxyサーバーからのみ外部と通信できるようフィルタリングをすればよい。なお、クライアントの設定はProxyサーバーを見るように変更する必要がある。
TCP 25, 110番ポート
SMTP, POPサーバーを内部に配置し、外部への配送は、そのサーバーを通じて行えばよい。ただ、外部からのメールを受け取れるようにするには、必然的にDMZへの配置が必要となる。
UDP 53番ポート
DNSサーバーは内部に配置し、そのサーバーが外部のDNSサーバーと通信できるようにすれば良い。なお、クライアントの設定は内部DNSサーバーを見るように変更する必要があるが、DHCPでIPアドレスを配信しているのであれば、DHCPサーバーに設定するだけでよい。
UDP 123番ポート
DNSと同様NTPサーバーは内部に配置し、そのサーバーが外部のNTPサーバーと通信できるようにすればよい。なお、クライアントの設定は内部NTPサーバーを見るように変更する必要がある。
その他のポートは基本的に拒否で良いが、たとえば、企業のWebサーバーなどがDMZ上に存在せず、レンタルサーバーなどを利用している場合には、アップロードする担当者の端末のIPアドレスを固定に設定し、そのIPアドレスからのみ通信できるようにするなどの配慮が必要と考えられる。
しかしながら、これでもなおUSBポートを使ったリムーバブルメディアからの情報漏洩や、印刷による紙媒体による漏洩、Webメールや通常のメールなどによる漏洩なども考えられ、後者への対策としては、Proxyサーバーやメールサーバーを経由するパケットを全て保存し、情報漏洩が発生した場合に究明できるようにしておかなければならない。(しかしながら現実には、これを実現するための膨大なストレージを用意する必要があり、検索可能な状態にするためのフォレンジックス製品の導入を検討しなければならないというとても頭の痛い問題がある)
しかしながら、技術的な制限だけでは(金銭的にも)限界の可能性があるので、運用面でのカバーやユーザーへの啓蒙も怠ってはならない。
電力線通信用のモデム BL-PA100KT がパナソニックからとうとう発売された。
無線では壁が厚いために電波が通らないというケースにおいても、ケーブルを部屋から部屋に通すといったことのないきれいなレイアウトにするための方法のひとつとなりそうだ。
ICANNが「.asia」をトップレベルドメインとして承認したようだ。
もはやトップドメインをこれだけ多くすることに意味があるのだろうか?まぁ、あれば良いじゃないかと言われれば、確かにそうではあるが。。。
NTT東日本、NTT西日本が提供する加入電話、公衆電話、緊急通報などの公共性の高いサービスを、全国で公平かつ安定的に利用できる環境を確保するために電話契約者は2007年1月から、毎月1電話番号あたり一定額のユニバーサルサービス料の負担が発生する制度。つまるところ、都心部では設備投資や維持費をペイできているが、過疎地においては大幅に赤字になっている部分を通信設備を使うみんなで負担しあうもの。
日経NETWORK12月号によると、実は2002年に制定された制度のようで、東西NTTが2006年8月に制度の適用を申請したことで運用が開始されるようになったそうです。
過疎地なんて通信できなくなってもいいというぶっきらぼうな議論もあるだろうが、もし田舎に旅行することがあって緊急事態があって通信が利用できなかったらどうだろうか?やはり通信はインフラのひとつであるように、いつでもどこでも利用できなければならない。そのための費用負担があってもやむをえないだろう(一部ではNTTの経営努力が足りないという指摘もあるわけだが・・・)。
ユニバーサルサービス料は実績に基づいて半年に一度見直しが行われる。
コンテンツホルダーと回線事業者が真っ向から対立する問題。コンテンツホルダーはリッチコンテンツを流して何が悪い、回線事業者は通信量に応じた従量制にすべきという議論。なぜこんな問題が起こるのだろうか?
回線事業者はブロードバンド化に伴い、コスト競争の波にさらされてきた。通信帯域の増大に関してはある程度設備投資をしていってもペイできるかどうかのギリギリまでコストを抑えて集客をしてきた。つまり、エンドユーザーから徴収する月額費用を抑えてでも、顧客の獲得ができれば全体としての売上は変わらないかあわよくば増えるといった目論見だった。
しかし、コスト競争になった時にこの考え方は往々にして正しくない。ネット証券の手数料引き下げの時も同じような構図だった。そもそもニーズが限られているにもかかわらず需要過多になりがちなのだ。
そこにプロバイダが意図しないほどのリッチコンテンツが増えてきた。USENのGyaoやYouTubeにみられるような動画配信だ。
ただこれは一概に回線事業者が悪いというわけでもない。このような形にしていったインターネット全体の問題であることには間違いないわけだから。
回線事業者はユーザー離れを防ぐために、エンドユーザーから徴収せずにUSENやYouTubeのようなパケットを垂れ流しつづけるアプリケーションプロバイダーから課金をしようとしている。おそらく歴史的な経緯を考えるならば、エンドユーザーから徴収せざるを得なくなるだろう。これは回線事業者がさらに淘汰されて、エンドユーザーは結局回線事業者を選べなくなることによる。
インターネットがこれだけ重要度を増している現在、ネット回線も電気や水道、ガスなどと同じようにコスト面においてひとつのインフラへの支払いを行っていると考えるべきだろう。
これだけのブロードバンドを支えるにはそれなりの維持費用もかかるし、さらに設備投資も必要となる。24時間365日インフラを使いつづけることができる(今後もいつでも当たり前のように使いつづけられる)ようにするためにも・・・
メール配送が554で中継拒否される理由については以下が大きく考えられる。
・ORDBなどの不正中継DBに登録されている最後に行けばいくほど可能性が少ないわけだが、SMTPサーバーしか設置していないホストにおいては最後のMXレコードの登録についてはよく注意したほうがよさそうだ。
・配送元の逆引きと正引きが正しくない(逆引きしたホストを正引きした結果のIPアドレスがもともとのIPアドレスと違う)
・メールアドレスのMXレコードが引けない
2000年12月18日~大阪国際会議場で行われていたセミナーの映像を見ることが出来るサイトを見つけました。なかなかマニアックな内容も含まれていますので、聞いているだけでも面白いかもしれません。
しかし、6年前というだけあって話の節々に出てくる話題が古いです。ただ、原理は何も変わっていないようです。
Linuxにおけるネットワーク関連コマンドには以下のものがある。ifconfigを除き基本的にrootユーザーのみ利用できる。
ifup
ネットワークディバイスを開始する
ネットワークディバイスを停止する
ネットワークディバイスの論理設定を見る
ネットワークディバイスの物理状態(通信速度やLinkupしているかなど)を見る
ネットワークを勉強するには、実際にハブやルータなどのハードウエアを動かしてネットワークを構築することから始まるのではないかと思う。ただ、実際のところ大規模なルーティングが必要なネットワークを構築できることはまれだし、当たり前につながっているネットワークになぜが生まれることは少ない(実際のところ、ネットワーク障害が発生して初めて学ぶことも多いはず)。
中国・四国インターネット協議会主催のIIJのセミナーのレジュメが公開されており、非常に分かりやすいので紹介する。ただし、201ページもある大作なので少しずつ見たほうが良いかもしれない。
業務用エントリーモデルのルーターで、シスコやアライドテレシスのような高価なルーターは導入できないけれども、市販のルーターでは心もとない場合には、是非これをオススメしたい。設定変更はCUIででき、コマンド発行と同時に変更が効くので、システム停止が発生しない。また帯域制御もできるので、QoSを要求されるサービスでも利用できる。市販価格は7万円前後。
http://journal.mycom.co.jp/articles/2005/03/25/rtx1100/
ネットワークなどの規格を定めるIEEE802を始めとしたネタ
802.1シリーズ
802.1D
スパニングツリー(STP)に関する規格。
ラピッドスパニングツリー(RSTP)に関する規格。IEEE802.1Dの改良版。
802.3シリーズ
有線LANに関する標準規格
802.3
10BASE-5(同軸ケーブル)に関する規格。
10BASE-2(同軸ケーブル)に関する規格。
10BASE-X(カテゴリー3以上のUTPケーブル)に関する規格。
100BASE-TX(カテゴリー5以上のUTPケーブル)に関する規格。
1000BASE-SX, 1000BASE-LX(光ファイバケーブル)に関する規格。
1000BASE-TX(カテゴリー6以上のUTPケーブル)に関する規格。
bonding(リンクアグリゲーション)に関する規格。
10GBASE-SR, 10GBASE-SR(光ファイバケーブル)に関する規格。
802.11シリーズ
無線LANに関する標準規格
802.11a
5.2GHz帯を利用し、54Mbpsで通信可能な無線LAN規格。
2.4GHz帯を利用し、11Mbpsで通信可能な無線LAN規格。
無線LANにおけるQoSを実現するための規格。
2.4GHz帯を利用し、54Mbpsで通信可能な無線LAN規格。
(まだドラフト段階)MIMOを使った無線LAN技術。5.2GHz帯を利用し、100Mbpsで通信可能な無線LAN規格。
802.16シリーズ
WiMAXに関する規格
802.16e
モバイルWiMAXに関する規格。
ネットワークストレージは今とても熱い。NASは低価格だが拡張性に欠ける、一方でSANは拡張性は高いものの価格が非常に高い。今後、J-SOX法に対応するために、ログはすべて保存され、いつでも検索できる状態になければならないとするならば、管理者はどこにログがあるかを意識する必要がなくなるような状態が望ましい。しかしながら、ほとんどアクセスされないログが単位容量あたりの単価が高いストレージにあるのも変な話であり、アクセス頻度に応じて保存されるストレージが決定ならびに変更されるようなシステムが望ましいということになる。
・DAS(Direct Attached Storage)
・NAS(Network Attached Storage)
・SAN(Storage Area Network)
・FC(Fibre)-SAN(光ファイバーケーブルで接続したSAN)
・IP-SAN(IP網で接続したSAN)
・NASゲートウェイ(SANの利点とNASの利点をうまく統合)
・iSCSI
秋の情報技術者試験のネットワークに受験して来ました。場所はたまプラーザの國學院だったので割と近くて助かりました。
試験は午前、午後1は問題ないように思えたんですが、午後2はSANとネットワークの冗長化及びVLANに関するマニアックな問題が出て少しヤバ目でした。
昨年実績12.8%合格率の狭き門だけど、受かってると良いんですが…
ここでいままでの受験実績です。
2006年春 DB試験(場所不明) 午前:580 不合格
2005年秋 AP試験(早稲田大学) 午前:免除/午後Ⅰ:590 不合格
2005年春 DB試験(場所不明) 午前:600/午後Ⅰ:540 不合格
2005年秋 AP試験(場所不明) 午前:免除/午後Ⅰ:680/午後Ⅱ:C 不合格
多重アクセスには以下のものがある。
CSMA(Carrier Sense Multiple Access) 搬送波感知多重アクセス方式。なお、検出方法に対する挙動の違いで次のものが存在する。
CSMA/CD:Collision Detection
有線LANで利用している衝突検知で、キャリア信号を検出しデータの送信を制御する。コリジョンが発生した際、ランダムの数ミリ秒の間隔をあけて再送信する。
CSMA/CA:Collision Avoidance
無線LANで利用している衝突回避
CDMA(Code Division Mutiple Access) KDDIのauが利用している符号多重アクセス方式
FDMA(Frequency Division Mutiple Access) 周波数を用いた多重アクセス方式
セキュリティを実現するための方法として、ネットワーク層のIPSec、データリンク層のPPTP(Point to Point Tunneling Protocol:Microsoft提唱プロトコル)、PPTPとL2FをIETFで標準化したL2TP(Layer2 Tynneling Protocol)がある。そしてアプリケーション層ではSSH(Secure SHell)、SSL(Secure Socket Layer)がある。
必ずといっていいほど情報処理技術者試験に出る問題。M/1/1待ち行列モデルにおける平均待ち時間Twは以下のとおり表される
Tw=(ρ÷(1-ρ))×Ts ここでρ=システム利用率、Ts=平均サービス時間である。
電話機の利用状況を示す単位で、呼数×平均保留時間÷測定時間で示される。
180台の電話があって、1台あたり3分に1回呼び出しがあり、平均通話時間が80秒とすると、呼数は、
180(台)×1(回)×80(秒)÷180(秒)=80アーラン
となるらしい。でもなぜネットワーク試験に出題されるのかが一番のなぞだ。
070はPHS、080と090は携帯電話。050はIP電話。
実はこれらは0A0電話と呼ばれていて、総務省の位置付けにおける従来の電話0AB~J(0からはじまってなぜかしらIをのぞく10桁で構成される普通の電話番号のこと)よりも品質が保証されていない(低い)電話ということになる。
※品質が保証されないというのは、常にノイズがのらないとか(通話品質と安定性)ということであって、電話できないとかということではない
ところでもうそろそろ060の電話番号の割り当てが始まる。
これは、固定電話と移動電話のいいとこどりの電話(FMC:Fixed Mobile Convergence)である。
ここで言う、固定電話というのは従来の固定電話のことではなくて、IP電話をさしていて、移動電話はPHSや携帯電話などの電話になる。(たとえば)PHSのような移動体端末を家の中に持ち込めば家の無線LANなどにつながって、IP電話として着信する。いったん家の外になれば、PHS網につながってPHSとして通信できるようになる。
電話をかける人は、IP電話にかけるとか、PHSにかけるとかを意識しなくて済むようになり、一方で電話を受ける人も家の電話を転送したりしなくても良くなって、家にいる時は同じ電話番号でありながら安い通話料で電話することができるようになる。
いつでもどこでもネットワークにつながっている「ユビキタス」社会がまた一歩近づいている。
いくら100Mbpsでイーサーネット接続できていたとしても、途中経路に低速な回線や処理能力の低いルータがあれば、100Mbpsで通信することはできず、輻輳(ふくそう:通信上限に達する)が発生する。
これを防ぐために、徐々に通信量を増やして最適になるように調整するアルゴリズムがスロースタートアルゴリズムである。
フィッシングとファーミングの違いは以下の通り
フィッシング
何らかの方法(URL偽装)などを利用して正規のサイトとそっくりの偽サイトに誘導し、実際にログインさせることでログイン情報などを取得する。URLを注意深くチェックすればフィッシングサイトに引っかかることは少ないが、Basic認証対応のURLの場合、ライトユーザーにはチェックが難しい。このURLでアクセスできなくなっているブラウザも存在する。
Basic認証対応のURLパターン:http://(ユーザー名):(パスワード)@(ドメイン名)/
http://www.yahoo.co:jp@hogehoge.com/
というサイトがYahooのサイトと認識されても不思議はない??(でも実際のところ無理がありそうな。。。)
ファーミング
DNSの解決の仕組みを悪用して、ホスト名の解決を正規のIPアドレスではなく、悪意あるホストのIPアドレスを返答させる。これを実現するには、DNSサーバーのキャッシュ情報を書き換える(DNSポイズニング)か、hostsファイルをウィルスなどによって書き換える。
この方法が成功すれば、ユーザーが良く訪れる信用あるURLが実は詐称サイトということになる。
この検出はかなり難しい。正しいhostsファイルのMD5を保存しておいて、それが変わった時点でhostsファイルを信頼しないしかない。あとは信頼あるDNSサーバーを登録するとか。。。もはやDNSサーバーが信頼できないなんて、ありえない事態だ。
スパムメールによるネットワーク負荷を減らす取り組み。
プロバイダが加入者の動的IPから外部ネットワークのSMTPサーバーに25番ポートで接続できないようにフィルタリングする。これによってスパムメール配信業者は、固定IPを使わざるを得なくなるので事実上送信数を減らせる。
ただ、一般ユーザーが外部ネットワークのSMTPサーバーへ接続できないのは不便なのでサブミッションポート(587番ポート)への接続を行うことになる。
懸念材料としては、
・587番ポートで待ち受けしていないSMTPサーバーへは接続できなくなる方向に今後進んでいくので、メールサーバーを管理するサーバー管理者は587番ポートでの待ち受けを検討する必要がある。
・自宅サーバーを運営しているユーザーにおいてはSMTPサーバーの運用が事実上できなくなるので、固定IPアドレスで運用するように変更するか、OP25Bの取り組みを行わないプロバイダへ移行するか、587番ポートで待ち受けするSMTP中継サーバーの利用を検討しなければならない。