OpenStack Kolla Horizon HTTPS化

horizon のコンテナでhorizonをHTTPS化する。

手順

  1. horizon コンテナにログイン
  2. /etc/httpd/conf.d/ssl.conf 修正
  3. コンテナ再起動

ログイン

# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ab109739a033 kolla/centos-source-manila-share:queens "kolla_start" 2 hours ago Restarting (1) 51 seconds ago manila_share
43c45131b740 kolla/centos-source-manila-scheduler:queens "kolla_start" 2 hours ago Up 2 hours manila_scheduler
313fcf872a06 kolla/centos-source-manila-data:queens "kolla_start" 2 hours ago Up 2 hours manila_data
e8d723fef1a4 kolla/centos-source-manila-api:queens "kolla_start" 2 hours ago Restarting (1) 4 seconds ago manila_api
df0eeda4a35b kolla/centos-source-horizon:queens "kolla_start" 2 hours ago Up 3 minutes horizon
ba1aa66b3c70 kolla/centos-source-heat-engine:queens "kolla_start" 2 hours ago Up 2 hours heat_engine
7a99a622e247 kolla/centos-source-heat-api-cfn:queens "kolla_start" 2 hours ago Up 2 hours heat_api_cfn
d3b5669aff16 kolla/centos-source-heat-api:queens "kolla_start" 2 hours ago Up 2 hours heat_api
7c6b49e46961 kolla/centos-source-neutron-bgp-dragent:queens "kolla_start" 2 hours ago Up 2 hours neutron_bgp_dragent
7b043fc70e34 kolla/centos-source-neutron-metadata-agent:queens "kolla_start" 2 hours ago Up 2 hours neutron_metadata_agent
cb58001b41f6 kolla/centos-source-neutron-l3-agent:queens "kolla_start" 2 hours ago Up 2 hours neutron_l3_agent
1d5fc5630757 kolla/centos-source-neutron-dhcp-agent:queens "kolla_start" 2 hours ago Up 2 hours neutron_dhcp_agent
b2fc74c8e428 kolla/centos-source-neutron-openvswitch-agent:queens "kolla_start" 2 hours ago Up 2 hours neutron_openvswitch_agent
3e8ef7289077 kolla/centos-source-neutron-server:queens "kolla_start" 2 hours ago Up 2 hours neutron_server
832cae84fab4 kolla/centos-source-openvswitch-vswitchd:queens "kolla_start" 2 hours ago Up 2 hours openvswitch_vswitchd
4dd0a7fa6d31 kolla/centos-source-openvswitch-db-server:queens "kolla_start" 2 hours ago Up 2 hours openvswitch_db
8096e4ec00e5 kolla/centos-source-nova-compute:queens "kolla_start" 2 hours ago Up 2 hours nova_compute
ea8129516288 kolla/centos-source-nova-novncproxy:queens "kolla_start" 2 hours ago Up 2 hours nova_novncproxy
6703fef99aab kolla/centos-source-nova-consoleauth:queens "kolla_start" 2 hours ago Up 2 hours nova_consoleauth
fb2068c78891 kolla/centos-source-nova-conductor:queens "kolla_start" 2 hours ago Up 2 hours nova_conductor
97057ff78bb6 kolla/centos-source-nova-scheduler:queens "kolla_start" 2 hours ago Up 2 hours nova_scheduler
25e12c436198 kolla/centos-source-nova-api:queens "kolla_start" 2 hours ago Up 2 hours nova_api
f3d3d445c1d2 kolla/centos-source-nova-placement-api:queens "kolla_start" 2 hours ago Up 2 hours placement_api
f47d12a757df kolla/centos-source-nova-libvirt:queens "kolla_start" 2 hours ago Up 2 hours nova_libvirt
1d8e05ba3c99 kolla/centos-source-nova-ssh:queens "kolla_start" 2 hours ago Up 2 hours nova_ssh
810e9ff31daf kolla/centos-source-cinder-backup:queens "kolla_start" 2 hours ago Up 2 hours cinder_backup
3bf3abd9b269 kolla/centos-source-cinder-volume:queens "kolla_start" 2 hours ago Up 2 hours cinder_volume
417c1087b432 kolla/centos-source-cinder-scheduler:queens "kolla_start" 2 hours ago Up 2 hours cinder_scheduler
fda972374b3f kolla/centos-source-cinder-api:queens "kolla_start" 2 hours ago Up 2 hours cinder_api
fd9107b2cc79 kolla/centos-source-glance-api:queens "kolla_start" 2 hours ago Up 2 hours glance_api
b814c910e21f kolla/centos-source-keystone-fernet:queens "kolla_start" 2 hours ago Up 2 hours keystone_fernet
7bda77c6543d kolla/centos-source-keystone-ssh:queens "kolla_start" 2 hours ago Up 2 hours keystone_ssh
0a151029226c kolla/centos-source-keystone:queens "kolla_start" 2 hours ago Up 2 hours keystone
d76caff26d23 kolla/centos-source-rabbitmq:queens "kolla_start" 2 hours ago Up 2 hours rabbitmq
113a23dfefb6 kolla/centos-source-mariadb:queens "kolla_start" 2 hours ago Up 2 hours mariadb
d64c194fa844 kolla/centos-source-memcached:queens "kolla_start" 2 hours ago Up 2 hours memcached
4ce505333564 kolla/centos-source-chrony:queens "kolla_start" 2 hours ago Up 2 hours chrony
c230924e585e kolla/centos-source-cron:queens "kolla_start" 2 hours ago Up 2 hours cron
5d9710d55d76 kolla/centos-source-kolla-toolbox:queens "kolla_start" 2 hours ago Up 2 hours kolla_toolbox
b9bc9d971441 kolla/centos-source-fluentd:queens "kolla_start" 2 hours ago Up 2 hours fluentd
# docker exec -it horizon /bin/bash
(horizon)[root@openstack /]#

ssl.conf 修正

(自己証明書はすでに作成されているのでそのまま利用する)
最終行に以下追加。

Listen 443 https #コメント削除
<Location />
Require all granted
</Location>
WSGIScriptReloading On
WSGIDaemonProcess horizon-https processes=5 threads=1 user=horizon group=horizon display-name=%{GROUP} python-path=/var/lib/kolla/venv/lib/python2.7/site-packages
WSGIProcessGroup horizon-https
WSGIScriptAlias / /var/lib/kolla/venv/lib/python2.7/site-packages/openstack_dashboard/wsgi/django.wsgi
WSGIPassAuthorization On
WSGIApplicationGroup %{GLOBAL}

Alias /static /var/lib/kolla/venv/lib/python2.7/site-packages/static

コンテナ再起動

docker restart horizon

アクセスすると。

無事HTTPS化された

パスワードの定期的変更

総務省が方針変更したというニュースを受けて, その他界隈はどうなっているのかググってみた。

総務省:定期的変更は不要(2018年3月1日に方針変更)
http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/privacy/01-2.html

内閣サイバーセキュリティセンター(NISC):定期的変更は不要(ハンドブック ver3.0)
https://www.nisc.go.jp/security-site/files/handbook-all.pdf

経産省:パスワードは随時変更(定期的とは言っていない)
http://www.meti.go.jp/policy/netsecurity/UAaccessCMG.htm

IPA:定期的変更には意味がある(あくまで予防的?)
https://www.ipa.go.jp/security/personal/onlinegame/index.html

海外ではずいぶん前からパスワードの定期的変更はセキュリティ上問題となりえると言われているようです。
https://www.schneier.com/blog/archives/2016/08/frequent_passwo.html

OpenStack Queens をKollaで入れ直す

Newtonのリポジトリがなくなっているので, Kollaで入れ直すことにした。
都度対処療法で進めていったので, 一般的な流れでは無いことをご了承ください。

まず, Packstack環境をこちらのスクリプトで削除する。
付録A PackStack デプロイメントの削除

# ./unpack.sh

一旦再起動&yum update。

# yum update -y

ここからはオフィシャルのページを参考にすすめていく・・・とやってみはいいけれど, うまくいかなかったのでQiitaのこちらも参考にやっていく。
Kolla Ansible Quick Start
kolla-ansibleでOpenStack(stable/queens)を構築する

最小要件は

  • NIC 2つ
  • メモリ 8GB以上
  • ディスク 40GB

今回はRDOの名残のbr-exをマネジメント用にして, もう一方のNICをExternal用にする。
External用のNICはIP無し。
と思ってやってみたけれど, 実際やってみるとbr-exはprecheck時にエラーになるので, openvswitchを利用せず, 物理NICに戻す必要あり。

1. 事前準備

$ sudo yum install epel-release
$ sudo yum install python-pip
$ sudo pip install -U pip
$
$ sudo yum install python-devel libffi-devel gcc openssl-devel libselinux-python
$
$ sudo yum install ansible

/etc/ansible/ansible.cfg 編集。

[defaults]
host_key_checking=False
pipelining=True
forks=100

その他, openstack-newtonのリポジトリで入れたPython系はごっそり消してキレイにしておく。

2. Kolla-ansible インストール

この手順でエラーがでる。

pip install -r kolla/requirements.txt

<エラーメッセージ>

oslo-config 6.4.0 has requirement PyYAML>=3.12, but you'll have pyyaml 3.10 which is incompatible.

この対応のため, 以下インストール実施。

$ wget http://pyyaml.org/download/pyyaml/PyYAML-3.12.tar.gz
$ tar xvfz ./PyYAML-3.12.tar.gz
$ sudo python ./PyYAML-3.12/setup.py install

今一度ansible インストール

$ sudo yum install ansible
$ sudo pip install -r kolla/requirements.txt
$ sudo pip install -r kolla-ansible/requirements.txt

うまくいった。

3. 初期設定ファイル準備

今回はAll-in-oneなので特にファイルいじらない。

$ sudo ansible -i all-in-one all -m ping
localhost | SUCCESS => {
"changed": false,
"ping": "pong"
}

成功。

4. Kolla パスワード設定

$ sudo kolla-genpwd

5. Kolla globals.yml 編集

kolla_base_distro: "centos"
kolla_install_type: "source"
openstack_release: "queens"
kolla_internal_vip_address: "192.168.1.100"
docker_registry: ""
network_interface: "enp4s0"
neutron_external_interface: "enp1s0"
enable_neutron_provider_networks: "yes" #追加(2018/08/29) 外部ネットワークにつなげたい時はこれ必要
enable_cinder: "yes"
enable_cinder_backup: "yes"
enable_cinder_backend_nfs: "yes"
enable_haproxy: "no"
enable_heat: "yes"
enable_horizon: "yes"
enable_manila: "yes"
enable_manila_backend_generic: "yes" #追加(2018/08/25)
enable_neutron_bgp_dragent: "yes"
glance_backend_file: "yes"
enable_cinder_backend_nfs: "yes"
nova_compute_virt_type: "kvm"
tempest_image_id:
tempest_flavor_ref_id:
tempest_public_network_id:
tempest_floating_network_name:

6.NFS設定

/share/cinder をcinderの共有先とした。
/etc/kolla/config/nfs_shares 編集

#storage01:/share/cinder    #コメントアウト
localhost:/share/cinder #all-in-oneなのでlocalhostに編集

7. デプロイ

$ sudo kolla-ansible -i all-in-one bootstrap-servers
$ sudo kolla-ansible -i all-in-one prechecks
$ sudo kolla-ansible -i all-in-one deploy
$ sudo kolla-ansible post-deploy

8. OpenStack CLIインストール

色々と依存関係でエラーが出たので対処療法で以下実施。
sudo mv ./ipaddress* /tmp/

sudo mv /lib/python2.7/site-packages/pyinotify* /tmp/
pip install python-openstackclient python-glanceclient python-neutronclient

この後, これも足りないとインストール。

sudo yum install python-stevedore.noarch

そしてサンプル構成をデプロイ時にまたエラーが出て以下対応をした。

sudo yum install python-stevedore.noarch

9. デプロイ

改めてサンプル構成デプロイ実行。

. /etc/kolla/admin-openrc.sh
. /usr/share/kolla-ansible/init-runonce

一応できている。

$ openstack subnet list
+--------------------------------------+----------------+--------------------------------------+-------------+
| ID | Name | Network | Subnet |
+--------------------------------------+----------------+--------------------------------------+-------------+
| 0d5a4b6f-a873-4ea1-9b50-f4f7b2c52c95 | public1-subnet | 6c5000d4-6cdc-4ded-8e04-dce9f85dd4eb | 10.0.2.0/24 |
| 72bd7b51-9ab0-4be3-956a-dd3ce1085048 | demo-subnet | ccc2adc9-9b5e-42c6-9787-b19d11605f63 | 10.0.0.0/24 |
+--------------------------------------+----------------+--------------------------------------+-------------+

ダッシュボードにアクセス。
http://<kolla_internal_vip_address>

https化したいけれど, どうしたらいいのだろう

ひとまず無事?にできたので今日はここまで。

はじめてのAnsible on EVE-NG

EVE-NGでAnsibleを触ってみるための環境構築メモ。

手順

  1. VMWare Playerで仮想マシンのNIC追加
  2. Ubuntu VMを立てる
  3. Ansible 入れる
  4. Playbook試す

VMWare Playerで仮想マシンのNIC追加

シミュレータ上でUbuntuをたて, apt-getでAnsibleをインストールするために外部接続用のNICを追加する。

ブリッジタイプのvNICを追加

外部ネットワークとの接続設定の確認。
eth1はCloud1に, eth2はCloud2というようにブリッジの設定が入っている。

# Cloud devices
iface eth1 inet manual
auto pnet1
iface pnet1 inet manual
bridge_ports eth1
bridge_stp off

iface eth2 inet manual
auto pnet2
iface pnet2 inet manual
bridge_ports eth2
bridge_stp off

今回はeth1が外部接続用のネットワークとなる。

簡単な構成イメージ

Ubuntu VMを立てる

ubuntuイメージは以下からダウンロードする。
linux_image_for_eve_pro
ちなみにバージョンは16.04.4。

その後はオフィシャルにある通りのやり方でイメージを登録する。

# cp ./virtioa.qcow2 /opt/unetlab/addons/qemu/linux-ubuntu-srv-16.04.4-webmin/
# /opt/unetlab/wrappers/unl_wrapper -a fixpermissions

これでVMを登録できる。

Linuxが選択できるようになる

追加したubuntuのイメージで起動
今回はNICは2つ

Cloud1とUbuntuを接続してInternetにつながるか確認。

テスト環境はこんな感じ
「To Internet」とあるのがCloud1

Ansibleインストール

UbuntuにログインしてアップデートからのAnsibleインストール。
オフィシャルドキュメントに従っていけばOK。
ただし, このイメージだとwebminのリポジトリがリンク切れ?なのかエラーになるので, これをコメントアウトする。

# vi /etc/apt/sources.list

# deb http://download.webmin.com/download/repository sarge contrib

Ansibleインストール。

# apt-get update
# apt-get install software-properties-common
# apt-add-repository ppa:ansible/ansible
# apt-get update
# apt-get install ansible

完了。

Playbookお試し

ルータ4台構成し, バナーメッセージを変更するPlaybookを作成して試行する。
事前準備として, ルータにはIPアドレス設定とSSH設定までは行っておく必要がある。(AnsibleはSSH接続前提のため)

まず最初に /etc/ansible/hosts の設定をする。ここに管理対象となる機器のIPアドレス(ないしはホスト名)を記述する。今回は簡単にルータのIPアドレスを記述し, それらをCiscoというグループでまとめる。
# vi /etc/ansible/hosts

[Cisco]
10.10.10.2
10.10.10.3
10.10.10.4
10.10.10.5

[Cisco:vars] # Ciscoグループ共通のパラメータ設定
ansible_connection=network_cli # ネットワーク機器なので network_cli を指定する
ansible_network_os=ios # Ciscoのiosを指定する
ansible_user=cisco # SSHのログインユーザ名
ansible_ssh_pass=cisco # SSHのログインパスワード(本番環境では非推奨)
ansible_become=yes # 特権モードになるか
ansible_become_method=enable # Ciscoなのでenable
ansible_become_pass=cisco # enable パスワード

Playbook準備。

# vi ~/playbook/ios.yml

- hosts: Cisco                                    # Ciscoグループ対象
gather_facts: no # 機器情報取得しない

tasks: # タスクを登録
- name: insert banner # 1つ目。バナー入れるタスク
ios_banner: # ios_banner というモジュールを利用
banner: motd # motd を対象
text: | # バナーメッセージ登録
You are logged in on $(hostname)
state: present # 登録。absent ならバナー削除

- name: save running to startup when modified # 設定保存するタスク
ios_config: # iso_config というモジュール利用
save_when: modified # 変更されていれば保存実行

実行結果。
# ansible-playbook ios.yml

root@ubuntu:~/playbook# ansible-playbook ./ios.yml

PLAY [Cisco] *********************************************************************************************************************************************************

TASK [insert banner] *************************************************************************************************************************************************
changed: [10.10.10.5]
changed: [10.10.10.4]
changed: [10.10.10.3]
changed: [10.10.10.2]

TASK [save running to startup when modified] *************************************************************************************************************************
changed: [10.10.10.2]
changed: [10.10.10.4]
changed: [10.10.10.3]
changed: [10.10.10.5]

PLAY RECAP ***********************************************************************************************************************************************************
10.10.10.2 : ok=2 changed=2 unreachable=0 failed=0
10.10.10.3 : ok=2 changed=2 unreachable=0 failed=0
10.10.10.4 : ok=2 changed=2 unreachable=0 failed=0
10.10.10.5 : ok=2 changed=2 unreachable=0 failed=0

すっごい簡単。
ログインしてみると・・・。

ちゃんと変わっている

Ansibleは冪等性といわれる「何度やっても同じ結果が得られる」というコンセプトのもと開発されているので, このPlaybookを2回目やってみると,

root@ubuntu:~/playbook# ansible-playbook ./ios.yml

PLAY [Cisco] *********************************************************************************************************************************************************

TASK [insert banner] *************************************************************************************************************************************************
ok: [10.10.10.3]
ok: [10.10.10.5]
ok: [10.10.10.4]
ok: [10.10.10.2]

TASK [save running to startup when modified] *************************************************************************************************************************
ok: [10.10.10.3]
ok: [10.10.10.4]
ok: [10.10.10.2]
ok: [10.10.10.5]

PLAY RECAP ***********************************************************************************************************************************************************
10.10.10.2 : ok=2 changed=0 unreachable=0 failed=0
10.10.10.3 : ok=2 changed=0 unreachable=0 failed=0
10.10.10.4 : ok=2 changed=0 unreachable=0 failed=0
10.10.10.5 : ok=2 changed=0 unreachable=0 failed=0

このように, 「changed=0」と変更したものは無いよ, という結果になる。スバラシイ。マクロよりも全然よいと思われる。

まだ手を付け始めたばかりのため理解及んでいませんが, これはすごい楽しい未来がやってくる気がする。なので, これからどんどん試していく。

なお, ネットワーク機器においてのAnsibleはこちらのスライドが超絶わかりやすいのでオススメです。

【メモ】EVE-NGのキャプチャ

EVE-NGのrootのパスワード変えると、キャプチャ用のバッチファイルの中身も変えないとキャプチャ開始時に「unable connect」って出る。

C:Program FilesEVE-NGwireshark_wrapper.bat の3行目

@ECHO OFF
SET USERNAME="root"
SET PASSWORD="eve" #これ

EVE-NGのHTTPS化

公式のマニュアルまんまです。
自己証明書なので, ブラウザの警告がでるからアンチウィルスソフト使っている場合は適宜除外設定する。

公式マニュアル
http://www.eve-ng.net/documentation/howto-s/81-howto-enable-ssl-on-eve

SSL有効化

root@eve-ng:~# a2enmod ssl
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
service apache2 restart

自己証明書作成

root@eve-ng:~#  openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt
Generating a 2048 bit RSA private key
..+++
.......................................+++
writing new private key to '/etc/ssl/private/apache-selfsigned.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Personal
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:192.168.10.20
Email Address []:

Conf修正

root@eve-ng:~# cat << EOF > /etc/apache2/sites-enabled/default-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin webmaster@localhost
DocumentRoot /opt/unetlab/html/
ErrorLog /opt/unetlab/data/Logs/ssl-error.log
CustomLog /opt/unetlab/data/Logs/ssl-access.log combined
Alias /Exports /opt/unetlab/data/Exports
Alias /Logs /opt/unetlab/data/Logs
SSLEngine on
SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt
SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key
<FilesMatch ".(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
<Location /html5/>
Order allow,deny
Allow from all
ProxyPass http://127.0.0.1:8080/guacamole/ flushpackets=on
ProxyPassReverse http://127.0.0.1:8080/guacamole/
</Location>

<Location /html5/websocket-tunnel>
Order allow,deny
Allow from all
ProxyPass ws://127.0.0.1:8080/guacamole/websocket-tunnel
ProxyPassReverse ws://127.0.0.1:8080/guacamole/websocket-tunnel
</Location>
</VirtualHost>
</IfModule>
EOF

Apacheリスタート

root@eve-ng:~# /etc/init.d/apache2 restart
[ ok ] Restarting apache2 (via systemctl): apache2.service.

以上。簡単なのでやっておくべし。

HTTPSになっている

NetflowをElastiflowで取り込む

Elasticsearchで取り込んだデータをKibanaでインデックス化まではいけたのだけれど, ダッシュボードにNetflowがないのでフォーラムに問い合わせしてみたら, 「ElastiFlowをおすすめする」と言われたのでそちらでやってみた。

手順はここにある。
https://github.com/robcowart/elastiflow

しかし必要リソースが多い・・・。

flows/sec (v)CPUs Memory Disk (30-days) ES JVM Heap LS JVM Heap
250 4 24 GB 305 GB 8 GB 4 GB
1000 8 32 GB 1.22 TB 12 GB 4 GB
2500 12 64 GB 3.05 TB 24 GB 6 GB

手順

  1. 確認
  2. Javaのヒープサイズ確認
  3. Logstash Pluginインストール
  4. Git Hubから関連ファイル取得・配置
  5. 設定ファイル編集
  6. プロセス再起動
  7. Kibanaでインデックス作成・ダッシュボードjsonを読み込む

アップデート

もろもろアップデートしておく。なお, Elasticsearchのバージョンは6.2.4。

yum update -y

Javaのヒープサイズ変更

It is recommended that Logstash be given at least 2GB of JVM heap. If all options, incl. DNS lookups (requires version 3.0.10 or later of the DNS filter), are enabled increase this to 4GB. 

とあったので初期値1G, MAX値を4Gへ変更。

vi /etc/logstash/jvm.options
# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space

#-Xms256m
#-Xmx1g
-Xms1g
-Xmx4g

Logstash Pluginインストール

# ./logstash-plugin install logstash-codec-sflow
Validating logstash-codec-sflow
Installing logstash-codec-sflow
Installation successful
# ./logstash-plugin update logstash-codec-netflow
Updating logstash-codec-netflow
Updated logstash-codec-netflow 3.13.2 to 3.14.0
# ./logstash-plugin update logstash-input-udp
Updating logstash-input-udp
Updated logstash-input-udp 3.3.2 to 3.3.3
# ./logstash-plugin update logstash-filter-dns
Updating logstash-filter-dns
Updated logstash-filter-dns 3.0.9 to 3.0.10

Git Hubから関連ファイル取得・配置・編集

% git clone https://github.com/robcowart/elastiflow.git
% ls -l elastiflow
total 32
drwxrwxr-x. 2 centos centos 75 May 24 20:02 kibana
-rw-rw-r--. 1 centos centos 1026 May 24 20:02 LICENSE.md
drwxrwxr-x. 3 centos centos 23 May 24 20:02 logstash
drwxrwxr-x. 2 centos centos 54 May 24 22:49 logstash.service.d
drwxrwxr-x. 2 centos centos 26 May 24 20:02 profile.d
-rw-rw-r--. 1 centos centos 28091 May 24 20:02 README.md

設定ファイル配置

# cp -r ./elastiflow/logstash/elastiflow/ /etc/logstash/

設定ファイル編集。
netflow以外使わないので, それ以外のファイルはdisableにした。

10_input_ipfix_ipv4.logstash.conf.disabled
10_input_ipfix_ipv6.logstash.conf.disabled
10_input_netflow_ipv4.logstash.conf
10_input_netflow_ipv6.logstash.conf.disabled
10_input_sflow_ipv4.logstash.conf.disabled
10_input_sflow_ipv6.logstash.conf.disabled
20_filter_10_begin.logstash.conf
20_filter_20_netflow.logstash.conf
20_filter_30_ipfix.logstash.conf.disabled
20_filter_40_sflow.logstash.conf.disabled
20_filter_90_post_process.logstash.conf
30_output.logstash.conf

インプットファイル編集

# vi 10_input_netflow_ipv4.logstash.conf

変更点。

host => "${ELASTIFLOW_NETFLOW_IPV4_HOST:172.16.10.50}"
port => "${ELASTIFLOW_NETFLOW_IPV4_PORT:9995}"

アウトプットファイル編集

# vi 30_output.logstash.conf

変更点。

hosts => [ "${ELASTIFLOW_ES_HOST:172.16.10.50:9200}" ]
user => "${ELASTIFLOW_ES_USER:elastic}"
password => "${ELASTIFLOW_ES_PASSWD:elastic}"

起動スクリプト配置

# cp -r ./elastiflow/logstash.service.d/ /etc/systemd/system/

起動スクリプト編集

# vi /etc/systemd/system/logstash.service.d/elastiflow.conf

変えたところは以下。

Environment="ELASTIFLOW_NAMESERVER=1.1.1.1"
Environment="ELASTIFLOW_ES_HOST=172.16.10.50"
Environment="ELASTIFLOW_ES_PASSWD=changeme"
Environment="ELASTIFLOW_NETFLOW_IPV4_HOST=172.16.10.50"
Environment="ELASTIFLOW_NETFLOW_IPV4_PORT=9995"

アプリケーションID登録。

# vi /etc/logstash/elastiflow/dictionaries/app_id.srctype.yml

Cisco841を登録。

"192.168.1.2": "c841m"

pipeline.ymlに以下追加。合わせてnetflowの行はコメントアウト。

# For ElastiFlow
- pipeline.id: elastiflow
path.config: "/etc/logstash/elastiflow/conf.d/*.conf"

プロセス再起動

#systemctl restart logstash
#systemctl daemon-reload

Kibanaにjson取り込み

「Management -> Save Objects -> Import」でGitから取得したelastiflow.dashboards.jsonをインポート。

できた!

ただ, うちの仮想マシンのスペック不足で結構な頻度でエラーが出る。
この辺は今の状況ではどうしようもないなー。

【メモ】elasticsearchアップグレードしたらエラーで起動しない件

Just a note。

こんなメッセージが出て起動しなかった。

java.lang.IllegalArgumentException: plugin [ingest-geoip] is incompatible with version [6.2.4]; was designed for version [6.1.2]
at org.elasticsearch.plugins.PluginInfo.readFromProperties(PluginInfo.java:237) ~[elasticsearch-6.2.4.jar:6.2.4]
at org.elasticsearch.plugins.PluginInfo.readFromProperties(PluginInfo.java:184) ~[elasticsearch-6.2.4.jar:6.2.4]
at org.elasticsearch.bootstrap.Spawner.spawnNativePluginControllers(Spawner.java:75) ~[elasticsearch-6.2.4.jar:6.2.4]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:167) ~[elasticsearch-6.2.4.jar:6.2.4]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:323) [elasticsearch-6.2.4.jar:6.2.4]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:121) [elasticsearch-6.2.4.jar:6.2.4]
at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:112) [elasticsearch-6.2.4.jar:6.2.4]
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86) [elasticsearch-6.2.4.jar:6.2.4]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:124) [elasticsearch-cli-6.2.4.jar:6.2.4]
at org.elasticsearch.cli.Command.main(Command.java:90) [elasticsearch-cli-6.2.4.jar:6.2.4]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:92) [elasticsearch-6.2.4.jar:6.2.4]
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:85) [elasticsearch-6.2.4.jar:6.2.4]

一度6.1.3へダウングレードして, ingest-geoipを削除。 その後またアップグレードで復旧。

NAT on a stick

例えばNATに対応していない機器(L3SW等)があったとして, それでもNATしなくてはならない場合。
図のようにワンアームでルータをつないでNATボックスとする構成が取れる。

図ではルータのアイコンになっているけれど, R1がNATに対応していないとき

ヘアピンNATやNAT on a Stick と呼ぶらしい。
Ciscoサイトを参照して検証する。
参照URL:スティック上のネットワーク アドレス変換

構成概要

    • 172.16.10.0/24 を172.20.10.0/24 へネットワークNATする。
    • NATポイントはR2。
    • VPC2は172.20.10.0/24のアドレスでアクセスする。

      そのため, R1では必然的にPBRを利用してVPC1の通信をR2へ転送する。

      Config

      ※ 抜粋
      R1 Config

      !
      interface Ethernet0/0
      description to R3
      ip address 192.168.2.1 255.255.255.0
      !
      interface Ethernet0/1
      description to R2
      ip address 10.10.10.1 255.255.255.0
      !
      interface Ethernet0/2
      description to R4
      ip address 192.168.1.1 255.255.255.0
      ip policy route-map PBR
      !
      ip route 172.16.10.0 255.255.255.0 192.168.1.2
      ip route 172.16.20.0 255.255.255.0 192.168.2.2
      ip route 172.20.10.0 255.255.255.0 10.10.10.2
      !
      ip access-list extended PBR
      permit ip 172.16.10.0 0.0.0.255 any
      !
      !
      route-map PBR permit 10
      match ip address PBR
      set ip next-hop 10.10.10.2
      !
      !

      R2 Config

      !
      interface Loopback0
      ip address 1.1.1.1 255.255.255.255
      ip nat outside
      ip virtual-reassembly in
      !
      interface Ethernet0/0
      description to R1
      ip address 10.10.10.2 255.255.255.0
      ip nat inside
      ip virtual-reassembly in
      ip policy route-map NAT
      !
      !
      ip nat inside source static network 172.16.10.0 172.20.10.0 /24 no-alias
      ip route 0.0.0.0 0.0.0.0 10.10.10.1
      ip route 172.20.10.0 255.255.255.0 Ethernet0/0
      !
      ip access-list extended PBR
      permit ip 172.16.10.0 0.0.0.255 any
      permit ip any 172.20.10.0 0.0.0.255
      !
      !
      route-map NAT permit 10
      match ip address PBR
      set interface Loopback0
      !

      パケットフロー
      CiscoルータにおけるNATの処理は公式ページにあるとおり。
      参考:NATの処理順序
      今回関係する箇所を太文字で。

      1. IPSec ACL チェック
      2. 復号化
      3. 入力ACLチェック
      4. 入力レート制限をチェック
      5. 入力アカウンティング
      6. Web キャッシュにリダイレクト
      7. ポリシー ルーティング
      8. ルーティング
      9. Inside から Outside への NAT
      10. クリプト(暗号化用のマップのチェックとマーク)
      11. 出力アクセス リストをチェック
      12. CBAC検査
      13. TCP インターセプト
      14. 暗号化
      15. キューイング
      1. IPSec ACL チェック
      2. 復号化
      3. 入力ACLチェック
      4. 入力レート制限をチェック
      5. 入力アカウンティング
      6. Web キャッシュにリダイレクト
      7. OutsideからInsideへの NAT
      8. ポリシー ルーティング
      9. ルーティング
      10. クリプト(暗号化用のマップのチェックとマーク)
      11. 出力アクセス リストをチェック
      12. CBAC 検査
      13. TCP インターセプト
      14. 暗号化
      15. キューイング

      プチ解説

      @R1
      NAT変換後のアドレスをR2へ向けます。

      ip route 172.16.20.0 255.255.255.0 192.168.2.2

      VPC1からのトラフィックをR2(NATボックス)へ捻じ曲げます。

      interface Ethernet0/2
      description to R4
      ip address 192.168.1.1 255.255.255.0
      ip policy route-map PBR
      !
      !
      ip access-list extended PBR
      permit ip 172.16.10.0 0.0.0.255 any
      !
      !
      route-map PBR permit 10
      match ip address PBR
      set ip next-hop 10.10.10.2

      @R2
      物理IFをinsideに指定します。

      interface Ethernet0/0
      description to R1
      ip address 10.10.10.2 255.255.255.0
      ip nat inside
      ip virtual-reassembly in

      Loopbackをoutsideに指定します。

      interface Loopback0
      ip address 1.1.1.1 255.255.255.255
      ip nat outside
      ip virtual-reassembly in

      NAT設定。IOS15以降はno-aliasが必要です。

      ip nat inside source static network 172.16.10.0 172.20.10.0 /24 no-alias

      global insideのアドレスを自身に持たせるためStatic Routeを物理IFへ指定します。
      が, この構成ではなくてもいけました。(NATの処理フロー見ると不要な気がするんですが未だ理解できず。)

      ip route 172.20.10.0 255.255.255.0 Ethernet0/0

      NAT対象となる通信をPBRでLoopbackインタフェース(outside IF)へ送り込みます。これでinside-outsideに偽装します。

      interface Ethernet0/0
      description to R1
      ip address 10.10.10.2 255.255.255.0
      ip nat inside
      no ip virtual-reassembly in
      ip policy route-map NAT
      !
      !
      ip access-list extended PBR
      permit ip 172.16.10.0 0.0.0.255 any
      permit ip any 172.20.10.0 0.0.0.255
      !
      !
      route-map NAT permit 10
      match ip address PBR
      set interface Loopback0
      !

      通信確認。

      VPCS> ping 172.16.20.1

      84 bytes from 172.16.20.1 icmp_seq=1 ttl=251 time=1.802 ms
      84 bytes from 172.16.20.1 icmp_seq=2 ttl=251 time=3.606 ms
      84 bytes from 172.16.20.1 icmp_seq=3 ttl=251 time=4.168 ms
      84 bytes from 172.16.20.1 icmp_seq=4 ttl=251 time=3.517 ms
      84 bytes from 172.16.20.1 icmp_seq=5 ttl=251 time=3.150 ms


      R2#sh ip nat translations
      Pro Inside global Inside local Outside local Outside global
      icmp 172.20.10.10:28052 172.16.10.10:28052 172.16.20.1:28052 172.16.20.1:28052
      icmp 172.20.10.10:28308 172.16.10.10:28308 172.16.20.1:28308 172.16.20.1:28308
      icmp 172.20.10.10:28564 172.16.10.10:28564 172.16.20.1:28564 172.16.20.1:28564
      icmp 172.20.10.10:28820 172.16.10.10:28820 172.16.20.1:28820 172.16.20.1:28820
      icmp 172.20.10.10:29076 172.16.10.10:29076 172.16.20.1:29076 172.16.20.1:29076
      --- 172.20.10.10 172.16.10.10 --- ---
      --- 172.20.10.0 172.16.10.0 --- ---
      R2#

      VPCS> ping 172.20.10.10

      84 bytes from 172.20.10.10 icmp_seq=1 ttl=59 time=2.539 ms
      84 bytes from 172.20.10.10 icmp_seq=2 ttl=59 time=4.796 ms
      84 bytes from 172.20.10.10 icmp_seq=3 ttl=59 time=5.276 ms
      84 bytes from 172.20.10.10 icmp_seq=4 ttl=59 time=4.397 ms
      84 bytes from 172.20.10.10 icmp_seq=5 ttl=59 time=6.855 ms

      VPCS>

      注意点

      Loopback IFへトラフィックを投げるのでCPU処理に落ちます。
      スループットが気になる場合は物理的に(もしくはトランク等して)2本インタフェースを用意したほうがベター。
      IOS12台と15台でコマンドが若干違うので古いバージョンを使うときは確認しましょう。

      EVE-NGインストールメモ

      GNS3の代わりになるシミュレータ。
      VMWare Workstation上で動かせるので入れてみた。

      事前準備

      – Win10 + VMWare Workstation にOVAファイルを展開して利用する。
      ここからコミュニティ版をダウンロード。
      http://www.eve-ng.net/index.php/community
      – Windowsのクライアントパックもダウンロード&インストール。
      http://www.eve-ng.net/downloads/windows-client-side-pack

      – 仮想マシンをインポート。
      プロセッサのIntel VT-xにチェックを入れる。

      – 起動。ログイン。
      root/eve

      – ログインするとパスワード変えろと言われる。

      – 続いてhostname。そのまま。

      – ドメイン。そのまま。

       – IPアドレスどうするかと。変わると面倒なのでStatic。

      – 適当に。

      – サブネットマスク入れる。

      – ゲートウェイ設定。VMWare Playerは「1」ではなく「2」がゲートウェイになるそうな。

      – DNSも同じにして。この後セカンダリも入れるので今流行りの「1.1.1.1」にした。

      – NTP無し。

      – Proxy無し。

      – で完了&再起動。

      – 改めてログインする。

      – いけてる。

      – ブラウザでアクセス。
      admin/eve

      – GNS3ではプロジェクトだったけれど, EVE-NGではラボ(Lab)だそうな。

      その後。

      – sshでログイン。
      – IOS/IOUをアップロード。ライセンス設定。
        IOSはbinからimageへファイル変更。permission変更。IDLE-PC設定。
      http://www.eve-ng.net/documentation/howto-s/64-howto-add-dynamips-images-cisco-ios

      – パーミッション変更

      # /opt/unetlab/wrappers/unl_wrapper -a fixpermissions

      個人的な感想ですが, 慣れればGNS3よりもこっちのほうが良いかもしれない。なんとなく安定しているし。
      しかし, ホストPCのVMWare Playerの上で動かす場合, リモートからアクセスできないので, 例えばUbuntu上でサービスとして動かすGNS3のようにX Forwardingできる方が検証環境としては場所にとらわれなくてよいかなとも思った。