masaya_yoshitomi
2023年12月8日 16時58分
お世話になっております。
ネットワークセキュリティの考え方について質問です。
理解不足の点もあるかと思いますが、ご協力のほどお願いいたします。
G3を用いて製品開発を実施しており、ネットワークセキュリティをどう担保するかを検討しております。
不要ポートを閉じたり、不要なサービスを起動しない、といった対策が必要なことは理解しているのですが、どういった状態が対策できているとみなされるのかを具体的に把握したいです。
①以下の認識があっていますでしょうか。
https://armadillo.atmark-techno.com/blog/7370/2953 （Armadillo: TCP/UDPポート開放状態、アプリケーション起動状態の確認方法）
こちらのブログのArmadillo-440上でコマンドを実行した例がありますが、
”iptable -L”の実行結果では以下のようにsshポートはACCEPTになっています。これはssh(22)ポートは開放されていることを示すと認識しております。
[armadillo ~]# iptables -L #省略 ACCEPT udp -- anywhere anywhere udp dpt:ssh
そして、"netstat -a"の実行結果では以下のようにsshは表示されていないことからサービスとして立ち上がっていない（使用されていない）と認識しています。
[armadillo ~]# netstat -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:x11 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:http 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:ftp 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:telnet 0.0.0.0:* LISTEN tcp 0 0 :::x11 :::* LISTEN udp 0 0 0.0.0.0:5353 0.0.0.0:* udp 0 0 :::5353 :::* Active UNIX domain sockets (servers and established) --------------以下略-----------------
"nmap"の実行結果も同様にsshはopenになっていないことから通信不可の状態であることを示していると認識しております。
atde:~/$ nmap [ArmadilloのIPアドレス] Starting Nmap 6.00 ( http://nmap.org ) at 2017-12-28 16:52 JST Nmap scan report for [ArmadilloのIPアドレス] Host is up (0.0010s latency). Not shown: 841 closed ports, 156 filtered ports PORT STATE SERVICE 21/tcp open ftp 23/tcp open telnet 80/tcp open http Nmap done: 1 IP address (1 host up) scanned in 10.40 seconds
②セキュリティ対策の考え方としては一般的に以下の考え方であっていますでしょうか？
ポートの開放状態 x サービスの起動状態 = セキュリティのリスク状態
つまり、以下のような考え方です。
ポートが開放 x サービス起動 = セキュリティリスク高
ポートが開放 x サービス未起動 = セキュリティリスク中
ポートが閉鎖 x サービス起動 = セキュリティリスク中
ポートが閉鎖 x サービス未起動 = セキュリティリスク低
上記のブログの例の場合、「sshはポートは開放状態だが、サービスは未起動なのでリスク中であり、リスクが高い状態ではない」といった考え方は一般的でしょうか？
もちろんアプリケーションや使われ方にも依るので一概には言えないとは思いますが、、、
ご参考程度でもいいのでご教示お願いいたします。
③LTE通信の場合、何をもってセキュリティの安全を図るのか
LTE通信ではグローバルIPが降られますが、それに対してアクセスしようとしてもできない仕組みになっていそうだと思うのですがどのように安全といえるのか、、、
抽象的な質問でもうしわけありませんが、何か参考になる情報等ご存知でしたらご教示のほどお願いいたします。
コメント
masaya_yoshitomi
2024年7月4日 19時46分
上記で回答いただいた内容を元にiptablesの設定を以下のように考えております。
INPUT許可のport番号：67(DHCP)、443(https)、icmp, デバイス側から接続確立(ESTABLISHED)したポート(※）
OUTPUT許可のport番号：基本的に許可
（※）デバイス側からクラウドに対してMQTT接続した際、確率した対象クラウドからの通信は許可
上記の目的を達成するためのiptablesの設定として考えているのが以下です。
セキュリティ向上のためのFirewall設定として問題ないでしょうか？抜けている観点などありましたらご教示お願いいたします。
[iptablesの設定]
/etc/sysconfig/iptables *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [2:58] -A INPUT -i lo -j ACCEPT -A INPUT -p udp -m state --state NEW -m udp --dport 67 -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 8 -m hashlimit --hashlimit-upto 1/min --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name t_icmp --hashlimit-htable-expire 120000 -j ACCEPT COMMIT
at_ohsawa
2024年7月4日 21時50分
はい。組織のNW運用ポリシー等あるとは思いますが、提示された
要件を満たした設定だと思います。
> 上記で回答いただいた内容を元にiptablesの設定を以下のように考えております。
> INPUT許可のport番号：67(DHCP)、443(https)、icmp, デバイス側から接続確立(ESTABLISHED)したポート(※）
運用で強く必要でなければICMPは塞いでしまうのも良いとは思いますが、
塞いだところで経路情報はtcpでも取れるのでDoSの標的になりづらい程度の意味あいです。
ただ、設定されているICMPのINPUTから最低限とした意図が伺えるので、
既に考慮された結果だとお見受けします。
> OUTPUT許可のport番号：基本的に許可
> （※）デバイス側からクラウドに対してMQTT接続した際、確率した対象クラウドからの通信は許可
これもとくに強く推奨するものでもないのですが、汎用的なサーバーと
異なり機能を限定した装置としてArmadilloを運用するはずなので、
OUTPUTを明示の上意図しないパケット送出はしない。
という運用ポリシーを明確に設定に反映するという考え方もあると思います。
もちろん何らかの攻撃によりiptablesを書き換え可能な程度に、
特権を取られる事態であれば、OUTPUTの制限は無意味です。
一方で、確実に使うものだけ出ていくように設定した上で、ネットワーク内を
別途監視している場合は、意図しないパケットが出てるという状況を確認
しやすくなるメリットはあります。明示しておくと意図が明確になる。程度の
意味です。
こちら余談ですが。
すでに使われているかもしれませんが、テスト時にINPUTルールの最後に
-A INPUT -j LOG --log-prefix "IN DROP: " --log-level 7
をつけておくと、ドロップした記録が取れるので開き忘れを確認できます。
ログが多量になるので他のログを押し流してしまう等の問題あるため
テスト時以外は制限したほうが良いです。
at_ohsawa
2023年12月8日 20時01分
> ACCEPT udp -- anywhere anywhere udp dpt:ssh
>
ここでsshについて抜粋するのであれば、tcpの方が主として
使われるので抜粋箇所がtcpではないのが気になりますが、①の理解は正しいです。
> ②セキュリティ対策の考え方としては一般的に以下の考え方であっていますでしょうか？
というより、最終的なソフトウェアの把握と運用が確定しているのであれば、
iptablesでdropするのも、サービスが立ち上がっていないのも
通信できないことに変わり無いため基本的には同程度です。
なので、完全に管理されているのであれば中も低も同じ状態ではあります。
しかし、iptablesは一元的に通信の可否を設定できるため、運用ミスによる
「うっかりサービスを有効にしてしまった。」
「アプリケーションの実装ミスで意図せずポートをacceptしていた」
という状況を一括で拒否・許可できる上に、第三者からもポリシーが
一覧して確認できるので、明確に説明できるメリットがあります。
sshのように最初から起動してacceptしているソフトの場合は
netstatをいつ実行しても判断できますが、
例えば、動作中にごく一時期しかsocketを作らないとか、
特定の条件でしか起動しないソフトウェアだと、netstatしても
気づかないことは多々あると思います。
そういう条件で、まず第一にiptablesで厳密にdrop/acceptを決めて
自社の運用ポリシーを確定したほうがリスク管理しやすいです。
> ③LTE通信の場合、何をもってセキュリティの安全を図るのか
> LTE通信ではグローバルIPが降られますが、それに対してアクセスしようとしてもできない仕組みになっていそうだと思うのですがどのように安全といえるのか、、、
> 抽象的な質問でもうしわけありませんが、何か参考になる情報等ご存知でしたらご教示のほどお願いいたします。
当社の採用しているLTEモジュールについては内部のファイヤウォール(というかNAT)の
設定で、外部からのセッションをデフォルトで拒否しているので、
インターネット側からの接続要求はできません。
(一部製品については特別な設定をすることでファイヤウォールを開放することもできます。)
つまり、LTE側についてはLTEモジュールの機構によってiptablesのINPUTがdropと
等価いうことになり、特に何もしなくても比較的安全です。
わざわざiptablesにdropルールを設定する意味は無いと思います。
当然Armadillo側から開始したセッションは通るので、Armadilloでhttp(wgetするとか)、
ssh等は開始できます。
これについては、そういったアプリケーションを実行するかどうかの問題です。
もし、誰でもArmadilloにログインして自由にアプリケーションを起動して良い。
という運用であれば、iptablesでoutput側にも制約すると良いのですが
あまり、そういう運用をする装置はArmadilloでは作らないとは思います。