はるかのブログ

プロキシサーバのユーザー認証を求められる環境下で、yumとwgetを使えるようにする。

【yumの設定】

/etc/yum.confにプロキシサーバの情報を追記する。

・proxy=http://プロキシーサーバ:ポート番号/　　　←最後の「スラッシュ（/）まで必要っぽい」

・proxy_username=ユーザー名

・proxy_password=パスワード

 

【wgetの設定】

/etc/wgetrcにプロキシサーバの情報を追記する。

・http_proxy = http://プロキシーサーバ:ポート番号/　　　←最後の「スラッシュ（/）まで必要っぽい」

・use_proxy = on

・proxy_user=ユーザー名

・proxy_password=パスワード

 

ユーザー名とパスワードを平文で追記するのは気が引けるけど、いちいちプロキシを指定したくないのでガマンする。

CentOSでは、Windowsのフォーマットであるntfsを認識できないので、fuseを使ってntfsを認識させてみる。

 

以下、やり方。

 

１．wget http://dag.wieers.com/packages/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

２．rpm -ivh rpmforge-release-0.3.6-1.el5.rf.i386.rpm

３．yum install fuse fuse-ntfs-3g dkms dkms-fuse

４．modprobe fuse

５．mount -t ntfs-3g /dev/sda1 /mnt/

「ウチとA社、ウチとB社、A社とB社は干渉させないでSFTPでファイルのやり取りをしたい」と言った用件が来た。

 

単純に所有グループ分けで、パーミッション770とかにしても、WinSCPとかで接続されると「どんなデータが存在するか？」が見えてしまう。

今回はそれすらさせたくないらしい。

 

んで、いろいろぐぐってみると、chrootを使用するのがあった。

openssh4.8まではパッチを当ててchrootを行なう必要があったらしいが、openssh4.9からは標準で組み込まれたみたい。

使っているCentOS5.2はopensshのバージョンは5.1なので、いけそう♪

 

 以下、やり方。

１．yumでrsshをインストールする。

　　# yum -y install rssh

 

２．rsshのソースファイルの中にある、chroot作成の際のスクリプトを使うので、wgetなりでrsshをダウンロードする。

　　※chroot作成用のスクリプト以外は使用しないので、以下にrssh-2.3.0のスクリプトだけを置いておきます。

　　mkchroot.sh

 

３．上記のmkchroot.shの引数に、chrootで作成したいディレクトリを指定して実行する。

　　# ./mkchroot.sh /var/chroot/home1

 

４．chroot作成用のスクリプトは、homeディレクトリが作成されないので、手動で作成する。

　　# mkdir /var/chroot/home1/home

 

５．chrootを使用するユーザを作成する。ホームディレクトリと合わせて、シェルをrsshに指定する。

　　# useradd -d /var/chroot/home1/home/user -s /usr/bin/rssh user

　　# passwd user

 

６．/etc/passwdファイルに追加されたchrootユーザーの情報を、chrootディレクトリ内のetc/passwdファイルにコピーする。

 

７．/etc/rssh.confを修正し、「allowsftp」の行のみコメントを外す。　※scpやrsyncはコメントアウトのまま。

 

８．sshd_configを修正し、chroot用のディレクトリを作成する。

　　Subsystem       sftp    internal-sftp

　　Match Group home1

　　PasswordAuthentication yes

　　AllowAgentForwarding no

　　AllowTcpForwarding no

　　ChrootDirectory /var/chroot/home1

 

９．sshdを再起動して終了

 

これで、SFTPのみしか利用できない、不要なファイルを閲覧できないユーザーが作成された。

そもそもの要件である、「受け渡し」は、同様の手順で同じグループに所属するchrootユーザーを追加すれば良い。

前回導入した「qmailmrtg」用の対応です。

※qmailmrtgはmultilog形式にしか対応していないので、syslog形式のログでは集計してくれません。

 

日本語の情報が少ないので、自身の覚書の為に。

 

【/service/clamd/run】

#!/bin/sh
exec 2>&1
exec /bin/setuidgid qscand /usr/sbin/clamd

  

【/service/clamd/log/run】

#!/bin/sh
exec /bin/setuidgid qscand /bin/multilog t s16777215 n40 /var/log/clamd

 

【/service/spamd/run】

#!/bin/sh
MAX=10
exec spamd -i -m ${MAX} –username=qscand –syslog=stderr 2>&1

 

【/service/spamd/log/run】

#!/bin/sh
exec /bin/setuidgid qscand /bin/multilog t s16777215 n40 /var/log/spamd

 

いろいろ失敗も踏んだが、とりあえず現状は上記run内容で稼動している。

テストデータとして250MBのファイルの転送速度を計測することになった。

適当にゴミファイルをzipでまとめても良いんだけど、ある程度正確な値を欲しかったので、きっちり250MBのファイルを作成した時のコマンドメモ。

 

dd if=/dev/zero of=testdate count=262144000 bs=1

CenｔOS5.2で作ったpostfixの、logwatchのメールサイズが大きくて（1MBぐらい）、かなり読み辛いかったので、postfix-logwatchというものを入れてみた。

qmailの時は、logwatchのscriptでqmail-sendやらqmail-pop3やらあったので、”集計をしない！”って逃げ方をしたけど、postfixのscriptは１つだけしかないから、逃げることが出来ないっぽい｡･ﾟ･(ﾉ∀`)･ﾟ･｡

 

以下、インストール方法

wget http://www.mikecappella.com/logwatch/release/postfix-logwatch-1.37.08.tgz

tar zxf postfix-logwatch-1.37.08.tgz

cd postfix-logwatch-1.37.08

make install-standalone

mv /usr/local/etc/postfix-logwatch.conf /usr/share/logwatch/default.conf/services/postfix.conf

chown root:root /usr/share/logwatch/default.conf/services/postfix.conf

chmod 644 /usr/share/logwatch/default.conf/services/postfix.conf

mv /usr/local/bin/postfix-logwatch /usr/share/logwatch/scripts/services/postfix

chown root:root /usr/share/logwatch/scripts/services/postfix

chmod 755 /usr/share/logwatch/scripts/services/postfix

 

公式サイトにはこれで動作するはずだけど、手動で試してみるとlogwatchメールに以下のエラーが表示された。 

 

 ——————— Postfix Begin ————————

 “-T” is on the #! line, it must also be used on the command line at /usr/share/logwatch/scripts/services/postfix line 1.
 
 ———————- Postfix End ————————-

 

まあ、安直にscriptファイルの1行目を、”#!/usr/bin/perl -T”から”#!/usr/bin/perl -w”に変更して正常に動くようになった。

正直待ち疲れた・・・。

旧サーバ側でユーザーデータの圧縮に1時間、VPN経由でデータ落とすのに3時間、新サーバにアップロードするのに1時間半。

たったこれだけの作業で5時間以上も待ちぼうけ　(´ー｀)y─┛~~・・・orz

メールデータの欠損も無くサーバ移行は完了したけど、サーバ上に残っていた既読メール（cur）がクライアントPC側で2重に受信してしまう結果になった。

多い人だと2000件程度、過去に受信したメールを再度受信する結果となってしまう。

まぁ、MTAが変わるのでしかたないと言えばそれまでだけど、事前にユーザーにクライアントPC側の設定変更の呼びかけをするべきだったな。

昨年の9月から計画していた会社のメールサーバのリプレース。

今回のリプレースは、情報漏えい対策として「社内ネットワーク以外からはPOP接続させない」という運用に変える事が最大の意図になっている。

あと、「外部ドメインへの送信メールを数年間保存する」って事も合わせて行う。

送信メールの保存のソフトウェアの初期設定以外、環境構築やドキュメント作成を全て１人でやってきたので、スキル的に得た物は大きかったと思うが、変わりに睡眠時間と偏頭痛と肩こりに悩まされた半年だった・・・。

とりあえず、今回のリプレースで行った事をシステム担当の観点からまとめておきます。
（構築の詳細はそのうちに書いていきます。）

１.MTAの変更
　 社内のSMTP/POP3のMTAを「qmail」から「postfix+devecot」に変更
　 DMZに「qmail」をリレー用のSMTPとして設置

2.メーリングリストの変更
　 qmailの「alias」から「Mailman」に変更。
　 基本的な運用は変わらないけど、MLを介したメールの件名に連番付加を行っていく。

3.メール利用ルールの強化
　 今までは配送容量の制限しか行っていなかったが、「自動転送禁止」、「分割送信禁止」を新たに設定した。
　 ただし、「自動転送禁止」、「分割送信禁止」は社内からの送信のみを対象として、社外から送られてくるメールに対する制限は行わない。

4.ウィルスチェック機能の導入
　 SMTPリレーサーバにSpamassassinとClamAVを導入して、自前のメールゲートウェイを構築。
　 通過する全てのメールのチェックを行い、ウィルスを検知した場合は「受信先へ通知する」ようにした。

5.VPNの導入
　 会社貸与のノートPCを使用している場合、VPN経由でメールサーバに接続できるようにした。
　 VPNサーバはOpenVPNで構築し、クライアントに渡す秘密鍵などの利用上限を90日までとする。

6.WEBメールの契約
　 VPNを使えない従業員用に、WEBメールの契約も行った。
　 VPNと同様に利用の上限を90日までとして、恒久的に利用する場合、90日ごとに利用申請を提出してもらうようにする。

ウィルスチェック機能の導入は、「社内からの送信メール」も精査の対象としているため、どのくらいのシステム負荷が掛かるか分からないので、状況を見つつ設定をいじるつもり。

VPNの利用もWEBメールの利用も、そもそも当社では開発も運用もしていない（業務委託）なので、休日などに急いで会社のメールをチェックしなくてはならない事は存在しないはず。
もし緊急事態が起きても、ちんたらメールのやり取りを行える暇があるなら、関係者に電話するし。

本当に社外からメールの利用が必要なのか？と疑問が残るが、兎にも角にも明日のリプレース作業をチャッチと終わらせて、ゆっくり寝たいです。