WEBサイト
  サポート

【WEBツール紹介】サーバー、WEBサイトのセキュリティ対策に貢献されてるIPAの攻撃兆候検出ツール iLogScanner をもっと使おう!

新ツール公開。サイトへの攻撃が日常になった今、まずはこれを利用して調査しよう IPA提供 攻撃兆候検出ツール iLogScanner で簡単ログ分析ツール ★iLogツカウン 企業や政府といった大きな組織でなくとも、無差別でサイトへの攻撃、侵入トライ・ハックトライが今や日常だ。 サイトやWEBページは簡単に便利に「創れる」ようになったが、「守る」というところは、まだまだ専門家やシステムに強いところが普通にやってるレベル。 でも、間違いなく常に狙われている。WEBディレクターの立場として、常に意識を持っていなければならないところだ。 もちろん、すでに業界化してて、多くのセキュリティ対策会社や有料の脆弱性検査サービスは存在する。 資金に余裕があり、任せているところは。どうぞ、だけれど、お金かけないでも注意すること、できるレベルのセキュリティ対策はある。 この、WEbサイトサポートでも、外から脆弱性監査をする「WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン」というのを用意しているが、 すでに攻撃を受けている。その兆候があるのでは? を調べてくれるのが、IPA(独立行政法人 情報処理推進機構)が提供してくれている「ウェブサイトの攻撃兆候検出ツール iLogScanner」だ。 PCにインストールして利用できる優れものだが、Java環境が必要だったり、ファイルの形式などの制限もあり、この素晴らしいツールをもっと容易に、利用してもらえるような仕組みを用意した。 もちろん、実際の保守の現場ではこれでは足りず、他の様々なログの解析や目視も含め、「守り人」をやっているわけだが、このツールをつかってまずは、現在「攻撃」されているのか、その兆候はあるのか、チェックしておこう。 ウェブサイトの攻撃兆候検出ツール iLogScanner IPA 独立行政法人 情報処理推進機構 が提供してくれている「iLogScanner」は、ウェブサーバのアクセスログから攻撃と思われる痕跡を検出するためのツールだ。 ウェブサイトの攻撃兆候検出ツール iLogScanner 「ウェブサイトのログを解析することで攻撃の痕跡を確認でき、一部の痕跡については攻撃が成功した可能性を確認できます。また、SSHやFTPサーバのログに対しても、攻撃と思われる痕跡を検出することができます。」と謳われている。 htmlファイルで詳細な結果を見ることができる いくつものサーバー、サイトの「守り人(保守)」やらせてもらってて、相当お世話になっている、無償で使える素晴らしいツールだ。 とても重宝させていただいて、ほんとにありがとうございます。 みなさんもぜひ、サイトにアクセスされ、ご利用されてくださいね。「推し」です。 ただ、使えば使うほど、色々とこうだったらなぁ、とかもやもやも貯まってきて、あとは、このツールもっと当たり前に使われるべきだろう、という勝手な「推し」も生まれてきて、今回のこのツール「★iLogツカウン」提示ということになった。あー、同じことまた言ってる。   iLogScanner を使うにすこしだけ、工夫を組み込んだ access.log ファイルは、基本、ローテートって言って、巨大ファイルにならないように、日別とか(まれに月別)ごとにファイルが分割保存されてて、それをひとつづつ指定するのは、少し手間(?)だったかな。 あと、tarファイルや gzファイルに圧縮されていることも多く、それを毎回解凍するのも面倒(?)な。 さらに、ログの記述形式、ね。iLogScannerでは特定の形式しか受け付けないから、それも毎回変換する手間が省けたらなぁ。 などの理由で、それらを仕組みで用意して あとはとにかく、広くこのツールを利用し、少しでも、WEBサイトを営まれている方々の安心につながれば・・・です。 iLogScanner はサーバーに組み込むこともでき、それをその通り組み込んでいるだけで、iLogScannerのすばらしい機能には何も手を加えていません(できるはずもないし)。 こちらで、変換・準備したソースを与えるというだけの 工夫ツールになります。 取得した、アクセスログファイルをセットして使ってみてください ツールの性格上、また当サイトへのセキュリティ考慮もあり、利用記録がわかる「会員限定ツール」にさせていただいている。ご容赦ください。 [実行] ボタンをクリックして、少しお待ちいただくと・・・ 圧縮されたファイルがダウンロードできるようになって ダウンロードされたファイルを解凍すると・・・ 走査対象の一つにまとめられた logファイルと、3つの解析結果ファイルが取得できます。 xmlファイル:iLogScanner が吐き出した xmlファイル(無修正) jsonファイル:xmlファイルを、みなさんが他の用途で利用しやすいように、jsonファイルに加工したもの excelファイル:結果をExcelファイルで見れるようにしたもの(iLogScannerの結果そのまま) Excelで状況が確認できます 対策のところは、最新の情報含め、こんごもっと整備したいと思っています。 検出されないのが一番いいでがね・・・ これからこれを さらに改善してゆく様子も、またオープンに公開したいと思います。 ぜひ、大事なサイトを守るためにお役立てくださいね 各所でお伝えしているように、この WEBサイトサポートでは、基本的にみなさんの詳細な情報を保存することはありません。生成が終え、ファイルダウンロードをしていただいた時点で、お預かりした元のログファイル、結果ファイルなど、すべて、すぐに削除されます。ご安心ください。 今日はここまで。またお目にかかりましょう。

【WEBツール紹介】会員になったらまず、ご利用いただける、管理サイト機能をご紹介。精度も品質もどんどん高めてゆきます!

少し用意したツールを紹介しよう。まずは、会員登録したら使える「管理サイト」機能 このサイトでは、WEBディレクターが本当に使える、役立てるツールを、現場目線で用意することをポリシーにしている。少しづつ紹介してゆきたいが、最初に、会員登録していただくと使ってもらえる「管理サイト」機能を。 これは、WEBツールというページにではなく、トップページに用意した3つ目のタブ「管理サイト」で用意されている。 会員登録してサインイン(ログイン)していただき、管理サイトを登録するとご利用いただける。 会員登録(もちろん、無料)して、マイページで管理するサイトを登録 サイトのURLアドレスをセットして、下部にある [ 更新 ] ボタンをクリックしてください。 ちなみに、おまけみたいな機能ではありますが、1日1回、サイト生存確認できる機能も用意してますよ。 登録後、トップページの「管理サイト」のタブを開いてみてください サイトのURLアドレスをセットして、下部にある [ 更新 ] ボタンをクリックしてください。ここからもゆけます。 最初、初回のクロール走査を行います。少しお時間かかると思うので、何か他のことをされてお待ちください。 管理サイトの基本的な状態を確認してください [基本情報]・[パフォーマンス]・[コンテンツ]・[リンク]・[SEO] の5つの視点から、簡易的ではありますが、サイトの状態をスキャンしてスコア付けされます。   スクリーンキャプチャ PC(デスクトップ)、mobile(スマホ)のスクリーンショットを配置 5つの視点でのスコア 下にある数値は エラー/警告(Warning)。自分で創ったシステムではありますが、このサイトの今、ひどいもんですねぇ ちょっと厳しすぎるかも。(変更するかもです)。まぁ、スコア・表示はほんとご参考程度で、それよりも提示している各要件に注視、どんどん対応してゆきましょう・・・私もやりまーす。 クリックで詳細な情報が表示されます 重要指標 [読込スピード]・[サイズ]・[重さ]・[リンク]・[OGタグ廻り] 優先改善事項 さぁ、何やりましょってことですね。どんどんつぶしてゆきましょう パフォーマンス、コンテンツ、リンク、SEO の スキャン詳細 なるべくシンプルに気にしなければならないところを端的にまとめています 再走査する ボタンで再スキャンしますので、確認して(大事!)、対応して、スキャン・確認の PDCAの始まりですね!! いまの WEBサイトサポート・・・ひどい状態だということはわかりました では、これからこれを どんどん改善してゆく様子も、またオープンに公開したいと思います。 ぜひ、みなさんも管理サイト登録してチェック、サイトをよりよくするためにお役立てくださいね なお、この WEBサイトサポートでは、基本的にみなさんの詳細な情報を保存することはありませんが、この「管理サイト」は、この後の追加機能で、検査したものを時系列に把握でき、何をやった同良くなった・・・を把握できる機能を予定しており、ここのスキャンデータだけは保持しています。(退会されれば抹消されます)。暗号化して保存しています。ご了承ください。 今日はここまで。またお目にかかりましょう。

このサイト、最初に何を整えるか・・・まずは少しセキュリティ対策を施す。SQLインジェクション対策とか、XSS防止とか・・・

しれっとオープンしてから数日。引き続きずっと触ってます。成長させる。 このサイトでは、今もいくつかのツールを提供してて、さらに今後も、サイト運営の現場で役に立つツールを、どんどん用意したい。 安心して使ってもらうためにも、このサイトを長く利用してもらうためにも、セキュリティ対策が必要だ。こんな小さなサイト、誰が狙うか、とも思うけども、最低限はしておかなくてはね。あ、どこかのハッカーさん、狙ってやろうなんて思わないでね、お金も得るものもは何もないから。 で、こうやってその事も書き留めておけば、誰かの目に留まり役に立つかもしれない・・・   "うちには関係ないよ" は 関係ない 「この規模のサイトが、狙われるわけないでしょ」・・・実は、ネットの攻撃は無差別に“自動”で仕掛けられるものが大半。たとえば放置しているWordPressの管理画面に、世界中からブルートフォース(総当たり)アタックが日常的に来るのは、実際によくある話。だから「最低限」だけでも、しておかないとだめなんだよね。サーバ委に対する、権限とかが影響して、できることにはもちろん限りもあるけどね。   セキュリティ対策の考え方 専門的な技術的な説明ではなく、なるべくわかりやすく記録しておく。 インターネットにおけるセキュリティ対策は、どこの時点で、何から守るかを明確に定義して、それに粛々と対応してゆくことが大事だと思っている。 何層かにわけた図とかよくあるけど、要に次の3つに分けられると思う。 一番外側 フロントと呼ばれるブラウザで直接アクセスするところ アクセスしたあと、プログラムなどの仕組みが動いているところ 大元のアクセスする基本部分 言い換えるね。 フロント(入口)  └ サイトを見に来た“誰でも触れる部分”   → ログイン画面、フォームなど 仕組み(中身)  └ サイトを動かしているプログラム部分   → CMS(WordPress等)、各種プラグイン、APIなど 土台(基盤)  └ サーバやOS、データベース、ネットワーク設定 じゃ 実践記録を。 フロント(入口) .htaccess というサイトにおいて色々な設定ができるファイル。最近は、rootという権限を持っていないサーバーでも、レンタルサーバーでも設定できるようになってきているね。 # ======================================== # リスト表示させない # ======================================== Options -Indexes # ======================================== # ファイル保護 # ======================================== <Files ".htaccess"> Order Deny,Allow Deny from all </Files> <Files ".htpasswd"> Order Deny,Allow Deny from all </Files> # ======================================== # アップロードファイル保護 # ======================================== # ログ・設定ファイル保護 <Files "*.log"> Order Deny,Allow Deny from all </Files> <Files "*.ini"> Order Deny,Allow Deny from all </Files> <Files "*.conf"> Order Deny,Allow Deny from all </Files> # バックアップファイル保護 <Files "*.bak"> Order Deny,Allow Deny from all </Files> <Files "*.backup"> Order Deny,Allow Deny from all </Files> <Files "*.old"> Order Deny,Allow Deny from all </Files> <Files "*.tmp"> Order Deny,Allow Deny from all </Files> # ======================================== # 著名な攻撃への基礎対策 # ======================================== # SQLインジェクション対策 RewriteCond %{QUERY_STRING} (union|select|insert|delete|update|drop|create|alter|exec|script) [NC] RewriteRule ^(.*)$ - [F,L] # XSS対策 RewriteCond %{QUERY_STRING} (<script|<iframe|<object|<embed|javascript:|vbscript:|onload|onerror) [NC] RewriteRule ^(.*)$ - [F,L] # パストラバーサル対策 RewriteCond %{REQUEST_URI} (\.\.\/|\.\.\\|%2e%2e%2f|%2e%2e\\) [NC] RewriteRule ^(.*)$ - [F,L] # 不正なユーザーエージェント対策 RewriteCond %{HTTP_USER_AGENT} ^$ [OR] RewriteCond %{HTTP_USER_AGENT} (sqlmap|nmap|nikto|w3af|acunetix|nessus|openvas) [NC] RewriteRule ^(.*)$ - [F,L] # ======================================== # セキュリティヘッダー強化 # ======================================== <IfModule mod_headers.c> # XSS Protection Header always set X-XSS-Protection "1; mode=block" # Content Type Options Header always set X-Content-Type-Options "nosniff" # Frame Options Header always set X-Frame-Options "SAMEORIGIN" # Referrer Policy Header always set Referrer-Policy "strict-origin-when-cross-origin" # サーバー情報隠蔽 Header unset Server Header unset X-Powered-By </IfModule> 少し説明、付けておきますね。 リスト表示させない ディレクトリの中身が丸見えだと、地味に危ない。見えなくしておくのが吉。 Options -Indexes ファイル保護 設定とかログとか、大事なファイルは外から見えないようにガード。 <Files ~ "\.(env|git|htpasswd|htaccess|ini|log|sh|bak)$"> Order Deny,Allow Deny from all </Files> アップロードファイル保護 もしもユーザーに変なファイルを上げられても、実行させなければとりあえずセーフ。 <FilesMatch "\.(php|cgi|pl|py|exe|sh)$"> Order Deny,Allow Deny from all </FilesMatch> バックアップファイル保護 消し忘れたバックアップ、意外と多い。ここも一応ブロック。 <FilesMatch "\.(bak|old|save|orig)$"> Order Deny,Allow Deny from all </FilesMatch> SQLインジェクション対策 URLに怪しいSQLキーワードが入ってたら強制シャットアウト。ざっくりだけど結構効く。 RewriteCond %{QUERY_STRING} (union|select|insert|delete|update|drop|create|alter|exec|script) [NC] RewriteRule ^(.*)$ - [F,L] XSS対策などHTTPヘッダー追加 サーバーやブラウザに一声かけておくだけで守れる部分は結構ある。 Header always set X-XSS-Protection "1; mode=block" Header always set X-Content-Type-Options "nosniff" Header always set X-Frame-Options "SAMEORIGIN" Header always set Referrer-Policy "strict-origin-when-cross-origin" Header unset Server Header unset X-Powered-By ほんと、シンプルな基本だけど、ひとまず・・・ Google reCaptcha フォームにはこれだね。いまは Version3(V3)。私はロボットじゃない とか バイクのある写真選べ とかなくなって使いやすくなった。閾値をセットして、アクセスがロボットかどうかを判断してくれる。完全、100%とは言えないだろうけど、最低限、ね。ありがとうございます。 1. API KEy の取得 https://developers.google.com/recaptcha?hl=ja こちらで まずはキーを取得。サイトキー と シークレットキー   2.フロント側 {サイトkey) には取得したサイトキーをセット。 <script src="https://www.google.com/recaptcha/api.js?render={サイトkey)"></script> <script> grecaptcha.ready(function() { grecaptcha.execute('{サイトkey)', {action: 'submit'}).then(function(token) { var recaptchaResponse = document.getElementById('recaptchaResponse'); recaptchaResponse.value = token; }); }); </script> 送信フォームにこれを追加しておく recaptcha の値を格納するところ。 <input type="hidden" name="recaptcha_response" id="recaptchaResponse">   3.サーバー側 これは phpサイトでの一例。 $_val は送られてくる Recaptcha の値。$_sid はシークレットキー、ね。 public function ckRecaptcha($_val,$_sid) { $_rt = null; if( (!empty($_val)) ){ $recaptcha_secret = $_sid; $recaptch_url = 'https://www.google.com/recaptcha/api/siteverify'; $recaptcha_params = [ 'secret' => $recaptcha_secret, 'response' => $_val, ]; $recaptcha = json_decode(file_get_contents($recaptch_url . '?' . http_build_query($recaptcha_params))); if(!( (!empty($recaptcha)) &&(!empty($recaptcha->score)) )){ $_rt = false; }else{ if ($recaptcha->score >= 0.6) { $_rt = true; } else { $_rt = false; } } } return $_rt; } こういう関数を用意してチェック。でも実際は、サーバーの様々な理由から簡単に導入できず数日悩むこともあるんだよね・・・まぁ、それに泥臭く対応するのが仕事なんだけど。 今日はここまで。本当はもっと フロント側やったことあるので、また、ここに追記しておきます。 後日、 仕組み(中身) 土台(基盤) でやったことも公開しておきます。お役に立てれば・・・

(サイト)保守って、なんじゃろ?

サイト保守。それは、サイトの守り人(もりびと)に違いない。  いまも、多くのお客様のサイトを保守させていただいている。 契約上のことで言えば、お客様によりまちまちではあるが、一定の料金で○○○をやります、というスタイル。 何時間かの作業時間も含まれてて、通常の料金より割安に設定。時には、制限時間を超えることもあるけれど・・・ 基本、定額でWEBサイトの更新や修正、改造を行う ・・・ うーむ。まるで、制作サブスクのようだ。 お客様にとっては、定額で運営を行う作業経費を計算でき、細かい見積のやり取りがなくなり、低コストで安心した運営を続けられる ・・・ ん?安心?割安?。 違うなぁ。 世の中の保守契約とか保守サポートとかの定義とは違うかもだけど、 私は、「サイト保守」ってのは、サイトの守り人(もりびと)になる事、それをやる事 ・・・なんだと思う。 家で例えると、管理人?か。 定期的に設備を見直し、壁がどうしようもなく痛んだらリペイント。ゴミが出てたら、綺麗になるように考える。 いやぁ、それじゃ足らないな。 家は人が住んでいる。毎日誰か(お母さん、か、最近はお父さん、も)掃除をし。痛んだところは直し、より楽しく暮らすために改築をする。 手入れも管理もしなければ。家はボロボロになるばかりだ。朽ちてゆくばかり。 そうだ。侵入者が来ないように戸締りをして、不審なことがあれば、セキュリティ対策をする。 ※・・・そういえば先日、私も庭に侵入された形式があり、しょぼい対応だけど、まずは、人感センサーで光るライトを取り付けた。 だけど、それだけじゃないね、いい日々を送れるように、花を飾り、空気の入れ替えをして・・・ いま稼働している多くのWEBサイト。もちろん、有料で構築された MicoroftのIISやOracleのサーバーもあるだろうけど、かなりの数が、世界中の有志によるオープンソースで用意されたものの集合体だ。プロバイダにサーバーの入れ物代は払うけれど、一番利用させてもらってるのは、中身の細かいプログラム・リソース、サーバーソフトウェアだけでなく、数千数万を超えるオープンソースのファイルの集まり。それら、ほぼ無償。凄い世界だ。 知らない間に、多くの見知らぬ人々(・・・ただただ、技術と好奇心、指名、没入に追われている、もちろん金儲けも野心もあるだろうが)から恩恵受けて、それを忘れてるわけだ。 日々、進化し続ける技術。サイトのあらゆるリソースが改変・拡張・改良続けされ続けている。 しかし、それに対して、何もしなければ、サイトはそのままだ。古いリソースのまま。セキュリティ対策の細かいパッチだって、存在知っていてもあてなければ何もならない。家と同じで、放っておくと、ゴミは貯まる一方。 いずれそんなのも、何にもメンテナンスのいらない完全自動の世の中になるのだろうか? いや、ならないだろうなぁ。自動てってのは曲者で、効率とリスクを交換しているようなものだ。自動にして、不要なものまでひきとる必要はないし、オープンソースの世界はほんと奥深いからね。様々な手法のせめぎあいだ、相性を考ええてやらないといけないのはいつものこと。時には、意味不明な大量なエラー文字に悩まされ、おそらく、それは(メンテナンスは)無くならないんだろうなぁ・・・ それがまt、面白いんだけど。 あぁ、ふと、が長くなってしまった。 でも、「保守」って別にめちゃ凄い技術をもってやっているわけでもない(もちろん、凄い技術持ってる方々もたくさんいますよ)。 基本、誰でもできる。 サイト保守、サーバー保守ってのは、一番は、いつも「気にする」って事なんだと思いますよ。結構大事で本質的なことだから、大変でもあります。 と、ぼやきまくって ・・・さて 本題。 SSHで接続して、簡単なサーバー健康状態を見れる人は見てみよう  もちろん、今の世ですから・・・お金かければわかりやすいシンプルな管理画面擁した、サーバー管理ソフトウェアなんてのはやまほど。うみほど、ありますよ。 でも、普通に telenet とかでSSHでサーバーに入り、コマンド打って様子見る・・・って、大事だし、面白い。 最近のレンタルサーバーは、ソフトウェア使った SSH接続しなくても、サーバーの管理画面に root権限でのコンソール用意していることも多いから、そこで容易に行えます。 ほら、子供のころにまだ入ったことのない裏の物置小屋に懐中電灯で入り込んだみたいで、楽しいもんです。ちと、不謹慎か。 ・・・おぉ、また 前置きが長くなってしまった。 いつも私が見守っているサイトたちに、どんなコマンド投げて何を見ているかを列記しますね。 何度も言うけど、プログラム書いて自動化だってできますよ。ただ、このあたりは、・・・意外とやらない。 私が、見守ってやんなきゃだからね。自動化って「自動にすることで意識が薄れ形骸化する」ことにもなりますしね。 さ、こっからは、下手な口上は無いですよ。ただただ、列記しますね。プロの方々はわかりきってる、当たり前のことだから参考にも何にもならないだろうから、スルーで。 でも、WEBディレクターになりたてや、好奇心たまらない方々は、こういうこともエンジニアや外注に投げるんじゃなく、自分でやってみると意外と、サイトに愛着・愛情(恐ろしく)湧いてきますよ。 ・・・さて ※なお、紹介するのは、Linuxにおいて広く使われている CentOS というディストリビューションが入っているサーバーです。OSによりコマンドは変わることもあるので、ご留意。 この "CentOS" はサポート期間の終了という課題テーマがあり、いくつかのお客様のサーバーでもその問題に直面してます。また、言えること、書きますね。 ※また、例としてあげているキャプチャは私の管理している自身のサーバーのうちのどれか、です。お客様の情報はあげられませんのでね。 まず把握。どんなことでも、これがファーストステップ  新しくサイトを預かり、「守人」になった時に行うチェック。 空き容量の確認 # df|grep -v loop ※基本は df -hなんだけど、こうしないと気にしなくていい snapの仕組みが利用している loopデバイスが表示されてしまう。 ※空き容量の確認とディスクのパーティーション構成のチェック。 ※メインパーティーションは "/dev/vda2" で、まだ 14%しか使ってませんね。 CPU・メモリの利用状況 # top ※リアルタイム表示。 ※(Windowsなら) Ctrl+Z で表示止められます。 ※メモリ8MBなので、ずいぶん、swap使ってますね。まだ、全然大丈夫そうだけど。 WEBサーバーチェック # systemctl status httpd ※Apache使っている場合。(nginxなら # systemctl status nginx) ※問題なさそうです。 まれに、最終行に "Notice: journal has been rotated since unit was started, output may be incomplete." とか出ることがあります。 その場合は httpd.service を再起動してみてください。 firewall の基本チェック # systemctl status firewalld ※firewalldが動作しているかどうかを systemctlコマンドにstatusを指定して確認 ※動いています。 firewall の設定チェック # firewall-cmd --get-active-zone<br> # ls /usr/lib/firewalld/zones<br> # cat /usr/lib/firewalld/zones/public.xml<br> ※firewalldの現在設定を確認 ※eth*インターフェースにpublicゾーンが設定してある状態。 ※CentOSのデフォルトの場合、設定ファイルはxml形式で/usr/lib/firewalld/zonesディレクトリに用意。 ※sshとdhcpv6-clientのみ許可。 firewall の現在のゾーンを詳しく見る # firewall-cmd --list-all ※firewall-cmdコマンドに--list-allオプション ※デフォルト状態。 ※実際はここにポート変更やIP制限ほか 必要な設定を加えてゆく。 不正アクセスを監視。チェックもしよう  どんなサーバーも必ず行われているハックトライ(ハッキング試行) 不正アクセス失敗のIPアドレスチェック # lastb -i | head --lines=-2 | awk '{print $3}' | sort | uniq --count | sort --reverse | less ※lastb コマンドで参照されるアクセス失敗のログで、IPアドレスによるカウント、多い順にソート。 ※この(私の)サーバーは、かなり古いやつですが、恐ろしいもんですね ユーザー別ログインチェック # lastlog ※侵入はされてませんが、これ、失敗はすべてハックトライ。 ※あまりの多さなので、ユーザー名での制限などは無意味です。 あとは、アクセスログ、エラーログ廻りですね。今回は割愛しますが、エラーログは、システムが吐き出すもの、メールやDBそのほかミドルウェアが吐き出すもの、そしてフレームワークやアプリケーションが吐き出すものなど多様です。細かく診なければなりません。そのあたり、実はいくつかは自動化しているのですが、そのあたりはまた今度、紹介します。 お互い、頑張って「守り人」やりましょうね。
2025/05/31
THU
00:00:00

ブラウザ・OS 最新バージョン

毎日更新:2025-09-08 調査更新済
  • Android(stable) 未取得
  • Chrome Android(stable) 140.0.7339.51
  • Chrome iOS(stable) 140.0.7339.101
  • Chrome(beta) 141.0.7390.7
  • Chrome(dev) 141.0.7378.4
  • Chrome(stable) 140.0.7339.81
  • Edge(stable) 140.0.3485.54
  • Firefox(stable) 142.0.1
  • Opera(stable) 121.0.5600.50
  • Safari iOS(stable) 未取得
  • Safari(stable) 未取得
  • iOS(stable) 未取得

現在の貴方のIPアドレス

216.73.216.31

このサイトで書いている人

株式会社ツクルン

株式会社ツクルン

Webアドバイジング・クリエイター
池田南美夫
もうすぐ●●歳。ずっーと現役SE。日本にインターネットが上陸してから、ずっーと携わる。 ほんとは超アナログ人間のギター弾き、バンドマン。でも音楽活動とSE、案外似てる。