libpwqualityあれこれ

 article  Comments Off on libpwqualityあれこれ
Apr 102016
 

RHEL 7やCentOS 7では、辞書に載っているパスワードへの変更を抑止する際に使われるPAMモジュールがpam_cracklibからpam_pwqualityに変更されています。パッケージとしてはlibpwqualityに含まれるモジュールになります。

libcrackにもリンクされていてパスワード辞書自体はデフォルトでcracklibのものを使用しますが、/etc/security/pwquality.confで変更可能です。詳しくはman pam_pwqualityやman pwquality.confを参照。

こちらのパッケージにはパスワードを生成してくれるpwmakeやパスワードの強度をチェックしてくれるpwscoreというコマンドが付属しています。

例えばpwscoreコマンドで「辞書に載っている」、「8文字未満」、「ユーザー名が含まれる」パスワードをチェックしてみると、それぞれ以下のような結果になります。

$ echo password | pwscore
Password quality check failed:
 The password fails the dictionary check - it is based on a dictionary word
$ echo passwor | pwscore
Password quality check failed:
 The password is shorter than 8 characters
# echo password4username| pwscore username
Password quality check failed:
 The password contains the user name in some form

3つめのコマンドのpwscoreに続く引数はユーザー名です。

pwmakeの使い方はビット数を引数に指定して実行するだけで、通常は64ビット、より強固にするには80や128ビットの指定がよいようです。
以下、Red Hat Enterprise Linux 7 セキュリティガイドの「第4章 ツールとサービスを使用したシステム強化」より。

指定可能な最小ビット数は 56 で、これはブルートフォース攻撃が滅多に仕掛けられないシステムやサービスのパスワードには十分なものです。攻撃者がパスワードハッシュファイルに直接アクセスできないアプリケーションであれば、64 ビットで十分です。攻撃者がパスワードハッシュへの直接アクセスを取得する可能性がある場合やパスワードが暗号化鍵として使用される場合は、80 ビットや 128 ビットを使うべきです。

Window XPのRRAS設定(Filter&NAT)

 article  Comments Off on Window XPのRRAS設定(Filter&NAT)
Apr 202011
 

Windows XPで動かすcoLinuxをNATで使いたいのですが、Windows Firewall/Internet Connection Sharing (ICS)ではNATで使用できる内部ネットワークアドレスに制限があります(192.168.0.0/24固定)。
Routing and Remote Access(RRAS)でもNATはできるのですが、ICSのFirewallと共存することはできません。

結局、NATとパケットフィルタリング両方にRRASを使うようにしているので、そちらの設定メモです。

ICSのサービスを止めてRRASサービスを有効にします。

C:\>net stop sharedaccess
C:\>net start remoteaccess

netshのrouting ipコンテキストでフィルタを設定します。

C:\>netsh
netsh>routing ip
netsh routing ip>set filter "Cable" input drop
OK

netsh routing ip>add filter "Cable" input 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 tcp-est 0 0
OK

netsh routing ip>add filter "Cable" input 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp 53 0
OK

netsh routing ip>add filter "Cable" input 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 udp 123 0
OK

netsh routing ip>add filter "Cable" input 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 icmp any any
OK

netsh routing ip>

設定したフィルタの確認。

netsh routing ip>show filter "Cable"

インターフェイス Cable のフィルタ情報
------------------------------------------------------------------

フラグメント チェックは 無効 です。

フィルタの種類        : INPUT
既定の操作            : DROP

    Src Addr       Src Mask         Dst Addr       Dst Mask      Proto  Src Port  Dst Port
------------------------------------------------------------------------------------------
        0.0.0.0         0.0.0.0         0.0.0.0         0.0.0.0 TCP-EST       0       0
        0.0.0.0         0.0.0.0         0.0.0.0         0.0.0.0    UDP      53       0
        0.0.0.0         0.0.0.0         0.0.0.0         0.0.0.0    UDP     123       0
        0.0.0.0         0.0.0.0         0.0.0.0         0.0.0.0   ICMP       0       0
出力フィルタが構成されていません。
デマンド ダイヤル フィルタが構成されていません。

netsh routing ip>

続いてNAT設定。coLinuxでインストールしたTapインターフェースをPrivate、Cableインターフェースをfullに設定します。

netsh routing ip>nat
netsh routing ip nat>install

netsh routing ip nat>add interface "Cable" full

netsh routing ip nat>add interface "Tap" private

netsh routing ip nat>

NAT設定内容の確認。

netsh routing ip nat>show interface

NAT Cable の構成
---------------------------
モード            : アドレスおよびポートの変換


NAT Tap の構成
---------------------------
モード            : プライベート インターフェイス


netsh routing ip nat>

最後にDNS Proxyを設定して終了。

netsh routing ip nat>dnsproxy
netsh routing ip dnsproxy>install
netsh routing ip dnsproxy>exit


C:\>

PPP Adapterに対するRRASのフィルタはデフォルトDROPらしい

 article  Comments Off on PPP Adapterに対するRRASのフィルタはデフォルトDROPらしい
Apr 102011
 

私はWindows XPのFirewall機能に、標準的なICS(Windows Firewall/Internet Connection Sharing (ICS))ではなくRRAS(Routing and Remote Access)を使っています。
ICSではNATで利用するIPアドレスに制限がある(192.168.0.0/24固定)ことや、RRASのほうがルーター等N/W機器の一般的なフィルタに近い感覚で設定できることが理由です(個々のプログラムレベルでの通信許可はできなくなるので、ウィルスやマルウェア対策面では不安が残りますが)。

で、RRASでは「ローカルエリア接続」等の各N/Wインターフェースに対してデフォルトポリシーを許可ルールを設定しますが、PPP Adapterに関してはこちらに一覧が出現しません。

C:\>netsh routing ip show filter
Input           Output          Demand-dial     Frag. Check     Interface
---------       ----------      -------------   --------------  ----------------
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            ループバック
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            内部
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            VMnet8
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            VMnet1
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            Cable
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            WiFi
0   (FORWARD)   0   (FORWARD)   0   (FORWARD)   無効            Tap


C:\>

※普段はInputをDROPにしてますが、テストのためFORWARDに変更しています

デフォルトはFORWARDなのかDROPなのか、リモートからnmapで確認してみました。結論からいうとRRASサービスを有効にしただけでPPP Adapterに対してはDROPの動作になるようです。

RRAS停止状態(net stop remoteaccess)

debian1:~# nmap 183.72.42.159

Starting Nmap 5.21 ( http://nmap.org ) at 2011-04-10 01:35 JST
Nmap scan report for u542159.xgsfmg18.imtp.tachikawa.mopera.net (183.72.42.159)
Host is up (0.15s latency).
Not shown: 988 closed ports
PORT      STATE    SERVICE
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
161/tcp   filtered snmp
445/tcp   filtered microsoft-ds
902/tcp   open     iss-realsecure
912/tcp   open     unknown
2049/tcp  filtered nfs
2869/tcp  open     unknown
8222/tcp  open     unknown
8333/tcp  open     unknown
12345/tcp filtered netbus
31038/tcp open     unknown

Nmap done: 1 IP address (1 host up) scanned in 10.16 seconds
debian1:~#

RRAS開始状態(net start remoteaccess)

debian1:~# nmap 183.72.42.159

Starting Nmap 5.21 ( http://nmap.org ) at 2011-04-10 01:37 JST
Note: Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 3.08 seconds
debian1:~#

mod_auth_kerbでgss_accept_sec_context() failed

 article  Comments Off on mod_auth_kerbでgss_accept_sec_context() failed
Jun 052010
 

Subversionリポジトリへのhttpsアクセス用に、mod_auth_kerbを使ってActive DirectoryのアカウントでのBasic認証を仕掛けたところ、認証要求が返ってこない(WWW-Authenticateヘッダーが返されない)事象に遭遇。
非SSLでのアクセスの場合はきちんと動作する。
Subversionではない、通常のコンテンツに対するhttpsアクセスも問題なし。
モジュールの組み合わせとして整理してみるとこんな感じか?

  • mod_auth_kerb + mod_ssl => OK
  • mod_auth_kerb + authz_svn => OK
  • mod_auth_kerb + authz_svn + mod_ssl => NG

失敗時は/var/log/httpd/ssl_error.logには以下のようなエラーが記録される。

gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information (No such file or directory)

キャプチャを仕掛けるとそもそもKerberosサーバーに通信にいく気配もない。WWW-Authenticateヘッダーも返ってこないのだから当たり前だが。

はっきりとした原因はわからないが、

KrbMethodNegotiate off

を設定したところ正常に動作するようになった。

Kerberos V4でなにかしら動こうとしていたのだろうか。謎だ 😕

May 232008
 

SELinuxを無効化する方法。[selinux-users:02051]からの引用。

SELinux を disable にするには3つの方法があります。
1. /etc/selinux/config で SELINUX=disabled と記述する
2. カーネル起動オプションに selinux=0 と記述する
3. カーネルコンフィグで SELinux のチェックボックスを外す

しかし厳密には、(1)と(2)及び(3)には違いがあり、SELinux以外のセキュリティモジュールを利用するには (2) か (3) の方法を使う必要があります。

(2)と(3)の場合は、LSMへのモジュール登録関数である register_security() 関数をコールしません。したがって、誰もLSMを専有していないために、後でセキュリティモジュールを登録する事が可能です。

奥が深い。

それから、How to Disable SELinuxの情報によれば、

  • カーネル起動オプションにenforcing=0と記述する

という方法もあるようで、これはおそらくregister_security()関数がコールされる通常のブート後、setenforce 0をおこなうのと同じ状態かと。

Dec 102007
 

Red Hat系Linuxにはmod_sslパッケージにcertwatchというユーティリティが含まれていて、SSL証明書の期限切れをメールで通知するようになっている。
こちらの通知を何日前からおこなうか(デフォルト30日)、またメール通知先をどこにするかは、/etc/sysconfig/httpdにCERTWATCH_OPTSを指定することで設定できる。

CERTWATCH_OPTS="-p 60 -a root@example.jp"

-pは期限、-aは通知先メールアドレスの指定で、メールアドレスを指定しないと標準出力に出力される(なのでデフォルトはrootユーザにcron結果として通知される)。

certwatchによるチェックを無効化したい場合は、

NOCERTWATCH=yes

とすればよい。

May 172007
 

mod_auth_mysqlモジュールではテーブル名やカラム名を細かく指定することができます。
以下Mantis Bug Tracker 1.1.0a2のユーザ情報を使ってHTTP認証を仕掛ける設定です。ユーザのパスワード忘れ対応やパスワード変更にMantisの機能でそのまま対応できちゃうので結構便利だと思ってます。

AuthType                  Basic
AuthName                  "Mantis username and password"
AuthMySQLHost             localhost
AuthMySQLDB               mysql_database
AuthMySQLUser             mysql_username
AuthMySQLPassword         mysql_password
AuthMySQLUserTable        mantis_user_table
AuthMySQLNameField        username
AuthMySQLPasswordField    password
AuthMySQLCryptedPasswords Off
AuthMySQLMD5Passwords     On
require valid-user

Apacheとmod_auth_mysqlモジュールはCentOS 3.8のパッケージを利用しています。

mod_auth_mysqlのディレクティブとMantis設定項目の対応は以下です。

ディレクティブ Mantis設定項目
AuthMySQLHost $g_hostname
AuthMySQLDB $g_database_name
AuthMySQLUser $g_db_username
AuthMySQLPassword $g_db_password
AuthMySQLUserTable $g_mantis_user_table
AuthMySQLNameField username固定
AuthMySQLPasswordField password固定
AuthMySQLCryptedPasswords Off
AuthMySQLMD5Passwords On
$g_login_method = MD5
AuthMySQLCryptedPasswords On
AuthMySQLMD5Passwords Off
$g_login_method = CRYPT

Mantisの設定値がどうなっているのかは、config_inc.phpやconfig_default_inc.phpをみればわかるはずです。
AuthMySQLNameFieldとAuthMySQLPasswordFieldは「固定」と書きましたが、ここらへんをMantis側で変更できる人には、そもそも「どの設定項目が対応するのか」なんて説明不要でしょう 😉

Jan 172007
 

今のところ直接変更する方法はありません。
Google Browser Sync – FAQに載ってます。

Can I change my PIN?
Currently, it’s not possible to change your PIN. If your PIN is compromised, the best thing to do is to remove the Browser Sync service from your Google account at http://www.google.com/accounts and start fresh. Since Browser Sync imports your current browser settings, you shouldn’t lose anything.

変更したい場合は、FAQに書かれているとおりGoogleのアカウント情報から”Browser Sync”のサービスを削除します。そしてアドオン自体は残したままFirefoxを起動すれば、再度Setup Wizardが実行されてPINを設定できるようになります。

ちなみにPINは同期データを暗号化、複合化するために使われます。認証というよりも秘密鍵のパスフレーズみたいなものです。

詳しくは同FAQの

あたりを参照ください。

Nov 302006
 

一部のSSLサイトにFirefox2で接続できない件は、Firefox 2 – もじら組 WikiのFAQにあるように、「SSL 2.0 等弱い暗号が無効」になったことが原因である可能性が高いです。
対策」にもあるように、Firefox2の設定を変更して接続できるようならサイトが強い暗号に対応していない、ということになります。
具体的にはabout:configでフィルタに”security.ssl3.”を指定し、”false”になっているところを”true”にして接続できるようならピンゴです。

恒久的な変更はお勧めしませんので、あくまでも確認のためにご利用ください。