アクセス数が高いシステムへのリアルタイムスキャンについて
Webサーバなど高頻度のファイルアクセスがあるシステムへのリアルタイムスキャンは設計が非常に難しいです。理由としては頻繁にロードアベレージ高騰などの高負荷状態に陥り、最悪の場合ハングアップする事も想定されるからです。
一般的にウィルススキャンは検索結果をキャッシュとして保持し、同一ファイルの二回目以降のアクセスに対してはキャッシュを利用することで負荷低減を行います。しかし、パターンファイルがアップデートされるとキャッシュされた結果に信頼性が失われるため、それまでのキャッシュを破棄します。
新規のファイルアクセスに加え、今までキャッシュを使用していたファイルにも検査が行われるため、一時的にディスクI/OおよびCPU使用率が上昇します。これに加え平行してパターンアップデートに伴うDBアップデートも行われ、この処理でも前述したディスクI/OとCPU使用率が上昇します。これらの処理が重なりサーバの高負荷状態が発生することでスキャン要求がサーバの処理能力を超えた場合、サーバハングが起きてしまう場合があります。また、メモリの断片化が進みPae Allocation Failureが頻発する場合もあります。
本問題を解消するためにはリアルタイムスキャン対象の領域を絞るか、パターンアップの頻度を下げたり影響が少ない(アクセス数が低いなど負荷の高くない)時間帯に実行するように変更する必要があります。メモリ断片化に関してはカーネルパラメータのvm.min_free_kbytesをチューニングして改善する場合もありますが、このカーネルパラメータは低すぎても高すぎてもサーバの正常動作に支障をきたすため注意が必要です。
最も安牌なのはデメリットを説明し、リアルタイムスキャンを実行しないことですが、要件として必須であれば導入は慎重に行い、充分な検証を実施すべきです。
Stack構成のメリットとデメリット
ネットワーク機器のStack構成は2台以上のスイッチを論理的に1台に束ねる技術です。個人的にStack構成の最も優れていると思うところは、Stack構成を組むことで論理的に1台に出来るため、ループフリー構成となりSTPを使用しなくて良くなるところです。また、管理するConfigも1台となり、設計がシンプル化出来ます。
以前は、提案する際に可能であればStack構成を推奨していましたが、ISP事業者としてバックボーンの運用を行うようになり、考え方が変化してきました。
まずスタック構成のデメリットとして、Stack構成を組むスイッチではすべてのスタックメンバーでバージョンを合わせるため、ファームウェアにバグがあった場合に両系に影響が出てしまいます。バグが通信に大きく影響があるレベルであれば、完全に停止してしまう可能性もあります。そのため、たとえばルーティングを片寄して迂回を行い、片系ずつバージョンアップするなど問題発生時の経路迂回が難しく、完全な冗長性を担保することが出来ません。
また、スタックケーブルの半刺しやスタックモジュール障害時にリブートを繰り返してバタついてしまうケースも存在します。さらにOSPFやBGPのプロセスも一度切れて再接続をするケースもあるため、機器障害時の通信断時間がシビアに求められる環境では、L3機能を使う場合はStack構成を避けることも検討すべきだと感じました。
Stack機能は非常に便利ですが、運用まで視野に入れる場合はファームウェアのアップデート手順や障害時の経路迂回など、どの程度の通信断時間が許容されるかを考慮した導入検討が必要です。
セキュリティインシデント向けのテレワーク保険
東京海上日動火災保険及び日本マイクロソフトがテレワーク保険というものを発表しました。本サービスは2月から開始予定で、Windows 10 搭載 PC に商品付帯する販売方式を採用するため、保険契約等は不要のようです。
モバイルPCの利用時に発生する各種損害に対し、損害賠償金や原因調査費用等を補償するサービスでウイルス感染時の調査費用や、PCを紛失してしまい情報漏えいした際の損害賠償金や各種対応費用を補償するサービスとのことです。
気になる具体的な補填内容(金額)や補填対象の条件が不明ですが、手軽に取り入れられるようであれば提案材料の一つになると思いました。専用線などネットワークインフラでは停止時間があれば月額料金の何%を返金するといったSLAが提示されていることは珍しくありませんが、セキュリティ対策はどこまで補償(対象条件/金額)するのか、明示することが難しいため、詳細情報を待ちたいと思います。
ipv6 source address selection
ipv6には送信元アドレスの選択に優先順位が存在します。本記事で記載するものは一時期話題となったipv4とipv6の優先順位ではなく、ipv6のみに限ったものとします。
まずipv6の自動アドレス設定には大きく2つの方法が存在します。
- ステートフル自動設定
- ステートレス自動設定
ステートフル自動設定ではDHCPv6サーバからipv6アドレスを取得します。ipv4との大きな違いはデフォルトゲートウェイを配信出来ないことにあります。この仕様からDHCPv6のみでクライアントに必要なipv6アドレス(ip/subnet/gw/dns)を付与することは出来ません。
一方ステートレス自動設定ではRAによってipv6アドレスを取得します。ステートフル自動設定とは違い、クライアントに必要なipv6アドレスをすべて付与することが可能です。ただし、RAで割り当てるのはプレフィックスのみでインターフェースIDはクライアント側で自動生成します、つまり割り当てるipv6アドレスはクライアントに依存します。また、RAでのDNSの配信にはRDNSS機能に対応している必要があります。RDNSS機能はIOS XE 3.9S以降( iosの場合15.4(1)T, 15.3(2)S.以降)で対応します。
ipv6RT(config-if)#ipv6 nd ra dns server x:x:x:x:x:x:x
1. 2.を見比べるとステートレス自動設定(2)であればDHCPv6サーバが不要で便利に感じますが、クライアントに割り当てるアドレスを管理出来ない欠点があります。つまりクライアントに割り当てるipv6アドレスを管理したいのであれば、ステートフル自動設定(1)を利用するしかありません、しかしステートフル自動設定はデフォルトゲートウェイを配信出来ないため、RAも併用する必要があります。前置きが長くなりましたがここからが本題です。実際に1. 2.を組み合わせてWindows7でIPを取得してみるとipv6アドレスを3つ保持します。
※残念なことにMフラグを有効化してもRAでipは取得します。
クライアントはこれらのipv6アドレスから決められた優先順位に従って送信元ipv6アドレスを使用します。クライアント側で特に設定変更をしない場合、3→2→1の順に使用します。つまりDHCPv6サーバを使用する目的である「クライアントに割り当てるipv6アドレスを管理」が出来ても実際に通信を行うipv6アドレスを管理出来ません。
本問題を解消するためにクライアント側で優先順位を変更しても良いのですが、台数が多い場合はあまり現実的ではありません。無難なのはRAを送信するインターフェースで以下のコマンドを設定することで プレフィックスを送信せず、クライアント側で自動生成することを無効化出来ます。RAで自動生成されないと一時ipv6アドレスも生成されないため、結果的にDHCPv6サーバから取得したipv6アドレスが送信元アドレスになります。
ipv6RT(config-if)#ipv6 nd prefix default no-advertise
注意点として、RAでプレフィックスを取得する前提の機能がないか確認が必要です。また、ipv4と違ってグローバルipv6アドレスはインターネットに出るのに途中でNATする必要がないため、通信先にクライアントの実ipアドレスが把握されてしまいます。そのため、インターネットに出るためではなくセキュリティの観点からNATを行うなど、ipv6はipv4以上にクライアントおよび途中経路での適切なセキュリティ設計が求められます。
ipv6化による速度向上
利用ユーザの急激な増加に伴い、フレッツ回線の遅延が目立ってきました。この問題はipv6化することで解消できる可能性があります。ただし、勘違いしがちなのですが、決してipv6自体が高速な訳ではないです。また、必ず速度が早くなるわけではないです。
まず一般的にフレッツが遅延する大きな理由としてはPOI(Point of Interface)の帯域不足が挙げられます。POIとはNTTとISPの相互接続点で、NTTのフレッツ網から各ISP(インターネット)への経路です。
POIの帯域を増強出来れば良いのですが、これにはNTTからの制約が厳しく、非常に高い費用が発生するので中々出来ないのが現状です。ipv6に速度向上が期待できるのは、ipv6のPOI(VNE)が帯域に余裕があること、同ipv4に比べ制約が緩く、帯域の増強が行い易いことにあります。
また、NGNのipv6契約同士であればNGN網内で折り返し通信が出来るため、通信距離が短くなり速度向上が期待できます。
ipv4でこれが出来ないのはインターネット網に各キャリアのPPPoEサーバがあり、必ずPOIを経由する必要があるためです。経由するPOIの帯域が不足している場合は速度が低下してしまいます。つまり経由するPOIの帯域に余裕がある場合、ipv6化しても大きな恩恵を得られない可能性があります、どのPOIを経由するかはONUの設置位置(住所)に依存するため、注意が必要です。
また、ipv6を使用してインターネット接続を行う場合、通信を行う相手がipv6に対応しているか確認が必要です。導入前には通信要件を正しく把握し、ipv6化しても問題ないか見定めましょう。VNEまでipv6トンネルを形成し、ipv4パケットをカプセル化するようなサービスを利用することで帯域に余裕があるVNEを中継したipv4通信が可能です。さらにIPoEではPPPoEを利用しないため、MTUサイズを1500にすることができ、一度に送信できるパケットサイズが増加します。
結論としてipv6化することで多くの場合は速度向上が期待できます。しかしPOIの遅延が起きているかはキャリア側でしか把握出来ないため注意が必要です。それ以外にも利用しているサービスがipv6化しているか確認が必要です。まだ普及が進まないipv6化ですが、早めに移行することで、より恩恵を受けることが出来るため、検討の価値はあると思います。
WPA3
Wi-Fi Allianceは米国時間の2018/1/8にWPA3について明らかにしました。今回の発表ではおおまかに以下の機能が判明しました。
- 総当り攻撃に対するセキュリティ向上
- 任意の端末での別端末の認証
- 端末~ルータ間の暗号化
- デフォルトの鍵長を192bitへ
1番目は任意の回数だけログインに失敗するとブロックするようです。
2番目はIotのように画面がない端末でも、他の端末を利用してWiFi認証が可能になります。
3番目は現在は多くのフリースポットではユーザの接続の手間を減らすために意図的に暗号化がされていない箇所が多く存在しますが、WPA3からすべて暗号化されるようになります。
4番目は現在のデフォルト値である128bitから、よりセキュアな192bitに変更されます。
少し前にWPA2の脆弱性 KRACKsが発表されるなど、WPA3によってより安全な無線通信が期待されますが、WPA3はAPとクライアントのどちらも対応している必要があります。どちらもファームウェアのアップデートで対応可能になれば良いですが、専用機材が必要であれば普及には時間がかかると思われます。
BGP+vrf
BGPはaddress-familyを使用することでvrfごとにネイバーを形成することが可能です。今後のプロジェクトではOSPFとBGPを使用する頻度が高くなりそうなので設定例を書き起こしておきます。
AS10000#
ip vrf VRF-1
rd 10001:1
!
ip vrf VRF-2
rd 10002:1
!
no ip domain lookup
ip domain name lab.local
no ip ips deny-action ips-interface
!
interface Loopback1
ip vrf forwarding VRF-1
ip address 1.1.1.1 255.255.255.255
!
interface Loopback2
ip vrf forwarding VRF-2
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip vrf forwarding VRF-1
ip address 10.0.0.1 255.255.255.252
!
interface FastEthernet0/1
ip vrf forwarding VRF-2
ip address 10.10.0.1 255.255.255.252
!
router bgp 10000
no synchronization
bgp log-neighbor-changes
no auto-summary
1
address-family ipv4 vrf VRF-2
neighbor 10.10.0.2 remote-as 10002
neighbor 10.10.0.2 activate
no auto-summary
no synchronization
network 2.2.2.2 mask 255.255.255.255
exit-address-family
!
address-family ipv4 vrf VRF-1
neighbor 10.0.0.2 remote-as 10001
neighbor 10.0.0.2 activate
no auto-summary
no synchronization
network 1.1.1.1 mask 255.255.255.255
exit-address-family
AS10001#
interface Loopback1
ip address 100.0.0.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.0.0.2 255.255.255.252
!
router bgp 10001
no synchronization
bgp log-neighbor-changes
redistribute connected
neighbor 10.0.0.1 remote-as 10000
no auto-summary
AS10002#
interface Loopback1
ip address 100.100.0.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.10.0.2 255.255.255.252
!
router bgp 10002
no synchronization
bgp log-neighbor-changes
redistribute connected
neighbor 10.10.0.1 remote-as 10000
no auto-summary
vrfを使用しているAS10000のshow コマンドが 若干馴染み無いものでした、、、
AS10000#show ip route vrf VRF-1 bgp
100.0.0.0/32 is subnetted, 1 subnets
B 100.0.0.1 [20/0] via 10.0.0.2, 01:02:42
AS10000#show ip route vrf VRF-2 bgp
100.0.0.0/32 is subnetted, 1 subnets
B 100.100.0.1 [20/0] via 10.10.0.2, 00:58:08
AS10000#
show ip bgp summuryの代わりが見つからない、、、
AS10000#show ip bgp all
For address family: IPv4 Unicast
For address family: IPv6 Unicast
For address family: VPNv4 Unicast
BGP table version is 71, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10001:1 (default for vrf VRF-1)
*> 1.1.1.1/32 0.0.0.0 0 32768 i
r> 10.0.0.0/30 10.0.0.2 0 0 10001 ?
*> 100.0.0.1/32 10.0.0.2 0 0 10001 ?
Route Distinguisher: 10002:1 (default for vrf VRF-2)
*> 2.2.2.2/32 0.0.0.0 0 32768 i
r> 10.10.0.0/30 10.10.0.2 0 0 10002 ?
*> 100.100.0.1/32 10.10.0.2 0 0 10002 ?
For address family: IPv4 Multicast
For address family: IPv6 Multicast
For address family: NSAP Unicast
なるほど、どうやらすべてallをつけるんですね。
AS10000#show ip bgp all summury
For address family: VPNv4 Unicast
BGP router identifier 1.1.1.1, local AS number 10000
BGP table version is 71, main routing table version 71
6 network entries using 822 bytes of memory
6 path entries using 408 bytes of memory
4/3 BGP path/bestpath attribute entries using 496 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1774 total bytes of memory
BGP activity 16/10 prefixes, 22/16 paths, scan interval 15 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.2 4 10001 569 571 71 0 0 08:05:14 2
10.10.0.2 4 10002 568 567 71 0 0 08:00:25 2
TLS実装の脆弱性 ROBOTO
2017/12/13にTLS実装の脆弱性が発表されました。この脆弱性はFacebookやPayPalなど有名なサイトも影響対象であり、RSA暗号の解読やトラフィックの暗号解読を目的とした鍵署名を実行できます。本脆弱性はサーバ側の問題のため、クライアント側では回避出来ないのが問題となっています。
本脆弱性の対象方法は以下となります。
各メーカの対応状況は以下となります、対象製品がある場合はメーカに指示に従ってアップデートが必要となります。
Vendor | Status | Date Notified | Date Updated |
---|---|---|---|
Cisco | Affected | 15 Nov 2017 | 12 Dec 2017 |
Citrix | Affected | 15 Nov 2017 | 12 Dec 2017 |
Erlang | Affected | - | 12 Dec 2017 |
F5 Networks, Inc. | Affected | 15 Nov 2017 | 20 Nov 2017 |
Legion of the Bouncy Castle | Affected | 15 Nov 2017 | 12 Dec 2017 |
MatrixSSL | Affected | 15 Nov 2017 | 12 Dec 2017 |
Oracle Corporation | Affected | 15 Nov 2017 | 12 Dec 2017 |
wolfSSL | Affected | 12 Dec 2017 | 12 Dec 2017 |
Botan | Not Affected | 15 Nov 2017 | 20 Nov 2017 |
Dell EMC | Not Affected | 15 Nov 2017 | 29 Nov 2017 |
GnuTLS | Not Affected | 15 Nov 2017 | 13 Dec 2017 |
IAIK Java Group | Not Affected | 15 Nov 2017 | 06 Dec 2017 |
Microsoft Corporation | Not Affected | 15 Nov 2017 | 12 Dec 2017 |
OpenSSL | Not Affected | 15 Nov 2017 | 20 Nov 2017 |
RSA Security LLC | Not Affected | 15 Nov 2017 | 13 Dec 2017 |
最近では暗号化やSSLの問題が発表されることが多い気がします、いたちごっこになるのは仕方ないですが、改めてエンジニアはこの手の問題に注視し続ける必要があると思いました。
メールクライアントの脆弱性 Mailsploit
複数のメールクライアントで「Mailsploit」という脆弱性が発表されました。この脆弱性を利用することで、一部のスパム対策が無効化され、正常なメールとの見分けが困難になります。この攻撃の恐ろしいところは、スパム対策の回避だけでなく、受け取ったメール送信者の表示名を偽装することでユーザをも欺こうとするところです。
この仕組みは、RFC-1342 を使った攻撃で、非ASCII文字をメールヘッダー内で用いるためにQuoted-printableとBase64でエンコードされた文字列を、ほとんどのメールクライアントはデコードする際にサニタイズしません。そのため、ヌルバイト文字や改行文字などをここに混入させることで攻撃が可能になっています。iOSのメールクライアントだとヌルバイト文字を混入させることでそれ以降の文字列は無視されます。つまりそれ以前の文字列のみが表示されるという問題があります。
本問題を回避するためには以下の対策を実施する必要があります。
- 対応済みのメールクライアントを利用する
- 不審なメールはメールヘッダーを確認する
- PGP/GPG などの仕組みを利用する
JPCERT/CCは各メーカの対応状況を記載しています。
メールクライアント | 対象環境 |
Mailsploitの 影響 |
対応状況 |
Apple Mail | iOS, MacOS | 有り | 対応中 |
Mozilla Thunderbird ≤ 52.5.0 SeaMonkey ≤ 2.4.8 |
MacOS, Windows | 有り | 対応しない |
Mail for Windows 10 | Windows | 有り | 対応中 |
Microsoft Outlook 2016 | MacOS, Windows | 有り | 対応中 |
Yahoo! Mail | iOS, Android | 有り | 修正済み(2017/10/19) |
Spark ≤ 1.4.1.392 | MacOS | 有り | 報告済み |
Spark | iOS | 有り | 報告済み |
ProtonMail | iOS, Android | 有り | 修正済み(2017/9/1) |
Polymail | MacOS | 有り | 報告済み |
Airmail ≤ 3.3.3 | MacOS | 有り | 報告済み |
BlueMail ≤ 1.9.2.62 | Android | 有り | 報告済み |
TypeApp | iOS, Android | 有り | 報告済み |
AquaMail | Android | 有り | 報告済み |
Opera Mail | MacOS, Windows | 有り | 対応しない |
Postbox ≤ 5.0.18 | MacOS, Windows | 有り | 報告済み |
Newton | Android, MacOS, Windows |
有り | 対応中 |
Guerrilla Mail | Android | 有り | 報告済み |
Email Exchange + by MailWise | Android | 有り | 報告済み |
AOL Mail | Android | 有り | 報告済み |
TouchMail | Windows | 有り | 報告済み |
Mailbird | Windows | 無し | |
Gmail / Inbox by Gmail | iOS, Android | 無し | |
eM Client | Windows | 無し | |
Claws Mail / Sylpheed | Windows | 無し | |
OE Classic | Windows | 無し |
Webメールクライアント | 対象環境 |
Mailsploitの 影響 |
対応状況 |
Hushmail | Web | 有り | 修正済み(2017/8/27) |
Openmailbox.org | Web | 有り | 修正済み(2017/8/27) |
Open Xchange (Mailbox.org) | Web | 有り | 修正済み(2017/9/25) |
ProtonMail | Web | 有り | 修正済み(2017/9/1) |
Yahoo! Mail (new interface in beta) | Web | 有り | 修正済み(2017/11/12までに) |
Mailfence | Web | 有り | 対応中 |
Microsoft Outlook Web | Web | 無し | |
Microsoft Exchange 2016 | Web | 無し | |
Microsoft Office 365 | Web | 無し | |
Gmail | Web | 無し | |
Fastmail | Web | 無し | |
GMX / Mail.com / 1&1 | Web | 無し |
サポートチケットシステム | 対象環境 |
Mailsploitの 影響 |
対応状況 |
Supportsystem | Web | 有り | 報告済み |
osTicket | Web | 有り | 報告済み |
Intercom | Web | 有り | 修正済み(2017/9/12) |
コミュニティで見つけた候補 | 対象環境 |
Mailsploitの 影響 |
対応状況 |
Vivaldi | Web | 有り | 報告済み |
K-9 Mail | Android | 有り | 報告済み |
MailMate | MacOS | 有り | 修正済み(2017/9/12) |
eM Client | Windows | 無し | |
Tutanota | Web | 無し | |
Sylpheed 3.6.0 | Linux | 有り(※) | |
Jolla Mail | Sailfish OS by JOLLA |
有り(※) | 報告済み |
RainLoop | Web | 有り(※) | 報告済み |
IBM Notes | Web | 有り(※) | |
IBM Verse | Web | 有り(※) | |
IBM Verse | iOS, Android | 有り(※) | |
NINE Email & Calendar | Android | 有り(※) | |
Roundcube | Web | 無し(※) | |
KMail | Linux | 無し(※) |
Cisco VoIP環境作成時の注意点
SkypeやLINEなど、最近ではスマートフォンを利用したVoIPが市民権を得ています。企業でも内線通話が可能なVoIP環境が浸透してきており、通話品質も以前より安定しています。しかしVoIP環境には多くの考慮すべき設計があるため、企業向けVoIP環境作成時の注意点を記載します。
1. チャンネル設計
- 802.11gを使用する場合、1ch 6ch 11chを固定で使用してください。自動は推奨さしません。
- 802.11aを使用する場合、36ch 40ch 44ch 48chを使用してください。DFSの影響を受けるW53 W56は推奨しません。
- 同一エリアだけでなく、上下階の干渉にも注意してください。壁の素材によっては頻繁にすり抜けて干渉します。
- 無線LANはCSMA/CAのため、同一キャリアセンスドメイン内ではAPを増やしても同時通話数は増えないので注意してください。
2. 出力設計
- 端末の受信レベルは周囲の人や端末の持ち方で5~10dbほど変動します。変動を考慮にいれたエリア設計を行い、サーベイによる確認を実施してください。
3. 低レート抑止
- 低レート通信はAirtimeを占有するためなるべく抑止すべきですが、端末によっては低レートを制限することで不安定になる場合があります。利用する端末で動作確認を行い、不要な低レート通信を抑止して下さい。
4. ステルスモード設定
- スマートフォンを使用する場合、ステルスモードを有効化していないとハンドオーバに時間がかかったり、帰属外れを起こす場合があるため、ステルスモードを有効化して下さい。
5. DTIM設定
6. IPアドレス設定
- IPアドレスは余裕を持った設計をしてください、アドレスのリース時間も短縮することを検討して下さい。
- ハンドオーバが想定されるAP間では、同一サブネットに収容されるように設計して下さい。
- iPhoneではDNSサーバのIPアドレスが設定されないとWiFiに帰属しません。DNSのIPアドレスも払い出すか設定するようにして下さい。