新規記事の投稿を行うことで、非表示にすることが可能です。
2016年03月28日
sendmailによる送信者アドレス(from:ヘッダー)による規制A
前回記事の続き。
引き続き、sendmailで、送信者アドレス(from:ヘッダー)による規制を検証してみる。
前回記事のSubject:ヘッダの内容をベースに調査を進め、設定をアレンジして検証を行う。
sendmail.mcに下記の通り、送信者アドレス(from:ヘッダー)による規制用のローカルルールセットを追加する。
アクセス制御対象を下記のとおり、記載する。(/etc/mail/from_rejects)
各文字の先頭は必ず、タブ文字を挿入する。また、文字列の一致は「含む」の考え方
・メールサーバ側での単体テスト
sendmailテストモード(-bt)で起動し、先述のリストファイルに記述されている内容(ここでは、「james、brown」)を含む送信者アドレスにすると、「553 Rejected , indicates spam Caused by from: header.」がリターンされ、
リストファイルに記述されていない内容(ここでは、「test@log.simalab.com」)をむ送信者アドレスにすると、拒否されず、そのままリターンされることを確認。
前回記事の検証環境のとおり、送受信テストを実施する。
・送信(メールクライアント)側
※メールクライアント側でfrom:ヘッダーを詐称するため、telnetでメールサーバに接続
受信(メールサーバ)側のログ
送信者アドレス(from:ヘッダー)による規制用リストファイル( /etc/mail/from_rejects)は、今回はmakemapコマンドなどで、バイナリ形式にしていないため、当該ファイル編集時は、下記のとおり、sendmailの再読み込みを行わないと反映されなかったため、注意。
送信者アドレス(from:ヘッダー)による規制用リストファイル( /etc/mail/subjects_rejects)に日本語(ダブルバイト文字)名を挿入し、動作検証を行ったものの、意図した動作は得られなかったため、そこにも注意。
・検証で利用した設定ファイル一式
https://github.com/shi4669/ServerConfig/tree/master/sendmail/etc/mail
続きを読む...
引き続き、sendmailで、送信者アドレス(from:ヘッダー)による規制を検証してみる。
参照URL
前回記事のSubject:ヘッダの内容をベースに調査を進め、設定をアレンジして検証を行う。
sendmail.mcアクセス規制設定
sendmail.mcに下記の通り、送信者アドレス(from:ヘッダー)による規制用のローカルルールセットを追加する。
LOCAL_CONFIG
F{PartFrom} -o /etc/mail/from_rejects
HFrom: $>CheckFrom
LOCAL_RULESETS
SCheckFrom
R$* $={PartFrom} $* $: REJECTFROM
R$* REJECTFROM $* $#error $: "553 Rejected , indicates spam.Caused by from: header."
送信者アドレス(from:ヘッダー)による規制用リストファイル作成
アクセス制御対象を下記のとおり、記載する。(/etc/mail/from_rejects)
各文字の先頭は必ず、タブ文字を挿入する。また、文字列の一致は「含む」の考え方
[root@mx-ns mail]# cat /etc/mail/from_rejects
brown
james
[root@mx-ns mail]#
sendmail.mcファイルコンパイル
[root@mx-ns mail]# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
sendmail再起動
[root@mx-ns mail]# service sendmail restart
sm-client を停止中: [ OK ]
sendmail を停止中: [ OK ]
sendmail を起動中: [ OK ]
sm-client を起動中: [ OK ]
[root@mx-ns mail]#
送信者アドレス(from:ヘッダー)による規制制御の動作確認
・メールサーバ側での単体テスト
sendmailテストモード(-bt)で起動し、先述のリストファイルに記述されている内容(ここでは、「james、brown」)を含む送信者アドレスにすると、「553 Rejected , indicates spam Caused by from: header.」がリターンされ、
リストファイルに記述されていない内容(ここでは、「test@log.simalab.com」)をむ送信者アドレスにすると、拒否されず、そのままリターンされることを確認。
[root@mx-ns mail]# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter
> Chefk^\終了
[root@mx-ns mail]# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter
> CheckFrom james※アクセス規制対象
CheckFrom input: james
CheckFrom returns: $# error $: "553 Rejected , indicates spam.Caused by from: header."
> CheckFrom brown@sample.com※アクセス規制対象
CheckFrom input: brown @ sample . com
CheckFrom returns: $# error $: "553 Rejected , indicates spam.Caused by from: header."
> CheckFrom test@log.simalab.com※アクセス規制対象外
CheckFrom input: test @ log . simalab . com
CheckFrom returns: test @ log . simalab . com
送受信テスト(アクセス制御)
前回記事の検証環境のとおり、送受信テストを実施する。
・送信(メールクライアント)側
※メールクライアント側でfrom:ヘッダーを詐称するため、telnetでメールサーバに接続
[ment@log ~]$ telnet 192.168.3.21 25
Trying 192.168.3.21...
Connected to 192.168.3.21.
Escape character is '^]'.
220 mx-ns.simalab.com ESMTP Sendmail 8.14.4/8.14.4; Sun, 20 Mar 2016 11:49:19 +0900
HELO localhost
250 mx-ns.simalab.com Hello [192.168.3.6], pleased to meet you
MAIL FROM:test@log.simalab.lom(エンベロープ)
250 2.1.0 test@log.simalab.lom... Sender ok
RCPT TO:testuser@simalab.com(エンベロープ)
250 2.1.5 testuser@simalab.com... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
From: james@example.com(fromヘッダー(アクセス制御対象)
To:testuser@simalab.com(toヘッダー)
this is from header test(本文)
.
553 5.0.0 Rejected , indicates spam.Caused by from: header.(553がリターンされ、アクセス拒否成功)
受信(メールサーバ)側のログ
メールサーバ側のログ(送信者アドレス(from:ヘッダー)でのアクセス制御が成功していることを確認)
Mar 20 11:50:15 mx-ns sendmail[7380]: u2K2nJ7u007380: ruleset=CheckFrom, arg1= james@example.com, relay=[192.168.3.6], reject=553 5.0.0 Rejected , indicates spam.Caused by from: header.
Mar 20 11:50:33 mx-ns sendmail[7380]: u2K2nJ7u007380: from=test@log.simalab.lom, size=73, class=0, nrcpts=1, msgid=<201603200249.u2K2nJ7u007380@mx-ns.simalab.com>, proto=SMTP, daemon=MTA, relay=[192.168.3.6]
Mar 20 11:50:33 mx-ns sendmail[7380]: u2K2nJ7u007380: to=testuser@simalab.com, delay=00:01:00, pri=30073, stat=Rejected , indicates spam.Caused by from: header.
(送信者アドレス(from:ヘッダー)による規制用リストファイル( /etc/mail/from_rejects)編集時
送信者アドレス(from:ヘッダー)による規制用リストファイル( /etc/mail/from_rejects)は、今回はmakemapコマンドなどで、バイナリ形式にしていないため、当該ファイル編集時は、下記のとおり、sendmailの再読み込みを行わないと反映されなかったため、注意。
[root@mx-ns mail]# service sendmail reload
日本語(ダブルバイト文字)件名による規制
送信者アドレス(from:ヘッダー)による規制用リストファイル( /etc/mail/subjects_rejects)に日本語(ダブルバイト文字)名を挿入し、動作検証を行ったものの、意図した動作は得られなかったため、そこにも注意。
設定ファイル一式
・検証で利用した設定ファイル一式
https://github.com/shi4669/ServerConfig/tree/master/sendmail/etc/mail
続きを読む...
タグ:sendmail
2016年03月27日
sendmailによる送信者アドレス(from:ヘッダー)による規制@
前回記事の規制方法をさらに応用して、sendmailで、送信元アドレス(from:ヘッダー)による規制を検証してみる。
引き続き、こちらの環境を利用。
今回の規制についても、前回記事と同様、/etc/mail/accessで規制される送信元アドレスであるエンベロープ(From:)の規制ではなく、Data部以下の各ヘッダー情報、(from::ヘッダ)の箇所に関しての規制を検証する。
下記のtelnetのシーケンスでは、下記の個所の規制の検証。
「Sendmailクックブック」には、「レシピ6.9 特殊なヘッダを実行する」にて、from:ヘッダではないが、To:ヘッダによる規制の方法が紹介されている。こちらと前回記事の規制方法とでアレンジを加えて検証をしていく。
続きは、次回。
検証環境
引き続き、こちらの環境を利用。
送信者アドレス(from:ヘッダー)による
今回の規制についても、前回記事と同様、/etc/mail/accessで規制される送信元アドレスであるエンベロープ(From:)の規制ではなく、Data部以下の各ヘッダー情報、(from::ヘッダ)の箇所に関しての規制を検証する。
下記のtelnetのシーケンスでは、下記の個所の規制の検証。
[ment@log ~]$ telnet 192.168.3.21 25
Trying 192.168.3.21...
Connected to 192.168.3.21.
Escape character is '^]'.
220 mx-ns.simalab.com ESMTP Sendmail 8.14.4/8.14.4; Sun, 20 Mar 2016 09:06:35 +0900
HELO localhost
250 mx-ns.simalab.com Hello [192.168.3.6], pleased to meet you
MAIL FROM:test@log.simalab.lom (エンベロープFrom:)
250 2.1.0 test@log.simalab.lom... Sender ok
RCPT TO:testuser@simalab.com (エンベロープTo:)
250 2.1.5 testuser@simalab.com... Recipient ok
DATA
-------- Data部 --------
354 Enter mail, end with "." on a line by itself
From:test@log.simalab.com (from:ヘッダー)(ここの内容による規制)
Subject:test (Subject:ヘッダー
.
250 2.0.0 u2K06ZOt006596 Message accepted for delivery
参考文献
「Sendmailクックブック」には、「レシピ6.9 特殊なヘッダを実行する」にて、from:ヘッダではないが、To:ヘッダによる規制の方法が紹介されている。こちらと前回記事の規制方法とでアレンジを加えて検証をしていく。
続きは、次回。
中古価格 |
タグ:sendmail
sendmailによる件名(Subject:ヘッダー)による規制A
前回記事の続き。
引き続き、sendmailで、件名(Subject:ヘッダー)による規制を検証してみる。
前回記事紹介の参考文献の内容をベースに調査を進め、下記のURLに行きついたので、下記の設定をアレンジ。
http://lists.roaringpenguin.com/pipermail/mimedefang/2004-March/020796.html
sendmail.mcに下記通り、件名(Subject:ヘッダー)による規制用のローカルルールセットを追加する。
アクセス制御対象を下記のとおり、記載する。(/etc/mail/subjects_rejects)
各文字の先頭は必ず、タブ文字を挿入する。また、文字列の一致は「含む」の考え方
・メールサーバ側での単体テスト
sendmailテストモード(-bt)で起動し、先述のリストファイルに記述されている内容(ここでは、「master」)を件名にすると、「553 Rejected , indicates spam Caused by Subject:」がリターンされ、リストファイルに記述されていない内容(ここでは、「test」)を件名にすると、拒否されず、そのままリターンされることを確認。
前回記事の検証環境のとおり、送受信テストを実施する。
・送信(メールクライアント)側
・送信(メールクライアント)側へのリターン
受信(メールサーバ)側のログ
・送信(メールクライアント)側
受信(メールサーバ)側のログ
件名(Subject:ヘッダー)による規制用リストファイル( /etc/mail/subjects_rejects)は、今回はmakemapコマンドなどで、バイナリ形式にしていないため、当該ファイル編集時は、下記のとおり、sendmailの再読み込みを行わないと反映されなかったため、注意。
件名(Subject:ヘッダー)による規制用リストファイル( /etc/mail/subjects_rejects)に日本語(ダブルバイト文字)件名を挿入し、動作検証を行ったものの、意図した動作は得られなかったため、そこにも注意。
・検証で利用した設定ファイル一式
https://github.com/shi4669/ServerConfig/tree/master/sendmail/etc/mail
引き続き、sendmailで、件名(Subject:ヘッダー)による規制を検証してみる。
参照URL
前回記事紹介の参考文献の内容をベースに調査を進め、下記のURLに行きついたので、下記の設定をアレンジ。
http://lists.roaringpenguin.com/pipermail/mimedefang/2004-March/020796.html
sendmail.mcアクセス規制設定
sendmail.mcに下記通り、件名(Subject:ヘッダー)による規制用のローカルルールセットを追加する。
LOCAL_CONFIG
F{PartSubjects} -o /etc/mail/subjects_rejects
HSubject: $>CheckSubject
LOCAL_RULESETS
SCheckSubject
R$* $={PartSubjects} $* $: REJECTSUBJECT
R$* REJECTSUBJECT $* $#error $: "553 Rejected , indicates spam Caused by Subject:"
件名(Subject:ヘッダー)による規制用リストファイル作成
アクセス制御対象を下記のとおり、記載する。(/etc/mail/subjects_rejects)
各文字の先頭は必ず、タブ文字を挿入する。また、文字列の一致は「含む」の考え方
[root@mx-ns mail]# cat /etc/mail/subjects_rejects
master
unsecured visa
Invoice #
Your Order #
[root@mx-ns mail]#
sendmail.mcファイルコンパイル
[root@mx-ns mail]# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
sendmail再起動
[root@mx-ns mail]# service sendmail restart
sm-client を停止中: [ OK ]
sendmail を停止中: [ OK ]
sendmail を起動中: [ OK ]
sm-client を起動中: [ OK ]
[root@mx-ns mail]#
件名(Subject:ヘッダー)による規制制御の動作確認
・メールサーバ側での単体テスト
sendmailテストモード(-bt)で起動し、先述のリストファイルに記述されている内容(ここでは、「master」)を件名にすると、「553 Rejected , indicates spam Caused by Subject:」がリターンされ、リストファイルに記述されていない内容(ここでは、「test」)を件名にすると、拒否されず、そのままリターンされることを確認。
[root@mx-ns mail]# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter
> CheckSubject master ※アクセス規制対象
CheckSubject input: master
CheckSubject returns: $# error $: "553 Rejected , indicates spam Caused by Subject:"
> CheckSubject test ※アクセス規制対象外
CheckSubject input: test
CheckSubject returns: test
送受信テスト(アクセス制御)
前回記事の検証環境のとおり、送受信テストを実施する。
・送信(メールクライアント)側
メールクライアント(規制内容に抵触する件名 「Invoice # 1221」)で送信
[ment@log ~]$ mail testuser@simalab.com
Subject: Invoice # 1221
This is test1
.
EOT>
・送信(メールクライアント)側へのリターン
メールクライアント側に「553 5.0.0 Rejected , indicates sapm Caused by Subject:」が
エラーリターンされることを確認
The original message was received at Sun, 20 Mar 2016 11:27:27 +0900
from log.simalab.com [127.0.0.1]
----- The following addresses had permanent fatal errors -----
(reason: 553 5.0.0 Rejected , indicates spamCaused by Subject:)
受信(メールサーバ)側のログ
メールサーバ側のログ(件名でのアクセス制御が成功していることを確認)
Mar 20 11:27:33 mx-ns sendmail[7262]: u2K2RXie007262: ruleset=CheckSubject, arg1= Invoice # 1221, relay=[192.168.3.6], reject=553 5.0.0 Rejected , indicates spam Caused by Subject:
Mar 20 11:27:33 mx-ns sendmail[7262]: u2K2RXie007262: from=, size=659, class=0, nrcpts=1, msgid=<201603200227.u2K2RRuN004209@log.simalab.com>, proto=ESMTP, daemon=MTA, relay=[192.168.3.6]
Mar 20 11:27:33 mx-ns sendmail[7262]: u2K2RXie007262: to=, delay=00:00:00, pri=30659, stat=Rejected , indicates spam Caused by Subject:
送受信テスト(正常系)
・送信(メールクライアント)側
メールクライアント(件名 normal mail)で送信
[ment@log ~]$ mail testuser@simalab.com
Subject: normal mail
this is normal mail
.
EOT
受信(メールサーバ)側のログ
メールサーバ側のログ(件名でのアクセス制御が実施されず、受信が正常に成功していることを確認)
Mar 20 11:33:27 mx-ns sendmail[7265]: u2K2XR6O007265: from=, size=662, class=0, nrcpts=1, msgid=<201603200233.u2K2XLq7004256@log.simalab.com>, proto=ESMTP, daemon=MTA, relay=[192.168.3.6]
Mar 20 11:33:27 mx-ns sendmail[7266]: u2K2XR6O007265: to=, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30842, dsn=2.0.0, stat=Sent
件名(Subject:ヘッダー)による規制用リストファイル( /etc/mail/subjects_rejects)編集時
件名(Subject:ヘッダー)による規制用リストファイル( /etc/mail/subjects_rejects)は、今回はmakemapコマンドなどで、バイナリ形式にしていないため、当該ファイル編集時は、下記のとおり、sendmailの再読み込みを行わないと反映されなかったため、注意。
[root@mx-ns mail]# service sendmail reload
日本語(ダブルバイト文字)件名による規制
件名(Subject:ヘッダー)による規制用リストファイル( /etc/mail/subjects_rejects)に日本語(ダブルバイト文字)件名を挿入し、動作検証を行ったものの、意図した動作は得られなかったため、そこにも注意。
設定ファイル一式
・検証で利用した設定ファイル一式
https://github.com/shi4669/ServerConfig/tree/master/sendmail/etc/mail
参考文献
タグ:sendmail
sendmailによる件名(Subject:ヘッダー)による規制@
前回記事の環境を使用し、
sendmailのセキュリティ設定の検証を実施してみる。
・検証環境のドメインは、「simalab.com」
・メールサーバのホスト名は、「mx-ns」、メールクライアントのホスト名は、「log」
・simalab.comのmxレコードは、mx-ns.simalab.com(192.168.3.21に設定)
・送信者は、ment@log.simalab.com(メールクライアント)
・受信者は、testuser@simalab.com(メールサーバ)
・エンベロープ(From:、TO:)の規制は、/etc/mail/accessの規制により、比較簡単にもかかわらず、Data部以下の各ヘッダー情報、(Subject:、from:、to:ヘッダ)による規制については、参考文献などにも多少の記載しかなかったので、実際に検証してみた。
なお、今回の規制検証箇所は、Data部以下の件名(Subject:ヘッダー)による規制で、
下記のtelnetのシーケンスでは、下記の個所の規制の検証。
「Sendmailクックブック」には、「レシピ6.9 特殊なヘッダを実行する」、「Sendmail(運用編)」には、「7.3 ルールセットでヘッダをチェック」でそれぞれ、ヘッダの規制の記載がある。取り合分け、「Sendmail(運用編)」には、「7.3 ルールセットでヘッダをチェック」が今回のやりたいことズバリの記載が紹介されていたが、そのまま実行したら、(設定の不備かもしれないが)期待する動作が得られなかったため、これらにアレンジを加える。
続きは、次回。
sendmailのセキュリティ設定の検証を実施してみる。
検証環境
・検証環境のドメインは、「simalab.com」
・メールサーバのホスト名は、「mx-ns」、メールクライアントのホスト名は、「log」
・simalab.comのmxレコードは、mx-ns.simalab.com(192.168.3.21に設定)
・送信者は、ment@log.simalab.com(メールクライアント)
・受信者は、testuser@simalab.com(メールサーバ)
件名(Subject:ヘッダー)による規制
・エンベロープ(From:、TO:)の規制は、/etc/mail/accessの規制により、比較簡単にもかかわらず、Data部以下の各ヘッダー情報、(Subject:、from:、to:ヘッダ)による規制については、参考文献などにも多少の記載しかなかったので、実際に検証してみた。
なお、今回の規制検証箇所は、Data部以下の件名(Subject:ヘッダー)による規制で、
下記のtelnetのシーケンスでは、下記の個所の規制の検証。
[ment@log ~]$ telnet 192.168.3.21 25
Trying 192.168.3.21...
Connected to 192.168.3.21.
Escape character is '^]'.
220 mx-ns.simalab.com ESMTP Sendmail 8.14.4/8.14.4; Sun, 20 Mar 2016 09:06:35 +0900
HELO localhost
250 mx-ns.simalab.com Hello [192.168.3.6], pleased to meet you
MAIL FROM:test@log.simalab.lom (エンベロープFrom:)
250 2.1.0 test@log.simalab.lom... Sender ok
RCPT TO:testuser@simalab.com (エンベロープTo:)
250 2.1.5 testuser@simalab.com... Recipient ok
DATA
-------- Data部 --------
354 Enter mail, end with "." on a line by itself
From:test@log.simalab.com (from:ヘッダー)
Subject:test (Subject:ヘッダー)(ここの内容による規制)
.
250 2.0.0 u2K06ZOt006596 Message accepted for delivery
参考文献
「Sendmailクックブック」には、「レシピ6.9 特殊なヘッダを実行する」、「Sendmail(運用編)」には、「7.3 ルールセットでヘッダをチェック」でそれぞれ、ヘッダの規制の記載がある。取り合分け、「Sendmail(運用編)」には、「7.3 ルールセットでヘッダをチェック」が今回のやりたいことズバリの記載が紹介されていたが、そのまま実行したら、(設定の不備かもしれないが)期待する動作が得られなかったため、これらにアレンジを加える。
続きは、次回。
タグ:sendmail
sendmail構築 on RHEL6.4
最近、ばらまき型のメールによる大量のスパムメールが流行しているため、
sendmailによる諸々の検証を行うための、環境を構築を実施してみる。
関連記事
http://www.security-next.com/068062
・関連記事で使用したRHEL6.4を使用して、rpmでのsendmailを実施する。
・sendmailのバージョンは、sendmail-8.14.4-9.el6.x86_64
・sendmail本体と、mailx(mailコマンド)をインストールする。
・/etc/mail/local-host-namesに自ドメインを設定する。
・下記の設定単純な設定でのmcファイルを設定する。
https://github.com/shi4669/ServerConfig/blob/master/sendmail/etc/mail/sendmail_plain.mc
当該設定をベースに、各種セキュリティのための設定検証を実施する。
sendmailによる諸々の検証を行うための、環境を構築を実施してみる。
関連記事・URL
関連記事
http://www.security-next.com/068062
環境の前提
・関連記事で使用したRHEL6.4を使用して、rpmでのsendmailを実施する。
・sendmailのバージョンは、sendmail-8.14.4-9.el6.x86_64
検証環境
各種インストール
・sendmail本体と、mailx(mailコマンド)をインストールする。
[root@mx-ns ~]# yum install sendmail
[root@mx-ns ~]# yum install mailx
バージョン確認
[root@mx-ns ~]# rpm -qa | grep sendmail
sendmail-cf-8.14.4-9.el6.noarch
sendmail-8.14.4-9.el6.x86_64
[root@mx-ns ~]#
基本設定
・/etc/mail/local-host-namesに自ドメインを設定する。
[root@mx-ns ~]# cat /etc/mail/local-host-names
# local-host-names - include all aliases for your machine here.
simalab.com
[root@mx-ns ~]#
sendmail.mc設定
・下記の設定単純な設定でのmcファイルを設定する。
https://github.com/shi4669/ServerConfig/blob/master/sendmail/etc/mail/sendmail_plain.mc
sendmail.mcのコンパイル
[root@mx-ns mail]# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
sendmail.の起動
[root@mx-ns mail]# service sendmail restart
sm-client を停止中: [ OK ]
sendmail を停止中: [ OK ]
sendmail を起動中: [ OK ]
sm-client を起動中: [ OK ]
[root@mx-ns mail]#
当該設定をベースに、各種セキュリティのための設定検証を実施する。
タグ:sendmail
2016年03月24日
SourceTreeでのGitHubの利用備忘録
たまにしか使わない、SourceTreeとGitHubについて、
使うたびに、あれこれ、ググりながら、調べるということを繰り返していたため、
備忘録的に、利用法を手順書にしてみた。
SourceTreeでのGitHubの利用備忘録
https://drive.google.com/file/d/0B2yjG8delT8WV0RYTmpIWHZTQkk/view?usp=sharing
GitHubについては、これで、まだまだ勉強中
タグ:プログラミング
2016年03月17日
BIND9.8.2構築 on RHEL6.4 (SPFレコードあり)
関連記事に関連し、SPFレコードの検証を行うため、前回の環境にBIND9.8.2を検証のため、構築する。
・RHEL6.4を使用し、rpmでインストールする。
・検証用途のため、内部からのみの利用の前提。
・検証を優先するため、セキュリティはあまり考慮してない設定。
・ドメインはsimalab.comを使用し、逆引きは設定しない
※セキュリティ度外視の設定のため、注意。
関連記事で学習したSPFレコードも追加する。
作成したファイルのパーミッションを変更する。
動作確認のため、構築したサーバのリゾルバを自身(ここでは192.168.3.21)に向ける。
(この際に、ハマったことは、こちら)
・nslooup起動
・対象DNSサーバに接続
・nsレコード検索
・mxレコード検索
・txtレコード検索
環境の前提
・RHEL6.4を使用し、rpmでインストールする。
・検証用途のため、内部からのみの利用の前提。
・検証を優先するため、セキュリティはあまり考慮してない設定。
・ドメインはsimalab.comを使用し、逆引きは設定しない
各種インストール
[root@mx-ns ~]# yum install -y bind
[root@mx-ns ~]# yum install -y bind-chroot
[root@mx-ns ~]# yum install -y bind-utils
named.conf設定
※セキュリティ度外視の設定のため、注意。
[root@mx-ns ~]# vi /var/named/chroot/etc/named.conf
options {
#listen-on port 53 { 127.0.0.1; }; ← 行頭に#を追加してコメントアウト
#listen-on-v6 port 53 { ::1; }; ← 行頭に#を追加してコメントアウト
version "unknown";
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
// Those options should be used carefully because they disable port
// randomization
// query-source port 53;
// query-source-v6 port 53;
allow-query { localhost; localnets; };
allow-query-cache { localhost; localnets; };
forwarders{
192.168.3.1; #自宅環境なのでルータをforwarderに設定
};
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
category lame-servers { null; };
};
view "internal" {
match-clients { localnets; };
match-destinations { localnets; };
recursion yes;
// include "/etc/named.rfc1912.zones";
include "/etc/simalab.com.zone";
};
zoneの定義ファイル登録
[root@mx-ns ~]# vi /var/named/chroot/etc/simalab.com.zone
zone "simalab.com" IN {
type master;
file "simalab.com.zone";
};
zoneのレコードファイル登録
関連記事で学習したSPFレコードも追加する。
[root@mx-ns ~]# vi /var/named/chroot/var/named/simalab.com.zone
$TTL 86400
@ IN SOA mx-ns.simalab.com. root.simalab.com.(
2016031601 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS mx-ns.simalab.com.
IN MX 10 mx-ns.simalab.com.
mx-ns IN A 192.168.3.21
msa IN CNAME mx-ns
simalab.com. IN TXT "v=spf1 +ip4:192.168.3.21 ~all"
root定義ファイル登録
[root@mx-ns ~]# vi /var/named/chroot/etc/named.root.hints
zone "." IN {
type hint;
file "named.ca";
};
rootレコードファイル登録
[root@mx-ns ~]# vi /var/named/chroot/etc/named.root.hints
[root@mx-ns ~]# dig . ns @198.41.0.4 > /var/named/chroot/var/named/named.ca
ファイルパーミッション変更
作成したファイルのパーミッションを変更する。
[root@mx-ns ~]# chown 640 /var/named/chroot/etc/named.conf
[root@mx-ns ~]# chown named:named /var/named/chroot/etc/named.conf
[root@mx-ns ~]# chown 640 /var/named/chroot/etc/simalab.com.zone
[root@mx-ns ~]# chown named:named /var/named/chroot/etc/simalab.com.zone
[root@mx-ns ~]# chown 640 /var/named/chroot/etc/named.root.hints
[root@mx-ns ~]# chown named:named /var/named/chroot/etc/named.root.hints
BIND起動
[root@mx-ns ~]# service named start
named を起動中: [ OK ]
[root@mx-ns ~]#
BIND自動起動設定
[root@mx-ns ~]# chkconfig --list named
named 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@mx-ns ~]# chkconfig named on
[root@mx-ns ~]# chkconfig --list named
named 0:off 1:off 2:on 3:on 4:on 5:on 6:off
[root@mx-ns ~]#
リゾルバの設定
動作確認のため、構築したサーバのリゾルバを自身(ここでは192.168.3.21)に向ける。
(この際に、ハマったことは、こちら)
[root@mx-ns ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.3.21
search simalab.com
[root@mx-ns ~]#
動作確認
・nslooup起動
>nslookup
・対象DNSサーバに接続
> server 192.168.3.21
・nsレコード検索
> set type=ns
> simalab.com
サーバー: [192.168.3.21]
Address: 192.168.3.21
simalab.com nameserver = mx-ns.simalab.com
mx-ns.simalab.com internet address = 192.168.3.21
>
・mxレコード検索
> set type=mx
> simalab.com
サーバー: [192.168.3.21]
Address: 192.168.3.21
simalab.com MX preference = 10, mail exchanger = mx-ns.simalab.com
simalab.com nameserver = mx-ns.simalab.com
mx-ns.simalab.com internet address = 192.168.3.21
・txtレコード検索
> set type=txt
> simalab.com
サーバー: [192.168.3.21]
Address: 192.168.3.21
simalab.com text =
"v=spf1 +ip4:192.168.3.21 ~all"
simalab.com nameserver = mx-ns.simalab.com
mx-ns.simalab.com internet address = 192.168.3.21
>
タグ:OS
RHEL6.4でresolv.confが書き換わる件
この記事の
環境構築中に遭遇した事象の備忘録。
DNSサーバの参照先を変更しようとして、viエディタで/etc/resolv.confを直接編集。
編集後は、問題なく反映されていたが、osリブート後に設定が元に戻って(書き換わって)しまう。
http://mrs.suzu841.com/mini_memo/numero_21.html
参照URLの方の事象とほぼ酷似。
自分の環境の状態はというと、下記の通り。
・ネットワークインターフェースファイル(ifcg-eth0)にDNS1=192.168.3.1が設定されている。
・NetworkManagerは起動していない
以下のとおり対応した。
・ネットワークインターフェースファイル(ifcg-eth0)にDNS1=192.168.3.1を削除
・network restart
・vi /etc/resolv.confを編集
・OSリブート
・ /etc/resolv.confがOSリブート前の状態であることを確認
・ネットワークインターフェースファイル(ifcg-eth0)にDNS1=192.168.3.1を削除
・network restart
・vi /etc/resolv.confを編集する(編集後は下記)
・OSリブート
・ /etc/resolv.confがOSリブート前の状態であることを確認
環境構築中に遭遇した事象の備忘録。
遭遇した事象
DNSサーバの参照先を変更しようとして、viエディタで/etc/resolv.confを直接編集。
編集後は、問題なく反映されていたが、osリブート後に設定が元に戻って(書き換わって)しまう。
編集前
[root@mx-ns ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.3.1
[root@mx-ns ~]#
vi エディタで編集後
[root@mx-ns ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.3.21
[root@mx-ns ~]#
OSリブート後
[root@mx-ns ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.3.1
[root@mx-ns ~]#
参照URL
http://mrs.suzu841.com/mini_memo/numero_21.html
環境の状態
参照URLの方の事象とほぼ酷似。
自分の環境の状態はというと、下記の通り。
・ネットワークインターフェースファイル(ifcg-eth0)にDNS1=192.168.3.1が設定されている。
DEVICE=eth0
TYPE=Ethernet
UUID=a31cbd35-6ff3-456c-ad14-2e2a765e9e9a
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=none
HWADDR=00:15:5D:03:04:05
IPADDR=192.168.3.21
PREFIX=24
GATEWAY=192.168.3.1d
DNS1=192.168.3.1
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"
・NetworkManagerは起動していない
[root@mx-ns network-scripts]# chkconfig --list NetworkManager
サービス NetworkManager に関する情報の読み込み中にエラーが発生しました: そのようなファイルやディレクトリはありません
[root@mx-ns network-scripts]#
対応方法
以下のとおり対応した。
・ネットワークインターフェースファイル(ifcg-eth0)にDNS1=192.168.3.1を削除
・network restart
・vi /etc/resolv.confを編集
・OSリブート
・ /etc/resolv.confがOSリブート前の状態であることを確認
・ネットワークインターフェースファイル(ifcg-eth0)にDNS1=192.168.3.1を削除
[root@mx-ns network-scripts]# cat ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
UUID=a31cbd35-6ff3-456c-ad14-2e2a765e9e9a
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=none
HWADDR=00:15:5D:03:04:05
IPADDR=192.168.3.21
PREFIX=24
GATEWAY=192.168.3.1
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"
[root@mx-ns network-scripts]#
・network restart
[root@mx-ns network-scripts]# service network restart
インターフェース eth0 を終了中: [ OK ]
ループバックインターフェースを終了中 [ OK ]
ループバックインターフェイスを呼び込み中 [ OK ]
インターフェース eth0 を活性化中: Determining if ip address 192.168.3.21 is already in use for device eth0...
[ OK ]
[root@mx-ns network-scripts]#
・vi /etc/resolv.confを編集する(編集後は下記)
[root@mx-ns network-scripts]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.3.21
search simalab.com
[root@mx-ns network-scripts]#
・OSリブート
[root@mx-ns network-scripts]# reboot
・ /etc/resolv.confがOSリブート前の状態であることを確認
[root@mx-ns ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.3.21
search simalab.com
[root@mx-ns ~]#
タグ:OS
2016年03月13日
RedHatEnterpriseLinux6.4インストール(on LVM)
会社で、メールサーバやDNSサーバなどの諸々の
検証を行う必要が生じたため、その検証環境を用意するために、
RedHatEnterpriseLinuxのインストールをLVMの構成で行ってみる。
なお、検証のターゲット環境は、本番環境に合わせてRedHatEnterpriseLinux6.4を使用する。
yumなどを実施するため、OSのメディアと評価用ライセンス(30日間)の取得を行う。
[RHEL6.4サブスクリプション取得・OSダウンロード手順]
https://drive.google.com/file/d/0B2yjG8delT8WLURHR1dGcUNzbU0/view?usp=sharing
OSのインストールにあたり、下記のパーティションを設定する。
[RHEL6.4インストール手順]
https://drive.google.com/file/d/0B2yjG8delT8WajNJcXJEdUZPZTg/view?usp=sharing
この後、yumなどを使用するため、「rhn_registerコマンド」でRedHatNetwork上に、
対象システムを認識させる。
[rhn_registerコマンド実行手順]
https://drive.google.com/file/d/0B2yjG8delT8WMURVN3hPNjE4U3M/view?usp=sharing
検証環境のため、セキュリティを緩和するため、SELisxを無効化する。
検証環境のため、セキュリティを緩和するため、ファイアーウォールも無効化する。
検証を行う必要が生じたため、その検証環境を用意するために、
RedHatEnterpriseLinuxのインストールをLVMの構成で行ってみる。
なお、検証のターゲット環境は、本番環境に合わせてRedHatEnterpriseLinux6.4を使用する。
サブスクリプション・OSダウンロード
yumなどを実施するため、OSのメディアと評価用ライセンス(30日間)の取得を行う。
[RHEL6.4サブスクリプション取得・OSダウンロード手順]
https://drive.google.com/file/d/0B2yjG8delT8WLURHR1dGcUNzbU0/view?usp=sharing
OSインストール
OSのインストールにあたり、下記のパーティションを設定する。
- swap(非LVM)
- /(LVM)
- /var(LVM)
- /boot(LVM)
[RHEL6.4インストール手順]
https://drive.google.com/file/d/0B2yjG8delT8WajNJcXJEdUZPZTg/view?usp=sharing
rhn_registerコマンド実行
この後、yumなどを使用するため、「rhn_registerコマンド」でRedHatNetwork上に、
対象システムを認識させる。
[rhn_registerコマンド実行手順]
https://drive.google.com/file/d/0B2yjG8delT8WMURVN3hPNjE4U3M/view?usp=sharing
SELinux無効化
検証環境のため、セキュリティを緩和するため、SELisxを無効化する。
[root@mx-ns ~]# vi /etc/selinux/config
#下記に変更
SELINUX=disabled
[root@mx-ns ~]# 再起動実施
[root@mx-ns ~]# reboot
[root@mx-ns ~]# 再起動後確認
[root@mx-ns ~]# getenforce
Disabled
[root@mx-ns ~]#
ファイアーウォール無効化
検証環境のため、セキュリティを緩和するため、ファイアーウォールも無効化する。
[root@mx-ns ~]# service iptables stop
iptables: チェインをポリシー ACCEPT へ設定中filter [ OK ]
iptables: ファイアウォールルールを消去中: [ OK ]
iptables: モジュールを取り外し中: [ OK ]
[root@mx-ns ~]#
[root@mx-ns ~]# chkconfig iptables off
[root@mx-ns ~]# chkconfig --list iptables
iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@mx-ns ~]#
タグ:OS
2016年03月12日
若者よ、外資系はいいぞ
コンビニで、本書が目に留まり、思わず購入。
著書は、インテルなどでキャリアを築いた方で、
タイトルからは、外資系企業はいいぞ、日本企業はけしからんという
内容を想像するが、内容はそういった単純な二元論ではなく、
それぞれの企業の背後にある組織の考え方や果ては、人生論にまで及び、
価格、ボリュームに比して、なかなかの読み応え。
特に個人的に良いと思ったのは、外資系のもつチーム観の記述箇所で、
これを読んで、思い出したのが、イチローのチーム観だ。
イチローのチーム観がとかく、個人主義として受け取られる傾向にあるが、
個人的には、下記のようなイチローのチーム観は大好きだ。
・イチロー
http://systemincome.com/14898
本田圭佑も、イチローに近いチーム観のようで、
チームの前に「個」があるというメンタリティーは、共通のものなのだろう。
・本田圭佑
http://blogs.yahoo.co.jp/nonakajun/62651157.html
以前、読んだ下記の本にも、「協調性」について、下記の通り、記載されている。
それぞれ、分野の違いはあれど、何かを成し遂げた人には、共通したチーム観が
根底にあるのだろう。
著書は、インテルなどでキャリアを築いた方で、
タイトルからは、外資系企業はいいぞ、日本企業はけしからんという
内容を想像するが、内容はそういった単純な二元論ではなく、
それぞれの企業の背後にある組織の考え方や果ては、人生論にまで及び、
価格、ボリュームに比して、なかなかの読み応え。
特に個人的に良いと思ったのは、外資系のもつチーム観の記述箇所で、
外資系では、個人が自分の能力を発揮することで、組織が動いていく。外資系企業でも、日本企業でも組織の目的はビジネスで勝つことで同じだが、組織を構成するプレーヤーに対する期待には大きな違いがある。外資系では、働く人は与えられた役割で、能力を発揮できる個人であることが大前提で、経営陣、プレーヤーが個々人の能力をチームの成果につなげるように協力し合って組織作りをする。
一方、日本企業では、働く人はまず良きチームプレーヤーであることが求められ、個人は集団との一体感と貢献にやりがいを見出す。その結果、外資系では、能力を持った個人が作り上げられていくのに対して、日本企業では、組織のルールと暗黙の了解の下で成果をだせる組織固有の人材が育てられる。
※もちろん、本書では、上記の解釈をすべての一般論とすることは否定しているので誤解なきよう。
一方、日本企業では、働く人はまず良きチームプレーヤーであることが求められ、個人は集団との一体感と貢献にやりがいを見出す。その結果、外資系では、能力を持った個人が作り上げられていくのに対して、日本企業では、組織のルールと暗黙の了解の下で成果をだせる組織固有の人材が育てられる。
※もちろん、本書では、上記の解釈をすべての一般論とすることは否定しているので誤解なきよう。
これを読んで、思い出したのが、イチローのチーム観だ。
イチローのチーム観がとかく、個人主義として受け取られる傾向にあるが、
個人的には、下記のようなイチローのチーム観は大好きだ。
・イチロー
http://systemincome.com/14898
強いチームというのは、個人があってチームがあると思うんです。個々が持っている力を発揮して、役割をはたして、それが結果としてチームとしての力となる。でも、弱いチームは、個々が持っている力を発揮されない。だから勝てない。「チームのために」という言葉でごまかして個人の力を発揮できないことへの言い訳を探す、そうしたらもっと勝てなくなる。悪循環ですよね
本田圭佑も、イチローに近いチーム観のようで、
チームの前に「個」があるというメンタリティーは、共通のものなのだろう。
・本田圭佑
http://blogs.yahoo.co.jp/nonakajun/62651157.html
シンプルに言えば個だと思います。(中略)結局、
最後は個の力で試合が決することがほとんどなので。日本のストロングポイントはチームワークですが、
それは生まれ持った能力なので、どうやって自立した選手になって個を高められるかというところです。
最後は個の力で試合が決することがほとんどなので。日本のストロングポイントはチームワークですが、
それは生まれ持った能力なので、どうやって自立した選手になって個を高められるかというところです。
以前、読んだ下記の本にも、「協調性」について、下記の通り、記載されている。
伸びる人には、協調性があります。
仕事の場において、協調性があるということはみんなと仲良くできるということではありません。仲良くするのはいいことですが、それだけでは、ただの仲良しクラブです。
協調性があるということは、複数の技術者が、それぞれ割り当てられている独立した職務と役割を果たし、かつ他の技術者と連携を取りながら仕事を進めることができるということです。
仕事の場において、協調性があるということはみんなと仲良くできるということではありません。仲良くするのはいいことですが、それだけでは、ただの仲良しクラブです。
協調性があるということは、複数の技術者が、それぞれ割り当てられている独立した職務と役割を果たし、かつ他の技術者と連携を取りながら仕事を進めることができるということです。
それぞれ、分野の違いはあれど、何かを成し遂げた人には、共通したチーム観が
根底にあるのだろう。