UPSと通信してみる!

UPSの通信ケーブルが届いたので実際に通信を行ってみました。

まずは設定済みのconfでapctesが実行できるか?です。
apctestを実行してみるとあっさりと繋がりました。
EEPROMのバッテリー交換日付を書き換えてランタイム較正を実行。
ランタイム較正が終わってもランタイム時間が短い・・・
バッテリーの不良かと思い実際にUPSのコンセントを抜いてみる。
確かにバッテリーメーターの最低目盛までは4分程度で到達(負荷40%程度)
しかしそこから実際に電源が落ちるまでは20分近く持つのでした。

これってバッテリーの電圧低下が実残量があっても早いってことなんだろうな。
純正に使われているメーカーではなくFiam社製のバッテリーと交換したのが仇になったのだろうか?
UPSがバッテリーの残量を電圧で検知している以上はどうしようもないのだろうか・・・
負荷10%程度だと40分くらいと表示されるが実際は1時間半くらい持つんですが。

とりあえずUPSとの通信は正常に行われるのでこの辺は今後の課題ということにして終了。
apcupsdを実行するとwebから見るCGIもMRTGも正常に値が取得出来ています。

UPSの状態をMRTGで表示する!

まだUPSのケーブルは届いてません・・・
しかし先に設定しちゃいます(笑)

とりあえずUPS監視に必要なパッケージをインストールします。
今回はapcupsdを使用します。
apt-get install apcupsd
apt-get install acpupsd-cgi
二つ目の奴はUPSの状態をCGIで表示するためのものです。
debianではapache2のCGIディレクトリにうまくインストールされました。

apcupsdの設定は沢山サイトがあるのでそれを参考にさせてもらいました。

そしてMRTGの設定に入ります。
こちらもサイトを参考に設定しました。
実際にMRTGのページを表示してみましたがまだUPSとケーブルで繋がっていないので
当然ながら全て0で表示されます・・・
あとはUPSのケーブルが届くのを待つばかりです。

#—————————————————————–
# UPS温度、容量
#—————————————————————–
Target[upsTemperature_Charge]: `/sbin/apcaccess status | awk ‘/^ITEMP/ {print $3*10} /^BCHARGE/ {print $3*10}’ && uname -n`
MaxBytes[upsTemperature_Charge]: 1200
Options[upsTemperature_Charge]: gauge, growright, absolute, nopercent, noinfo, unknaszero
YTicsFactor[upsTemperature_Charge]: 0.1
Factor[upsTemperature_Charge]: 0.1
YLegend[upsTemperature_Charge]: UPS Capa.&Char.
ShortLegend[upsTemperature_Charge]:
LegendI[upsTemperature_Charge]: 容量(%)
LegendO[upsTemperature_Charge]: 温度(deg.)
Legend1[upsTemperature_Charge]: バッテリィ容量 [BCHARGE]
Legend2[upsTemperature_Charge]: 温度 [ITEMP]
Title[upsTemperature_Charge]: UPS温度、容量
PageTop[upsTemperature_Charge]:

UPS温度、容量 for SmartUPS 700J

System:APC SmartUPS 700J
Maintainer:Root

#—————————————————————–
# UPS入、出力電圧
#—————————————————————–
Target[upsVoltage]: `/sbin/apcaccess status | awk ‘/^LINEV/ {print $3*10} /^OUTPUTV/ {print $3*10}’ && uname -n`
Maxbytes[upsVoltage]: 1200
Options[upsVoltage]: gauge, growright, absolute, nopercent, noinfo, unknaszero
YTicsFactor[upsVoltage]: 0.1
Factor[upsVoltage]: 0.1
YLegend[upsVoltage]: UPS Voltage(v)
ShortLegend[upsVoltage]: V
LegendI[upsVoltage]: IN
LegendO[upsVoltage]: OUT
Legend1[upsVoltage]: 入力電圧 [LINEV]
Legend2[upsVoltage]: 出力電圧 [OUTPUTV]
Title[upsVoltage]: UPS入、出力電圧
PageTop[upsVoltage]:

UPS入、出力電圧 for SmartUPS 700J

System:APC SmartUPS 700J
Maintainer:Root

USB-シリアル変換ケーブルを認識

前回の妄想から2日。
秋月電子からUSB・シリアル変換ケーブルが届きました。

kernelも前もってコンパイルしていたので早速USBに挿してみると・・・
認識しました!
usbserial_generic 2-1:1.0: usb_probe_interface – got id
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
pl2303 2-1:1.0: usb_probe_interface
pl2303 2-1:1.0: usb_probe_interface – got id
pl2303 2-1:1.0: pl2303 converter detected
usb 2-1: pl2303 converter now attached to ttyUSB0
usbcore: registered new driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver

ただ色々調べてた時にkernel標準ドライバはコマンドの送信が出来なくてパッチが必要と複数のサイトに書いてあった。
なんでも秋月電子で売ってる変換ケーブルのチップはPL-2303ではなくPL-2303XとXが付くらしいです。
そこでkernel標準のPL-2303ドライバでコマンド送信が可能か試してみることに。
しかしクロスのシリアルケーブルが家にありません・・・
UPSのシリアルケーブルもまだ届いてません・・・
どうやって確認するか悩みましたがシリアル接続のモデムがあったのでそれで試すことに!

まずcuコマンドが使えるように apt-get install cu
ttyUSB0のパーミッションを変更しときます。
テストなので適当に・・・ chmod 777 /dev/ttyUSB0
モデムの電源を入れていざ接続開始!

# cu -l /dev/ttyUSB0
Connected.
at[ENTER]
OK
at+fmfr?[ENTER]
ROCKWELL

OK
at+fmdl?[ENTER]
AC/K56

OK
~.[ENTER]

Disconnected.

※参考:オモイノホカ日々徒然
※既にリンク先のサイトはなくなっているようです

ATコマンドの送受信が出来ますね。
kernel2.6.16.16のPL-2303ドライバはPL-2303Xでもパッチなしで動くようです。
USB-シリアル変換ケーブルの動作確認はこれにて終了!

LS-GLで電源管理

自宅のUPSにはACP製のSmart-UPS700Jを使用しています。
このUPSにはPCとの通信にシリアルポートを利用します。

ですがLS-GLはシリアルポートを持っていません。
またLS-GLは電源OFF状態で通電なし>通電状態にしても
電源復帰による自動起動は不可能なのでシャットダウン機能のみとなります。

※ここからは接続機器を購入するまでの妄想になります(笑)
とりあえずUSB機器は使用できるのでUSB-シリアル変換ケーブルでやろうと思います。
安いシリアル変換機器を探したところズバ抜けて安いのがありました!
みなさんもご存知の秋月電子にありますね。
USB・シリアル変換ケーブル
USB・シリアル変換ケーブル

この変換ケーブルはPL-2303というチップを使っているようです。
RedHat用のドライバソースもDL出来るようです。
PL-2303 Software and Drivers
•ld_pl2303_v0728.rar (Linux RH)
※Linux カーネルバージョン 2.4.31 以上は標準で組み込まれています。

試しにRedHat用のドライバをDLして中身のドキュメントを見てみました。
ドライバを使用するにはKernelの再構築が必要なようです。
そこでLS-GLのGPLソースに含まれるKernelのconfigにPL-2303があるか確認してみました。
なければとりあえずKernelでシリアルーUSB変換をモジュール扱いにして
上のサイトにあるドライバをコンパイル&インストールすれば使えるはずです。
しかしKernelのconfigにはしっかりとPL-2303が存在します!
これはKernelコンパイルと標準モジュールのインストールだけで動きそうですね。

とりあえずここまでは機器を購入したら試すつもりです。

その後はUPS管理のアプリを選定することになります。
また他のNASもLS-GLがシャットダウンする際にリモートで一緒にシャットダウンさせる計画もあります。
が、今はまだ妄想の段階です(笑)

Linuxのメモリ使用量の計算方法

Linuxのメモリ使用量の計算は単純にusedではなく
メモリ使用量=total - (free + buffers + cached) と計算するようです。

そこでmrtgのメモリ部分の設定を以下のように変更しました。

Target[memory]: 1.3.6.1.4.1.2021.4.5.0&1.3.6.1.4.1.2021.4.3.0:public@localhost
– 1.3.6.1.4.1.2021.4.6.0&1.3.6.1.4.1.2021.4.4.0:public@localhost
– 1.3.6.1.4.1.2021.4.14.0&1.3.6.1.4.1.2021.4.1.0:public@localhost
– 1.3.6.1.4.1.2021.4.15.0&1.3.6.1.4.1.2021.4.1.0:public@localhost

これでバッファやキャッシュを引いた実メモリの使用量が正しく表示されるようです。

アタックに対処するルールを追加

特定のポートに自動で繰り返しアクセスしIDやPASSを盗もうとする行為が日常的に起きています。
これは気付かなくてもネットに繋いでいる以上はどなたも経験されていることです。
通常利用ではルーター経由であればフォワーディングの宛先が無いのでパケットが破棄され特に問題はありません。
(偽装パケットだと問題になります)

ここで問題になるのはサーバーを公開されている方です。
サーバーをルーターの外側に設置するのはもちろんですが
静的NATで特定のポートを公開している場合も注意が必要です。

試しにsshのポートを開けてみるとかなりのアタックがあることがログから分かると思います。
IPフィルターでアタックの多い国のアクセスを遮断すればかなり減りますが
それでもアタックの形跡はログに残ったりします。

これらのアタックをiptablesでブロックするのが今回の目的です。

時間当たりのアクセス回数で制限する為にiptablesのrecent機能を使います。

※以下のサイトを参考に設定しました。
Netfilter Extensions HOWTO: New netfilter matches

基本的な構文は以下のように書くようです。

# iptables -A FORWARD -m recent –name badguy –rcheck –seconds 60 -j DROP
# iptables -A FORWARD -p tcp -i eth0 –dport 139 -m recent –name badguy –set -j DROP

オプションの説明を読んでみると色々と説明が書いてありますね。
自分の環境に合わせて書き換えてみましょう。

iptables -A INPUT -p tcp -i eth1 –dport 22 -m recent –name SSH -m state –state NEW –set
iptables -A INPUT -m recent –name SSH -i eth1 -p tcp –dport 22 -m state –state NEW –update –seconds 60 –hitcount 6 –rttl -j DROP

この設定内容はeth1デバイスのTCP22番ポートへ60秒間に6回以上アクセスがあったホストを拒否するようになっています。

–name SSH ルールの名前は他のルールと重複しない名前ならなんでも良いようです。
-iオプションのeth1と書いてある部分は自分の環境のWAN側に接続されているデバイスに書き換えます。
–dport 22 の22は規制の対象とするポートを指定します。
–seconds 60 最後のアクセスからログをさかのぼる秒数の範囲を指定します。つまり「○秒間の間に」となります。
–hitcount 6 上の–secondsで設定した時間ログの中に何回以上ヒットするものを対象にするかを指定します。

これは一度実行してもrebootすると設定は消えてしまいます。
他のiptablesの設定と同じように起動時等に実行されるように設定を行って下さい。
※個人的には起動時にスクリプトで読み込んでますがiptablesの設定を一括して
  iptables-save、iptables-restoreなどで行っても良いと思います。

最後に・・・
この機能ではゆっくりと繰り返されるアタックには対応出来ません。
他の機能と組み合わせてセキュリティを高めることで高い効果を発揮出来る機能だと思います。

主にPC、車・バイク、トイガンなどについて書いてます