2018年4月2日月曜日

tcpdump入門① (tcpdumpでよく使うオプションたち)

サーバー間通信がうまく動作しない場合などに、パケットキャプチャをして調査することがある。Linuxの場合、パケットキャプチャツールとして、tcpdumpが定番となっている。名前がTCPとなっているが、UDPの通信も確認できる。

本記事では2回にわけて、tcpdumpの使い方を説明する。1回目となる今回はtcpdumpの基礎的な使用方法と、よく使うオプションの説明を行う。次回では、実際にtcpdumpで取得したTCP通信のパケットキャプチャのデータを見て、どのような通信が行われているかを読み解いてみることにする。

tcpdumpの使い方

まずは、調査対象のインターフェース番号を確認する必要がある。-Dオプションで確認ができる。通常、CentOS 7では、3番が通常のネットワークインターフェースとなるようだ。

# tcpdump -D
------------------------------
1.nflog (Linux netfilter log (NFLOG) interface)
2.nfqueue (Linux netfilter queue (NFQUEUE) interface)
3.eno16780032
4.any (Pseudo-device that captures on all interfaces)
5.lo
------------------------------

インタフェースを指定し、すべてのパケットをキャプチャするコマンドは以下の通りとなる。なお、tcpdumpを終了する場合は、Ctrl+Cにて行うこと。

# tcpdump -i 3
------------------------------
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno16780032, link-type EN10MB (Ethernet), capture size 65535 bytes
10:30:56.887081 IP 192.168.11.110.ssh > 192.168.11.82.62780: Flags [P.], seq 2961489592:2961489832, ack 1367601915, win 274, length 240
10:30:56.887192 IP 192.168.11.82.62780 > 192.168.11.110.ssh: Flags [.], ack 240, win 8210, length 0
10:30:56.887514 IP 192.168.11.110.53846 > 192.168.11.31.domain: 17612+ PTR? 82.11.168.192.in-addr.arpa. (44)
10:30:56.887647 IP 192.168.11.31 > 192.168.11.110: ICMP 192.168.11.31 udp port domain unreachable, length 80
10:30:56.887674 IP 192.168.11.110.34744 > 192.168.11.31.domain: 17612+ PTR? 82.11.168.192.in-addr.arpa. (44)

~(以下略)~
------------------------------

上記のようにキャプチャはできるものの、すべてのパケットがキャプチャされてしまうことから大量の情報が表示されてしまい、解析することが困難となる。このような場合は、次節で述べるフィルター機能を使うとよい。

tcpdumpでよく使うフィルター機能

tcpdumpでは、条件に合致したパケットのみ表示させるフィルター機能が存在する。よく使うフィルター機能について、以下に記載する。

特定のホストの通信をキャプチャする

# tcpdump -i 3 host 192.168.11.112

特定のプロトコルの通信をキャプチャする

# tcpdump -i 3 port 25

特定のホストの特定のプロトコルの通信をキャプチャする

複数条件指定にて対応する。andやorを使えばよい。

# tcpdump -i 3 host 192.168.11.112 and port 25

送信元ホストと送信先ホストを指定する

送信元はsrc、送信先はdstで指定することができる。ただし、srcとdstを指定した場合は、戻りパケットがキャプチャされないため、通信の全体を確認したい場合は不向きである。

# tcpdump -i 3 src 192.168.11.112 and dst 192.168.11.110

tcpdumpでよく使うオプション

フィルター以外によく使うオプションを以下に記載する。

キャプチャの表示を詳細化する

以下3種類があり、下に行くほど詳細になるようだが、具体的にどのように詳細になるかというと不明である。とりあえず詳細にしたければ、一番詳細な-vvvにしておくとよいと思われる。

tcpdump -i 3 -v host 192.168.11.112
tcpdump -i 3 -vv host 192.168.11.112
tcpdump -i 3 -vvv host 192.168.11.112

IPアドレスをホスト名に変換させないで表示させる

tcpdumpは、デフォルトでIPアドレスをhostsやDNSで名前解決して表示する。IPアドレスの方がわかりやす場合もあるので、名前解決を抑止する場合は-nオプションを付与する。

tcpdump -i 3 -n host 192.168.11.112

プロトコル名をポート番号で表示させる

tcpdumpは、デフォルトでポート番号をプロトコル名に変換して表示する(たとえば、22番ポートならsshと表示される)。しかしこの機能は、かえってキャプチャを見る際にわかりにくくなることもあるので、そのような場合は、-nnオプションを使ってポート番号で表示させることができる。

tcpdump -i 3 -nn host 192.168.11.112

通信内容をASCIIで表示させる

-Aオプションを使うことで、実際の通信内容がASCIIで表示させる。これにより、通信内容を視覚的に理解しやすくなる。

tcpdump -i 3 -A host 192.168.11.112

以下表示例。

------------------------------
17:40:21.060227 IP 192.168.11.110.54942 > 192.168.11.112.25: Flags [P.], seq 29:146, ack 171, win 237, options [nop,nop,TS val 2436234930 ecr 3717090658], length 117
E.....@.@......n...p.....N.Hn..U...........
.5....MbMAIL FROM:<ex-1@example.com> SIZE=632 BODY=8BITMIME
RCPT TO:<ex-1@example.com> ORCPT=rfc822;ex-1@example.com
DATA
------------------------------

パケットキャプチャをファイルで出力する

-wオプションの後にファイル名を指定することで、パケットキャプチャをファイルとして出力することができる。

なお、-s 0のオプションは、古いtcpdumpでは1つのパケットの取得上限サイズが96バイトとなっており、それ以上の情報は切り捨てられてしまうので、65535バイトまで受け取ることができるようにする設定となる。ただし、最近のtcpdump(少なくともCentOS 7のtcpdump)ではデフォルト65535となったようなので、-sオプションは省略しても問題ない。

tcpdump -i 3 -s 0 -w test.cap host 192.168.11.112

出力されたファイルを確認すると、tcpdumpユーザーでファイルが作成されていることがわかる。

# ls -l
------------------------------
-rw-r--r--  1 tcpdump tcpdump  4277  3月 31 07:22 test.cap
------------------------------

このファイルはWiresharkで開くことができる。Wiresharkによって通信の流れがグラフィカルかつ整理されて表示することができるようになり、通信解析が非常にはかどる。


以上がtcpdumpの基本的な使用方法となる。次回は、tcpdumpで実際の通信の流れを調べてみることにする。

★次回はこちら↓
tcpdump入門② (パケットキャプチャからTCP通信を読み解く)
https://tech-mmmm.blogspot.jp/2018/04/tcpdump-tcp.html

2018年3月19日月曜日

ZabbixでAllowRoot=1をせずに/var/log/messagesなどを監視する方法

LinuxのOSログといえば/var/log/messagesとなるが、このログファイルはroot権限がないと読み込みができないログファイルとなっている。

◆Redhat系Linuxの場合
# ls -l /var/log/messages
------------------------------
-rw------- 1 root root 134324  3月 16 12:50 /var/log/messages
------------------------------

◆Debian系Linuxの場合
$ ls -l /var/log/messages
------------------------------
-rw-r----- 1 root adm 157  3月 11 06:25 /var/log/messages
------------------------------

通常、Zabbix Agentのプロセスはzabbixユーザーの権限で動作するため、このログファイルが監視できず困る場面がある。回避策としては、Zabbix Agentをroot権限で動作させるようにすることが考えられる。Zabbix Agentをroot権限で動作させるためには、zabbix_agentd.confに以下の設定を加えればよい。

# cat /etc/zabbix/zabbix_agentd.conf | grep AllowRoot
------------------------------
### Option: AllowRoot
AllowRoot=1
------------------------------

しかし、上記方法は、Zabbix Agentがroot権限で動くことになり、セキュリティ面で推奨されない設定となる。そこで、今回はAllowRoot=1せずにログ監視できる方法を考えてみた。

zabbixユーザーをrootグループに追加して対応する

zabbixユーザーをrootグループ(後述するが、Debian系Linuxではadmグループ)に追加し、監視対象ログの権限をrootグループにて読み取り可能とすることで対応する。Linuxディストリビューションごとに若干手順が異なるため、Redhat系LinuxとDebian系Linuxの手順をそれぞれ記載することにする。

Redhat系Linuxの場合

/var/log/messagesの権限を再掲する。

# ls -l /var/log/messages
------------------------------
-rw------- 1 root root 134324  3月 16 12:50 /var/log/messages
------------------------------

権限は600となっているおり、rootグループのユーザーであっても読み取りができないため、まずは権限変更を行う。

# chmod 640 /var/log/messages
# ls -l /var/log/messages
------------------------------
-rw-r----- 1 root root 134324  3月 16 12:50 /var/log/messages
------------------------------

権限を変えても、ログローテーションされる際にもとの権限(600)に戻ってしまうため、ログローテーション時に、新しいファイルの権限を640として作成する設定を以下の通り追加する。

# cat /etc/logrotate.d/syslog
------------------------------
/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
{
    missingok
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
    create 640 root root
}
------------------------------

最後にzabbixユーザーをrootグループに所属させる。

# id zabbix
------------------------------
uid=995(zabbix) gid=993(zabbix) groups=993(zabbix)
------------------------------
# usermod -aG root zabbix
# id zabbix
------------------------------
uid=995(zabbix) gid=993(zabbix) groups=993(zabbix),0(root)
------------------------------

Debian系Linuxの場合

/var/log/messagesの権限を再掲する。

$ ls -l /var/log/messages
------------------------------
-rw-r----- 1 root adm 157  3月 11 06:25 /var/log/messages
------------------------------

Redhat系Linuxと異なり、admグループに読み取り権限が付いている。したがって、zabbixユーザーをadmグループに所属させるだけで対処可能である。

$ id zabbix
------------------------------
uid=111(zabbix) gid=116(zabbix) groups=116(zabbix)
------------------------------
$ sudo usermod -aG adm zabbix
$ id zabbix
------------------------------
uid=111(zabbix) gid=116(zabbix) groups=116(zabbix),4(adm)
------------------------------

Zabbixにて確認

zabbixユーザーで読み込み権限のないファイルを監視している場合、該当のアイテムに「ZBX_NOTSUPPORTED」のエラーが表示され、ステータスが「取得失敗」となっているはずである。


ログ監視対象のサーバーのZabbix Agentのログからも、エラーが出ていることがわかる。

# tail -100 /var/log/zabbix/zabbix_agentd.log | grep messages
------------------------------
  4870:20180317:220745.694 cannot open "/var/log/messages"': [13] Permission denied
  4870:20180317:220815.697 cannot open "/var/log/messages"': [13] Permission denied
  4870:20180317:220845.700 cannot open "/var/log/messages"': [13] Permission denied
  4870:20180317:220845.700 active check "log[/var/log/messages,"@messages word",,,skip]" is not supported
------------------------------

zabbixユーザーに対して、必要な権限を付与し、再度監視状況を確認してみる。設定変更後数分待つとエラーが消え、ステータスが「有効」となった。


2018年3月14日水曜日

Postfixで"454 4.7.1 Relay access denied"で送信が失敗する

Postfixでメール送信を行う際に、/var/log/maillogに以下エラーが出力されて、送信が拒否されることがある。

------------------------------
Feb 17 08:26:31 t1110rh72 postfix/smtpd[10936]: connect from unknown[192.168.11.82]
Feb 17 08:26:31 t1110rh72 postfix/smtpd[10936]: NOQUEUE: reject: RCPT from unknown[192.168.11.82]: 454 4.7.1 <test2@example100.com>: Relay access denied; from=<ex2-1@example2.com> to=<test2@example100.com> proto=ESMTP helo=<[192.168.11.82]>
Feb 17 08:27:36 t1110rh72 postfix/smtpd[10936]: disconnect from unknown[192.168.11.82]
------------------------------

これはメールクライアントにおいてもエラーとして表示される。


エラー原因

Postfixのmain.cfの以下2つの設定値が適切に設定されていないことが原因となる。
  • mynetworks
  • smtpd_relay_restrictions
エラー発生時の設定内容を抜粋する。

------------------------------
mynetworks = 127.0.0.0/8
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
------------------------------

smtpd_relay_restrictionsは、メールをリレーをする際の制限ルールを記載する。デフォルトで、「permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination」が設定されており、それぞれの意味は以下の通りとなる。
  • permit_mynetworks:mynetworksに記載されたクライアントからのメールリレーを許可
  • permit_sasl_authenticated:SASL認証されたメールのリレーを許可
  • defer_unauth_destination:不明な宛先からのメールリレーを一時的なエラーコード(4xx)で拒否
上記の3つのルールは先頭から順番に処理されるようだ。今回の場合、mynetworksにメールクライアントのIPアドレス登録がされておらず、SASL認証もしない設定だったため、defer_unauth_destinationの制限に該当し、「Relay access denied」となった。

したがって、エラーを回避するためには、メールクライアントのIPアドレスをmynetworksに登録すればよい。例えば、メールクライアントのIPアドレスが192.168.11.82であれば以下のように記載する。

------------------------------
mynetworks = 127.0.0.0/8, 192.168.11.82
------------------------------

参考

・Postfix Configuration Parameters - smtpd_relay_restrictions
http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions

2018年3月12日月曜日

RaspbianなどのDebian系Linuxでスタティックルートを追加する方法

自宅のネットワーク環境は、仮想ルータ-であるVyOSを使って2つのセグメントに分割している。そのため、2つのセグメント間の通信を正常に実施するために、スタティックルートの設定を実施する必要がある。

先日Raspberry Piを自宅環境に導入する際も、同様にスタティックルートの設定が必要となったが、Raspberry PiのOSであるRaspbianは、CentOSなどのRed Hat系のLinuxと勝手が違ったこともあり、対応に少々苦労した。

今回は備忘録として、Raspbianでスタティックルートを追加した際の手順を記載することにする。なお、RaspbianはDebian系のLinuxとなるため、Ubuntu等の他Debian系Linuxでも同様の手順となると想定される。

環境について

今回はRaspberry Pi Zero Wに対して設定を行っており、Raspbianのバージョンは以下の通りとなる。

$ lsb_release -a
------------------------------
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 9.1 (stretch)
Release:        9.1
Codename:       stretch
------------------------------

スタティックルート設定手順 (一時的に追加)

取り急ぎスタティックルートを追加したい場合は、routeコマンドを利用すればよい。構文は以下の通り。

route add -net <ネットワークアドレス> netmask <サブネットマスク> gw <ゲートウェイ> metric 1 <インターフェース名>

例として、192.168.11.0/24のゲートウェイを192.168.33.31にしたい場合は、以下の通り設定する。

$ sudo route add -net 192.168.11.0 netmask 255.255.255.0 gw 192.168.33.31 metric 1 wlan0

確認コマンドはrouteとなる。黄色網掛けのルートが追加されていることがわかる。ただし、あくまで一時的に追加するだけであり、OS再起動をすると消えてしまうので注意。

$ route
------------------------------
カーネルIP経路テーブル
受信先サイト    ゲートウェイ    ネットマスク   フラグ Metric Ref 使用数 インタフェース
default         192.168.33.1    0.0.0.0         UG    302    0        0 wlan0
192.168.11.0    192.168.33.31   255.255.255.0   UG    1      0        0 wlan0
------------------------------

スタティックルート設定手順 (恒久的に追加)

OS再起動してもスタティックルートを消えないようにするためには、「/etc/network/if-up.d/static-routes」という設定ファイル(というかスクリプト)を新規に作成し、起動時にスタティックルートが追加がされるようにすればよい。

$ sudo vi /etc/network/if-up.d/static-routes
------------------------------
#!/bin/sh
# Add Static Route
sleep 10
route add -net 192.168.11.0 netmask 255.255.255.0 gw 192.168.33.31 metric 1 wlan0
------------------------------

上記の通りスクリプトになっているので、実行権限を与えておく。

$ sudo chmod +x /etc/network/if-up.d/static-routes
$ ls -l /etc/network/if-up.d/
------------------------------
-rwxr-xr-x 1 root root  703  7月 26  2011 000resolvconf
-rwxr-xr-x 1 root root  484  1月 23  2017 avahi-daemon
-rwxr-xr-x 1 root root  972  6月 18  2017 openssh-server
-rwxr-xr-x 1 root root  112  3月  7 21:52 static-routes
-rwxr-xr-x 1 root root 1483  6月  2  2015 upstart
lrwxrwxrwx 1 root root   32 10月 14 21:18 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh
------------------------------

これで、OS再起動時に本スクリプトが実行され、スタティックルートが追加されるようになる。

なお、sleepコマンドで10秒の待ち時間を入れている理由は、DHCPにてIPアドレスを取得する前に本スクリプトが実行されてしまった場合、「SIOCADDRT: ネットワークに届きません」というエラーにてスタティックルートの追加に失敗するためである。何回か私の環境で試したところ、5秒だと失敗することがあるため、10秒と設定するのがよさそうだ。

【参考】「/etc/rc.local」で対応する方法

今回は「/etc/network/if-up.d/static-routes」というファイルにて設定する方法としているが、「/etc/rc.local」もOS起動時に実行されるスクリプトになっており、同様にsleepとrouteコマンドを記載することでスタティックルートの追加が実現できる。

どちらで実装するかは好みの問題ではあるが、スタティックルートはネットワークの設定となるため、static-routesを使う対応が設計としてはわかりやすいと思われる。

2018年3月5日月曜日

Amazonアウトレットで「可」の評価になっていたWi-Fiルーターを買ってみた

自宅のWi-Fiルーターは、2年ほど前からNECのAterm WG1800HP2を使っている。特に故障もなく安定して動作しているのだが、以下TP-LinkのC2300というルーターの評判がよさそうだったので、買い替えを検討していた。



ある日、Amazonアウトレットで出品がされており、通常13,172円であるものが、10,854円とお手頃価格になっていた(約18%の値引き)。


商品のコンディションは「中古品 - 可」となっていたが、安かったので買ってみることにした。

Amazonアウトレットの「中古品 - 可」の商品とは、いったいどのような状態で届くのか気になる人もいると思うので、本記事では写真付きで商品のコンディションをレポートしようと思う。

Amazonアウトレットとは

Amazonアウトレットの商品は、返品された商品や倉庫内で傷がちょっと付いたものなど、新古品の商品をお手頃価格で販売する仕組みとなる。以下、Amazon公式から抜粋となる。

------------------------------
Amazonアウトレットでは、お客様から返品された商品や、倉庫内で梱包に傷を負った商品のうち、商品の状態が良いもの、食品および飲料については倉庫内で保管され賞味期限が近づいたものを、お手頃な価格で販売しています。
------------------------------

今回購入したWi-Fiルーターに記載されていた商品のコンディションは以下の通り。

------------------------------
コンディション: 中古品 - 可 - 商品の数か所に小さな傷があります . 外装に多少の損傷があります . Amazonアウトレットは、Amazon.com グループの一部ですので、Amazon.co.jpが発送やカスタマーサービス業務を行います
------------------------------

Amazonプライム会員なので、購入した翌日に早速届いたので、商品を確認してみることにする。

外装を確認

商品は通常のAmazonダンボールで届いた。ダンボールから商品を取り出し、まず外装を確認してみる。

商品の外装は、何も言われなければ新品のものと区別はつかないレベルとなっていた。


ただし、通常の商品と違い、「検品済」のシールが貼られている。


また、Amazonアウトレットのシールで封がされていることも確認できる。おそらく検品のため、一度箱を開けているためと思われる。


注意して見ると、確かに外装に細かい傷があるようにはみえる。しかし、この程度であればよほど神経質でなければ気になるレベルではないだろうし、そもそも外装は後ほど捨てるものなので、特に問題にはならない。


機器を確認

外装から取り出すと、さらに中に箱で梱包されていた。


箱を開けてみる。本体、アンテナ3本、ACアダプター、Cat5eのLANケーブル、説明書が収まっている。検品のためか、一度ビニール袋の封を開けた形跡が確認できる。



本体の傷がつきそうなプラスチック光沢の部分は、保護シールが貼られているで剥がしてみる。


保護シールを剥がして確認してみたところ、傷はどこにも見つけることができなかった。


念のため電源を入れてみると、問題なく起動した。もちろん、各種設定も問題なく実施でき、現在は自宅のブロードバンドルーターとして正常に稼働している。


まとめ

Amazonアウトレットで「可」となっている商品であったが、外装や梱包に一度検品された形跡があるものの、気になるような傷は見当たらず、新品同様であった。

検品された商品が嫌であるとか、きれいな外装の箱を残しておきたいといったようなことがなければ、積極的に購入しても問題はないだろう。

人気の投稿