<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>WAN &#8211; 業務改善コンサルティング情報ブログ</title>
	<atom:link href="https://www.trilogyforce.com/blog/tag/wan/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.trilogyforce.com/blog</link>
	<description>業務改善で収益改善！</description>
	<lastBuildDate>Mon, 17 Jun 2024 01:21:12 +0900</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.1</generator>
	<item>
		<title>3389番ポートへの対策を推奨</title>
		<link>https://www.trilogyforce.com/blog/recommended-action-for-port-3389/</link>
		<comments>https://www.trilogyforce.com/blog/recommended-action-for-port-3389/#respond</comments>
		<pubDate>Mon, 24 Jun 2019 10:59:03 +0900</pubDate>
		<dc:creator><![CDATA[Shingo Takahashi]]></dc:creator>
				<category><![CDATA[情報セキュリティ]]></category>
		<category><![CDATA[23]]></category>
		<category><![CDATA[445]]></category>
		<category><![CDATA[3389]]></category>
		<category><![CDATA[5555]]></category>
		<category><![CDATA[@police]]></category>
		<category><![CDATA[ADB]]></category>
		<category><![CDATA[Android Debug Bridge]]></category>
		<category><![CDATA[Android端末]]></category>
		<category><![CDATA[Microsoft]]></category>
		<category><![CDATA[RDS]]></category>
		<category><![CDATA[Remote Desktop Services]]></category>
		<category><![CDATA[TCP]]></category>
		<category><![CDATA[WAN]]></category>
		<category><![CDATA[Windows]]></category>
		<category><![CDATA[コマンドラインツール]]></category>
		<category><![CDATA[パケット]]></category>
		<category><![CDATA[パスワード]]></category>
		<category><![CDATA[ファイル共有]]></category>
		<category><![CDATA[プリンタ共有]]></category>
		<category><![CDATA[ポート番号]]></category>
		<category><![CDATA[ユーザー名]]></category>
		<category><![CDATA[リモートアクセス]]></category>
		<category><![CDATA[リモートデスクトップ]]></category>
		<category><![CDATA[リモートデスクトップサービス]]></category>
		<category><![CDATA[リモートデスクトップ接続]]></category>
		<category><![CDATA[警察庁]]></category>
		<category><![CDATA[遠隔操作]]></category>

		<guid isPermaLink="false">https://www.trilogyforce.com/blog/?p=7674</guid>
		<description><![CDATA[先週末警察庁は、『RDS（Remote Desktop Services / リモートデスクトップサービス）』の探索行為への注意喚起を『＠police』において公開しています。 皆さん、こんにちは。 業務改善を行うIT・&#8230;]]></description>
				<content:encoded><![CDATA[<p>先週末警察庁は、『RDS（Remote Desktop Services / リモートデスクトップサービス）』の探索行為への注意喚起を『＠police』において公開しています。</p>
<div class="mgt10 mgb10" itemprop="image" itemscope itemtype="https://schema.org/ImageObject"><img decoding="async" src="//www.trilogyforce.com/blog/wp-content/uploads/2019/06/remote-desktop.jpg" alt="リモートデスクトップ接続" width="450" height="450" class="size-full wp-image-7681"  loading="lazy" srcset="https://static.trilogyforce.com/blog/wp-content/uploads/2019/06/remote-desktop.jpg 450w, https://static.trilogyforce.com/blog/wp-content/uploads/2019/06/remote-desktop-150x150.jpg 150w, https://static.trilogyforce.com/blog/wp-content/uploads/2019/06/remote-desktop-300x300.jpg 300w" sizes="auto, (max-width: 450px) 100vw, 450px" /><meta itemprop="url" content="https://www.trilogyforce.com/blog/wp-content/uploads/2019/06/remote-desktop.jpg"><meta itemprop="width" content="450"><meta itemprop="height" content="450"></div>
<p>皆さん、こんにちは。</p>
<p>業務改善を行うIT・業務コンサルタント、高橋です。</p>
<p class="pdt20">Windowsの遠隔操作に使われる『RDS（Remote Desktop Services / リモートデスクトップサービス）』、何も変更していなければ『3389/TCP』というポートが使われますが、変更していればその限りではありません。</p>
<p class="pdt20">そんな『RDS（Remote Desktop Services / リモートデスクトップサービス）』に対して『警察庁』は『＠police』にて注意喚起を促しています。</p>
<h2 class="contTitle">3389番ポートとRDSへの対策など</h2>
<h4 class="fontB">＜3389番ポートとRDS＞</h4>
<p class="pdt20">まず、警察庁が注意喚起を促しているRDSに関しては以下のセキュリティ対策を推奨しています。</p>
<p class="pdt20">・Windows OSを最新の状態にする</p>
<p>・RDSを使用しない場合はサービスを無効にする</p>
<p>・RDSをインターネット経由で接続する場合はアクセス制限を行う</p>
<p>・リモートアクセス可能なユーザーは必要最小限に限定する</p>
<p>・ユーザー名、パスワードは推測されにくいものにする</p>
<h4 class="fontB pdt20">＜その他のポート番号＞</h4>
<p class="pdt20">確かに『3389/TCP』へのパケット数は増加していますが、それよりも注意すべきものがあるように感じます。</p>
<p class="pdt20">１．telnet/23ポート</p>
<p class="pdt10">以前から変わらず一番多いもので、不要であれば閉じておくべきです。</p>
<p class="pdt20">２．microsoft-ds/445ポート</p>
<p class="pdt10">Windowsでファイルやプリンタの共有に使われますが、これは少なくともWAN側の内向きは閉じてしまうべきです。</p>
<p class="pdt20">３．5555番ポート</p>
<p class="pdt10">Android端末のコマンドラインツール（ADB / Android Debug Bridge）などでも使われているポート番号ですが、昨今、攻撃にもよく使われています。</p>
<p class="pdt20">この辺りにも注意をされた方が良いと思われます。</p>
]]></content:encoded>
			<wfw:commentRss>https://www.trilogyforce.com/blog/recommended-action-for-port-3389/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>WAN側のIPは定期的に見直せ</title>
		<link>https://www.trilogyforce.com/blog/periodically-review-the-ip-on-the-wan-side/</link>
		<comments>https://www.trilogyforce.com/blog/periodically-review-the-ip-on-the-wan-side/#respond</comments>
		<pubDate>Wed, 30 Jan 2019 10:02:51 +0900</pubDate>
		<dc:creator><![CDATA[Shingo Takahashi]]></dc:creator>
				<category><![CDATA[WEBに関する情報]]></category>
		<category><![CDATA[Analytics]]></category>
		<category><![CDATA[Google]]></category>
		<category><![CDATA[IP]]></category>
		<category><![CDATA[IPアドレス]]></category>
		<category><![CDATA[OCN]]></category>
		<category><![CDATA[WAN]]></category>
		<category><![CDATA[au]]></category>
		<category><![CDATA[アクセス]]></category>
		<category><![CDATA[アクセス解析]]></category>
		<category><![CDATA[アナリティクス]]></category>
		<category><![CDATA[インターネット]]></category>
		<category><![CDATA[ウェブサイト]]></category>
		<category><![CDATA[セキュリティ]]></category>
		<category><![CDATA[フィルタ]]></category>
		<category><![CDATA[プロバイダ]]></category>
		<category><![CDATA[ホームページ]]></category>
		<category><![CDATA[メンテナンス]]></category>
		<category><![CDATA[中小]]></category>
		<category><![CDATA[事業者]]></category>
		<category><![CDATA[企業]]></category>
		<category><![CDATA[停電]]></category>
		<category><![CDATA[小規模事業者]]></category>
		<category><![CDATA[障害]]></category>
		<category><![CDATA[零細]]></category>

		<guid isPermaLink="false">https://www.trilogyforce.com/blog/?p=7012</guid>
		<description><![CDATA[ウェブサイト（ホームページ）の管理を自社で行われている事業者の方、WEBの担当者は定期的にWAN側のIPアドレスの見直しをされていますか？ 皆さん、こんにちは。 業務改善を行うIT・業務コンサルタント、高橋です。 ウェブ&#8230;]]></description>
				<content:encoded><![CDATA[<p>ウェブサイト（ホームページ）の管理を自社で行われている事業者の方、WEBの担当者は定期的にWAN側のIPアドレスの見直しをされていますか？</p>
<div class="mgt10 mgb10" itemprop="image" itemscope itemtype="https://schema.org/ImageObject"><img decoding="async" src="//www.trilogyforce.com/blog/wp-content/uploads/2019/01/ip.jpg" alt="IPアドレス" width="450" height="450" class="size-full wp-image-7014"  loading="lazy" srcset="https://static.trilogyforce.com/blog/wp-content/uploads/2019/01/ip.jpg 450w, https://static.trilogyforce.com/blog/wp-content/uploads/2019/01/ip-150x150.jpg 150w, https://static.trilogyforce.com/blog/wp-content/uploads/2019/01/ip-300x300.jpg 300w" sizes="auto, (max-width: 450px) 100vw, 450px" /><meta itemprop="url" content="https://www.trilogyforce.com/blog/wp-content/uploads/2019/01/ip.jpg"><meta itemprop="width" content="450"><meta itemprop="height" content="450"></div>
<p>皆さん、こんにちは。</p>
<p>業務改善を行うIT・業務コンサルタント、高橋です。</p>
<p class="pdt20">ウェブサイト（ホームページ）を公開している会社や店舗であれば、自社や自店のウェブサイト（ホームページ）にどれくらいのアクセスがあるのかが気になるところです。</p>
<p class="pdt20">しかし、その中に自社や自店からアクセスしたものも含めていては正確なアクセス数に大きな誤差が生じる場合があります。</p>
<h2 class="contTitle">WAN側のIPを定期的に見直す必要性</h2>
<p>ウェブサイト（ホームページ）のアクセス解析を行う場合、多くはGoogleのAnalytics（アナリティクス）が使われていますが、それに何も設定をしなければ全てのアクセスが含まれてしまうため正確なアクセス数とは言えないことが多いのも事実です。</p>
<p class="pdt20">つまり、自社や自店の従業員・スタッフがアクセスした数まで含まれてしまうため、大幅にアクセス数が増えてしまっていることも考えられます。</p>
<p class="pdt20">これはAnalytics（アナリティクス）の管理上でフィルタリング設定を行うことで除外できますが、問題なのは自社や自店で契約しているインターネット回線のWAN側IPアドレスです。</p>
<p class="pdt20">どういうことかと言うと、中小・零細企業、小規模事業者の多くは固定IPアドレスの契約をすることは少なく、OCNやauなどのプロバイダから割り当てられる動的なIPアドレスを使用することになります。</p>
<p class="pdt20">これが今日の本題です。</p>
<p class="pdt20">プロバイダから割り当てられる動的なIPアドレスはある日突然変わることがあります。</p>
<p class="pdt20">例えば、プロバイダ側で設備メンテナンスがあったとか、影響する部分において障害が発生したとか、自社や自店付近などにおいて停電があったとかによる影響を受けます。</p>
<p class="pdt20">このような場合、自社や自店に設置されているルータはIPアドレスを取得し直すため、WAN側のIPアドレスが変わってしまうことがあるのです。</p>
<p class="pdt20">それ以外にも、セキュリティ的な観点から一定期間を経過すると割り当てているIPアドレスの割り当て直しを行うこともあり、WAN側のIPアドレスが変わってしまうのです。</p>
<p class="pdt20">これを把握しないまま放置していると当然ながらアクセス解析に影響しますので、定期的にWAN側のIPアドレスを確認し、変わっていたのであればAnalytics（アナリティクス）のフィルタ設定にて除外しているIPアドレスを変更してあげる必要性があります。</p>
]]></content:encoded>
			<wfw:commentRss>https://www.trilogyforce.com/blog/periodically-review-the-ip-on-the-wan-side/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>回線自動判別機能は影響がある</title>
		<link>https://www.trilogyforce.com/blog/the-automatic-line-judgment-function-is-affected/</link>
		<comments>https://www.trilogyforce.com/blog/the-automatic-line-judgment-function-is-affected/#respond</comments>
		<pubDate>Tue, 08 Jan 2019 10:51:40 +0900</pubDate>
		<dc:creator><![CDATA[Shingo Takahashi]]></dc:creator>
				<category><![CDATA[ITに関する情報]]></category>
		<category><![CDATA[WAN]]></category>
		<category><![CDATA[Wi-Fi]]></category>
		<category><![CDATA[Wi-Fiルーター]]></category>
		<category><![CDATA[buffalo.jp]]></category>
		<category><![CDATA[インターネット]]></category>
		<category><![CDATA[インターネット＠スタート]]></category>
		<category><![CDATA[ケーブル]]></category>
		<category><![CDATA[サーバー]]></category>
		<category><![CDATA[サーバー障害]]></category>
		<category><![CDATA[ネットワーク機器]]></category>
		<category><![CDATA[バッファロー]]></category>
		<category><![CDATA[パソコン]]></category>
		<category><![CDATA[ファームウェア]]></category>
		<category><![CDATA[ルーター]]></category>
		<category><![CDATA[再起動]]></category>
		<category><![CDATA[周辺機器]]></category>
		<category><![CDATA[回線自動判別]]></category>
		<category><![CDATA[無線LAN]]></category>
		<category><![CDATA[無線LANルーター]]></category>

		<guid isPermaLink="false">https://www.trilogyforce.com/blog/?p=6917</guid>
		<description><![CDATA[事務所などの多くで使われている『無線LANルーター（Wi-Fiルーター）』には、インターネット回線を自動で判別する機能が搭載されているものがあります。 しかし、この機能は時には障害の影響を受ける可能性があります。 皆さん&#8230;]]></description>
				<content:encoded><![CDATA[<p>事務所などの多くで使われている『無線LANルーター（Wi-Fiルーター）』には、インターネット回線を自動で判別する機能が搭載されているものがあります。</p>
<p class="pdt20">しかし、この機能は時には障害の影響を受ける可能性があります。</p>
<div class="mgt10 mgb10" itemprop="image" itemscope itemtype="https://schema.org/ImageObject"><img decoding="async" src="//www.trilogyforce.com/blog/wp-content/uploads/2019/01/router.jpg" alt="無線LANルーター（Wi-Fiルーター）" width="450" height="450" class="size-full wp-image-6922"  loading="lazy" srcset="https://static.trilogyforce.com/blog/wp-content/uploads/2019/01/router.jpg 450w, https://static.trilogyforce.com/blog/wp-content/uploads/2019/01/router-150x150.jpg 150w, https://static.trilogyforce.com/blog/wp-content/uploads/2019/01/router-300x300.jpg 300w" sizes="auto, (max-width: 450px) 100vw, 450px" /><meta itemprop="url" content="https://www.trilogyforce.com/blog/wp-content/uploads/2019/01/router.jpg"><meta itemprop="width" content="450"><meta itemprop="height" content="450"></div>
<p>皆さん、こんにちは。</p>
<p>業務改善を行うIT・業務コンサルタント、高橋です。</p>
<p class="pdt20">昨日、パソコン周辺機器で有名なバッファローがこんな発表をしました。</p>
<p class="pdt20">『無線LANルーター製品の一部でインターネットに接続できない障害が発生した。』と。</p>
<p class="pdt20">さて、これは何が影響してそのような事態になったのでしょうか？</p>
<h2 class="contTitle">回線自動判別機能が影響した障害</h2>
<p>インターネットに接続できなくなった原因は、2018年12月29日から2019年1月3日の間に発生していた『buffalo.jpサーバーの障害』にありました。</p>
<p class="pdt20">これ、一見何の関係が？と思えてしまいますが、バッファローの無線LANルーターに搭載されている『インターネット＠スタート』という回線自動判別機能が障害の起きたサーバーを使っているために起きたものです。</p>
<p class="pdt20">バッファローの無線LAｎルーターは非常に多く使われていますが、簡単に設定ができるように出荷時の初期状態において『インターネット＠スタート』を使うようになっています。</p>
<p class="pdt20">この状態でサーバー障害の発生期間に無線LANルーターの再起動やWANポートのケーブルの抜き差しを行ってしまうとインターネット接続ができなくなってしまい、上流のネットワーク機器の設定変更や再起動などによっても同じ障害が発生した可能性があるとされています。</p>
<p class="pdt20">ただし、この現象が起きた無線LANルーターは以下の機種に限定されているようです。</p>
<p class="pdt20">・WSR-1166DHPシリーズ</p>
<p>・WCR-1166DS</p>
<p>・WXR-1900DHP2（ファームウエアVer2.49以前）</p>
<p>・WXR-1750DHP（同Ver2.48以前）</p>
<p>・WXR-1900DHP</p>
<p class="pdt20">上記の機種においてインターネットに接続できない回線であると誤判定されていたようです。</p>
<p class="pdt20">このインターネット接続判定は機種のグループによってサーバーが異なるようで、対象機種以外の無線LANルーターにおいては問題は発生しなかったとされています。</p>
<p class="pdt50">このように、回線自動判別機能を使って無線LANルーターを設定している場合、メーカーのサーバー障害による影響を受ける可能性がありますので、できればそれを使わずに設定を行いたいものです。</p>
<p class="pdt50">ちなみに、現在サーバーは復旧しているとのことで、現在でもインターネット接続ができない場合は無線LANルーターを再起動するか、WANポートのケーブルを抜き差しすることでインターネット接続が復旧するようです。</p>
]]></content:encoded>
			<wfw:commentRss>https://www.trilogyforce.com/blog/the-automatic-line-judgment-function-is-affected/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>23番ポートは今すぐ閉じるべき</title>
		<link>https://www.trilogyforce.com/blog/the-port-23-should-be-closed-now/</link>
		<comments>https://www.trilogyforce.com/blog/the-port-23-should-be-closed-now/#respond</comments>
		<pubDate>Fri, 16 Jun 2017 12:55:54 +0900</pubDate>
		<dc:creator><![CDATA[Shingo Takahashi]]></dc:creator>
				<category><![CDATA[情報セキュリティ]]></category>
		<category><![CDATA[23番ポート]]></category>
		<category><![CDATA[Aterm]]></category>
		<category><![CDATA[LAN]]></category>
		<category><![CDATA[NEC]]></category>
		<category><![CDATA[NICT]]></category>
		<category><![CDATA[TELNET]]></category>
		<category><![CDATA[WAN]]></category>
		<category><![CDATA[インターネット]]></category>
		<category><![CDATA[サイバーセキュリティ]]></category>
		<category><![CDATA[サイバーセキュリティ研究所]]></category>
		<category><![CDATA[サイバー攻撃]]></category>
		<category><![CDATA[ダークネット]]></category>
		<category><![CDATA[パケット]]></category>
		<category><![CDATA[モニタリング]]></category>
		<category><![CDATA[リアルタイム]]></category>
		<category><![CDATA[リモートメンテナンス]]></category>
		<category><![CDATA[ルータ]]></category>
		<category><![CDATA[国立開発研究法人情報通信研究機構]]></category>
		<category><![CDATA[遠隔操作]]></category>

		<guid isPermaLink="false">https://www.trilogyforce.com/blog/?p=4425</guid>
		<description><![CDATA[昨日、某テレビ局の番組で、サイバー攻撃に関することが少し触れられていました。 日本にも、とんでもない数のサイバー攻撃を日々受けています。 皆さん、こんにちは。 業務改善を行うIT・業務コンサルタント、高橋です。 以前にも&#8230;]]></description>
				<content:encoded><![CDATA[<p>昨日、某テレビ局の番組で、サイバー攻撃に関することが少し触れられていました。</p>
<p>日本にも、とんでもない数のサイバー攻撃を日々受けています。</p>
<div class="mgt10 mgb10" itemprop="image" itemscope itemtype="https://schema.org/ImageObject"><img decoding="async" src="//www.trilogyforce.com/blog/wp-content/uploads/2017/06/atlas.jpg" alt="NICTER Atlas" width="450" height="302" class="size-full wp-image-4429"  loading="lazy" srcset="https://static.trilogyforce.com/blog/wp-content/uploads/2017/06/atlas.jpg 450w, https://static.trilogyforce.com/blog/wp-content/uploads/2017/06/atlas-300x201.jpg 300w" sizes="auto, (max-width: 450px) 100vw, 450px" /><meta itemprop="url" content="https://www.trilogyforce.com/blog/wp-content/uploads/2017/06/atlas.jpg"><meta itemprop="width" content="450"><meta itemprop="height" content="302"></div>
<p>皆さん、こんにちは。</p>
<p>業務改善を行うIT・業務コンサルタント、高橋です。</p>
<p>以前にも、『<a class="sb-line" href="/blog/the-internet-is-a-cyber-war/">インターネットはサイバー戦争</a>』という記事にて触れましたが、インターネットの世界をリアルタイムでモニタリングすると、すさまじい勢いで世界的にサイバー攻撃がなされています。</p>
<p>当然、日本に向けられたサイバー攻撃もとんでもない数になっています。</p>
<p class="pdt20">さて、ここで注目したいのは、一番攻撃を受けているのは何か？というところです。</p>
<h2 class="contTitle">23番ポートへの攻撃はNo.1</h2>
<p>NICT（国立開発研究法人情報通信研究機構）のサイバーセキュリティ研究所が公開しているデータを見ると、昨年のダークネット観測パケット数の年間統計では、約1,281億ものパケットが観測されています。</p>
<div class="mgt10 mgb20" itemprop="image" itemscope itemtype="https://schema.org/ImageObject"><img decoding="async" src="//www.trilogyforce.com/blog/wp-content/uploads/2017/06/darknet.jpg" alt="ダークネット観測パケット数の年間統計" width="450" height="252" class="size-full wp-image-4434"  loading="lazy" srcset="https://static.trilogyforce.com/blog/wp-content/uploads/2017/06/darknet.jpg 450w, https://static.trilogyforce.com/blog/wp-content/uploads/2017/06/darknet-300x168.jpg 300w" sizes="auto, (max-width: 450px) 100vw, 450px" /><meta itemprop="url" content="https://www.trilogyforce.com/blog/wp-content/uploads/2017/06/darknet.jpg"><meta itemprop="width" content="450"><meta itemprop="height" content="252"></div>
<p>そして、昨日のパケット数に目を向けると、No.1は23番ポートに対する8,108,510パケットで全体の37%も占めていました。</p>
<div class="mgt20 mgb10" itemprop="image" itemscope itemtype="https://schema.org/ImageObject"><img decoding="async" src="//www.trilogyforce.com/blog/wp-content/uploads/2017/06/packets-top10.jpg" alt="TCP宛先ポート別パケット数Top10" width="450" height="291" class="size-full wp-image-4435"  loading="lazy" srcset="https://static.trilogyforce.com/blog/wp-content/uploads/2017/06/packets-top10.jpg 450w, https://static.trilogyforce.com/blog/wp-content/uploads/2017/06/packets-top10-300x194.jpg 300w" sizes="auto, (max-width: 450px) 100vw, 450px" /><meta itemprop="url" content="https://www.trilogyforce.com/blog/wp-content/uploads/2017/06/packets-top10.jpg"><meta itemprop="width" content="450"><meta itemprop="height" content="291"></div>
<p class="pdt20">この23番ポートというのは、リモートメンテナンスなどの遠隔操作で使われる『telnet』用のポート番号で、暗号化されていない平文ベースの通信を行うものになります。</p>
<p>そこが一番狙われいているということです。</p>
<p class="pdt20">この『telnet:23番ポート』は、未だ多くのネットワーク機器においてメンテナンス用として残っていることが多いのですが、これは必要がなければ閉じてしまうべきです。</p>
<p>ただし、外部業者などから遠隔操作におけるメンテナンスを受けている場合は業者と協議せざるを得ません。</p>
<p class="pdt20">昨今のセキュリティソフトには、ネットワークに危険性があるのか否かを調査するツールがあったりもしますが、これはツールによって検知の仕方が異なりますので、それで問題がなかったからと言って絶対とは言えません。</p>
<p class="pdt20">現に、とあるメーカーのルータを確認したところ、A社のソフトでは問題が出ず、B社のソフトでは問題が発見されました。</p>
<p class="pdt20">このような場合においては、WAN側、LAN側、ともに23番ポートを内向きにすべてを拒否（廃棄）する設定を加えてあげなければポートは開いたままになりますので、万が一狙われてしまった場合においては被害を受ける可能性があるということになります。</p>
<p class="pdt20">そういったことにならないためにも今すぐ確認をし、やむを得ない理由がないのであればすぐに閉じてしまうことをお勧めします。</p>
]]></content:encoded>
			<wfw:commentRss>https://www.trilogyforce.com/blog/the-port-23-should-be-closed-now/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>別セグメントへのTCP/IP印刷</title>
		<link>https://www.trilogyforce.com/blog/tcp-ip-printing-to-another-segment/</link>
		<comments>https://www.trilogyforce.com/blog/tcp-ip-printing-to-another-segment/#respond</comments>
		<pubDate>Wed, 29 Jun 2016 11:30:52 +0900</pubDate>
		<dc:creator><![CDATA[Shingo Takahashi]]></dc:creator>
				<category><![CDATA[ITに関する情報]]></category>
		<category><![CDATA[DHCP]]></category>
		<category><![CDATA[IP]]></category>
		<category><![CDATA[LAN]]></category>
		<category><![CDATA[LPR]]></category>
		<category><![CDATA[RAW]]></category>
		<category><![CDATA[TCP/IP]]></category>
		<category><![CDATA[WAN]]></category>
		<category><![CDATA[キュー]]></category>
		<category><![CDATA[グループ]]></category>
		<category><![CDATA[ゲートウェイ]]></category>
		<category><![CDATA[セグメント]]></category>
		<category><![CDATA[ネットワーク]]></category>
		<category><![CDATA[プリンタ]]></category>
		<category><![CDATA[プロトコル]]></category>
		<category><![CDATA[ルータ]]></category>
		<category><![CDATA[印刷]]></category>
		<category><![CDATA[部署]]></category>

		<guid isPermaLink="false">https://www.trilogyforce.com/blog/?p=2711</guid>
		<description><![CDATA[社内ネットワークを構築する際、運用管理の利便性などを考慮してグループや部署ごとなどにてネットワークセグメントを分けることをしたりもします。 しかし、このセグメント分割に対して間違った認識をしている人もいます。 皆さん、こ&#8230;]]></description>
				<content:encoded><![CDATA[<p>社内ネットワークを構築する際、運用管理の利便性などを考慮してグループや部署ごとなどにてネットワークセグメントを分けることをしたりもします。</p>
<p>しかし、このセグメント分割に対して間違った認識をしている人もいます。</p>
<div class="mgt10 mgb10" itemprop="image" itemscope itemtype="https://schema.org/ImageObject"><img decoding="async" src="//www.trilogyforce.com/blog/wp-content/uploads/2016/06/network-1.jpg" alt="ネットワーク" width="450" height="323" class="size-full wp-image-2715"  loading="lazy" srcset="https://static.trilogyforce.com/blog/wp-content/uploads/2016/06/network-1.jpg 450w, https://static.trilogyforce.com/blog/wp-content/uploads/2016/06/network-1-300x215.jpg 300w" sizes="auto, (max-width: 450px) 100vw, 450px" /><meta itemprop="url" content="https://www.trilogyforce.com/blog/wp-content/uploads/2016/06/network-1.jpg"><meta itemprop="width" content="450"><meta itemprop="height" content="323"></div>
<p>皆さん、こんにちは。</p>
<p>業務改善を行う業務コンサルタント、高橋です。</p>
<p>今日は、企業間の担当者同士にあった会話の中で耳を疑うような内容のものをご紹介します。</p>
<p>それはこんな内容です。</p>
<h2 class="contTitle">TCP/IP印刷に対する間違った認識</h2>
<p>A氏：『新しく別のセグメントでネットワークを追加したのですが、そちらのセグメントにあるプリンタに印刷させてもらって良いでしょうか。』</p>
<p>B氏：『プリンタを使う分には構いませんが、TCP/IP印刷は同一セグメント内でしか印刷できないですよ。』</p>
<p>A氏：『いえ、別のセグメントに対しても印刷はできます。念のため社内でもテストをしてきましたので。』</p>
<p>B氏：『そんなことはあり得ませんよ。それは間違っていますね。』</p>
<p>A氏：『では、印刷の許可だけもらえれば結構です。』</p>
<p>こんな感じの会話なのですが、これはどちらが正解かというと、Aさんは正しくBさんは間違いです。</p>
<p>ちなみに、とあるプリンタを製造しているメーカーのサポートセンターのオペレーターもB氏と同じことを言っていたようなので驚きです。</p>
<h2 class="contTitle">別セグメントへのTCP/IP印刷</h2>
<p>この会話が行われたところのネットワーク構成は下記のような構成です。</p>
<p>B氏構築のネットワークセグメント：192.168.1.0/24</p>
<p>同ルータLAN側IP：192.168.1.1（デフォルトゲートウェイ）</p>
<p>同セグメント内のプリンタIP：192.168.1.100</p>
<p>A氏構築のネットワークセグメント：192.168.2.0/24</p>
<p>同ルータWAN側IP：192.168.1.200、デフォルトゲートウェイとDNS IP：192.168.1.1</p>
<p>同ルータLAN側IP：192.168.11.1</p>
<p>同クライアント：DHCP自動取得</p>
<p>こんな感じのネットワーク構成になっているのですが、A氏が構築したネットワーククライアントからは下記のようにプリンタを設定します。</p>
<p>プリンタポートをStandard TCP/IPとし、プリンタのIPアドレスに192.168.1.100を設定します。</p>
<p>それ以外は、プロトコルでLPRを選択してLPRのキュー名を入れるか、Rawを選択してポート番号に9100などを設定するかです。</p>
<p>この設定で基本的には192.168.2.0のセグメントにあるクライアントから192.168.1.0のセグメントにあるプリンタ192.168.1.100に印刷を行うことができます。</p>
<p>もしこれで印刷できないとすれば、プリンタの置かれているセグメントにあるルータの設定としてプライバシーセパレート（ネットワーク分離）をしている可能性があります。</p>
<p>その場合はその機能をOFFにしないと印刷することができません。</p>
<p>ご参考までに。</p>
]]></content:encoded>
			<wfw:commentRss>https://www.trilogyforce.com/blog/tcp-ip-printing-to-another-segment/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ネットワーク構築時の問題事例</title>
		<link>https://www.trilogyforce.com/blog/problem-in-network-construction/</link>
		<comments>https://www.trilogyforce.com/blog/problem-in-network-construction/#respond</comments>
		<pubDate>Wed, 22 Jun 2016 12:17:11 +0900</pubDate>
		<dc:creator><![CDATA[Shingo Takahashi]]></dc:creator>
				<category><![CDATA[ITに関する情報]]></category>
		<category><![CDATA[DHCP]]></category>
		<category><![CDATA[LAN]]></category>
		<category><![CDATA[WAN]]></category>
		<category><![CDATA[インシデント]]></category>
		<category><![CDATA[インターネット]]></category>
		<category><![CDATA[クライアント]]></category>
		<category><![CDATA[ゲートウェイ]]></category>
		<category><![CDATA[サーバ]]></category>
		<category><![CDATA[セグメント]]></category>
		<category><![CDATA[ネットワーク]]></category>
		<category><![CDATA[ルータ]]></category>
		<category><![CDATA[無線LAN]]></category>

		<guid isPermaLink="false">https://www.trilogyforce.com/blog/?p=2682</guid>
		<description><![CDATA[ネットワーク対応の業務システムを開発したA社は、他の業者Bが構築したネットワークが既存のネットワークを経由する以上、業務システムに不具合が起きないとは約束もできなければその責任も負えないと回答しました。 さて、この真意は&#8230;]]></description>
				<content:encoded><![CDATA[<p>ネットワーク対応の業務システムを開発したA社は、他の業者Bが構築したネットワークが既存のネットワークを経由する以上、業務システムに不具合が起きないとは約束もできなければその責任も負えないと回答しました。</p>
<p>さて、この真意は？</p>
<div class="mgt10 mgb10" itemprop="image" itemscope itemtype="https://schema.org/ImageObject"><img decoding="async" src="//www.trilogyforce.com/blog/wp-content/uploads/2016/06/network.jpg" alt="ネットワーク" width="450" height="450" class="size-full wp-image-2683"  loading="lazy" srcset="https://static.trilogyforce.com/blog/wp-content/uploads/2016/06/network.jpg 450w, https://static.trilogyforce.com/blog/wp-content/uploads/2016/06/network-150x150.jpg 150w, https://static.trilogyforce.com/blog/wp-content/uploads/2016/06/network-300x300.jpg 300w" sizes="auto, (max-width: 450px) 100vw, 450px" /><meta itemprop="url" content="https://www.trilogyforce.com/blog/wp-content/uploads/2016/06/network.jpg"><meta itemprop="width" content="450"><meta itemprop="height" content="450"></div>
<p>皆さん、こんにちは。</p>
<p>業務改善を行う業務コンサルタント、高橋です。</p>
<p>冒頭にお書きした内容は実際に起きた内容なのですが、こういった話しはよくあると言えばよくある話しです。</p>
<p>では、何故業者はこういった対応になるのでしょうか？</p>
<h2 class="contTitle">別セグメントのネットワーク</h2>
<p>今回の事例では、元々A社が構築されていた業務システムネットワークに配慮し、別のセグメントにて構築するというものでした。</p>
<p>＜業務システム側のネットワーク＞</p>
<p>ルータ：192.168.10.1<br />
サーバ：192.168.10.2（GW-192.168.10.1）<br />
業務システムクライアント：192.168.10.3～5（GW-192.168.10.1）<br />
事務クライアント：192.168.20.3～5（GW-192.168.20.1）</p>
<p>＜B社追加構築のネットワーク＞</p>
<p>無線LANルータ：WAN側-192.168.20.100（GW-192.168.20.1）/LAN側-192.168.30.1<br />
クライアント：DHCP自動取得</p>
<p>簡単にはこんな感じなのですが、事務クライアントはアドレス変換にてルータを経由してインターネット回線に出ます。</p>
<p>また、B社追加構築のクライアントは、無線LANルータのWAN側である192.168.20.100からゲートウェイを通じて事務クライアントと同じ経路を経由してインターネット回線に出ます。</p>
<p>つまり、構成上から業務システムに与える影響はないのです。</p>
<p>もし可能性があるとしたら、事務クライアントも業務システムに影響を与える可能性を秘めていることになりますので、A社が主張したことは少々矛盾を感じます。</p>
<p>（A社も一般的には問題がないはずであることは認めていた。）</p>
<h2 class="contTitle">業者は自社以外のものを避けたがる</h2>
<p>では、何故A社は業務システムへの責任を回避したかったのか？</p>
<p>よく、システム業者同士がサーバを分けて欲しい旨をクライアントに依頼することはあります。</p>
<p>単純に、どちらのシステムが問題で不具合が生じたのかの切り分けが難しく、相手方のシステムの問題であっても自社も調査をしなければいけない可能性を秘めているからです。</p>
<p>しかし、ネットワークの場合、別々に分断されたネットワークでは片方がインターネット回線を使用することができなくなってしまいますので、どこかでつなげておくしかありません。</p>
<p>そのためにセグメントを分け、影響が出ないようにしてつなげているわけです。</p>
<p>となると何故なのか？</p>
<p>私からすると、業務システム全体を把握できていないような気がします。</p>
<p>もし新しいネットワークの一部である無線LANルータを懸念しているのであれば、既に事務クライアントでも近い可能性はもっていますので、結局のところは全体を把握しきれていないと考えざるを得ないです。</p>
<p>もしくは、自分達が携わったもの以外による影響の可能性を残し、インシデント発生時の盾にしたいのではないかと思われます。</p>
<p>平たく言えば、問題が起きたら調査費用を請求したいということなのでしょう。</p>
<p>いずれにせよ、もう少しクライアントファーストである必要性があるのではないでしょうか。</p>
]]></content:encoded>
			<wfw:commentRss>https://www.trilogyforce.com/blog/problem-in-network-construction/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
