HSBC sg account re-activation

　こっちもかよ！という突込みが来そうだがHSBC SGもaccount re-activationをした。

　こちらはinactive警告郵便が届いて、暫くした後、「re-activeキャンペーン」の案内が届いた。
キャンペーン内容は同封の申込書でre-active申請をするとSG$10（だっけなか？）差し上げます、というもの。
　渡りに船とばかりに口座番号記入やサインをして、同封の返信用封筒にて送付。これ、日本から差し出す場合も無料という至りつくせりの扱い。

　で、送付したのも忘れかけた頃、携帯電話に+44の国際電話が。国番号+44は英国である。
　新手のオレオレ詐欺か！？と身構えたところ、HSBC SGであった。何故SGの連絡がUKから？と思ったが、まあ、嘘ではないみたい。

　外出中であったので、後日掛けて貰うことにした。2回目の電話は職場で着信したが「パスポート番号が必要」ということで、再度掛けなおしを。3回目でそれ以外の書類が必要だったりすると厄介だから、「パスポート以外に何か情報が必要か？」と質問したら「セキュリティを配慮して事前には言えない」と、まあ、当たり前の回答が。

　3回目でパスポート番号、住所、メールアドレス等の質問に回答して、re-activate終了、

　Operatorはインド人らしく、ゆっくりとした特徴のある発声だが意外に聞き取りやすい。HKのマシンガントークよりは楽。

Read More

HSBC AU account reactiveにしても定期預金情報が見えない

　HSBC AUでaccount inactiveになってしまったので、re-active処理を依頼した。2年ぶり2回目。
　で、term depositの情報が表示できないので確認したら、以下の回答が。

　満期になるまで、この状態になってしまうとのこと。


Thank you for your reply e-mail.

I can confirmed that your Term Deposit Account re-activation request has
been forward to our relevant team but this account could only be
activate on the maturity date on 16 Mar 2018. For the time being, you
would unable to access this account online.

Read More

HSBC AU account inactive

　話が前後してしまうが、HSBC AUでacount inactiveになってしまった。

　封書で案内が来たのだが、re-activeするには本人確認のために認証済みのパスポートコピーが必要であると。その認証は日本国内であればオーストラリア大使館位しか受け入れられるものがない旨記載されていた。
　以前より「海外投資を楽しむ会」で司法書士によるパスポート認証サービスが紹介されているが、HSBC AU側で受け入れ認証が列記してある中に、それはない。他にはHSBCの職員（口座開設権限を持つ）による認証も可、対象として日本のHSBCも含まれてと記載しているが、HSBC JPは個人向けの対応を一切止めているだろうが！とHSBC AUに文句を言いたくなるほど厳しい制限がされていた。

　で。

　HK旅行時にHSBC HKのプレミアセンターで認証の対応して頂いた。
　パスポートやstatementのコピーを持参、HSBC HKのRMが確認後copyのスタンプを押して担当部署へ送付してくれるとの事。
　

　やれやれと思い、帰国後HSBC AUからのsecure mailを確認したら、「こちらでre-activeの部署に依頼をしておきました」との返信が届いていた。

　結論として、パスポートのコピー送付等は不要。一体HKでの必死の英語対応は何だったんだ。という落ちが。

　ちなみに、re-active処理は少額を口座間で移動させる、というものをHSBC AU側で実施しているようだ。transactionを見ると前述の取引が記載されていた。

Read More

raspberry pi(jessie-lite) pt.5

raspberrypi2がFSMO、1台目の設定


1,2共に同じ

  GNU nano 2.2.6                                File: /etc/krb5.conf

[logging]
        default = FILE:/var/log/krb5libs.log
        kdc = FILE:/var/log/krb5kdc.log
        admin_server = FILE:/var/log/kadmind.log


[libdefaults]
        default_realm = HIGHSPEC.ORG
        dns_lookup_realm = false
        dns_lookup_kdc = true


[realms]
        HIGHSPEC.ORG = {
        kdc = raspberrypi2.highspec.org
        admin_server = raspberrypi2.highspec.org
        }

[domain_realm]
        .highspec.org = HIGHSPEC.ORG
        highspec.org = HIGHSPEC.ORG


2

  GNU nano 2.2.6                             File: /opt/samba/etc/smb.conf

# Global parameters
[global]
        netbios name = RASPBERRYPI2
        realm = HIGHSPEC.ORG
        server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate, dns, smb
        workgroup = HIGHSPEC
        dns forwarder = 192.168.0.1
        dcerpc endpoint servers = epmapper, wkssvc, rpcecho, samr, netlogon, lsarpc, drsuapi, dssetup, unixinfo, browser, eventlog6, backup$
        server role = active directory domain controller
        idmap_ldb:use rfc2307 = yes

[netlogon]
        path = /opt/samba/var/locks/sysvol/highspec.org/scripts
        read only = No

[sysvol]
        path = /opt/samba/var/locks/sysvol
        read only = No


1

  GNU nano 2.2.6                          File: /opt/samba/etc/smb.conf

# Global parameters
[global]
        netbios name = RASPBERRYPI1
        realm = HIGHSPEC.ORG
        workgroup = HIGHSPEC
        server role = active directory domain controller
        dns forwarder = 192.168.0.1

[netlogon]
        path = /opt/samba/var/locks/sysvol/highspec.org/scripts
        read only = No

[sysvol]
        path = /opt/samba/var/locks/sysvol
        read only = No

2

nterface eth0
static ip_address=192.168.0.21/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.20 192.168.0.21

static domain_search=highspec.org
static domain_name=highspec.org

1

interface eth0
static ip_address=192.168.0.20/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.21 192.168.0.20

static domain_search=highspec.org
static domain_name=highspec.org


2

  GNU nano 2.2.6                                  File: /etc/hosts

127.0.0.1       localhost.highspec.org localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

192.168.0.21    raspberrypi2.highspec.org raspberrypi2



1

  GNU nano 2.2.6                              File: /etc/hosts

127.0.0.1       localhost.highspec.org localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

192.168.0.20    raspberrypi1.highspec.org raspberrypi1


1,2共に

  GNU nano 2.2.6                             File: /etc/modules

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

ipv6


# Global parameters
[global]
        dcerpc endpoint servers = epmapper, wkssvc, rpcecho, samr, netlogon, lsarpc, drsuapi, dssetup, unixinfo, browser, eventlog6, backupkey, dnsserver, winreg, srvsvc
        dns forwarder = 192.168.0.1
        netbios name = RASPBERRYPI1
        realm = HIGHSPEC.ORG
        server role = active directory domain controller
        server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate, dns, smb
        workgroup = HIGHSPEC
        idmap_ldb:use rfc2307 = yes

[netlogon]
        path = /opt/samba/var/locks/sysvol/highspec.org/scripts
        read only = No

[sysvol]
        path = /opt/samba/var/locks/sysvol
        read only = No
/opt/samba/etc/smb.conf (END)



# Global parameters
[global]
        dns forwarder = 192.168.0.1
        netbios name = RASPBERRYPI2
        realm = HIGHSPEC.ORG
        server role = active directory domain controller
        workgroup = HIGHSPEC

[netlogon]
        path = /opt/samba/var/locks/sysvol/highspec.org/scripts
        read only = No

[sysvol]
        path = /opt/samba/var/locks/sysvol
        read only = No
(END)

root@raspberrypi2:/opt/samba/etc# pstree
systemd─┬─2*[agetty]
        ├─cron
        ├─dbus-daemon
        ├─dhcpcd
        ├─ntpd
        ├─rsyslogd─┬─{in:imklog}
        │          ├─{in:imuxsock}
        │          └─{rs:main Q:Reg}
        ├─samba─┬─12*[samba]
        │       └─samba───winbindd───winbindd
        ├─sshd───sshd───sshd───bash───su───bash───pstree
        ├─systemd-journal
        ├─systemd-logind
        ├─systemd-udevd
        ├─thd
        └─xinetd


root@raspberrypi1:/opt/samba/etc# pstree
systemd─┬─agetty
        ├─cron
        ├─dbus-daemon
        ├─dhcpcd
        ├─ntpd
        ├─rsyslogd─┬─{in:imklog}
        │          ├─{in:imuxsock}
        │          └─{rs:main Q:Reg}
        ├─samba─┬─samba───smbd─┬─cleanupd
        │       │              ├─lpqd
        │       │              └─smbd-notifyd
        │       ├─10*[samba]
        │       ├─samba───winbindd───winbindd
        │       └─samba───2*[python]
        ├─sshd───sshd───sshd───bash───su───bash───pstree
        ├─systemd-journal
        ├─systemd-logind
        ├─systemd-udevd
        └─thd


root@raspberrypi2:/opt/samba/etc# service samba-ad-dc status
● samba-ad-dc.service - LSB: start Samba daemons for the AD DC
   Loaded: loaded (/etc/init.d/samba-ad-dc)
   Active: active (running) since 土 2017-08-19 18:58:24 JST; 1h 25min ago
  Process: 2672 ExecStop=/etc/init.d/samba-ad-dc stop (code=exited, status=0/SUCCESS)
  Process: 2682 ExecStart=/etc/init.d/samba-ad-dc start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/samba-ad-dc.service
           ├─2691 /opt/samba/sbin/samba -D
           ├─2692 /opt/samba/sbin/samba -D
           ├─2693 /opt/samba/sbin/samba -D
           ├─2694 /opt/samba/sbin/samba -D
           ├─2695 /opt/samba/sbin/samba -D
           ├─2696 /opt/samba/sbin/samba -D
           ├─2697 /opt/samba/sbin/samba -D
           ├─2698 /opt/samba/sbin/samba -D
           ├─2699 /opt/samba/sbin/samba -D
           ├─2700 /opt/samba/sbin/samba -D
           ├─2701 /opt/samba/sbin/samba -D
           ├─2702 /opt/samba/sbin/winbindd -D --option=server role check:inhibit=yes --foreground
           ├─2703 /opt/samba/sbin/samba -D
           ├─2704 /opt/samba/sbin/samba -D
           ├─2705 /opt/samba/sbin/samba -D
           └─2711 /opt/samba/sbin/winbindd -D --option=server role check:inhibit=yes --foreground

 8月 19 19:28:06 raspberrypi2 samba[2796]: [2017/08/19 19:28:06.404163,  0] ../source4/smb_server/smb2/sesssetup.c:242(smb2srv_cl...ructor)
 8月 19 19:28:06 raspberrypi2 samba[2796]: free session[0x55e3eee8]
 8月 19 19:40:12 raspberrypi2 samba[2820]: [2017/08/19 19:40:12.400668,  0] ../source4/smb_server/smb2/sesssetup.c:242(smb2srv_cl...ructor)
 8月 19 19:40:12 raspberrypi2 samba[2820]: free session[0x55e3eee8]
 8月 19 19:52:24 raspberrypi2 samba[2839]: [2017/08/19 19:52:24.391006,  0] ../source4/smb_server/smb2/sesssetup.c:242(smb2srv_cl...ructor)
 8月 19 19:52:24 raspberrypi2 samba[2839]: free session[0x55e3eee8]
 8月 19 20:04:30 raspberrypi2 samba[2892]: [2017/08/19 20:04:30.372169,  0] ../source4/smb_server/smb2/sesssetup.c:242(smb2srv_cl...ructor)
 8月 19 20:04:30 raspberrypi2 samba[2892]: free session[0x55e3eee8]
 8月 19 20:16:42 raspberrypi2 samba[2926]: [2017/08/19 20:16:42.361856,  0] ../source4/smb_server/smb2/sesssetup.c:242(smb2srv_cl...ructor)
 8月 19 20:16:42 raspberrypi2 samba[2926]: free session[0x55e3eee8]
Hint: Some lines were ellipsized, use -l to show in full.


root@raspberrypi1:/opt/samba/etc# service samba-ad-dc status
● samba-ad-dc.service - LSB: start Samba daemons for the AD DC
   Loaded: loaded (/etc/init.d/samba-ad-dc)
   Active: active (running) since 土 2017-08-19 20:10:15 JST; 13min ago
  Process: 3446 ExecStop=/etc/init.d/samba-ad-dc stop (code=exited, status=0/SUCCESS)
  Process: 3456 ExecStart=/etc/init.d/samba-ad-dc start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/samba-ad-dc.service
           ├─3465 /opt/samba/sbin/samba -D
           ├─3466 /opt/samba/sbin/samba -D
           ├─3467 /opt/samba/sbin/samba -D
           ├─3468 /opt/samba/sbin/smbd -D --option=server role check:inhibit=yes --foreground
           ├─3469 /opt/samba/sbin/samba -D
           ├─3470 /opt/samba/sbin/samba -D
           ├─3471 /opt/samba/sbin/samba -D
           ├─3472 /opt/samba/sbin/samba -D
           ├─3473 /opt/samba/sbin/samba -D
           ├─3474 /opt/samba/sbin/samba -D
           ├─3475 /opt/samba/sbin/samba -D
           ├─3476 /opt/samba/sbin/samba -D
           ├─3477 /opt/samba/sbin/samba -D
           ├─3478 /opt/samba/sbin/samba -D
           ├─3479 /opt/samba/sbin/samba -D
           ├─3480 /opt/samba/sbin/winbindd -D --option=server role check:inhibit=yes --foreground
           ├─3484 /opt/samba/sbin/smbd -D --option=server role check:inhibit=yes --foreground
           ├─3486 /opt/samba/sbin/smbd -D --option=server role check:inhibit=yes --foreground
           ├─3489 /opt/samba/sbin/winbindd -D --option=server role check:inhibit=yes --foreground
           └─3490 /opt/samba/sbin/smbd -D --option=server role check:inhibit=yes --foreground

 8月 19 20:10:17 raspberrypi1 samba[3465]: [2017/08/19 20:10:17.076682,  0] ../source4/smbd/server.c:487(binary_smbd_main)
 8月 19 20:10:17 raspberrypi1 samba[3465]: samba: using 'standard' process model
 8月 19 20:10:17 raspberrypi1 samba[3465]: [2017/08/19 20:10:17.168526,  0] ../lib/util/become_daemon.c:124(daemon_ready)
 8月 19 20:10:17 raspberrypi1 samba[3465]: STATUS=daemon 'samba' finished starting up and ready to serve connections
 8月 19 20:10:17 raspberrypi1 winbindd[3480]: [2017/08/19 20:10:17.510942,  0] ../source3/winbindd/winbindd_cache.c:317...cache)
 8月 19 20:10:17 raspberrypi1 winbindd[3480]: initialize_winbindd_cache: clearing cache and re-creating with version number 2
 8月 19 20:10:18 raspberrypi1 winbindd[3480]: [2017/08/19 20:10:18.886633,  0] ../lib/util/become_daemon.c:124(daemon_ready)
 8月 19 20:10:18 raspberrypi1 winbindd[3480]: STATUS=daemon 'winbindd' finished starting up and ready to serve connections
 8月 19 20:10:18 raspberrypi1 smbd[3468]: [2017/08/19 20:10:18.978784,  0] ../lib/util/become_daemon.c:124(daemon_ready)
 8月 19 20:10:18 raspberrypi1 smbd[3468]: STATUS=daemon 'smbd' finished starting up and ready to serve connections
Hint: Some lines were ellipsized, use -l to show in full.



root@raspberrypi2:/opt/samba/etc# samba-tool drs showrepl
Default-First-Site-Name\RASPBERRYPI2
DSA Options: 0x00000001
DSA object GUID: 83d5465a-5868-4d58-8b07-b0608eac17f7
DSA invocationId: 996613d6-1b04-4529-a3a6-d78d3c77e895

==== INBOUND NEIGHBORS ====

DC=ForestDnsZones,DC=highspec,DC=org
Default-First-Site-Name\RASPBERRYPI1 via RPC
DSA object GUID: 813430b0-ba62-41a5-b766-b15f93c60640
Last attempt @ Sat Aug 19 20:23:42 2017 JST was successful
0 consecutive failure(s).
Last success @ Sat Aug 19 20:23:42 2017 JST

DC=DomainDnsZones,DC=highspec,DC=org
Default-First-Site-Name\RASPBERRYPI1 via RPC
DSA object GUID: 813430b0-ba62-41a5-b766-b15f93c60640
Last attempt @ Sat Aug 19 20:23:42 2017 JST was successful
0 consecutive failure(s).
Last success @ Sat Aug 19 20:23:42 2017 JST

DC=highspec,DC=org
Default-First-Site-Name\RASPBERRYPI1 via RPC
DSA object GUID: 813430b0-ba62-41a5-b766-b15f93c60640
Last attempt @ Sat Aug 19 20:23:43 2017 JST was successful
0 consecutive failure(s).
Last success @ Sat Aug 19 20:23:43 2017 JST

CN=Schema,CN=Configuration,DC=highspec,DC=org
Default-First-Site-Name\RASPBERRYPI1 via RPC
DSA object GUID: 813430b0-ba62-41a5-b766-b15f93c60640
Last attempt @ Sat Aug 19 20:23:44 2017 JST was successful
0 consecutive failure(s).
Last success @ Sat Aug 19 20:23:44 2017 JST

CN=Configuration,DC=highspec,DC=org
Default-First-Site-Name\RASPBERRYPI1 via RPC
DSA object GUID: 813430b0-ba62-41a5-b766-b15f93c60640
Last attempt @ Sat Aug 19 20:23:45 2017 JST was successful
0 consecutive failure(s).
Last success @ Sat Aug 19 20:23:45 2017 JST

==== OUTBOUND NEIGHBORS ====

DC=ForestDnsZones,DC=highspec,DC=org
Default-First-Site-Name\RASPBERRYPI1 via RPC
DSA object GUID: 813430b0-ba62-41a5-b766-b15f93c60640
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

DC=DomainDnsZones,DC=highspec,DC=org
Default-First-Site-Name\RASPBERRYPI1 via RPC
DSA object GUID: 813430b0-ba62-41a5-b766-b15f93c60640
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

DC=highspec,DC=org
Default-First-Site-Name\RASPBERRYPI1 via RPC
DSA object GUID: 813430b0-ba62-41a5-b766-b15f93c60640
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

CN=Schema,CN=Configuration,DC=highspec,DC=org
Default-First-Site-Name\RASPBERRYPI1 via RPC
DSA object GUID: 813430b0-ba62-41a5-b766-b15f93c60640
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

CN=Configuration,DC=highspec,DC=org
Default-First-Site-Name\RASPBERRYPI1 via RPC
DSA object GUID: 813430b0-ba62-41a5-b766-b15f93c60640
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

==== KCC CONNECTION OBJECTS ====

Connection --
Connection name: 2e25c83c-96ea-4c5e-ba0c-2252a11f8d46
Enabled        : TRUE
Server DNS name : raspberrypi1.highspec.org
Server DN name  : CN=NTDS Settings,CN=RASPBERRYPI1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=highspec,DC=org
TransportType: RPC
options: 0x00000001
Warning: No NC replicated for Connection!






root@raspberrypi2:/opt/samba/etc# ldbsearch -H /opt/samba/private/sam.ldb '(invocationId=*)' --cross-ncs objectguid

# record 1
dn: CN=NTDS Settings,CN=RASPBERRYPI1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=highspec,DC=org
objectGUID: 813430b0-ba62-41a5-b766-b15f93c60640

# record 2
dn: CN=NTDS Settings,CN=RASPBERRYPI2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=highspec,DC=org
objectGUID: 83d5465a-5868-4d58-8b07-b0608eac17f7

# returned 2 records
# 2 entries
# 0 referrals

Read More

Firstradeでパスワードロックしてしまった

　久々にFirstradeでやらかした。iPhone SEを入手してアプリをダウンロード、さてログイン試行したところ、パスワードを規定回数以上間違ってしまい、パスワードロックの状態になった。

　Firstradeの場合、パスワードリカバリの手段はなく、一定時間経過後のパスワードロック解除も無いので、電話によるロック解除依頼が必要である。

U.S. Toll Free: 1-800-869-8800

Overseas: 1-718-961-6600

　上記へ営業時間内に電話をする。日本からはOverseas宛とするがSkypeであればU.S. Toll Free宛で無料で通話可能。chatやemailでは対応してくれない。

　架電後3を押すとカスタマサービスへ繋がる。User ID、名前、生年月日、自分で設定したSecurity Question 2種類を質問される。自分で設定したSecurity Questionであるが、設定自体を忘れていて、「そんなの設定したかな？」という体たらく。

　質問回答後、直ぐにロック解除され「ロック解除できたか？」と質問されるので、ログイン成功したら一連の手続きは終了。

Read More

情報処理技術者試験 セキュリティスペシャリスト 午後2 簡易解説（自作なのでbugあると思います）

H21.春

問1

設問1
ハッシュ関数は256bitより長いSHA-2へ切替されている。
f.はウエブブラウザでオレオレ証明書を利用する時と同様。インターネット上のCA局へ公開鍵の検証ができないので、ルート証明書を予め導入しておく必要がある。むろん、このルート証明書は安全に届けられたものを導入しないと意味が無い。

設問2
ウイルス定義ファイルは極力最新化したいが、PCを社外へ持ち出す前提ではPCを社内ネットワークへ接続しないと定義ファイルが更新されない。
そのため、インターネットへ接続可能であれば、そちらの経路から定義ファイを取得する。

設問3
PKIの証明書や暗号鍵が流出した場合は容易になりすましが可能となる。
そのため、証明書と暗号鍵を管理外のPCへ導入しないこと、PCの盗難、紛失、他人の利用を防止することが必要となる。

設問4
問題文に記載されているように、公開鍵から秘密鍵を計算できた場合、以下の手順で受信者に改ざんしたデータを送信者を偽っても気付かれずに出来る。

本来のデータを改ざんする
改ざんしたデータのハッシュ値を求める
ハッシュ値に対して計算した秘密鍵で電子署名
送信元を偽って相手に届ける

送信者の公開鍵で電子署名からハッシュ値を取り出す
データからハッシュ値を生成する
比較する
この場合、電子署名は正しく復号されハッシュ値が一致し、受信者からはデータが改ざんされておらず、送信者は公開鍵の発行元と見える。

設問5
(1)設問3と同様にPKIではCA局の秘密鍵があれば、攻撃者の証明書に正当なものであると署名できる。このような偽証明書を作成された場合、CA局の公開鍵で確認しても正しい証明書を判断してしまうので、大変危険である。

(2)CA局の中身を細かく見ていくと、証明書を発行して良いか判断するRA局と実際に発行するIA局に機能が大別される。問題文を見ると「RA局の役割を社員が担う」とあるので、対応する作業工程を選択すれば良い。

(3)公開鍵暗号では利用者も秘密鍵と公開鍵の鍵ペア作成が必要となる。問題文では利用者に鍵ペア作成までさせるのは荷が重いのでCA局で行うとしている。よって、CA局に利用者の秘密鍵が残るので、これを破棄、または安全に管理する必要がある。

設問6
所謂オレオレ証明書では証明書の確認ができない問題。自営CA局のルート証明書を配布して導入すれば良いのだが、社外では予め済ませておくことは難しい。また、証明書を安全に配布する必要もある。


問2


H21.秋

問1


問2

設問1
IP電話はRTPがIP電話のデータ本体、SIPがIP電話の制御のサービスである。通話開始前はSIPによりSIPサーバと制御通信を行い、通話相手と接続後は直接RTPで音声データを交換する。

設問2
動的にポート開放を行えないTネットワークで使用しているFWはIP電話導入に伴い、多数のポートを常時開放する必要がある。そのためFWxと比較してDoS攻撃に使われるポートの通信も通過させてしまう可能性が高くなる。

設問3
開発、製造LANには機密情報が格納されているため、相対的に重要度が低い工場LANからの接続は避けるべきである。そのため開発、製造LANはFWxで工場LANと隔離している。よって、工場LANに位置する箇所へ情報共有サーバを設置するのが望ましい。

設問4
(1)テンペスト攻撃や、ケーブルへのPC接続攻撃の防御。

(2)SPCは機密区画である執務エリアに設置されている。しかしながら、元は製造LANに接続しており、製造サーバへアクセスして製造装置に製造データを投入する役割がある。そして製造サーバには極秘情報が格納されるようになってきている。
表1セキュリティポリシーでは機密区画は「例外的に（製造サーバにある）極秘情報を保有（中略）適切な対処を施す」としている。

SPCは本来極秘区画に設置するのが最適であるが、上述のように機密区画に設置している。
SPCを製造LANに接続すればアクセス制御はできない。
そのため、次善の策として工場LANへ接続しFWxによりアクセス制御する。

設問5

(1)
(2)PEAPはパスワードを利用者が入力する事により、利用者を認証している。EAP-TLSはクライアント証明書を端末が保有しているかで認証しているので、利用端末を認証している。
(3)NPCは共有端末となっているので、誰が何時、どの端末を利用したかが判らない。




H22.春

問1
難易度は低いが、セキュリティ周りの基本技術が全て盛り込まれている。

設問1
(1)SSHでは接続先の証明書を確認することで、接続先が正しい接続先か確認できる。PGP署名の仕組みと同様にフィンガプリントを見るだけでは真正の確認は出来ない。別途、安全な方法で通知されたフィンガプリントと比較することで、正しい接続先かが確認できる。
（そういう意味では「公開鍵が正しい」という解答例は微妙である。「正しい」というのは何が正しいのか明記していないからだ）
(2)リモートメンテナンスのノートPCは接続プロバイダから固定IPアドレス割当を受けることで、Y社サーバ側で接続元IPアドレス制限を行い、より安全な接続元制限が可能となる。

設問2
(1)社内DNSキャッシュサーバは社外上位DNSへ問い合わせを行う。問い合わせ応答時に偽装した応答を送りつけられて、これを正しい応答として受信する可能性がある。自分の問い合わせに対する応答かをデジタル署名により確認するのがDNSSECの考え方になっている。
(2)DNSキャッシュが汚染されると、正しい接続先ではなく汚染された接続先へ接続してしまう。
(3)上記(1)の様にデジタル署名による問い合わせ応答の確認が望ましいが、双方での対応が必要で普及しているとは言い難い。問い合わせの偽装応答は、送信元ポートへ送りつけられる。それであれば問い合わせポートをランダムに変更すれば受信する可能性を減らせる。

設問3
(1)迷惑メール受信拒否には、怪しい送信元から送出されたメールを受け取らないという方法がある。メールエンベロープの送信元ドメインが実在していない、エンベロープと異なるドメインから送信されている、というメールは怪しいので受信拒否をすれば良い。
(2)p.7を確認すると「catalog.y-sha.co.jpのサブドメイン名を使ったメール送信元は無い」と判る。全てのメールは「y-sha.co.jp」が送信元となる。よって、catalog.y-sha.co.jpのドメイン名で送出するメールサーバは無いので、SPF TXTレコードでは+ip4:x.y.z.nの部分は記載せず、-allのみ設定する。
(3)SMTPオープンリレー防止方法の問題。自社社外SMTPサーバは自社宛のメールを受信するのみで、他者宛のメールを「社外から」受信する事はありえない。（社内SMTPサーバから受信して、相手先ドメインのSMTPサーバへ届けるのみ）
(4)spam送信はTO:へ相手先を記載して送信する以外に、FROM:へ届けたい宛先を記載しTO:は適当に記載してエラー返信を使って送信する方法がある。

設問4
(1)(2)(3)表5を確認すると「問い合わせ元:すべて」の非再帰的な問い合わせ（このDNSに対して他社の社外DNS経由ではなく、インターネットへ直接接続したPC等からの問い合わせ）には応答すると判る。次に表6を確認すると、「キャッシュ領域の保持されているY社管理ドメイン名以外のドメイン」問い合わせはキャッシュを用いて応答する（「左に同じ」）とある。社外からの問い合わせは非再帰、再帰を問わず、Y社管理ドメインのものしか応答する必要は無い。


H.22秋

問1
開発問題を含むのでパス。


問2

設問1
午前2の知識で良いが、b.のみ初見。
LDIF(LDAP Data Interchange Format)はLDAP用の書式と思えば良い様子。
http://gihyo.jp/admin/serial/01/ldap/0002


設問2
(1)チャレンジ&レスポンス認証はチャレンジ（=乱数）が毎回変化するため、チャレンジとパスワードから生成されるレスポンスが毎回変化する特徴がある。この特徴のため、通信を盗聴されてレスポンスを認証に再利用されても認証されない。しかし、問題文のようにチャレンジが同一ならば、必要なレスポンスは同一になってしまう。そのため、同一レスポンスで認証できることになってしまう。
個人的には「リプレイ攻撃」の和訳「反射攻撃」は好みではない。「リフレクション攻撃」の和訳も「反射攻撃」であり、違いが分かりにくい。「反復攻撃」が適切と思う。

https://ja.wikipedia.org/wiki/%E5%8F%8D%E5%B0%84%E6%94%BB%E6%92%83

(2)WindowsのActive DirectoryもKerberos認証を利用しており、問題文にあるとおり有効期限切れのチケットが悪用されないように、ドメイン参加サーバはActive Directoryサーバと時刻同期を行う。

設問3
(1)問題文p.17を見ると、クッキーが暗号化されていること、暗号化方式は共通鍵のトリプルDESで、共通鍵を各業務サーバへ配布している事が判る。

(2)A-SSOはcookieを利用したエージェント型のSSOである。SSOサーバがcookieを端末へ発行、端末がcookieをログオン先のサーバへ渡し、ログオン先のサーバが確認する。
処でcookieは「同一ドメイン」のみ有効である。どこの馬の骨とも判らないドメインが発行したcookieはセキュリティ上受け入れないという思想になっているため、問題文の様にSSOサーバとログオン先のサーバが同一ドメイン上に配置される必要がある。
問題文p.20の図9を見るとcookieに相当するものはSAML responseと判る。

設問4
(1) 図1(2)の指摘事項はシステム毎のパスワードルールが同一ではない、というもの。統合認証環境を用意する事でこれを解消する。回答要旨としては以下3点があれば良い。
パスワードルールの決定
IDMでの一元管理
これを各システムへ自動反映

(2)設問3(2)で示されている通り、SAML型SSOでは顧客企業のSSOサーバとA社のサービスとが別ドメイン上にあっても統合可能となる。これにより、SSOサーバ側でのID&パスワード管理とA社のサービスとを分離、運用できる。

設問5
(1)(2)製品サポート部、製品開発部のシステムリプレースは2014年になっているため、2014年までにA-SSOを移行すれば良い。
一方、問題文p.13の表によればイントラ系のサーバマシン群のベンダサポートは2012年終了とあるので、A-SSOは2012年中に移行を済ませる必要がある。


H.23春

問1

設問1
メールサーバ類の基本知識。

設問2
(1)(2)MUA（メールソフト）のFrom行は利用者が任意に設定できる事に留意する。

設問3
(1)mail以外の外部への通信はプロキシ経由となる。FWのログは接続元がプロキシになるので、当該時刻の通信ログを見ても誰のPCかを判別できない。
(2)図2(3)の参照。サーバ、端末両端でウイルス検知が望ましい。

設問4
(1)図4メールソフト機能を参照すると、ドメイン単位の送信先警告が可能とある。さらに表2の警告除外リストを見るとサブドメイン単位でも判別可能と判る。それであれば、社外メンバが登録されている場合は別のサブドメンとして、表2の警告除外リスト外とすればメールソフトで警告が表示される。
(2)ウイルススキャンを社内メールサーバで実行するが、表7の設定ではML用のメールは社内メールサーバを素通りしている。
(3)p.4 [メールシステムの概要]では「社内メールサーバの許可アドレスリストにはPCネットワークのIPアドレスブロックが登録されている」とある。MLサーバはブロック外なので別途追加が必要となる。
(4)汚染されたシステムを連絡に用いる事は適切ではない。
(5)典型的なML管理問題。MLではP社外所属者は社外の所属会社が送信元となり、社外の送信元ホストの情報を持つ。これをMLで社外へ配信した場合、MTAのSPFでは送信元ホストがP社ではないと判断する。そのため、メールエンベロープのFromのみP社のML管理者にして、メールヘッダのFromは元の送信者の物としておくと迷惑メールとして判定されない。またMUAでも元の送信者が送信元として表示される。

設問5
(1)(2)省略


H.23秋

問1


問2

設問1
基本問題。ログ監査、解析を含む問題ではNTPによるサーバ時刻同期有無、同期設定の追加を問われる設問があるので、NTP設定状況を意識すること。

設問2
(1)p.16で「特権ID利用者が管理端末からの各サーバにアクセスする際の通信においても暗号化」とある。
(2)図2 を参照すると製品Rはキーキャプチャ方式のログ取得と判る。入力した文字は全てキャプチャされるが、複数ウインドで作業する場合は、どのウインドで入力しているのかは区別できない。ログオフ操作は明示的に「〜サーバからログオフする」というコマンド書式ではないので、複数ウインドで作業している場合はどのウインドでログオフ操作をしたのか判別できない。
(3)p.22-23で「ログの保存及び分析のために大量のディスク資源を追加する必要がある」とある。
(4)表5にてシステム1,2でログ取得は表単位、3,4はユーザ単位と判る。システム1,2では一般ユーザ（特権操作をしない）の操作も同一表であれば全て記録されてしまう。
(5)R製品の特性から表4(E)(F)(G)(H)のどれが取得可能か考える。
（(F)は設定ファイルの内容なので、理解できるが(G)(H)の様に参照更新をコマンドで文字列として入力しているのか、設定ファイルを用いているのか判らない設問では回答が困難かと思う）

設問3
(1)p.16 「電源設備の定期保守」を参照
（データセンタで停止必要なのは如何なものかと思うが）
(2)(3)計算問題
(4)ログの改竄防止方法
(5)ログに機密情報を含むので、安全にバックアップを運搬、盗難時のリスク低減をする必要がある。

設問4
(1)表1より、管理端末の時刻同期が十分でないこと、ID体系が統一されていない事が判る。端末は各社の管理者が自社要員へ任意にIDを割当てているので、A社でIDを割当てているサーバとの整合性を取るのが難しい。
(2)p.18「運用手順は、手順の概要を記した引継ぎ資料と口頭説明」を参照。
（設問の日本語は今一つ良く判らなかった）
(3)監査と被監査とは分離するという原則。




H.24春

問1

設問1
基本問題

設問2
(1)(2)マルウエア活動の確認方法。当該は特定Webへ直接、プロキシ経由両方で通信を試行する。「活動がなかったこと」の確認なので、通信に失敗するがFWでPCから特定Webへの直接通信有無も確認が必要。
(3)常識問題
（回答例は当たり前なのだが、他のマルウエアで通信が妨害されているというのもあるのでは？）
(4)p.3「出張先で他の従業員のPCを借用して」を参照。

設問3
(1)迷惑メール対策の送信ドメイン認証にSPFを用いる。DR時には外部メールDRサーバがメール送信を行なうのでTXTレコードに予め記述しておく。
(2)
（回答例は判らないのでもないが、それを防止するために図6(1)の運用ではなく設問3(1)を予め実行しておくのでは...）
(3)表2 FW-Iのルール設定を参照。

設問4
(1)(2)DR時はイントラ等への情報参照が殺到するので文字主体の情報提供に努め、帯域を使うコンテンツへのアクセスを絞る。

設問5
(1)DRへの切替、切戻し手順の考え方。DR系を通常系とパッチ等を同期させる必要がある。図4 (5)で修正プログラム適用は常時行なう旨あるので、他に必要な物が何かを探す。DR系へ切り替え中は通常系にパッチ等が適用できないので、これを適用する。




H.24秋

問2

設問1
(1)(2)(3)無線LANの基本。事前共通鍵での認証は自宅等の接続者が変化しない環境では運用が容易だが、企業の様に後日使用を禁止したい場合は運用負荷が高い。

設問2
(1)MACアドレスは容易に変更できる。SSIDをステルス化しても、SSIDを明示的に指定してプローブ要求（動的スキャン）すれば応答有無でSSIDが判る。
（解答例の「SSIDは傍受可能」というのはパッシブスキャンを指している気がする。パッシブスキャンされないためにSSIDのステルス化をしているのだと思うが...）
(2)p.17 (2)会議室利用環境に関する要望より、会議室からWebサイト閲覧が要件と判る。

設問3
(1)表1 のセキュリティ周りの機能要件を参照する。
(2)表2そのまま
（当たり前すぎて良く判らなかった）
(3)PCを使用しないときはスクリーンロックまたはログオフする。

設問4
(1)簡単
(2)p.18で端末認証にクライアント証明書を端末へ導入していると判る。来客者向けに証明書発行と導入を行なうのは運用負荷が高いので、本設問では事前共有鍵（パスワード入力）としている。
(3)簡単




H.25春

問2

設問1
基本問題

設問2
(1)メール経由のウイルス感染はPC単体の対策も必要だが、メールサーバでのウイルススキャンも必要である。外部から内部へのメールスキャンも必要だが、内部から外部、内部間でのウイルス対策にも留意する。
(2)(3)オープンリレー対策

設問3
POP before SMTPで送信許可は接続元IPアドレスでの認証である。DHCP運用ではIPアドレス回収、配賦で同一IPアドレスが他の端末に配賦される可能性がある。

設問4
(1)メール添付書類が暗号化されていた場合、FW、ウイルススキャンでは検知されない。Webメールでhttps通信を利用している場合も同様。
(2)bccではメールヘッダに宛先は記載されない。しかしメールエンベロープにはbccであっても届け先のメールアドレスが記載される。
(3)アーカイヴ対象の特許情報メールは社外から届く事はありえない。よって、外部メールサーバの拒否リスト宛先として登録する。
(4)送信メールアーカイヴと持ち出し牽制。

設問5
(1)タイムスタンプの効用。スタンプ時（以前に）に存在していたこと、改竄された場合判ること。改竄の防止ではない点に留意する。
(2)バックアップデータの安全な運搬と暗号化。H.23秋 設問3と同様。
(3)鍵の脆化問題。計算機性能が向上すると将来的には鍵は破られてしまう。




H.25秋

問1

設問1
(1)ウイルス感染時の対処は、先ずLANケーブルを抜き二次被害を防止する。その後は証拠保全のためPC内のファイル、設定等を変更せず保持する。
(2)図2 ではウイルスPは他のPCへの感染機能を持たないが、他のウイルス感染も想定して先ずはLANケーブルを抜く。

設問2
(1)設問1(1)に同じ
(2)電子メールのreceivedは受信者が一番上、送信者が一番下になる。8行目が最初のReceivedであり、freefree-web-mail.comからhttp経由で送信したというヘッダになっている。
(3)(4)httpで使用するポート番号の知識。webサーバ自体が稼動していない場合はレスポンス無しになる。ア,イ,ウはhttpサーバ自体は稼動しているが、該当するコンテンツが無いといったものなので、稼動自体はしていると判る。

設問3
(1)図10 では14:10に感染、14:11からGETリクエスト送信を開始していると判るので、14:10のタイムスタンプのファイルから確認が必要。
(2)(3)Lさん宛メールはL3 SW経由でメールサーバから送られている。図13 を参照するとL3 SWのMACアドレスとIPアドレスとの対比が書き換えられている。本来、L3 SW MAC & L3 SW IP,のARP組み合わせが正しい。しかし図13ではL3 SW IP & NさんPC MACとなり、L3 SW IPアドレス宛通信がNさんPCのMACアドレスへ解決され、NさんPCへ盗聴されていたと推測できる。本来はL2 SWであればMACアドレス学習により、LさんPC-L3 SWとNさんPC-L3 SW間の通信は隔離される。
(4)上記(2)の攻撃はL3 SWで隔離された他のセグメントには波及しない。192.168.1.0/24のセグメントに対して有効な攻撃となる。

設問4
(1)最新パッチ適用は必要だが業務アプリの検証も忘れない。
(2)表3 項番1を参照。「現状は利用してない」「現状は無効」の記述は設問で「有効にする」の解答をする事が多い。
(3)マルウエアPのみであれば、特定のC&Cサーバをブラックリスト登録で防御できるが、p.13で「マルウエアPを含め、多くのマルウエアとC&Cサーバ」とあるので、プロキシサーバの利用者認証の方が防御範囲が広く出来る。
(4)汚染されているのはNさんPCである。LさんPCでFWにより通信を制御した場合、LさんPCの業務に影響が出る。


問2

設問1
(1)問題文の要件を読み取る。スマートフォンからのアクセスは「社内Webサーバへのアクセス禁止」「Webメールのみ利用可能」とある。これに準じないサービス利用を可能にする通信があるかを確認する。
(2)上記の要件を満たすために、案2ではモバイルPCとスマートフォンの接続先DMZを分けて、各DMZから社内システムへ接続可能なものをそれぞれ異なったものにする。
(3)また案1で、接続IDを1個人がモバイルPC、スマートフォンで共用している。そのため、スマートフォン紛失時に接続IDを無効化すると、モバイルPC接続も不可になってしまう。
(4)表5の対策でC15以外は、D社自身のネットワークや運用対策、製品EのMDMによるスマートフォン管理機能で充足している。

設問2
(1)製品Eは管理用の通信をinternet上のサーバと行う。対して携帯電話事業者のサービスはキャリア通信網を利用している。そのため、WiFi接続時に製品Eは携帯電話の制御が出来るが、携帯電話事業者のサービスでは制御できない。
(2)android,iPhoneではGoogleやiCloudの自動連携機能があり、クラウド上へデータを定期転送、データ保護の仕組みがある。

設問3
BYOD（Bring Your Own Device、個人端末の業務使用）運用では、業務都合でデータ消去されるリスクがある。



H.26春

問2

設問1
(1)(2)ウイルス感染時の証拠保全の基本。
(3)???

設問2
(1)(2)メンテナンス用の接続はインターネット経由なので暗号化を原則、接続元を限定する。

設問3
(1)EV-SSL証明書は発行元組織の厳密な審査が行われ、証明書の発行元だけでなく、Webサイトの運営者情報もブラウザ上で明確に判るようになっている。今回の様にプロキシでSSL復号と再暗号化を行なうとクライアント側から見える証明書はプロキシサーバのものになってしまい、EV-SSL証明書ではなく通常のSSL証明書になる。
(2)表7 「ユーザ定義リスト1」は表6を参照すると項番1の「事務サーバ,設計管理サーバ,CAD/CAMシステム」に対して適用するものである。PCのhttpsアクセスに適用するものではないので、U銀行を含めてはいけない。

設問4
p.22 [ログの取得及び管理方法の見直し」で「攻撃者が用意したサーバへのウイルスからの通信」とあるので、Webサーバが外部へ通信するものを全部拒否する。Webサーバは他の社内システムと連携してデータ授受等はしていないため、一律拒否でよい。

設問5
(1)特定の相手としかデータ交換を許可したくないという要求があれば、クライアント証明書を使用する。
(2)
（正直、当たり前だ！という問題だが...）
(3)禁止できないとあるので、プロキシ経由通信とメール通信とを検討する。D社環境はDMZ上のメールサーバは「内部メールサーバ」であり、「外部メールサーバ」はF社に置かれている。図1には明記していないので解答時には留意すること。
(4)



H.26秋





H.27春

問1

設問1
(1)(2)DNSへのCP攻撃、オープンリゾルバを用いたreflection攻撃の基礎知識。
(3)(4)オープンリレーとその対策。メールの厳密な宛先はメールヘッダではなく、メールエンベロープ（封筒）に記載されたものを基準に判断が必要。

設問2
spam送信はTO:へ相手先を記載して送信する以外に、FROM:へ届けたい宛先を記載しTO:は適当に記載してエラー返信を使って送信する方法がある。

設問3
検疫ネットワークでは必要最小限の通信先を許可して、社内ネットワーク等から隔離する。通信先は最新パッチ、パターンファイル入手先とする。

設問4
(1)設問3に同じ
(2)図5の中継サーバへの最終接続先サーバの指定方法はサブドメイン名を用いている。解答例では部分一致としているが、ドメイン単位（example.net）でのブラックリストでも良い。（ブラックリストの登録書式による）
(3)kouhou@n-sha.co.jp宛に攻撃メールが届いているので、前述のメールを受け取る広報グループへ確認依頼をする。
（一般的には同一ドメイン宛に大量に攻撃メールを送りつけるので、対象は社内全部が良いと思うが）
(4)運用上、黒判定だけでなく、灰色判定も管理者へ通知した方が安全である。

設問5
スキャンやパターンファイルが更新されていない場合、管理者権限で強制適用する。

設問6
(1)(2)問い合わせフォームを用いたスパム、攻撃メールの送信方法。
（そもそもHTMLメール対応やURLをそのまま開くメーラが良くないのだが）


問2

設問1
特に機器制御用PCは互換性等の問題でセキュリティパッチ、アンチウイルスソフトが導入されていない、製造元での動作保証をしない場合が多い。なお、本問では製造用PC、製造統合管理サーバ、製造装置の3種類への感染が考えられるが、本文中に対策済、未対策の記述があるので、留意すること。反射的に製造PCが未対策と考えないこと。

設問2
(1)(2)端末セキュリティの原則。脆弱性対策パッチは遅滞なく適用するが、事前のシステム動作確認が必須である。

設問3
（私見だがg.は愚問）

設問4
(1)インターネット経由での接続元制限の基本知識。グローバルIPアドレスは変化する可能性がある。NAT,Proxy経由で接続しているPC群は個別PCを識別できない。
(2)
(3)
(4)クライアント証明書は端末単位（機器単位）に発行する。当該端末の盗難、廃棄時にはクライアント証明書のシリアル番号をCRLへ登録すれば無効化できる。




H.27秋

問1

設問1
Thin Clientの基本知識。従来クライアントPC上で動作していた全てのアプリケーションはTCサーバ上（例えばXenAPP等）で動作することを意識して通信内容を考えれば良い。

設問2
(1)添付ファイルが暗号化されているとウイルススキャンは効かない。SSL通信も同様。
(2)類似の問題がDHCP + POP before SMTPのメール送信時認証にも存在する。
(3)(4)(5)設問1に同じ

設問3
(1)(2)設問1に同じ

設問4
(1)計算問題
(2)TC系サーバ以外全部が同等のセキュリティ基準を満たすために必要となる。

設問5
監査と被監査部門は分離独立していなければならないという原則。


問2




H.28春

問2

設問1
(1)(2)httpサーバが接続してきたブラウザ種別を認識するためにuser-agentという概念がある。
（最近は少ないですが、IEとNetscapeとで挙動が大きく違うためUA判断でHTMLを変えるという時代もありました...）

設問2
午前2でも出てこない単語なので記憶する

設問3
(1)午前2でも出てこない単語なので記憶する。データ流出は分割して送信するという方法も忘れずに。
(2)簡単

設問4
他には「棚卸し」等も解答例として考えられる。

設問5
(1)ハードディスク暗号化の基礎知識。HDD透過型暗号化は、OSより下の階層でHDDを暗号化している。そのため上位層（この例ではOS）からデータは平文として扱える。
(2)クライアントPCのシステムリカバリに相当する操作となる。
(3)VDI端末へスクリーンキャプチャ、キーロガーによる攻撃があった場合は情報窃取が可能である。
(4)Thin Client,VDIではクライアントPC上で動作していた全てのアプリケーションはVDIサーバ（XenAPP等）で実行する。そのためアプリケーションのアクセス元はVDIサーバになる。

Read More

情報処理技術者試験 セキュリティスペシャリスト 午後1 簡易解説（自作なのでbugあると思います）

H.21春

問1

設問1
図3では、DNS（p1.p2.p3.p4）からインターネット上（r1.r2.r3.r4)へのDNSクエリレスポンスが存在している。(V)で判るが、インターネット側から、インターネット上の(s1.s2.s3.s4)の名前解決問い合わせ受ける必要は無いので、これはDNS reflection攻撃と判る。
なお(IV)はA社のWebサーバの名前解決なので、正当なものである。(III)はA社のサブドメイン問い合わせに失敗しているか、A社以外の名前解決の問い合わせなのでやや怪しい。
修正箇所はインターネット側からの名前解決を受けない事であるが、Webサーバ,Mailサーバの名前解決は必要なので「A社ドメイン以外の」を回答文に入れる。

設問2
(1)(2)図4では感染端末(a1.a2.a3.a4)からインターネット上へMXレコードの問い合わせが発生している。MXレコードの問い合わせを社内端末が発する必要は無い。（メールサーバのみが行う）
(VII)はIPアドレス直接指定で外部との通信を行なう事は考えずらい。一般的には名前解決を用いる。またTCP/IPの3wayコネクション(SYN,SYN+ACK,ACK)の最初のSYNのみが発生して、それ以降の通信が発生していない。

設問3
(2)hostsファイルでウイルスパターンファイル配付ソフトのIPアドレスを127.0.0.1のループバック（自分自身）アドレスに書き換えられている。これにより、パターンファイル配付ソフト宛の通信先が自分自身になってしまい、パターンファイル更新が出来なくなる。結果、定期的に発生するパターンファイル更新の通信パケットが観測されなくなっている。


問2

設問1
図3にてWebサーバでOSのコマンドを実行できる脆弱性が指摘されている。この脆弱性があれば、DBへのアクセス、システムの停止は容易に行なえる。
Exploitコード（脆弱性実証コード）も公開されているので、試行も容易であり、攻撃は直ぐに始まると想定する必要がある。

設問2
(1)(2)
（HTML手打ちの時代は随分前なので、送信フィールドのHTMLがfrom,inputというのは忘却の彼方であった。getでデータを送信する問題点は富士通の以下のsiteが初心者向けに詳しく書いている。
http://www.fujitsu.com/jp/solutions/infrastructure/dynamic-infrastructure/sdas/technology/web-apl/01-http-protocol/
）
(3)X-Senderの文字列が含まれるgetが送られてきたら攻撃とIPSに判断させる
(4)そもそもhttpdやWebアプリを特権ユーザで稼動させてはいけない。実行できる事が限定されたユーザで稼動させるべき。
（昔のcgiの教科書とかは結構うるさく書いていましたね...）

設問3
(1)(2)負荷分散装置を使っていると有難い事は、分散先のサーバ群から保守対象を切り離して順次メンテナンス可能な事である。これにより利用者から見て無停止でメンテナンスができる。重要システムへいきなりパッチ適用はしないのが常識だが、試験問題では明示しない限り検証作業はしない事になっている点に留意する。


問3

設問1
(1)ログイン認証はcookieの文字列で行なっている。それも暗号化していない会員番号と前回のログイン年月日を使っている。これであれば、文字列を変えて順次試行すれば容易に突破可能である。
(2)図3はHTMLを出力するプログラムであるが、24行目はhttp、50行目はhhtpsで画像を出力している。この実装をすると、HTML中の一部要素がhttpになるためブラウザからは安全な接続と認識されない。
(3)プログラミング問題なのでパス

設問2
(1)透過型暗号化は、DBの中のデータのみを暗号化して、外部からは平文で扱える（透過的）というものである。よって、DBまでの通信経路、DBの暗号化機構直前までは一切暗号化されていない。DBの実データ部分が暗号化されているので、記録媒体の持ち出しには有効である。
(2)定番のハッシュ化とソルト付加の設問。


問4

設問1
(1)金融商品取引法は証券、銀行の店頭での商品購入等へ関連したものと思われがちだが、「上場企業」であればその企業の証券や債権格付けに影響する企業財務が正確である事も範囲に含んでいる。
(2)(3)IDの使いまわしは個人特定に支障がある。良く問われる設問。同じ特権IDでも個人の役割にってサーバAのみ付与、サーバABに付与と役割毎に制御する必要がある。
（個人的には設問の様な特権IDを作るというより、個人毎にIDを割当、IDへ必要な権限付与、という説明や思想が良いと思われる）

設問2
(1)unixの基本知識
(2)セキュリティの基本知識
(3)設問1(3)に同じ
(4)攻撃方法の基本知識
(5)H.24秋 問2に類似問題あり。￥
(6)設問1(1)(3)に同じ。完全な（改竄されてない）財務データを上場企業は公表する事が求められている。




H.21秋

問1

設問1
常識問題

設問2
(1)5.9(4)は②のリモートデータ消去機能を使える様に思えるが、本設問時に②は実施していないので、情報システム部に報告されても何も出来ない。
(2)携帯電話紛失時はメール送受信データだけではなく、電話帳周りの連絡先情報も流出する可能性がある。連絡先の確認はcc:でも良さそうだが、電話帳に登録しただけで送受信履歴がない相手の場合は流出の判定が難しい（電話帳を全部記憶している必要がある）ため回答例の様に、電話帳のバックアップが適切。

設問3
設問2(1)を参照

設問4
(1)(2)携帯電話にSSLクライアント証明書を導入して許可された端末か認証する。認証はA社DC設置のY社ポータルサーバが行う。ポータルサーバはLDAPへ問い合わせをする。この時、端末認証に確実に使えるのはSSLクライアント証明書のコモンネームである。表にも「電子証明書のコモンネームにはSIMカードを一意に識別できる」とある。Y社ポータルへアクセス後はメールサーバへアクセスするが、その際のID,パスワードはポータルサーバで連携し自動的に処理されるため、携帯電話自体のアクセスセキュリティが施されていないとメールへ容易にアクセス可能となってしまう。
(3)携帯電話-ポータル間はメール系のプロトコル（POP3,IMAP4）は使わず、ポータルがメールクライアントとしてA社DC設置のメールサーバへアクセスしている。そのため、メールクライアント-メールサーバ間はIMAP4で通信している。
(4)設問4は社内宛に届いたメールは携帯電話自身のメール機能を使わず、謂わばwebメールの形式でポータル経由で閲覧をするアーキテクチャである。携帯電話自身のメール機能は削除出来ないので、回答例の様に携帯電話のキャリアメールアドレスへメールを転送されてしまうと、端末紛失時の情報流出リスクが発生する。


問2
プログラミングを含むのでパス。

問3


問4

設問2
[管理状況の把握](2)を参照する。

設問3
ハードディスク暗号化はハードディスクが取り外された場合、単体で読み出し不可の特徴がある。しかし、OS起動後はOSや利用者からは暗号化を意識せず、平文として（透過的に）ファイルへアクセスできる。そのためOS起動後で操作を受け付ける状態で盗難に合うとファイル読み出しを防げない。

設問4
図1(ii)の利用形態からUSBメモリ経由で顧客に情報を渡す事を考慮する必要がある。この場合、顧客PCへ復号ソフトウエアを導入してもらうのは困難と思われるのでQ製品の自己復号型が望ましい。
（但し、これは自己実行のexe形式ファイルを渡した相手に実行させる事になる。これに慣れるとexeを警戒無く実行する癖がついてしまい、セキュリティ教育上著しく望ましくない。）

設問5
(1)これ意味不明。P製品は鍵メモリとNPCとがセット使用が必須なので、図2(i)の様な「同時に持ち歩く必要がなく」という前提が良く判りません。いろいろ見てみると、P製品は起動時には鍵メモリが必須なので安全、対してQ製品はTPMへ起動時パスワードを投入するので、パスワードが簡単だったりすると相対的に危険、という判断なのかと思います。
使用しないけど、NPCを運搬している、という前提なのか？


(2)USB型鍵メモリよりTPMの方が攻撃に強い点に留意する。TPMはパスワードを間違えると次回パスワード入力まで一定期間時間を空けることが必要なので、パスワード総当たり攻撃には強い、

(3)R製品はUSBメモリ暗号化が出来ないので除外。P製品、Q製品は前述(2)からQを選択。（？）





H.22春

問1
プログラミングを含むのでパス


問2

設問1
(1)図1を確認すると、TPMで秘密鍵、公開鍵を作成し、これでファイルを暗号化する共通鍵をさらに暗号化している。
よって、b.は公開鍵で暗号化されたものを復号するものなので秘密鍵となる。

設問2

(1)(2)図3では、営業所サーバへ個人データをコピーする際に復号され平文でテープへ格納される点に注目する。現在は媒体上のデータ暗号化も普及しているが、本設問では使用していないのでテープ紛失時は容易に読み取られてしまう。

設問3
(1)(2)ファイル暗号化をしている表(a)(c) はPC上のHDDは暗号化されているが、営業所サーバ上へ平文でバックアップが取られている。一方(b)はS/MIMEであり、PC上のHDD、営業所サーバ両方共に暗号化されている。S/MIMEの秘密鍵がPCのTPMに格納されているので(b)はTPM交換後復号出来なくなる。

(3)TPMの仕様上、秘密鍵は読み出しが出来ない。よって、TPMで鍵生成して秘密鍵をバックアップという手順が取れない。
鍵ペアをTPM外で作成し、秘密鍵のみをTPMに保存する必要がある、

問3

設問1
(1) a.は「S/MIME証明書」が最適で一般的な「ディジタル証明書」「公開鍵証明書」は次点かも？
(2)所謂「オレオレ証明書」の諸問題。自己証明書では発行体が本当に正しいのか誰も証明してくれない。

(3)PGPフィンガープリントはwebやメールに記載しても良いのだが、それが改竄されていないのは100%確定出来ない。類似事例として、Webからのダウンロード時にハッシュ値が記載されている場合も多いが、ダウンロード対象ファイルとWebコンテンツの両方を改竄されてしまうと無力である。よって、ネットワークを使わない他の方法でフィンガープリントを入手すれば、より確実である。

(4)典型的なブルートフォース攻撃とその対策方法を回答すればよい。


設問2
(1)実在する求人企業の社員を名乗って申し込みされた場合を想定する。実在する企業と異なる住所、メールアドレスで申し込まれる可能性を考慮して、登記簿の住所、「責任者宛」へ郵送とすれば前述の様な不正申込を防げる。

(2)複数のIDとパスワードとの組み合わせを比較するとパスワード生成のルールが判る。設問では3名の初期パスワードを見た、とあるので、これに該当する。（他人の初期パスワードを見る責任者も如何なものかと思うが）

(3)(4) (3)の様にパスワード再設定前に他社に盗聴されても、さらに1種類の鍵（初期パスワード）が無いと再設定が出来ないシステムとする。（但し、この様な事象では初期パスワードも失念していることが多々あるので、運用は楽にならない）


問4

設問1
設問に回答が書いてある珍しい例？

設問2
TCP/IP通信の特性と図4の「L2SWにはモニタポートは付いてない」の記述に留意する。
TCP/IP通信にはMACアドレスとIPアドレスとが必要となる。同一セグメントのPCへ感染するには、各PCのMACアドレス入手が必要となりブロードキャスト通信でARPを発行する。モニタポート（ミラーリングポート）であればブロードキャスト以外の通信も見えるが、通常のポートはブロードキャスト通信しか見えない。本設問ではa.にTCPパケットと書きたくなるが、ブロードキャスト通信を観察している点に留意して回答する。

設問3
Xウイルスを削除しても、OSセキュリティホールは残存しているので再感染の可能性がある。

設問4
(1)所謂「検疫ネットワーク」の簡易版を作ってパッチ適用を行なう。
(2)図3 感染方法2を見ると、脆弱性を突くのではなく1000種類の用意済パスワードを用いるとあるので、複雑なパスワードへ変更すれば感染を防止できる。








H.22秋

問1

設問2
(1)指摘1の（ウ）は「Webサーバ自身」ではなく、「Webサーバにおける、【ディレクトリに対する】アクセス制御」となっている。案1はWebサーバが各社専用Webサーバ、案2は共用Webサーバとなっている。そのため、共用Webサーバ内のディレクトリに対して各社別の権限を付与する必要がある。

(2)当たり前過ぎるが、「他ベンダの専用ディレクトリ」「保守担当者」の組み合わせ。もしくは「各SIベンダの専用ディレクトリ」「他のSIベンダの保守担当者」。模範解答は後者。

設問3
(1)監査問題。ログと作業指示書とを突合する。本設問では「Webサーバの通信ログ」（表より）「作業報告書」（図3より）とを突合する。
(2)図3で「運用管理者が1IDを共有」「SIベンダ毎に1ID」の記述がある。一方作業報告書では個人名レベルの粒度で管理をしている。あるべき論から言っても、利用者IDはグループで共有せず、個人毎に設定するのが望ましい。

(3)日時、利用者ID、ファイル名が回答例であるが、利用者IDやパスワードは盗難可能なので「通信元IPアドレス」も追加するのが望ましいだろう。監査視点では回答例で良い。

設問4
（ア）はSSL証明書をPCに入れるため、「ソフトウエア等を勝手に導入してはいけない」というポリシーがあった場合抵触する。（イ）はWebアクセスやWebからのダウンロードを許可しないポリシーがあった場合抵触する。これらはセキュリティポリシーでも良く見かけるので、案2の運用が取れるかを各SIベンダへ確認する必要がある。


問2

設問1
(1)(2)(3)頭の体操

設問2
(1)(2)(3)第一案は契約終了後はアカウントが100日後に自動的に無効になるので、それを削除すればよいだろう、というもの。第二案は契約終了日を契約書基づき入力しておき、それを基準に削除する、というもの。p.11で契約が自動継続されないこと、厳格に管理されていることを鑑みると、案2が適切である。また、厳密に管理する契約管理部門からの通知を基にUIDを削除すれば確実である。

設問3
[従業員のUID管理]（エ）を参照のこと。典型的なソーシャル・エンジニアリング（クラッキング）の手法。

設問4
仮パスワードの送付先を本人に確実に、かつ他者に間違って届かない手法を考えれば良い。


問3
webプログラミングを含むのでパス


問4

設問1
a.では「検疫システム」の文字に注目する。所謂、社内LAN接続前にOSセキュリティパッチ、ウイルスパターンファイルが最新かを検疫システムで確認後、接続するというもの。

設問2
(2)p.20に「インターネットへ向けたFTPアクセスは、プロキシサーバに限定」の記述がある。また、FTP専用PC以外からはFTPを禁止したいとあるので、PCを固定IPアドレスとして端末識別するか、プロキシサーバで利用者認証をすれば良い。

設問3
(2)感染は「不正プログラム送り込みサイトへリダイレクトされる」「不正プログラムをダウンロードさせられる」「感染したPCでFTPアクセスしているWebを不正プログラム送り込みサイトに書き換えさせられる」が連鎖して起きる。当初は「送り込みサイト」がブラックリストに登録されて気付くが、これが書き換えられた元正規サイトであった場合はURLフィルタで気付かなくなってしまう。





H.23春

問1
プログラミングを含むのでパス


問2
簡単


問3

設問1
(1)定番問題。PC,HDDの盗難には暗号化と覚える。
(2)リスク回避（リスクテイクを諦める。他の方法を取る）、低減（リスク対策する）の使い分け。自社レビューでも「低減」の意味で「回避」を使う人が多いから要注意。

設問2
自社の持ち出しPC規則に同じ。

設問3
(1)PC盗難時はPCの全データ、PCからアクセス可能な社内システムにアクセスされると考える。本問は所謂モバイル環境の有無に触れられていないので、前者のみと回答が必要と思われる。
(2)公開している期間を必要最小限に、という原則。良くあるzip復号パスワード入力は短時間でパスワード総当りにより簡単にクラックされてしまうので、気休め程度にしかならない。
(3)送付内容の複数回チェック。

設問4
簡単過ぎて逆に不安なのだが、表3 （イ）と「E社における左記対策の実施状況」の交差部分を参照のこと。


問4
難易度は低いが、N社、R社の役割を理解しておかないと回答に迷う問題である。

設問1
(4)
FWでWebサーバからインターネットへftp,sftp,scpを拒否設定。定期的にFWのドロップ（拒否）がログにあるかを確認するという趣旨。N社はコンテンツ作成だけなので、httpサーバログを見たりはしないから、前述の拒否設定をしても管理上問題が無い。

(5)(6)
図2でスクリプトファイルに対してRWX権限付与をしている点に注目する。これであれば、会員データ出力スクリプトをアップロードし、実行すれば会員データを閲覧できる。
アカウントCNT-MGRはコンテンツ作成N社が使用する。RアプリのスクリプトはR社が開発するので、R社にスクリプト周りの権限は本来不要である。よってCNT-MGRからスクリプトRWX権限を削除して構わない。

設問2
IDを固定してパスワードを順次試行するのを「ブルートフォース攻撃」と称する。表1のV-1が相当する。
一方、IDを固定せずログイン試行するのを「リバースブルートフォース攻撃」と称する。他のwebサイトより盗んだID,パスワードを順次試行するのはこれに相当する。同一IPアドレスからIDを変化させて攻撃するので、同一IDアドレスでログイン失敗が連続するのを検知、遮断する対策を取る。





H.23秋

問1


問2

設問1
暗号化とハッシュ化とが回答選択肢に混在している。ハッシュ化を選択する。

設問2
プログラムロジック問題。落ち着いて考えれば解ける。

設問3
(1)(2)図1（オ）でサスペンドは利用責任者からの申請で解除するとある。しかしながら図4ではサスペンドに対する判定がないため、サスペンドでもパスワード初期化が可能である。

設問4,5
H.22春 問2と類似部分あり。


問3

設問1
(1)(2)https通信ではhttpリクエスト全体が暗号化されて通信する。p.14の「インターネットサイト向けに送信された内容」をログにすることは出来なくなる。そのため、ウイルスチェックも送受信内容が復号できないので不可能となる。

設問2
(1)(2)中間者攻撃（端末-中間攻撃者（代理応答）-Webサーバ）の設問。中間者攻撃を受けると、httpsの証明書は中間攻撃者のものになる。ブラウザ上でhttps通信となっていても、証明書が「Webサーバ」のものかを確認する必要がある。また、証明書が自己証明書でないこと（オレオレ証明書でもOKを押させる事を推奨するWebサイトが多いので、そういうものだ、と思っている人も多い）、信頼に足りる証明局から発行されている事も確認が必要。（建前としてCA局は信頼に値する前提だが、怪しい本人確認で証明書を発行してしまうCA局があるとか、無いとか）

設問3
(1)(2)(3)設問2と同様。図4ではLプロキシが設問2の中間者と同様の動きをするので、LプロキシのSSL証明書2のコモンネームは証明書1と同一としないと、Webブラウザで証明書を確認した時に、正しく「webサーバ」に接続出来ているか判らない。


問4




H.24春
問1
Webアプリケーション。セキュアプログラミング、セッション維持（パス）

問2

設問1
(1)(2)(3)どのアクセスが、どの様な攻撃かを判断する問題。
攻撃1は「会員ID」「パスワード」両方の全員分を窃取している部分に留意する。
ip毎の攻撃内容は以下の通り。

ipB 攻撃4 cust51に対して複数のパスワードを試行
ipD SQLインジェクション。但しunion select対象はpwdのみ
ipE リバースブルートフォース攻撃。異なるIDに対して、パスワード'password'でのログイン試行
ipF SQLインジェクション。但しunion select対象はcust_idのみ
ipG ディレクトリトラバーサル攻撃。'../ls'で上位ディレクトリのリスト出力を試行
ipJ 攻撃2 コンテンツの一部を'www.evil.example.com'へのリンクに書き換えて誘導する。
ipH 攻撃1 union selectでcust_id,pwd両方を対象としている。
ipI 攻撃3 コンテンツの一部をjavascriptによりdocument.writeのスクリプト実行に書き換えている。

設問2
(1)(2)暗号化の基礎知識を問うもの。g.は平文（本問ではパスワードの文字列）を入れてどのような暗号文が出力されるかを確認する。そしてアルゴリズムを推測する方法である。
よって、このシステムに格納された暗号化済みパスワードは平文が攻撃者に判ってしまったと考えて行動する必要がある。p.10の②はそれを踏まえて、何をするべきかを問うもの。パスワードを使いまわしている場合、他のサイトのパスワードが判ってしまったということなので、他のサイトのパスワードを変更する必要がある。

設問3
(1)回答例は「プラグイン」である。「レンダラー」も良さそうだが設問で「ブラウザ本体への攻撃は実施されない」とあるので、「プラグイン」が正しい。
(2)設問1を参照。


問3
案1, 案2のサーバログ取得方法を図にすると理解し易い。

設問1
(1)(2)ログをハッシュ関数に入れてハッシュ値を取得。ログが改竄された後、再度ハッシュ値を取得すると元のハッシュ値と異なるため改竄が判明する。SHA-1はセキュリティ脆弱性が発見されているので、SHA-256（SHA-2に含まれる）の使用が望ましい。

設問2
各モジュールの配置と通信とを問う。
(1)エージェントモジュールは無害で他システムへ影響しない前提であるが、実環境で検証後、運用が必要。
(2)保守担当者（Z社）は中継サーバ経由で保険サーバへアクセスに変更する。そのため、保険サーバの通信可否を見直す必要がある。
設問3
(1)(2)保険サーバからログサーバへの通信を妨害にするには、保険サーバのネットワークセグメントを変更、またエージェントモジュール自体を停止してしまえば良い。通信不可時には保険サーバのローカルディスクにログを一時保管するが、このログを削除してしまえば、ログ記録と、ログ内容から検出するファイル操作の警告もなされない事になる。
(3)表1 一番下の「機密ファイルへアクセスした場合（中略）メールアドレス宛に電子メールを送信」機能を用いる。ネットワーク設定「ファイル｣、エージェントモジュールの設定「ファイル」等への変更を監視すると実現できる。（筈、ちょっと弱い気がするが...）

設問4
(1)当たり前過ぎて気付かなかった....。
(2)表1 案2(d)に「中継サーバの利用IDごとに（後略）」の記述があるので、この機能を利用する。


問4

設問1
所謂フィッシングメール。②は正直、偽装してもウイルス対策ソフトでウイルスのコード本体のパターンマッチングをして検出されてしまう気もするが....。

設問2
図4、各プログラムが使用するTCPポートをパケットキャプチャで絞っていく。

設問3
HDDを取り外して、当該HDDで起動しなければウイルスは活動できない。このHDDを正常なPCへ接続してファイルを取り出す。（ファイルシステムにアクセスしただけでウイルス感染しない、という前提になっていると思われる。そういうウイルスはあるんですかね？）
設問4
どの時点の対策を問うのか、今一つ判りづらいが...。フィッシングメールかを送信者へ確認する。
それ以外には、以下を設定、操作手順とする。
1)ファイル拡張子を表示
2)拡張子がexeなどの実行形式のものは開かない
3)文書形式のものはマクロ実行を禁止後開く





H.24秋

問1
Webアプリ&マッシュアップサービス（パス）

問2

設問1
(1)監視閾値を定めるにはどの程度が正常な業務なのかを利用部門に確認する必要がある。
(2)表1 注記1から、個人情報アクセスは機能番号8000番台である。表1 中から、無権限者はメニューに表示された8000番台へアクセスすると、利用は出来ないがログに記録されると判る。
(3)利用者IDが登録されていない場合は、端末を貸与された従業員以外が端末を利用してログイン試行したと考えられる。

設問2
(1)ログ取得の目的は抑止効果と事後の調査が可能となる、の2点。
(2)(3)監視閾値を公開すると、閾値以内で不正を行えば、検知されないようにできる。
(4)異常と看做す閾値を50回とするが、別途急激な増加をしている利用者を検知したいという条件になっている。（とは言え、急なキャンペーンだと、最初の1回目のピークは通知されてしまう）

設問3
監査のPDCAサイクルを意識する。業務形態は常に変化するので現在の閾値が妥当であるかを定期的に見直す。


問3

設問1
ア 各サーバの時間帯を見ると、3番目のReceivedはCET（中央ヨーロッパ時間）で表示されている。適切ではないが、ミスもありえる。
イ Receivedの経路は全て繋がっている
ウ DNSで名前解決をしない設定となっていると、この様な結果となる（DNSで名前解決出来ないと怪しいsmtpと看做す判定もあるので、設定が望ましい）
エ アドレスはグローバル、ローカル共に図3でどちらを使用しているか判別できない。

設問2
(1)SMTPのコマンドなので普段馴染みがない。覚えましょう。
(2)SPFのTXTレコードで+ip4:の部分は「送信元SMTPサーバのIPアドレスはxxxです」を意味する。よってxxxから送信されたメールであれば正当である、という判断ができるようになっている。
Z社はDMZに外部メールサーバMX1を配置しているので、MX1はグローバルIPアドレスを割当てていると通常考えるが、図2文末に「社内とインターネットとの間の通信には、グローバルIPアドレスx.y.z.1をNATアドレス」とある。判りづらいが前述の「社内」とは「社内LAN」ではなく、DMZを含むZ社の社内という意味でインターネットからDMZへ入ってくるとNATされてSMTPサーバはx.y.z.1とインターネット側からは見える。

設問3
(1)HTMLメールではhttp://canon.jp/の様な騙しリンクを作れる。そもそもメーラは原則HTMLメールを表示するべきではないし、送信側もHTMLメールを送るべきではない。HTMLメールのハイパーリンクは画面上の表示と実際のリンク先とが同一であると思ってはいけない。
(2)社内に侵入された後の対策となるので異なるセグメント間の通信を制御ファイアウオールでは防御できない。
(3)(4)バックドア通信がインターネット向けに行なわれても、FWで拒否される。しかしながら、http通信としてバックドア通信を行なわれた場合、PRX経由で外部へ通信可能なので、防御できない。
これはPRXの通信先が妥当なものかを判断して通信可否を制御する。（回答はURLフィルタリングでも良さそうである）


問4

設問1
業務ピーク以外で計算機資源が大量消費されているのは、何らかの異常を示唆している。

設問2
(1)(2)(3)脆弱性はCPUリソースが枯渇するとあるので、図3のピークを確認する。表2,表3,表4の同時刻帯にLBのdown,upが、またFW1で△△,123,123,123から送信バイト数が多い通信が発生している。表5,表6を参照すると、ステータスコード500となっているものがある。一般的にステータスコード200は正常通信なので、500(Internal Server Error)が怪しいと判る。

設問3
(1)LBのSSLアクセラレータ機能の理解を問う問題。（d.の回答が秘密鍵というのは一寸参った）
(2)[インシデントの発生]で記述しているように、アクセス数増加に伴う最大同時セッション数が不足している。これが不要なイベント通知の発生原因となっている。
(3)図2 (7)に「LBはX-Forwarded-Forヘッダフィールドは利用していない」旨記述している。これを設定していないため、表5,6のLBの送信元IPアドレスだけがログとして取得されている。XFFを設定すると、HTTP通信元のIPアドレスが下流であるWebサーバ群へ付加して送信されるため、Webサーバのログに本来の通信元IPアドレスが記録される。設問では「攻撃元を特定しやすくする」「FW1とWebサーバ群のログを関連付ける」の表記があるので、これを利用する。





H.25春

問1

設問1
(1)(2)ML4の侵入経路はML2,ML3が候補となる。ML2はプロキシ経由でWebサーバ、ML3は直接Webサーバへの通信を試行する。J社のhttp通信はプロキシ経由としているのでML2が正解。ML3はインターネット上のWebサーバへの通信を試行するため、FWに通信失敗ログが残る。

設問2
(1)[マルウエア解析後の暫定対策]ではDMZの全サーバ、OA-LANの残PC、RD-LANのPC、RDサーバを検査するとある。マルウエアが保存される可能性のある全サーバ&PCのHDDを検査して記録媒体として残るものはRD-LANとの情報交換に用いるUSBメモリとなる。
(2)SC試験の定番。マルウエアの通信先をプロキシ、ファイアウオールで遮断すればよい。また、プロキシで認証を行う方法も考えられるが、マルウエアに認証情報を読み出されている可能性もあるので、前者が望ましい。
(3)表2 ML2の特徴を見るとZブラウザの脆弱性を攻撃するとある。問題文p.3で脆弱性のあるver.2以外にver.3が存在している事がわかるので、ver.3へ更新をする。

設問3
(1)表2 マルウエアの共通する特徴を参照する。新しいファイルがあると「最近追加変更されたファイルの検索」で発見されてしまうので、タイムスタンプを書き換えして発見されにくくする。パック処理でウイルス対策ソフトの単純なバイナリ、コード検索から逃れられる。
(2)(3)ML5はUSBメモリ経由で感染するもの。攻撃者はMLから得た情報で社内にRD-LANの隔離されたネットワークが存在する事を知り、USBメモリ経由での攻撃を検討したと考えられる。


問2

設問1
(1)DNS,TCP,UDPの基本知識を問うもの
(2)CP攻撃はDNSの問い合わせパケットに対して、偽装した応答パケットを送りつけるもの。問い合わせ時のポート（=応答を受け取るポート）をランダムに変更すると、偽装した応答パケットを受信してしまう確率を下げられる。
(3)B-DNSはDNSコンテンツサーバであり、外部からA社のサービス（例えばhttp://a-sha.co.jp/のIPアドレス）に対する名前解決のみ、行なう。リゾルバ、DNSキャッシュ機能は提供しないとある。リゾルバ、DNSキャッシュ機能はC-DNSが受け持つため、外部へメールを送信する際はC-DNSがリゾルバとして名前解決を行なう
(4)項番3,5,7を見るとIF-2,3,4は接続している送信元のみからの通信を許可し、それ以外を拒否している。IF-1は記載ルールが異なるが、インターネット側からの通信を許可し、それ以外を拒否する設定とするのが正しいが、DMZ2からの通信が拒否設定していない。
(5)CP攻撃でSPFのTXTレコードが汚染されると、汚染したTXTレコードに記載されているSMTPサーバのIPアドレスを正当なものと判断し、そこから送出されたメールを受け取ってしまう。

設問2
(1)(2)C-DNSはIF-1からの名前解決を依頼される事はない。設問1(2)も参照。しかし、支社LANをB社基幹ネットワーク経由で接続すると、支社からの通信はIF-1から入ってくる。支社へPXYを設置すると名前解決のため本社C-DNSへIF-1経由アクセスする必要が発生する。これは正当な通信で許可する必要がある。
すると、支社PXYを送信元としてインターネット側から送出されたパケットと区別がつかなくなってしまう。そのため、本社と同様に支社DMZにリゾルバ、DNSキャッシュを設置する必要がある。


問3

設問1
微妙な設問だが、支店に共通端末があるから社外持ち出しPCで作業しなくても済む、よって情報流出リスクが下がる、という事かと思われる。

設問2
(1)(2)端末紛失時を考慮すると「HDD暗号化」「端末にデータを保存しない」の2種類が考えられる。表2 案2（ウ）で「（業務データ）の保存を制限」の項目があるので、b.は残る「HDD暗号化」となる。
(3)図1 (d)(e)(h)(i)を参照のこと。特に(i)のログオフしないと使用中の複製V-PCが維持される点に留意する。

設問3
図1 (g)を参照のこと。

設問4
(1)図5 (ii)(iii)を参照のこと。
(2)業務システムをVDI経由で使用するのであれば、端末から直接業務システムへ通信で接続する必要は無い。


問4

設問1
基礎知識

設問2
Digital Forensicsなので「デジタル・フォレンシクス」が正しい発音で「フォレンジクス」と濁るのは本当は誤り。

設問3
(1)情報が届き次第遅滞無く、と書きそうだが、アクセス禁止にするのは契約が終了する終業時刻になってから。
(2)インターネット直結の社外持ち出し用PCであれば、インターネットのサービス全てにアクセス可能であり、L社の社内システムでは制御できない。速度は遅くなるが、一旦社内へVPNで接続し、折り返してインターネットへ出る方式とすれば社内のFW、URLフィルタ等を適用出来る。

設問4
設問1と同様。（自社で当たり前の様に実施していると意外に気付かない）

H.25秋

問1
Webアプリケーション開発のXSS脆弱性問題（パス）

問2

設問1
(1)IMEIは端末で表示できるし、設問のシステム以外でも収集されている。パスワードの様な秘密情報ではない。回答では考慮していない様だが、Android端末では書き換えも可能であろう。
(2)(3)IMEIをハッシュ化して送信すればIMEIをそのまま送信するより安全だろうか？という趣旨だが、ハッシュ化キーをリバースエンジニアリングで突き止めれば、成りすましは可能。ハッシュ化でメッセージダイジェストを送信する方式をHMACという。H.26春でも出題しているが、午前2では出題されていない。

設問2
「電話帳データ全員分」という個人情報の不必要な取得と、その対応を問うもの。必要な個人情報のみを収集するということなのだろうが、（送信に必要な分を）「 APで選択して送信する」という当たり前すぎる回答は逆に思いつかなかった。

設問3
表2 のアプリケーション設計の問題を問うもの。良く判らないのだが、DateTimeを変更せずYoyakuCodeだけ変更しても当該の予約明細コードの予約を表示できそうな気もするが...。


問3

設問1
図2 (1),(2)を見ると管理責任者は利用者が指定した携帯電話メールアドレスを確認せずCサービスに登録してしまう。第三者が実在する利用者の名前、第三者の携帯電話メールアドレスで申請メールを出すと、第三者の携帯電話メールアドレスに仮パスワードが送られてくる。

設問2
個人の携帯電話が盗まれ、かつ利用者ID、パスワードが漏洩している前提で、図3を確認してみる。攻撃者は盗んだ携帯、利用者ID、パスワードの3点でワンタイムパスワードを入手する(3)。その後、ログインし有効期限90日のクッキーを受け取る(6)。次回からはクッキーのみでログインできる(2)ため、90日間はパスワードを変更しても不正使用が可能となる。
（そもそも、このようなログイン方式が脆弱なのである。最低でも重要なデータの表示、トランザクションの前にパスワード認証を行なう構造とするべきである。回答では携帯電話が盗難されたら電話を停止して、パスワードを変更するとしているが、十分な対策とは思えない）

設問3
BCPと不測のクラウドサービス終了の対応。クラウドだから安心、というと痛い目にあうので代替手段の検討は必要である。





H26.春

問1
Webアプリケーション開発（パス）


問2

設問1
(1)unixの基本
(2)SPF記述の基本。文頭から評価されるので、図3では、SMTPサーバはx1.y1.z1.4のIPアドレス、（それ以外は）全てSMTPサーバのIPアドレスではない、という設定。

設問2
図3のMXレコードを見ると、SMTPはmsv1.a-sha.co.cjp、msv2.a-sha.co.jpの2サーバが指定されている。優先順位はmsv1が高いため、通常はmsv1（迷惑メール対策装置）へ送られ、msv1が停止していると次のmsv2（外部メールサーバ）へ送られる。
この構造の場合msv2を直接指定してメールを送ると受け取ってしまう。

設問3
(1)通常SMTPサーバ等のグローバルIPアドレスは変更しないものだが、プロバイダ変更等で異なるグローバルIPアドレスが割当てられる可能性がある。DNSコンテンツサーバで解決先IPアドレスを新しいものに変更すれば外部からの接続には問題ないのだが、IPアドレスでのWL,BLでは影響がある。
(2)迷惑メール業者自身でドメインの取得とSMTPサーバ立ち上げ、MXレコードにSPFを記述されたらSPFでの対策は無力だ。
(3)ドメインBLはなるべく色々な情報を元に、という趣旨。アクセス先webとして許可できるが、メールの送信元として許可できない相手先、というのは存在しない。両方とも許可できるか、拒否、のどちらかである。

設問4
（正直問題と回答とが良くない。確かに迷惑メール対策装置が正常であれば、MXレコードの指定先をmsv1だけにしても良いだろうが、実運用でありえるのだろうか？
LBが冗長化されていれば、SMTPをLBで受け、MXレコード宛先をLBとする。外部からはmsv1,msv2は見せない。LBからmsv1優先、msv2次候補として負荷分散設定するのが良さそうだが...。）


問3

設問1
(1)(2)フィッシングの基本知識。法人向けサービスではクライアント証明書による認証も行なうため、セキュリティが厳しい。
（乱数表カードを加えたログイン認証が多いが、私見では振込等の重要なトランザクション時に限って乱数表を使わせた方が安全な気がする。ログイン毎に入力するとそれだけ盗聴の危険も増す）

設問2
(1)(2)中間者攻撃とSSLに関する知識を問う。SSLでは証明書を確認すれば、x-bank.jpに接続されているかブラウザ上で確認できる。（スマートフォン向けサイト等でURL部分を隠したり、ポップアップでウインドを開くものを見掛けるが、デザイン優先でユーザの安全性を損なう実装である。でも、ブラウザで警告してくるのか？）

設問3
(1)(2)(3)HMACツールは簡易的なクライアント証明書として機能する、という事なのだろうか？





H.26秋

問1
プログラム開発におけるメモリ管理、スタックオーバーフローの知識が必要（パス）


問2

設問1
(1)(2)暗号化方式と名称の基本知識を問う。AESアルゴリズムは共通鍵暗号である。表2から256ビット安全性と判るので、RSA（素因数分解）、ハッシュ関数でそれぞれ鍵ビット数を求める。
(3)表2とシステム要件から、必要なビット安全性を求める。

設問2
公開鍵暗号方式の基本知識を問う。

設問3


問3

設問1
(1)(2)p.15のSaaS型クラウド、サービスXのメール周りの動作を理解する。


設問2
(1)(2)(3)利用者セグメントからインターネットへは直接接続できず、プロキシサーバ経由となる点に留意する。また顧客管理のSaaSへは特定ポートを指定した接続が必要なので、これをプロキシサーバで許可する必要がある。（表4）


設問3
(1)設問がわかりづらいが、図1 開発サーバセグメントに開発専用PCを配置して、開発は当該セグメントで閉じた環境で行なう。
(2)色々考えられるので、設問が良くない気がする。


設問4
(1)可能なパスワード数の計算。問題文に「14文字までのパスワード」と書いている点に留意する。
(2)ソルト（パスワードに塩を振りかけ味を微妙に変えるように、入力されたパスワードにランダムな文字列を加えてパスワードを内部で長くする）を付加すると、ソルトによって出力されるハッシュ値が異なる。






H.27春

問1
Webアプリケーションのセッション維持に関する問題。cookie周りの知識必要（パス）


問2

設問1
(1)(2)L社のネットワークにDMZは存在するが、DMZはローカルIPアドレスを配賦し、FWのNAPT（Linux用語ではIPマスカレード）でグローバルIPアドレスへ変換して通信している点に留意する。

設問2
(1)IPA特有の「DNSは最小限の名前解決しかさせない」ルールが適用されている。
一般的な企業であればPCのDNS参照先は内部DNS、内部DNSは社内の名前解決&DNSフォワーダ設定で外部DNSを指定、外部DNSがDMZ&インターネット上の名前解決、という構造を取る。
しかしながら、本設問では内部DNSはL社内の名前解決しかしない。明示していないが「フォワーダ設定はしていない」と考えられる。
この設定であれば、マルウエアからC&Cサーバ向けの通信は内部DNSはC&Cサーバの名前解決で失敗して終了する。
なおmail、webの名前解決はメールサーバ、プロキシサーバが外部DNSで名前解決できれば運用できるので、PCからインターネット上のドメインを名前解決出来なくても、問題は無い。
類似の考え方をする問題がSC PM2 H.26春 問2 設問5(3)(4)に出ているので参照されたし。
（確かに問題文からは上記の通り解釈できるのでしょうが、一般的な企業でも上述の設定をしているところ、多いのでしょうかね？）
(2)FWはUTM型ではないので、特定URLへの接続禁止はプロキシサーバで設定する。

設問3
(1)
(2)
(3)サーバ自身のログは改竄されている可能性がある。別途syslogで飛ばして保管されているログ管理サーバのものを照合する。


問3

設問1
ハッシュ値が漏洩した場合、選択平文攻撃でパスワード解読が可能となる。選択平文攻撃とは、大量の平文を暗号化モジュールに入れて、ハッシュ値が同値となったものを平文として選択する。しかし、ソルトを付加して暗号化モジュールに入れるパスワードを長くして変化させると、ハッシュ値も異なるものになるので、選択平文攻撃が通用しづらくなる。

設問2
(1)SHA-256の'256'bitが出力されるハッシュ値の長さ。bit表示なので回答はbyteに変換すること。
(2)リバースブルートフォース攻撃では同一IPアドレスからIDを変更してログイン試行を行なうので、同一IPアドレスからの大量のログイン失敗を検知する。
(3)接続元を分散してログイン試行された場合は、通常のログイン失敗と判定がしずらい。急激に利用者が増加（≒ログイン失敗数も比例して増加）する事は考えずらいので、（ウ）の様に対策する。

設問3
設定可能なパスワード数を求める問題。文字数が1-8文字の様な問題だとsigmaを使う必要があるが、本設問はパスワード長が固定なので、x^yで求められる。

設問4
同一のID,パスワードを使いまわすと流出時のリスクが大きい。





H.27秋

問1
Webアプリケーションの脆弱性とWAFによる対策問題。正規表現の知識必要（パス）

問2
H.24春 問3の類似問題


問3

設問1
ログイン時刻とアクセス元から推測する。

設問2
(1)(2)表5から推測されるクラック手順

1 testというディレクトリがあるかを確認したが404でディレクトリが無いと判った
2 demoというディレクトリがあるかを確認したが404でディレクトリが無いと判った
3-10 /manager/以下の管理画面へのログインを試行するが401で失敗する
11 /manager/以下の管理画面へのログインが200で成功する
12 /manager/以下の管理画面での操作
13 管理画面から攻撃ツールをアップロード
14 /demoの攻撃ツールへアクセス
15-23 攻撃ツールを用いて、/Temp/Printer以下にファイルを作成等

設問3
(1)DMZから内部LANへの通信を制御しているものを探す。
(2)表6 項番5は運用端末のアクセス制御であるが、図2の許可する操作よりアクセス制御が緩い。

設問4
(a)ローカルホストからのみ接続を許可するため、設定は当該端末から物理コンソールを用いる運用とする
(b)p.17 A氏の発言参照





H.28春

問1
WebアプリケーションのXSS脆弱性問題（パス）

問2

設問1
外部メールサーバに要求される対策。オープンリレーでspam踏み台にならない様に。spfでspamを受信拒否。

設問2
外部に公開しているDNSサーバはリゾルバ、キャッシュ機能は使わない。コンテンツ機能（自社のwebやsmtpに関する名前解決のみ）のみ動かす。

設問3
(1)(2)DNSポイズニングと対策。不正なDNS応答を受け取らないために問い合わせポートをランダムに変更する。DNSが汚染されると、異なるサーバへ名前解決してしまう。
(3)https通信では通信内容が暗号化されている。通信相手は判るが、パス名といった通信内容は暗号化されて判らなくなる。

設問4
複合機からの通知メールを偽装された場合の対処方法を考える。複合機は社内にあるので、社外からメールが届く筈はない。社外からのメールであれば、メールエンベロープが複合機のものになる事はない。しかし、メールヘッダは自由に設定できるので、複合機のものに設定できる。このメールを拒否すれば良い。


問3

設問1
DNSの初歩

設問2
(1)所謂「オレオレ証明書」を用いたときの挙動を理解する。
(2)無線LANはSSIDを初めとする認証要素が一緒であれば自動接続してしまう。
（でも、明示的に指示するまでAPへ接続しない設定って出来ないのかな？出来る気がするけど）

Read More