More from: linux

またbashにパッチが当った模様?

bashの脆弱性に対する対策で先週bash-3.2.22からbash-3.2-33.el5_10.4に上げたばかりなんだけど、今日yumでチェックしたらbash-3.2-33.el5_11.4が出ていたらしいので早速アップデートした。
とはいえ、このバージョンはRHEL5のバージョンが5.11なので出たらしく、CentOS用のel5_10.4との違いは全く無いらしい。
それでも出来るだけ新しくしたほうが気分的に良いからそのままにしておこう(笑)。

3.0-27(EL4)のほうはOracleのサーバを見てもbash-3.0-27.0.3以降はまだ無いみたいだな。
こちらも引き続きチェックをするように心掛けておこうっと。

人気ブログランキングへ←クリックしてくれると嬉しいです。

何故今頃?

先週の金曜日(9/26)に書いた「bashの脆弱性対策」の被参照数が今日になって増えている。
週末の休みが終って対策に奔走する羽目になったサーバー管理者の方々が多いのだろうか?
まぁ先の記事にはyumが使えない場合の手順も書いたからそのせいかな?

先の記事を書いた後にさらにパッチが公開されているので、ホントは「bashが「CVE-2014-7169」に仮対応」とか「さらにパッチが当っている模様(bash)」のほうが参考になると思うけど(汗)。

人気ブログランキングへ←クリックしてくれると嬉しいです。

さらにパッチが当っている模様(bash)

先日セキュリティホールが公開されて騒ぎになっているbash。
私のところで使っている古いLinuxで使用可能なbashも対策が適用されたVer.と入れ替えた。
昨日の夕方インストールしたのは
bash-3.0-27.0.2.el4.src.rpmからビルドし直したbash-3.0-27.0.2.el4.。
bashが「CVE-2014-7169」に仮対応参照。
今朝方チェックするとさらに新しい
bash-3.0-27.0.3.el4.src.rpm
が公開されているので、早速ダウンロードして(ダウンロード元は先の記事参照)
# rpmbuild –rebuild bash-3.0-27.0.3.el4.src.rpm
リビルドし、
# rpm -Uvh bash-3.0-27.0.3.i386.rpm
でインストールした。
検証用のコード
# env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
を実行すると前バージョンの3.0-27.0.2.el4の時には出力されていた
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
が抑制され、
this is a test
のみとなったが、これで正常の筈。

人気ブログランキングへ←クリックしてくれると嬉しいです。

bashが「CVE-2014-7169」に仮対応

「bashの脆弱性対策」で書いたbashの脆弱性に関して、未対応だった残りの脆弱性(CVE-2014-7169で報告)に仮に対応したbash-3.0-27.0.2.el4がリリースされていた。
先の記事同様ソースパッケージ
https://oss.oracle.com/el4/SRPMS-updates/bash-3.0-27.0.2.el4.src.rpm
をダウンロードして
# rpmbuild –rebuild bash-3.0-27.0.2.el4.src.rpm
でrpmパッケージをビルドして
# rpm -Uvh bash-3.0-27.0.2.i386.rpm
で適用完了。
CentOS版のbash-3.2-33.el5_10.4も出ているとのことなので、yumでアップデートが出来るようになる筈。

情報を下さったちょろさんありがとうございます。

人気ブログランキングへ←クリックしてくれると嬉しいです。

ちょっと新しくなったVer.は駄目だった(汗)

bashの脆弱性対策を行ったが、bash-3.2-33.el5.1.src.rpmを使ってビルドしようとしたら「とあるヘッダファイルが無い」って言われてコンパイル出来なかった。
bash-3.2-33.el5.1.i386.rpmをそのまま入れようとしたらglibcのVer.が古くて入れられないのでソースから入れ直そうと思ったけど、やっぱり無理だったか(汗)。

人気ブログランキングへ←クリックしてくれると嬉しいです。

bashの脆弱性対策

9/24にbashの脆弱性が発見されたと公表されてから一部では騒ぎになっている。
bashをインストールしていないシステムでは無関係だけど、使い勝手の良いshellなので各ディストリビューションではデフォルトのshellになっているものもあり、その場合は対処が必要となる。
まずは自システムにbashがインストールされているかどうかをチェックし、入っていたなら下記を実行して結果を見る。
$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
実行結果として
vulnerable
this is a test
と表示されたらこの脆弱性の影響を受ける可能性があるので、bashにパッチを適用する必要がある。
RedHat系でyumが使えるなら
# yum uodate bash
でbashパッケージをアップデートすればOK。

再度テスト用の上記コマンドを実行して
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
this is a test
と表示されれば一応は対策出来たことになる(今回のパッチでも脆弱性が残ると報告されているので、再度のパッチの適用が必要になる)。

yumが使えない古いシステムならup2dateを使うか、bashパッケージをダウンロードして自分でインストールする必要がある。

私の場合は古いシステムで1台だけbashの2系が入っていて、さらにyumもup2dateも使えないサーバがあり、結局その1台だけはソースパッケージを探し出してrpmパッケージをビルドしてインストールすることで対処した。
ソースパッケージはOlacle Linuxの配布サイトから
https://oss.oracle.com/el4/SRPMS-updates/bash-3.0-27.0.1.el4.src.rpm
をダウンロードし、
# rpmbuild –rebuild bash-3.0-27.0.1.el4.src.rpm
でrpmパッケージをビルドして
# rpm -Uvh bash-3.0-27.0.1.i386.rpm
でインストールした。

人気ブログランキングへ←クリックしてくれると嬉しいです。

早朝から・・・

昨夜は早くに寝てしまったので今朝は早起き。
は良かったんだけど、そんな時に限ってユーザーからSOSのコール。
いつもならそろそろ起きようかという時間だったけど、今日は早起きしていたので受けたところ、「メールの受信が出来ない」とのこと。
急いで身支度をして職場に駆けつけ問題のメールサーバーをチェックすると/var/の下が満杯orz
すぐに古いログ等を消してディスクを空けて受信は可能になった。
さらに調べると全く使われていないアカウント向けへのメールが大量に残っていることが判明したのでそれも削除。
そのアカウントに配信されるように設定してあるaliasもアカウント自体も削除したので、しばらくは大丈夫な筈。

他のサーバーからの受信も拒否していたので、問題のサーバーに向けてメールを送ろうとしていた他サーバーにはqueueが溜まっていた。
それら溜まっていたqueueを吐き出したところ自分のクライアントで受信が出来たので対応は完了。
sendmailで溜まっているqueueを強制的に吐き出すには
#sendmail -q
でOK。
溜まっているかをチェックするには
#sendmail -bp
を実行し、
Mail queue is empty
と出ればqueueは溜まっていない。
逆に
Mail Queue (1 request)
–Q-ID– –Size– —–Q-Time—– ————Sender/Recipient————
xxxxxxxx 9999999 ”曜日” ”月” ”日” ”時刻” <”送信者”/”送信先”>
のように表示されれば残っているということ。

人気ブログランキングへ←クリックしてくれると嬉しいです。

またやっちゃった・・・orz

先週サーバーにfetchmailを使ってメールサーバからメールを取り込むように設定した。
今朝になってそのサーバーからスプールが満杯で配信出来ないと警告のメールが来たので調べてみると、取り込んだメールをメールサーバ側に残すようにしていたために同じメールを何度も取り込んでしまい、その結果スプールが満杯になっていた。
あれ?何で何回も同じメールを取り込むかなぁ?と思って調べてみると、.fetchmailrcファイルにはkeepオプションを記述してあるのに、実際の取り込み時にはallオプションを付けていたorz
これじゃメールサーバに残したメールを毎回取り込んでしまうのも当たり前だ・・・
早速allオプションを外したので、今後は一度取り込んだメールは取り込まなくなる筈。
滅多にやらない設定なので油断したなぁ・・・

人気ブログランキングへ←クリックしてくれると嬉しいです。

メールアドレスに使える文字の話

「メールが送れない」
と連絡が来た。
「送ろうとするとなんかエラーとなる。」
と言うのでエラーメッセージを読んで貰ったところ、
「501 Bad recipient address syntax」
というようなエラーが出ている模様だ。
このエラーは読んだ通り「宛先アドレスの書き方に問題がある」状態なので、送ろうとした相手先アドレスを見ると先頭と@の直前に「-(ハイフン)」が使われている。
メールアドレスに使える文字はRFC 2822内の”Internet Message Format”セクションで規定されていて、「-(ハイフン)」を先頭に使うことは特に禁止はされていない。
ところが、先頭に「-(ハイフン)」があるとUNIX系OSのコマンドに文字列を渡す際にオプションと混同される危険性があるので、UNIX系OS上で動作するMTAによっては先頭に「-(ハイフン)」を使うことを禁じているものがある(Postfix等)。
今回のエラーはまさにこれに引っかかった様で、現在のところはこの宛先にメールを送る手段が存在しない(Postfixを使っている場合はオプションで許可することも出来る様だ)ので、送るのを諦めて貰うことになった(汗)。

プロバイダによってはユーザーが希望するアドレスを使うことが出来るが、先頭の文字を英小文字に限定しているところがある(ソフトバンクとかOCNとか)。
反対に制限を設けていない(もしくは過去に設けていなかった)プロバイダやキャリアもあるが、そのようなアドレスを持っている人は受け取れないメールもあるということになるので、出来れば先頭には英小文字を使うようにしたほうが良さそうだ。

参考までに携帯電話各キャリアでの使用文字の制限は以下の通り(2013年10月10日現在)
au
・Eメールネーム文字数が、30文字まで利用可能です。
・半角英数字、小文字、「- (ハイフン)」、「. (ピリオド/ドット)」、「_ (アンダーバー)」が使用できます。
・「.」をアドレス内での連続使用や「.」をEメールネームの最初/最後に使用することはできません。また最初に数字の「0」を使用することもできません。

docomo
・半角英数字および「_」(アンダーバー)、「.」(ピリオド)、「-」(ハイフン)の記号にて、3字以上30字まで設定することができます。
ただし、「.」は「..」などのように連続で使用することや@マークの直前で使用することはできません。
・「スペース(空白)」は使用できません。
・英字を入力する場合、大文字小文字の区別はありません。すべて小文字で表示されます。(注:大文字の使用は不可ということ)
・先頭文字は英文字にしてください。

ソフトバンク
・文字数 半角文字 3字~30字
・文字の種類 半角英数字 「-」(ハイフン)、「.」(ドット)、「_ 」(アンダーバー)
・ひとつ目の文字は英文字のみ 「1abc@i.softbank.jp」などは、設定できません。
・英文字については、小文字のみ使用できます。
・「-」(ハイフン)、「.」(ドット)、「_ 」(アンダーバー)以外の記号は、ご利用いただけません。
 例 : 「a bc@i.softbank.jp」 など
・「@」直前の「.」(ドット) は設定できません。
 例 : 「abc.@i.softbank.jp」 など
・「.」(ドット)の連続使用は設定できません。
 例 :  「a..bc@i.softbank.jp」 など
・携帯電話の社名、および、サービス名に関わる文字は、設定できません。
 例 : 「softbank.abc@i.softbank.jp」など

これを見ると各社で細かい違いはあるが、文字数(30字まで)や文字種(英小文字と数字の他は「-」「.」「_」のみ)は共通だというのが判る。
面白いのはソフトバンクの「携帯電話の社名、および、サービス名に関わる文字は、設定できません。」と言う項目で、例では”softbank”という文字列は駄目となっているが、”docomo”とか”ezweb”とかも駄目なのかな?(笑)

人気ブログランキングへ←クリックしてくれると嬉しいです。

人気ブログランキングへ←クリックしてくれると嬉しいです。