2017年8月15日火曜日

Netgearのarlo proでホームセキュリティを敷く

ぶっちゃけ「ホーム」では無いのだが、arlo proを使用したので設定関係のtipsと使用感。
レビューです。
 
監視カメラとしてarloを使用する場合、留意しなければならないことは3つある。

一つはずばりバッテリー。
人通りが多い場所に設置する場合、1ヶ月持たない可能性がある。
逆にバッテリー問題さえ解決してしまえば何とでもなる。
もしLANケーブルを引っ張れるのであれば、arlo q plusでPOE給電をお勧めする。
屋外ではそうはいかないのでバッテリー頼みになるが、大体30回程度1日に反応させると2ヶ月持つくらいである。
屋内でコンセントが近ければ、充電しながらの使用も可能。

二つ目は動体感知方式。
arloもarlo proも、PIRセンサーを使っているので、感知距離は4m~7m程度。

三つ目は録画開始タイミング。
公式でも1~4秒のラグがあることを明記しているので、素早く移動されると感知はするが、録画されたものには人が映っていないということがある。
ラグは無印arloの方が激しいし、バッテリーが電池なのを鑑みると、数年使うならproをお勧めする。

これら3つを勘案して、設置場所を選定することをお勧めする。
屋内で組むのであれば、arlo q plusを組み合わせてやることをお勧め。有線で検知方式が画像差分方式、且つ録画は数秒「前」から始まる。


利点・メリット
兎に角arloの利点はワイヤレスであること。ケーブルの引き出しをしなくて良いので、どこにでも付けられる。

また、基本はクラウド録画で、インターネット接続が切れた場合且つローカルストレージ(USBメモリなど)があれば、そちらに書き出してくれる(インターネットに接続された際にクラウドに送られる)。

設定が簡単。ベースステーションとのリンクはボタン式で、繋がってしまえばウェブ上で設定することになる。

思った以上に綺麗。光量があるところなら、そこそこ見られる絵作り。

アプリも使いやすい。

難点・デメリット
設定が簡単すぎて細やかな設定が出来ない。ベースステーション枠で1カメラにつき1設定で設定するため、
ある時間帯のみ、あるカメラだけアラート送信して欲しい、みたいな事をしたくても出来ない。

感度設定がピーキーなところ。移動する人を検知する場合、動体感知は100%にしておかないと撮り逃す。
また、音声検知は環境音を無駄に配慮してくれるらしく、車通りが多いところだとエンジン音を検知してくれない。だからといってレベル5にすると検知が止まらなくなる。

ベーシックプランの1アカウント5台制限。
これはアカウントに紐付けられた全てのカメラをまとめて5台と言うこと。たとえばarlo pro4台とarlo q plus2台を同一アカウントで管理は出来ない。
ただ別アカウントも組み合わせて共有すれば良いのだけれども、初期セットアップの際に面倒。

ブラウザで見る場合はflashプレーヤーが必須。

要望したいことは、ローカルストレージへの同時録画。あくまでローカルストレージはインターネット接続が切れた際のバックアップ扱いなので、ここは改善して欲しい。

また気付いたら追記予定。

全くarloとは関係ないけど・・・
Planexのカメラ一発は兎に角不安定なのが敗因なんだよなあ。
遠隔で見ることは出来てもNAS録画されてないとかどうしてくれようと思うことが多々ある。
で、一番の解決策は再起動という・・・。1000円位の電源タイマーを組み合わせないと連続常用は難しい。

2017年7月10日月曜日

Proselfを弄ってみた。

Proselfを弄ってみた。
詳しいことは書かないけど、弄る機会がありまして。
UIは、なんというか、owncloudチック、というか丸パクリ感。
使いやすいUIをまんまパクるそのスタイル、嫌いじゃ無いです。
ver.4はまだ昔のストレージ感あるのにね。
機能面では、痒いところに手が届く感じはしました。gigaccとは大違い。
なんというか、Proselfは、ユーザフレンドリーなのに対して、gigaccは大上段に構えてる感じ。
詳しく弄ってない前提で、印象だけ語ると、色んな意味でがちがちなのはgigacc。組織ベース。上長確認システムとか旧態歴然とした組織にはがっつりはまります。でも融通は利かない。
Proselfは、ファイル主体。組織システムにがっちり合わせるというよりも、個人とグループというまとまりで管理するから、昔のはんこ回しとかはやらないよ、という。
FAQにもそれは現れていて、きめ細かいFAQが載っているのがProselfの方だったり。

FAQの話ついでに。
SSLプロキシを設定してから分かってきたことは、XSS対策としてリファラの参照を用いることが多いようなこと。
詳しく見てないけど、恐らくadobeもgoogleも画面遷移させる上でやってる。
Proselfもそうで、
https://www.proself.jp/support/faq341/
https://www.proself.jp/support/faq335/
とのこと。うちは勿論リファラ全切りなので(ブラウザは偽装だし)、勿論引っかかる。
ただ、リファラの偽装は昔からの手段で、携帯サイトを覗きたかったり、ブラウザ指定を回避する際にも弄る場所(だよね?)
XSS対策で入れるのは分かるけど、コントロールしたい人や企業は相当苦労しそう。
だからProselfは外せるようにしているんだろうし。

2017年7月6日木曜日

ntpを設定するのと、squidプロキシを噛ませてyum出来るようにする

最近ファイルスタンプのずれが気になるという声が「やっと」聞けたので、ntpを設定していこうと思い立った。
もののついでに、SSLプロキシがはまったせいで、yumさえ出来なかったサーバプロキシの設定をしてyum出来るようにする。

まずゲートウェイサーバをNTPサーバにする。と言っても、外部NTPサーバと同期させるというだけである。
詳しいNTPについては
http://tech.ckme.co.jp/ntp.shtml

環境はcentos5~7、192.168.168.1がプロキシ兼NTPサーバとする。

yum install ntp
設定ファイルを編集
vi /etc/ntp.conf
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap <これをコピーして下で編集
restrict 192.168.168.0 mask 255.255.255.0 nomodify notrap

あと同ファイルで
server ntp.nict.jp#<<公開NTPサービス
server ntp1.jst.mfeed.ad.jp#<<公開NTPサービスに同期している会社の公開NTP
server ntp2.jst.mfeed.ad.jp
server ntp3.jst.mfeed.ad.jp
server 契約しているISPのNTPサービス
#server 0.centos.pool.ntp.org iburst#デフォルトのはコメントアウトして負荷を減らす
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst
これで設定終了。

ntpdate ntp.nict.jp
で手動同期。

systemctl start ntpd
systemctl enable ntpd
で自動起動させる。

iptablesでFW機能をさせているので、iptablesにローカルから自機へのNTP問い合わせ許可設定をする
iptables -I INPUT -p udp --dport 123  -s $trusthost -d $mylanip -j ACCEPT
*$trusthostはローカルIP群、たとえば192.168.168.0/24、$mylanipは、LAN側のIP(この場合は192.168.168.1)。厳密にしないなら-sと-dは無くても良い。

次に、クライアント側設定。
プロキシを通すので、yumの設定ファイルにプロキシを追加
vi /etc/yum.conf

#proxy=http://PROXY-SERVER.ADDRESS:port
proxy=http://192.168.168.1:8080


プロキシの噛ませ方は、以下のページが詳しい
http://fj.hatenablog.jp/entry/2014/08/20/204554

で、サーバと同じようにyumでNTPを入れる

yum install ntp
設定ファイルを編集
vi /etc/ntp.conf
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap <これをコピーして下で編集
restrict 192.168.168.0 mask 255.255.255.0 nomodify notrap
更に、サーバはnictを登録したけど、クライアントはnictを参照させず、NTPサーバを参照させるので
server 192.168.168.1
とする。
ntpdate 192.168.168.1
で手動同期。

systemctl start ntpd
systemctl enable ntpd
で自動起動させる。

追記
上記でも良いけど、設定しながら「これってntpdateをcronで動かした方がリソース消費しなくね?」という事実に気付き、上記の設定ファイルの編集をせず、たとえば
vi /etc/cron.daily/ntpdate_update.sh
とかで新規ファイルを作って
#!/bin/sh
ntpdate 192.168.168.1
で保存し、
chmod +x ntpdate_update.sh
で実行権限付けて、デーモンは動かさないことにした。クライアントなんだから走らせ続ける意味はないわな。
まあ別に走らせても良いと言えばいいわけで(どうせローカル参照だし)、取り消し線で済ませておくことにする。

手動あわせしようとした際に出る「the NTP socket is in use, exiting」というエラーメッセージは、読んで字のごとく、「NTPソケットはもう使ってるから!」と言われている。
おとなしく
systemctl stop ntpd
なり
service ntpd stopなりでNTPを止めてから
再度実行して下さい。

備忘録
オレオレ証明書等ルート証明書をlinuxに読ませる場合
centos7
https://cloudpack.media/14148
/usr/share/pki/ca-trust-source/anchors
に証明書をコピーして
update-ca-trust extract
を実行

centos5~6
https://wp.kaz.bz/tech/2013/05/02/1651.html
/etc/pki/tls/certs/にコピーか、
/etc/pki/tls/certs/ca-bundle.crtに追記する。

2017年7月1日土曜日

別環境にファイルサーバを据えたら認証で待たされる(遅くなった)。サーバが参照するdnsサーバを疑え

念願のclassB環境にネットワークを移行させたのは良いものの、結局トラブった。
classC環境(いわゆる192.168.x.x)からPC台数と管理の関係でclassBに移行したのだけれども、
何故か社内の特定ファイルサーバだけ、認証画面に行き着くまでかなりの時間(数十秒)待たされる。
認証してしまえば全く問題なく使えるのだけれども、統括部内だと全ての部署に配置されているファイルサーバに接続するため、
いちいち時間がかかってしようが無い。

結論から言うと、サーバ側の問題だったが、まあおつきあい下さい。
環境はcentos 5x~7xまでばらばらだが、centosとsambaで構成されたファイルサーバ群。クライアントは大半がwindows10。

まず疑ったのが、クライアントPCのルーティング。
クラスC環境は全て取っ払った」ので、192.168とか吐いたら間違いなくそれの筈。
そこで、Wiresharkで通信ログを取るが、
全てDHCPで管理しているので、ルーティングをしくじっている気配は無い。
192.168とか吐いていればこれだと言えるが、吐いているのはサーバ群のみ。
*このときに気付いていれば良かったが、CからBへの移行の際、シームレスに移行するためにファイルサーバにはIPアドレスを2つ(BとC)持たせていたので、別に不自然だとは思わなかった。

次に、正常なサーバと異常なサーバを比較。
smb.confを比較したが、特に引っかかるところは無かった。
強いて言えば、netbios_nameがあったりなかったり程度。
iptablesではじいてしまっているのかと思って比較するも、関係なし。
ただ、
いつもはさっと引ける「iptables -L」が異常に重い

google先生に
「iptables "-L" ローカルIPアドレス 遅い 表示」
で聞いてみると、どうやら名前を逆引き出来ないから、という結論に。
iptables -nLで逆引きしなければ良いよ、と教えて貰えるが、それはこの環境での答えとは違う。引いているのはローカルIPアドレスなのである。
ここら辺で、なんとなく名前の解決関係(DNS)がらみなのではと疑い出す。

ゲートウェイやDHCPはクラスB環境に移行していたので、最後にファイルサーバ群のネットワークの記述をクラスCのみにすることに。
ここで比較していると、一点だけ違う、奇妙なことに気がついた。
PEERDNS。
解説は
http://think-t.hatenablog.com/entry/20110113/p1
が詳しいのだけれども、あるなしの違いがあった。
正常に繋がる方は、PEERDNS=no、繋がらない方は記述自体が無い。
上記ページに従うと、resolv.confの記述内容を使うかどうかということ。
Centos5から使い続けていたので、NetworkManagerとは因縁がある。
もしNMを使っていれば関係ないのかもしれないが、
NMを使っていると、勝手にresolv.confを書き換えるので、意図的に停止させているのである。
なので、resolv.confの書き換えをしないと、設定は生きっぱなしになる。
resolv.confには、ばっちりclassCのDNSサーバアドレス。
しかも僕はご丁寧に(移行中だったからだけど)NICの設定ファイル(ifcfg-foobar)にも書いていた。

ということで、問題点は、
「存在しないDNSサーバにファイルサーバが問い合わせまくって、その問い合わせの答えが出ないから時間がかかりまくった」
ということでした。
解決法は
NICの設定ファイル(/etc/sysconfig/network-scripts/ifcfg-foobar)に正しいDNSサーバアドレスを書く
ことと、
resolv.confを見直し、ちゃんと正しいDNSサーバアドレスを認識しているかどうかを確認する
こと。

前者は、たとえばNICの設定ファイルがifcfg-eth1だった場合、
vi /etc/sysconfig/network-scripts/ifcfg-eth1
で、正しいDNSサーバのIPアドレスを指定する。たとえば
DNS=192.168.0.1
と記述してやる。
僕がはまったのは、サーバは番号を振ればいくらでも登録出来るので
DNS1=192.168.XXX.XXX
DNS2=172.16.YYY.YYY
のように登録して、DNS1は既に取り外していたこと。

後者も同じように、nameserver=でいくつでも登録出来るので、使う(使える)DNSサーバだけにする。

これで問題なくなった。

以下はgoogle先生に聞きまくったときに出てきた似たような事例。
残念ながら答えは出ていなかったが、恐らく問題は同じだろうと推察。
http://cgi.samba.gr.jp/mailman/archives/samba-jp/2013-July/003306.html
クライアント-サーバ間では全く問題ないログしか吐かないし、Wiresharkでも問題が認識出来ないのがミソ。

自分の関連過去エントリは
resilv.confとPEERDNSなど
http://roserogue.blogspot.jp/2011/10/cent-os6resolvconf.html

sambaがらみ
http://roserogue.blogspot.jp/2007/08/samba.html

2017年6月26日月曜日

SSLプロキシとして動作中のSquid内ネットワークでwindows機にwindows updateさせたい

もう透過プロキシなんて全く考えなくなってしまった僕です。
SSL対応させて分かったことは、もう透過させて何とかしようっていうのが無意味に感じたこと。
証明書読ませる時点で何やってるか自明ですやん・・・。

で、表題の件。
SSL bumpでSSL対応プロキシとして動作しているSquidを頂点としたネットワーク内から、windows updateさせようとしてはまった。
構成は

インターネット - Squid入りゲートウェイ - ハブで分かれたPC群(ほぼwindows10)

まず、Squid公式で、windows updateの項目を見る
http://wiki.squid-cache.org/SquidFaq/WindowsUpdate#Squid_with_SSL-Bump_and_Windows_Updates
To pass WU check through Squid splice, you only need to splice next MS servers:

update.microsoft.com
update.microsoft.com.akadns.net

For use in real setups, write file url.nobump:

# WU (Squid 3.5.x and above with SSL Bump)
# Only this sites must be spliced.
update\.microsoft\.com
update\.microsoft\.com\.akadns\.net

Just add this file as Squid ACL as follows:

acl DiscoverSNIHost at_step SslBump1
acl NoSSLIntercept ssl::server_name_regex -i "/usr/local/squid/etc/url.nobump"
ssl_bump splice NoSSLIntercept
ssl_bump peek DiscoverSNIHost
ssl_bump bump all

どうやらurl.nobumpに正規表現で書いたドメインをプロキシから除くということらしい。



centos7のrpmインストールなので、/usr/local/squidは/etc/squidに読み替え。
update.microsoft.com
update.microsoft.com.akadns.net
だけ接いでやればいいから!と読めるが、実はそうでも無かった。
実行すると、
一部の署名ファイルが正しく署名されていません。
エラー コード: (0x800b0109)
とでる。
恐らくオレオレ証明書を参照しているからだろうと推測できるが、となると全く接げてないじゃん。
で、更にgoogle先生にお伺いを立てると
https://blogs.technet.microsoft.com/jpwsus/2017/02/27/wu-mu-list/
結構あるぞ・・・。
全部上記に追加して、Squidを再起動してみるが、駄目。
割り切って
windows\.com
windowsupdate\.com
microsoft\.com
とすると、繋がった。がばがばである。
ただ、アップデータをダウンロードするところまで見られていないので、もしかしたらダウンロードに失敗するかもしれない。
等と思っていたら、

が出た。
Squidログを見ていると、
live.net
live.com
宛てにも接続しようとしている。
なので
live\.net
live\.com
を追加して、事なきを得た。
筈だった。
たまたまonenoteを立ち上げたら、onedriveと同期できない。
で、google先生に再度お伺いを立てると、
https://support.microsoft.com/ja-jp/help/2894304
という、winhttpという機構にもプロキシを噛まさなければならないことが判明。
どういう理屈なんだろう・・・・・・・。
プロキシを通せば良いので、
netsh winhttp set proxy proxy-server="server-domain-or-ip-address:12345"  bypass-list=""
としてあげると繋がった。必ず管理者権限で動かすこと。バイパスは多分ローカルだけで良いと思う。
※12345はポート番号。
winhttpについては
http://www.maruko2.com/mw/WinHTTP%E3%83%97%E3%83%AD%E3%82%AD%E3%82%B7%E3%81%AE%E8%A8%AD%E5%AE%9A%E6%96%B9%E6%B3%95

さて、SSLゲートウェイを通すためにユーザに配布するものを整理しよう・・・。
・自己署名証明書ファイル(.derファイル。ブラウザに読ませる)
・winhttpを設定するバッチファイル(管理者権限で動かすこと)
・windowsのプロキシ設定ファイル(設定のネットワークとインターネットから設定するシステムのプロキシをレジストリ直で書くもの。)
この3つかな。
多分透過で上手く動くのであれば、下2つは要らない。
最後の一つのレジストリ上プロキシの場所は
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]

2017年6月24日土曜日

AMD APUのA10-7890Kで、D-SUB出力しようとしたら解像度ではまる

windows10をインストールした表題のA10-7890Kマシンで、何故か上限が1600×1200ピクセル止まりになって悩んでしまった。
そもそもモニタが非pnpディスプレイとして認識され、削除しようが結局同じ。
モニタのプロファイルを導入しても変わらず。
グラフィック側のプロパティで上げようとすると、インターレース扱いになる。
その解決法は、実は未だ分かっていないのだけれども、何故かDVI接続すると、DVIは1920出せる。
うちの環境だと、DVI一本だと表示さえされず、D-SUBとDVIの二本繋ぎでデュアルディスプレイとして認識し、ミラーリングしたらしっかり認識した(そしてその後はDVIのみで繋がっている)。
解決という解決ではないが、不思議。

2017年6月23日金曜日

squidをSSLに対応させたい。https通信なんて大っ嫌いだ・・・。

今回何をやったかというと、SquidのSSL対応である。その備忘録。やり方は後日ここにも書きます。ひとまずわかりやすいpslaboさんの記事の方へ

元々
http://pslabo.hatenablog.com/entry/20150703/p1
で、https通信、しかも透過型で噛ませられることは認識していた。
ただ二の足を踏んでいたのは、
・作っている暇が無かった。
 作るならゲートウェイサーバをすげ替えることになるので、何より面倒くさかった。
・透過型なのだけれども、証明書をクライアントにインストールしなければならなかった。
 実は結構これが大きくて、今はプロキシが噛んでいることをユーザは認識せずに使っているのだけれども、証明書を入れなければいけない時点で認識されてしまう。
 また、ゲストネットワークをどう認識させるかという問題もあった。ゲストがネットワークに繋ごうとすると、証明書のインストール必須だと、まあ誰も接続しないだろうし、接続したいと言い張られてサポートに人手が必要とか、切ないことになりそうだったので。

でももう背に腹は代えられなくなってしまった。
どうも社内ファイルがgoogleドライブで作業されているようなのである。
せめてoffice onlineなら分かる。お漏らし回数で考えると、圧倒的にまだマイクロソフトに分があるから。
googleはあくまでも自己責任ツールの集合体で、信用しても信頼してはならない。
大企業だからって信頼してはならないことを知っているはずなのに。
また、銀行系マルウェアに感染した人が居て、大騒ぎになった。愚かとしか言い様がないが、いとも簡単に感染してしまっているのが現実。
で、そのマルウェア、誘導にSSL使っていやがります。
今のままだと、まず間違いなくやられる。
ということで、以下を実行。
pslaboさん本当にありがとうございます。。。見ず知らずなのに即行エントリ書いてもらいました・・・。
http://pslabo.hatenablog.com/entry/2017/06/18/CentOS7%E3%81%A7squid%E3%81%A7SSL%E3%82%92%E3%83%95%E3%82%A3%E3%83%AB%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%99%E3%82%8Bproxy%E3%82%92forward_proxy%E3%81%A7%E8%A8%AD%E5%AE%9A%E3%81%97%E3%80%81

はまったところは、透過プロキシとフォワードプロキシで動作が違うらしく、google「だけ」HSTS通信と見なされ、証明書エラーで通らないこと。facebookもtwitterもHSTS通信でも大丈夫だったのに。
透過プロキシだとどうしても通らなかったのが、通常のプロキシだと通るという・・・。
ここからカスタムしていくことになるのだけれども、まずはOK/NGという初期段階まではいけたということで。
#検証前だけど、googleがリダイレクト動作をしているので、そこで引っかけている可能性が高そう。どう回避するかなあ・・・。