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

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

人気の投稿