雑記帳

■ [AWS][Ruby] AWS SDK for Rubyでセキュリティグループに対するICMPの設定

AWS SDK for Rubyで、アクセスの許可をするには、AWS::EC2::SecurityGroup#authorize_ingressを使う。

ICMPを許可する場合、大抵はすべてを許可するので、次のようになる。

sg.authorize_ingress(:icmp, -1..-1, '10.0.0.0/8')

これで設定すると、ICMP ALLで設定するのと同等となる。

普通はこんなことはしないが、試しにICMPの、Destination Unreachable/Source route failedを設定してみたい。

まずは、AWS Management Consoleから設定してみると、次のようになる。

これを、AWS SDK for Rubyで参照してみる。

sg.ip_permissions.each {|perm| puts "port_range: #{perm.port_range}, protocol: #{perm.protocol}" }
#=> port_range: 3..5, protocol: icmp

どうやら、ICMPのType, Codeが、Rangeオブジェクトの最初と最後に設定されているらしい。では、"Parameter Problem: Bad IP header/Bad length"ではどうか。これもAWS Management Consoleから設定して、AWS SDK for Rubyから先ほどと同じように参照してみると、次のような結果が帰ってくる。

sg.ip_permissions.each {|perm| puts "port_range: #{perm.port_range}, protocol: #{perm.protocol}" }
#=> port_range: 12..2, protocol: icmp

ということで、12..2というRangeオブジェクトが設定されていることが確認できる。

では、これをAWS SDK for Rubyで設定してみるとどうなるか。

sg.authorize_ingress(:icmp, 12..2, '10.0.0.0/8')
#=> nil
sg.ip_permissions.each {|perm| puts "port_range: #{perm.port_range}, protocol: #{perm.protocol}" }
#=> port_range: 0..0, protocol: icmp

なぜか0..0になってしまう。AWS Management Consoleで見ると、以下のようになってしまう。

動作がおかしいと思ったので、コードを確認してみたところ、次のようになっているのを見つけた。

# aws-sdk-1.2.3/lib/aws/ec2/security_group/ip_permission.rb 49-53

# not all egress permissions require port ranges, depends on the
# protocol
if ports
  @port_range = Array(ports).first.to_i..Array(ports).last.to_i
end

これだと、12..2を渡すと、Array(12..2)になってしまい、空の配列が帰ってくることになり、nil.to_iが実行され、0になってしまう、ということのようだ。ICMPに個別の設定をしていると、セキュリティグループをコピーするコードに、さらに問題が発生するということのようだ。

■ [Linux] ファイルへのアクセスを監査する

Linuxでは、auditdというシステム監査のためのdaemonが動作している。auditdで、特定のファイルにアクセスがあった場合に、監査ログに記録をするというセキュリティ要件がでてきたため、下記のように設定した。

設定ファイルは、/etc/audit/audit.rulesで、このファイルの最後に次の設定を追記した。

-w /path/to/file

-wの後に、アクセスがあったことを記録したいファイルのフルパスを指定すれば良い。これで、このファイルにアクセスが合ったときに、/var/log/audit/audit.logに、下記のような記録が残る。

type=SYSCALL msg=audit(1323175567.561:7561): arch=40000003 syscall=5 success=yes exit=4 a0=8b160a8 a1=8000 a2=0 a3=8b16089 items=1 ppid=26281 pid=26308 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=539 comm="less" exe="/usr/bin/less" key=(null)
type=CWD msg=audit(1323175567.561:7561):  cwd="/root"
type=PATH msg=audit(1323175567.561:7561): item=0 name="/path/to/file" inode=3408161 dev=ca:51 mode=0100600 ouid=0 ogid=0 rdev=00:00

■ [AWS] S3のバケットポリシーでIPアドレスによるアクセス制限

S3のオブジェクトにアクセスする際に、特定のIPアドレスからのみ許可したいという場合には、下記のようなポリシーを作成して、バケットに設定すれば良い。

{
  "Version":"2008-10-17",
  "Id": "S3PolicyId1",
  "Statement": [
    {
      "Sid": "IPAllow",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::bucketname/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "198.51.100.0/24"
        }
      }
    }
  ]
}

この例だと、bucketnameバケット以下のすべてのオブジェクトに対して、198.51.100.0/24からのみアクセスを許可するという設定となる。

■ [AWS] AWS Multi-Factor Authenticationを複数デバイスで同時利用

AWS Multi-Factor Authenticationを使うでは、ひとつのアカウントにひとつのデバイスを登録してみたのだが、同時に複数のデバイスを登録したらどうなるのかが気になったので、試してみた。

その結果が、下記の写真。

写真を見ると、二台の別のデバイスに同じ数字が表示されていることが分かる(それぞれ下の数字が同じ)。つまり、登録時に表示されるQRコードを、複数のデバイスで読みこめば、MFAで一つのアカウントに複数のデバイスを使うことができるようだ。また、この時のQRコードを保存しておけば、いつでも登録することもできるので、QRコードを保存しておくとセキュリティは低下するが、デバイスが失われた際のリカバリはやりやすくなる。

デバイスを失くしたときは、すぐにデバイスを無効にするべきなのだが、デバイスを失くしたことでログインできなくなってしまう。この時、保存していたQRコードから別のデバイスに登録することで、ログインできるようになる。ログインした後にすぐにデバイスを無効にするのが良いだろう。