hotohoto による投稿:

１当初

２そのうち、

３次に

４今は

つまり全部ダメになってしまいました

何度も言われてるとは思うのですが、この順番で「何をどうした」んでしょう?

hotohoto による投稿:

どこから手をつけたら良いでしょうか？

本来は「最初から最後まで情報を提供する」かと。

一番手っ取り早いのは apache に関するパッケージをすべて完全削除して再度インストールするとデフォルトで動くところまでは戻ることができるでしょう。
その後LAN内のみでしか扱えないようにしておきましょう。


それはサテオキ、

ついでに厳しいこと言っておきます。

私的には「やる」とか「やろう」とする意気込みがあることは全然構わないです。
ただ、今の実力のまま外部公開する形はヤメたほうが無難です。

自分で何をどう設定したか理解できないうちは、またこういう場所で情報を出せない状態のままであれば、単に世界的にクラックされる対象が一つ増えるということにしか過ぎません。
自分が設定し管理するであろうシステムによって、第三者を攻撃されて且つ責任は自分にかかる...という現実にあっても良いのであれば止めませんが...。

hotohoto による投稿:

なお、セキュリティはばっちりです＞？？？　その意味は
現在もそうですが、自分のLAN内のサーバ本機を除く、このsubnetからはアクセスできないです。
使っているのは自分だけです。
自分の他のマシンから同じLAN内からも見えない！　状態ですからセキュリティはばっちりかと。(苦笑い)
横のマシンで自分のサーバを見たいよぅ

一時的にテストのために外部から見えるようにしてみたい、普段はイントラネットからしかアクセスできないようにするつもり、
という理解でいいですか？

もし常時外部に公開しようと思っているのならば、 n_saito さんの指摘する通り、
もう少し Apache の使い方を理解してからの方がいいと思いますよ。

epii　さん　s_naitoさん　ありがとうございます。
なんとなく　おっしゃている意味がわかるような気がしています。たぶん推測のほとんどが当たっている感じがします。
ルータは接続業者のお勧め設定です。セキュリティは緩めていません。
また高級な機械ではなくRP-S300NE それほど設定項目が多くありません。
そのルータの設定はお勧めのとおり「８０番ポートを順方向のみをLAN内指定サーバに設定」しているだけです。


Local DNSについて：
また当該サーバからDDNSで設定したドメインが見えるはホスト名自己解決しているからでしょう。
ローカルなDNSとのことですが、それはたてています。
先週、必要ないのではととめてみたたら、メール配信で不具合が起きたので再開しています。


DDNSについて：
普通のグローバルIPが有る場合にはおきなかったのですが、今回おきているのはDDNSにしてからです。
このDDNSの場合のDNS設定の仕方がいまいち理解できていません。


ご指南の解決法のうち：
LAN内からドメイン解決方法として考えているのは
まずはDNS設定を変更して、
その内容変更を
「他のLAN上のPCがDNSサーバに自己ドメインを叩いた時にGIPを返す」設定から
「他のLAN上のPCがDNSサーバに自己ドメインを叩いた時にLANを返す」に変更すればよい感じがします。
これが出来ればとりあえず端末PC操作する分には便利です。
ただ見えたつもりで相手には見えていないことのチェックにはならないような感じがします。


apacheの勉強の薦め：
それからapacheの勉強とイントラオンリーというご提案ですがどうしても急いでいます。
急ぎの内容というかその目的は、
LAN外部にいる会員にファイルを自前のサーバから供給することです。
昔 relay attack で踏み台にされたの解決する様子を横で見ていました。
そのとき以来、セキュリティの大切さはわかっているつもりです。
ですからそれほど逸脱した設定をしているとは思いません。
「apacheの全てがわかってからでないと使ってはいけない」ものでしょうか？


なぜにapacheでサーバを建てる？：
ここでUBUNTUのコーナーを入りしている達人の皆さんならば
「 FTP にしたら？とかFTP・HTTPサービスとか使えば？　フリーもいろいろあるし」
となるかもしれません。しかし、
メール操作がやっとできるという人たちに対して、私のほうで「ここをクリックしてねとそのHTTPを書いておく」
というのが、私の精一杯のサービスであることと、これが彼らの操作の限界です。（高齢者が多い）
だからこちらで易しい操作で出来るように対応してあげなければならないのです。
そういった素人相手ではFTPが良くわかってもらえません、ですからHTTPにせざるを得ない。
ほとんどの会員はメールで配信している状態です。
メール添付の限界を超える大きさの場合はみな困っている。私も困っています。


ストレージサービスがあるじゃない？
フリーでストレージサービスもたくさんでてきました。
実際に使いましたが、さまざまな問題点があって結局不便でやめました。
リンク先が宣伝で隠れてしますし、会員も悩みまくって結局使えなかった。
やっぱり有料に誘導されちゃう。「このでてきた宣伝はなに？」ですよ。
もちろんストレージサービスの使い方などは私にも良くわかっています。
ところで、私の都合としては、機密書類は外部ストレージに置きたくない。
だからこの点からもLAN内がよい。LAN内には私一人のようなものです。


私のしている現状の告知の方式：
告知の文書を会員にメールで送ります。
添付に出来ない大きさを送る場合のその要件は
「私がリンク先を記入しておくことが容易」であることです。


手元のマシンをサーバにすれば？：
データの詰まっている端末をwindowsサーバにすれば、
「本当に意味でのデータがセキュリティが問題」となるのでサーバには出来ないです。
また他の重要データの入っているマシンもサーバ機能をさせない。

apacheの必要：
これは、「当該の機を新規でLAN内に置き、必要最低限のデータだけ置くというapacheサーバを設置する必要」
の意味です。
この機には最低限のデータしかないので安全。（もっていってもらいたいものだけしか無い）
これを脇に置いています。
万が一？百が一？　動作がおかしい場合、不正使用されてもすぐ止められる。
CPU500Mz程度のチープマシン。これの再利用リユースし、45Wで省エネ。
ファイル転送が早い
ディレクトリ構造を決められる
そのうちにperlでも動かそう（今はなぜか動かない）
とかのメリットがあります。


ファイル転送は：
FTPかけてファイルを隣（もちろんLAN内使用者はほぼ私だけ）のサーバにデータをおく。
チープマシンですので転送速度が遅かったけれど、
proftpd のTransfer Limmit を変えたら早くなったし、
当該サーバのＣＰＵ・ＨＤＤ負荷もほとんど問題にならなかった。
便利に使えています。
これはセキュリティの関係でLAN内のみからのアクセス許可にしています。


自分が告知分出す前：
送信前に「メールのリンク先の確認」をして送り出したい。
ところが、現在は他の端末からそのメーラー内での「リンク先の確認が不能」なので不便です。
そこで、どうしてもapacheをたてたい、となっています。

質問の理由：
今回この不便を解決したく質問をさせてもらったわけです。

hotohoto

一点書き忘れました。すみません。

> ストレージサービスがあるじゃない？
> フリーでストレージサービスもたくさんでてきました。
> 実際に使いましたが、さまざまな問題点があって結局不便でやめました。
> リンク先が宣伝で隠れてしますし、会員も悩みまくって結局使えなかった。
> やっぱり有料に誘導されちゃう。「このでてきた宣伝はなに？」ですよ。
> もちろんストレージサービスの使い方などは私にも良くわかっています。
> ところで、私の都合としては、機密書類は外部ストレージに置きたくない。
> だからこの点からもLAN内がよい。LAN内には私一人のようなものです。

http で公開すること自体、機密でもなんでもありません。
そこまで機密性を考慮するのであれば https を使用することになりますが、その点はどうなさるおつもりですか？

また、セキュリティは横から見ていて苦労がわかる、程度のものではありませんよ。
ご自分で apache を立ち上げても、クラックされたら終わりです。

ゴールとそれまでのマイルストーンをはっきりされて、一つずつ確実にこなされるのが結局一番の近道だと思いますよ。
そうして、疑問点をこのフォーラムに書き込めば、きっと皆さん良いアドバイスを下さると思います。

頑張って下さい。

　なんらかの認証をつけずに公開する以上は、「publicな」ものになります。単にサイトからリンクがないだけ　というのは、期待しないほうがよいです。その上で、正規のユーザを認証するシステムなり、経路を暗号化するなり、いろいろと必要となるかと思います。
# 経路の暗号化(https)まで必要となると、高いんですよね・・・

と考えると、有償でしっかりした外部ストレージを探したほうが、大抵は低コストかつ安全です。
# 大抵、共有するなり受け渡すための、期限付きの認証する仕組み持っています。

あとは、有償で(信頼できる会社に)構築をお願いして資料とともに引き継ぐことです。実際に設定されているサーバと設定資料から構成を把握した上で、自身でカスタマイズする　という形になるかと思います。

失敗しつつ試行錯誤できるシステムではないなら、上記のいずれかが良いのではないか　と思うところです。
(ネットワーク周りの質問で、関連する設定値やそこから考える仮定や検証(と、実測地)ではなく、わからないまま試行錯誤したのではないかというような結果が出てくるという時点で、不安があります。)
# 不正使用があったら、とめる　のは、良いとしても、早期に検出する現実的な仕組みのほうが大変かなぁ　と思うところです。外部から直接入れる範囲は意味のない(?)スキャンは結構受けますしね。

先程は大変失礼致しました　m(__)m > n_saito さん

安全に、且つ安易にファイルを公開するなら、ルーターで Port22 を開けて、PC に WinSCP を入れて SCP でもありかと。

930 による投稿:

一点書き忘れました。すみません。

> ところで、私の都合としては、機密書類は外部ストレージに置きたくない。

http で公開すること自体、機密でもなんでもありません。

これについてはおっしゃるとおりです。
ただ私が書いた本当の意味の機密書類についての説明が足りませんでした。誤解を与えました、すみません。
秘密には５種類ほどあるのですが、２種に絞って、いわゆる極秘には「これは載せないネットに接続しない」でOK
私の場合に問題となる秘密の種類は次のものです。
それは「特定の人には見せたい」かつ「公開サーバー上」というものです。
これをサーバー技術でやろうとするとメンバーの登録であるとかいろいろ作業が多くなるし、私のスキルが障壁になる。
また公開ストレージでは、全文を保存解読されます。この「公開無料ストレージというのは、載せた資料をいただくこと」
が隠された目的です。だから載せたくないのです。

では「サーバ技術を使わずに、そこそこの秘密書類を配るために、不特定のサーバーからアクセスさせる」にはどうしたらよいか？
と考えました。
そこで簡単な方法として、「端末でPDF化して暗号を掛けたファイルをアップロードする」というものです。
これならwin操作だけで済みます。
この程度で、「そこそこの機密文書は載せるけど、公開しなければならない」といった命題は解決できました。

930 による投稿:

そこまで機密性を考慮するのであれば https を使用することになりますが、その点はどうなさるおつもりですか？

途中でコピーしても口頭でのパスワードを入れなければ印刷も見ることも出来ないわけですね。

930 による投稿:

また、セキュリティは横から見ていて苦労がわかる、程度のものではありませんよ。
ご自分で apache を立ち上げても、クラックされたら終わりです。

クラックしも暗号化してある置き場なだけですからどうぞ持っていってください。
程度です。

930 による投稿:

ゴールとそれまでのマイルストーンをはっきりされて、一つずつ確実にこなされるのが結局一番の近道だと思いますよ。
そうして、疑問点をこのフォーラムに書き込めば、きっと皆さん良いアドバイスを下さると思います。

書いているつもりなんですが・・・ご理解いただければ幸いです。
これについては、実際的にさまざまな制約の中で考えねばならないと思います。
全てを書くわけにはいかず、質問の仕方も悩んでいます。

930 による投稿:

頑張って下さい。

ども！

hotohoto による投稿:

930 による投稿:

また、セキュリティは横から見ていて苦労がわかる、程度のものではありませんよ。
ご自分で apache を立ち上げても、クラックされたら終わりです。

クラックしも暗号化してある置き場なだけですからどうぞ持っていってください。
程度です。

ここだけ。
クラックされた場合、「置き場」がクラックされただけならいいんですが、その「置き場」の箱までクラックされることもある or 確率が上がるわけです。

乗っ取られた痕跡を探せなければ、発覚するまではすでに悪意を持った第三者のマシンになります。
それがrootでなくてもshellが使えるアカウントであれば、色々外部へいたずらはできるわけですが...。

ここらが私が言い続けている「DDoSの片棒をかつぐとかspam配信マシンと化すとかありえる」ということです。
このリスクと、このリスクが具現化した時の影響をどう考えるかなので、対策コストのかけかた次第でしょうね。

これだけではナンなんで、ちょっとした情報ですが、

host$ apt-cache show pdfcrack
Package: pdfcrack
(snip)
Description: PDF files password cracker
pdfcrack is a simple tool for recovering passwords from pdf-documents.
It should be able to handle all pdfs that uses the standard security handler
but the pdf-parsing routines are a bit of a quick hack so you might stumble
across some pdfs where the parser needs to be fixed to handle.
.
pdfcrack allows configure the size of the searched password, use an
external wordlist file and save cracking sessions to restore it later.

というものもあったりなかったり。
ということで、暗号化時のパスワードはわかりにくく、また長くしておきましょう。

hotohoto による投稿:

ところで、逆にお尋ねしたいのですが 930さんは、次の要求事例があるときどうしますか。
------要求事例---------------------------------------
自前サーバは無い
会員が数千人で、毎日メールで配信する。
扱うファイルサイズは毎日全体で1MB-200MBｍ
アップロードするファイル数は500個
近々にperlを使う必要がある（これはまた後でもいいですが）
これを無料のレンタルサーバに限ったら
-----------------------------------------------------

サーバー持っている人には簡単ですが、
もしないとしたらどうしますか？
yahoo ですか gmail ですか？
ちょっとお尋ねしてみたくおもいます

結論から言ってしまうと、Case by Case ですので、一概に「こうします」とは言い難いですね。
このような場合、以下のような要件を考慮して方針を決定し、サーバー・Network の設計をします。

1. 予算はどの位あるか？

2. そのサービスへのアクセスの負荷はどの位あるか？
# サーバーのサイジング、回線の太さ等をここで決定します。
# hotohoto さんの場合、数千人に対して、最大 200MB のファイルを HTTP で配信する事になり、またそのトリガーが
# hotohoto さんからのメール配信になりますから、メール配信直後は瞬間的な同時アクセス数がかなりの数字になると
# 思われます。

3. サービスの重要度は？
# 費用対効果の側面も考慮する必要があります。
# また、そのサービスが障害時等でのサービス断がどの程度許されるのか、それは Working Time のみなのか、
# 休日・夜間もそのサービスの継続を約束する必要があるのか、も考慮します。

4. 自分達 (運用する人達) がどの程度スキルがあるか？
# サービスは開始してしまえば終わりではなく、運用し続けることも重要です。
# OS、ミドルウェア (apache等)、ネットワーク、セキュリティと、運用にはそれぞれのスペシャリストである必要はありませんが
# 幅広いスキルが要求されます。
# 日々のログチェック、機器・回線の状態のモニター、問題が発生した場合の対応、またそれに備えての対応手段の明確化
# と実行等等うんざりするほど項目はあります。(但し、その深さはサービスの重要度によって決定されます。)

と、大きなものだけをあげてもこの位あります。

そこで、hotohoto さんからのご質問の答えですが、以下のようになります。

Case-1 資金が潤沢で、サービス断もある程度許され、休日・夜間はサービスしない (でも OK) で、自分達にスキルがあまり無い。
サーバーを購入し、ベンダーにお願いして構築してもらい、回線も太くする。
  - 最大 200MB x 500 ファイルとのことですので、データだけで 100GB 必要です。
    それ以外にも、世代でファイルを残すのであればその分 DISK を積む必要があります。
  - また、同時アクセスも、メール配信直後は 1,000 アクセス程度が予想されますから、メモリーも 4GB 以上は最低必要でしょう。
    (apache での同時アクセスを 1000 としての感覚的な数字で計算はしていませんが...)
  - 回線は、ある程度の遅延は許されるのであれば Bフレッツ。

Case-2 資金が潤沢で、サービス断は許されず、休日・夜間のサービス提供も約束する必要があり、自分達にスキルがあまり無い。
サーバーを購入し、ベンダーにお願いして構築してもらい、サーバーはデータセンター (コロケーション) で運用する。
回線は、データセンターの BackBone に LAN 渡しで直結する。
監視・運用はデータセンター、若しくは MSP と契約し委託する。

Case-3 資金があまりなく、サービス断もある程度許され、休日・夜間はサービスしない (でも OK) で、自分達にスキルがあまり無い。
Uploader サービスを活用する。
   - これだけのデータ量であれば、Haousing もきついので、結局専用サーバーになると思います。
     であれば、資金もないので Uploader でその落とし方のマニュアルを作成したりの創意工夫でなんとかする。

Case-4 資金があまりなく、サービス断は許されず、休日・夜間のサービス提供も約束する必要があり、自分達にスキルがあまり無い。
この場合は最低の条件です。このままでは打つ手なし、と言えます。

Case-3、4 の場合は、これ以外にも、複数の安価なサーバーレンタルを利用して、データを振り分けてサーバー辺りの負荷をうまく
分散して乗り切る、という手もあります。

以上、hotohoto さんのおかれていらっしゃる状況が分らない中での一般論ですので、その状況に起因する認識のズレ等はご容赦
下さい。
その上で、実際にサービスを構築する際には、もっと考慮点があります。
また、こればあくまで私自身が今までこのような仕事に携わってきて、その上での考え方ですので、異論はたくさんあると思いますので、
考え方の一つの例、参考程度にお聞き下さい。


＞ 皆さん
hotohoto さんからご質問がありましたので、なにかお悩みになられている事の解決のきっかけにでもなればと思い、当書き込みを
致しました。
但し、スレットの内容・フォーラムの趣旨からは逸脱している内容かと思います。
どうかご容赦下さい。

＞ モデレータ様
当書き込みの内容が不適切である、と判断された場合は、通告なしで削除して頂いて結構です。
お手数をお掛けして大変申し訳ございませんが、何卒よろしくお願い致します。