過去ログ
100.んー(2) |
|
| 投稿者: | ぴゅあ - 2003年06月10日 22時20分55秒 |
| 続く説明で解るとは思うけど もう少し詳しく > 挙げられているのも901に対して拒否しておいてeth1に対しては許可するとか ポート901に対する拒否だけを記述 インターフェイスを書かないのでeth0,eth1或いはeth2とか増えても全てのインターフェイスを拒否 > 実際にはeth0からの接続要求は全て拒否するで631の方も要らなくなりますよね eth0からの接続要求については全て拒否するルールを書いたとしての意 ポートに関係なくWAN側(正確にはやはりeth0なんだが(WANではなくそこはLANでしょ))からの接続要求を拒否するので901だけでなく631も同時に拒否されるということ コメント>> |
|
99.んー |
|
| 投稿者: | ぴゅあ - 2003年06月10日 22時12分28秒 |
| > 端末からだとcanaserverだったかがあればいいんでしょうか 端末からだとcannaサーバーも要らないです(筈) Winで言えばMS-IMEなりATOKなりに相当する部分ですから それは端末側が行いその結果としてその文字(文字コードデータ)のみが届きます でもってkonを使っているときと使っていないときでカーソル↑↓キー(bashのhistory機能)で出てくるものが違いますよね 確認はしていないけどだけどkon上であるかそうでないかでaliasの内容が違ってないかな？というのと端末上では使えないという意味を含んでたりします > 直接WANにつながっているPCでSWATとか起動すると・・・ 漏れるってのはないんだと思いますけど サーバーですからクライアントからの要求を待っていて互いに繋がっている間は「その間の経路を」パケットが流れますよね その「中間に」そのパケットを覗こうとするものが居れば漏れるってことになりますけど 要求もなくパスワードとかばら撒くというサーバーは正当なサーバーには居ないでしょう(居たら設定だけでもすんごく骨が折れてしまいます) 最低のサーバーは個々にどのネットワーク或いはどのクライアントからの接続要求を受け付けるか或いは拒否するか等を設定できるようになっているものです(それは書いてあるフィルタに相当するものでもある) その許可・拒否も何処でやるのか(NetFilterか各サーバー等か)ってのも考え方で色々ですけどひとつの考え方としては(特にNetFilterの大組み直しをして更に思ったけど) １．サーバーでできることはサーバーでやった方がいい ひとつに個々のサーバーの範囲内で考えられるので判り易い またどのポートが使われるかとかどういう風に通信しているのか等をいちいち細かく調べる必要がない それで足りないってことになればNetFilter等の助けを借りることになるんだと思うけど(当然NetFilterでは成りすましとか細かく対処し切れない部分は処理されているとして・・・サーバー個々ではなく共通処理として処理することになるだろうし) ２．なんでもNetFilterに頼るようにはしない ある意味一元管理という意味で全てのパケット管理をNetFilterに委ねるというのもひとつの考え方でしょう しかし前項のように全ての設定がiptablesなりに集まってくるので(前にも出てきた)「どの順番で書くか」とか設定のための余計な要素も増えてくる これは設定に手間が増えるということだけでなく 全てNetFilter任せにするとやるべき個所は１箇所なので楽そうだけどルールを書いたら書いただけNetFilterのお仕事は増えてきます 先のポート901に対するルールも実際にポート901に対するパケットが来たとき初めて必要となるもので毎回マッチングしてみる必要はないわけで関係ないパケットに対しての余計な処理が入れば入るほど重くなると言っていいでしょう 例えばこれをサーバー側でやらせるようにすれば本当に必要になったときだけチェックされるのでネットワークのトラフィックもかなり改善されることでしょう 逆にあっち(NetFilter等)でやったから大丈夫とか思ったりして各サーバーに必要な設定を見逃してないかということにもなるのかも知れない またNetFilterも(設定者のポリシーによって様々ではあるけど)全てを拒否して許可したいものを許可するというのが簡単というか判り易いんでしょう 挙げられているのも901に対して拒否しておいてeth1に対しては許可するとか 実際にはeth0からの接続要求は全て拒否するで631の方も要らなくなりますよね (そのとき例えばhttpサーバーを出したいというときにはポート80なりを許可すると追加する) (デフォルトポリシーがこれだと見えないけど901,631は拒否してるけど他はどうっている？というのもありますけど) なおINPUT,OUTPUT共にデフォルトポリシーをDROPにしておいてeth1からの901,631にある個々のINPUTのDROPの代わりにeth0からのINPUTをACCEPTすると書けばOUTPUT側はeth0に対してこの前出てきたESTABLISHED１個で済む(901,631共に１つで適用される)つまり３つのルールで済むということ(更にはeth0に関するこの辺のルールは他に書いていたりすると全体的にはかなり減る筈) この辺はある意味ロジック回路(エレクトロニクス)のロジック設計(最適化)に似たようなところはあるけど(いやぁコンピュータってロジック回路で動いているよな(違うか(照)))シンプルになればなるほど(怪しいテクを使っている場合は除いて)大抵人にもマシンにもシンプルで判りやすいものになるものです それは熟練とか経験の積み重ねの末とか或いは後回し感とかで別の話とか思うかも知れないけどちゃんとやってるとつまらんミスとか軽減・発見し易くなるもんです(というか元々お呼びでないお方をお断りしたいからやりたいと思っている筈なわけでミスに気付いたときには嬉しくない状況だったなんていうのでは悲しいでしょう) コメント>> |
|
98.RE: ん？ |
|
| 投稿者: | Pyzar - 2003年06月10日 14時51分50秒 |
| > クライアント(端末)からだとkon(kon2)自身不要では？ > konはマシン自身(コンソール)で漢字表示で使いたいときに起動します 端末からだとcanaserverだったかがあればいいんでしょうか でも、コンソールで使うこともまれにあるので… > 因みに > 端末からの操作はコンソールより楽だったりしますが 楽ですね…なんでもコピペできるし… > 端末からsuでrootになって作業するのは控えた方がいいそうな > 最近知ったのだけど(照) > それはインターネット上で各種ログイン(ブラウザでログインとかメールとか)しているような場合と同じように > 盗聴(て言い方ではないよな(照))の危機に晒されるから > ということ > 尤も会社とかの多数のユーザーがネットワーク上に居るような場合であって > 個人レベルでの自分しか居ないようなネットワークでは関係ないけど > まぁ 知ってて損はしないことです 要はなんでも漏れるって事ですよねえ。 ぴゅあさんに教えてもらったのかどうか覚えがないですが、直接WANにつながっているPCでSWATとか起動すると パスワードやらなんやらがいっぱい漏れるそうで…cupsもブラウザで設定していると漏れるんでしょうか… で、一応意味あるかないかわからないけれど…iptablesで # DROP for samba config(=swat) iptables -A INPUT -p tcp --dport 901 -i eth0 -j DROP iptables -A OUTPUT -p tcp --sport 901 -o eth0 -j DROP # DROP for cups config iptables -A INPUT -p tcp --dport 631 -i eth0 -j DROP iptables -A OUTPUT -p tcp --sport 631 -o eth0 -j DROP としてるんですが… > ISDNもそうだしADSLもそうだけど(Bフレッツは判らないけど)番号の統一はプロバイダにとってはアクセスポイントの全国展開とかし易い(電話回線提供会社，プロバイダ双方にメリットのある)魅力的なものだけど > これってプロバイダのサーバーに入る前にまず電話回線の提供会社のサーバーへ行くのね ってADSLはNTTの回線だけじゃなくNTTのサーバーも通っているって事ですか？ ブラウジングしている最中にDelegateがプロバイダのDNSサーバー以外のポート53と話をしたがるので気になるけれど… これは、関係ないですね(自爆) コメント>> |
|
97.pop before smtpって？？ |
|
| 投稿者: | Pyzar - 2003年06月10日 13時58分58秒 |
| わからない… しまっておくつもりだったけれど気になります。 pop before smtpって たとえばプロバイダDの回線を使用せずにプロバイダDのsmtpサーバーを使用して メーラーでメールを送信する時に、一度popで認証をする。 そうすると、そのサーバーは一時的にpopで認証してきたプロバイダAの回線のIPアドレスを使うユーザーをユーザーとして認める。 で、一時的にそのIPアドレスからプロバイダDのsmtpサーバーを利用してメールを送信する事が可能になる。 ですよね！？ わたしがプロバイダAの回線でDelegateのsmtpサーバーを起動する。 メーラーのsmtpサーバーはDelegateのsmtpサーバーが起動するPCのIPアドレス・ポートを指定。 メーラーのユーザー名はプロバイダAのユーザー名@プロバイダAのpopサーバー、 そしてパスワードは、プロバイダAのpop認証用パスワード〜これは実在するpopサーバーであって、ユーザーが実在しており、パスワードと合致すればどんな設定でも可能… で、メールをdelegateのsmtpサーバーを利用して送信。 この時、なぜ４つのメールアドレスのうち１つのメールアドレスだけそのsmtpサーバーに拒否される時があるのか プロバイダAのメールアドレスにしか送信できないならわかります。 けれど、プロバイダB・プロバイダCのメールアドレスにも問題なく送信できる。 プロバイダDのメールアドレスにだけ送信できる時と送信できない時がある。 プロバイダB・C・Dともプロバイダのsmtpサーバーを利用してメールを送信する時は 現状プロバイダAの回線を使用しているから、pop before smtpの設定を使います。 メーラーでプロバイダDのpop認証を実施すれば、プロバイダDのメールアドレスにメールが送信出来るとは限らない。 どんな因果関係なんだろうか… コメント>> |
|
96.ん？ |
|
| 投稿者: | ぴゅあ - 2003年06月10日 12時35分45秒 |
| > sshでクライアントからしか見てないです。 クライアント(端末)からだとkon(kon2)自身不要では？ konはマシン自身(コンソール)で漢字表示で使いたいときに起動します でもってrmのオプションでさえコンソールか端末かで挙動が違うらしいです (挙動が違う理由：端末の方がセキュリティが甘くなるから(だろう)) 因みに 端末からの操作はコンソールより楽だったりしますが 端末からsuでrootになって作業するのは控えた方がいいそうな 最近知ったのだけど(照) それはインターネット上で各種ログイン(ブラウザでログインとかメールとか)しているような場合と同じように 盗聴(て言い方ではないよな(照))の危機に晒されるから ということ 尤も会社とかの多数のユーザーがネットワーク上に居るような場合であって 個人レベルでの自分しか居ないようなネットワークでは関係ないけど まぁ 知ってて損はしないことです そういや ISDNが流行ってた頃の一時期以降までは大抵直接プロバイダにダイヤルして接続してましたよね((たぶんNTT側からのの筈な)番号が統一される前まで) このときってプロバイダのサーバー(PPP)へは直に接続されていた筈でしょう ので(音声とかの盗聴とかと同じように)IDとかパスワードとか外部からの何らかの特別なこととかなければ安全ではあった筈(ある程度は) 直に繋がっているとはいえ同じ加入者はネットワーク内に一緒にいるけど 多くの場合「中継されることなく直に繋がるということ」(尤も接続プロバイダ外のメールプロバイダに対して送受信とかはインターネット上の普通のログインと同じだけど) ISDNもそうだしADSLもそうだけど(Bフレッツは判らないけど)番号の統一はプロバイダにとってはアクセスポイントの全国展開とかし易い(電話回線提供会社，プロバイダ双方にメリットのある)魅力的なものだけど これってプロバイダのサーバーに入る前にまず電話回線の提供会社のサーバーへ行くのね でもって(特に全国展開とか可能にするためには)実際にプロバイダのサーバーへ到達するまではいくつかのサーバーを経由している可能性が高いと思われたり(それは普通にインターネットだったりするのだろう？) まぁそこはちゃんと考えてて(電話回線提供会社までは暗号化する設定が不可になっていても対プロバイダまでは暗号化されているとか)だいしょぶなんだろうと思うけど(「だろう＝やってる筈だ」と殆どの場合そうとらえられるのが日本の悪い風潮だ・・・と思ったりするが) と ふと思ったりしたけど てのはうちの信頼できるプロバイダになんかのときにちらっと聞いてみよかなとか思ってたり コメント>> |
|
95.やっぱり… |
|
| 投稿者: | Pyzar - 2003年06月10日 9時52分25秒 |
| [root@localhost root]# alias alias cp='cp -i' alias l.='ls -d .* --color=tty' alias ll='ls -l --color=tty' alias ls='ls --color=tty' alias mv='mv -i' alias rm='rm -i' alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-ti lde' コメント>> |
|
94.rmについて |
|
| 投稿者: | Pyzar - 2003年06月10日 9時05分11秒 |
| ＞ぴゅあさん レスありがとうございます > kon2の環境で試しました？ > たぶんそっちでも同じように見られるんだと思うけど sshでクライアントからしか見てないです。 でも、rmコマンドの挙動はどう見ても"rm"="rm -i"です 絶対必ず確認が入ります (・＿・)．．．．．．ン？ スーパーユーザーで"alias"かな！？…もう一度確認！！ 昨日、自分のiptablesの設定をもう一度見ていたのですが identの設定がおかしい… たぶんWin98SEでDelegateを起動した時のWin98SEのFireWallの設定を移植しただけなのだろうけど… どうして、こっちのポート113を開けてるの？？…要確認 コメント>> |
|
93.どうも |
|
| 投稿者: | ぴゅあ - 2003年06月09日 19時50分23秒 |
| DMZができてから(なのか？)外部との通信が遮断されることが多くなったような？ 元々外部の問題なのか内部でループができてしまっていたりするのか(そういうログはまだ発見していないが・・・) > 扶養者控除もなくなるし、消費税も上がるらしいし… とかはまだまだぁ 会社立て直しだと言っている筈なのに当人たちが全く他人事ののような気で居るし 加えて会社中を遊び場にして社内プライバシーまで破壊しまくっているのまで居てぐしゃぐしゃだし そんな会社でしかも外部の人間が仕事するってのはとんでもなく大変なことです (て社員も大変な筈だが気にはならないらしい・・・) まぁ公的な点としてはサラリーマンとかと違って元々何の保証もないし 金がないから払えないとかなったところで保証・援助されることもなく 対会社として自力で対処するしかないので・・・・なのだが kon2の環境で試しました？ たぶんそっちでも同じように見られるんだと思うけど -iもfも指定されてないときはどうなるかってのは削除対象にもよるのでそれはmanを整理してみて 少なくとも書き込み不可でない単一ファイルは何も聞いてこないで削除された筈 それは怖いので-iなり付けとくのが吉なのかも aliasの設定の仕方はman bashだったかな？ bashのmanは非常にデカイのでテキストファイルにでもして(後でも読めるようにもして)じっくり見てみるのがいいでしょう コメント>> |
|
92.RE: 仕事休み(さぼり)ちぅ |
|
| 投稿者: | Pyzar - 2003年06月09日 16時49分29秒 |
| ＞ぴゅあさん レスありがとうございます。 > てか仕事やれる状況(環境)ではないし > ちぅかまぁ色々と事務仕事も含めてやることがあるのではあるが > まぢでやばいよ取引先(経営が) > で行く先検討ちぅ だが どこも厳しいですよね… 扶養者控除もなくなるし、消費税も上がるらしいし… > > 送れた 送れない なんだかタイミングですね！？ 続けて3通ぐらい送信できる時もあるようになってきた… 設定変えてるのかなあ… 設定変えてから、メールの返事が来たりして… これは、どこかにしまっておきましょう > rm → rm -iとする > つまりrm -rはrm -i -rとなる(ひとつひとつ聞いてくる) > -iと-fは似ているが若干動作が違う > aliasと打てば現在設定されているエイリアスのリストが出てくるでしょう わたしの環境ではこうでした alias l.='ls -d .* --color=tty' alias ll='ls -l --color=tty' alias ls='ls --color=tty' alias which='alias | /usr/bin/which --tty-only --read-alias --show-dot --show-ti lde rmにiオプションはついてないですよね？？ コメント>> |
|
91.仕事休み(さぼり)ちぅ |
|
| 投稿者: | ぴゅあ - 2003年06月09日 13時36分00秒 |
| てか仕事やれる状況(環境)ではないし ちぅかまぁ色々と事務仕事も含めてやることがあるのではあるが まぢでやばいよ取引先(経営が) で行く先検討ちぅ だが > 送れた 送れない POP after SMTP認証ってのは メールを送信する前に受信操作をすることで送信者を信頼させる方法 メール受信のときにはアカウント・パスワードでPOPサーバーにログインして読み出しをやってるでしょ で受信操作をやることによって「あちしはそのサーバーの正式ユーザーよ」ということを知らせてから送信するという仕組み その間受信から送信の間にプロバイダと繋がった状態だと受信操作した人だと判っているのでそのまま送信できる が規定時間内に送信をやらないと認証してたのを取りやめるので再び受信操作をしないと送信を受け付けなくなる 直にPPP接続しているプロバイダのサーバーなら(ダイヤルアップ接続しているプロバイダ)回線を切断するまでは同一人物であるということなので認証後の保持時間は長かったりするんだろうけど他のプロバイダ(ISP)に接続している場合には(×××プロバイダ(freecomとは別の)にダイヤルアップ接続してfreecomのメールサーバーに繋ごうとしている場合とか)受信操作と送信操作の間(実は別々に行われるのではなく一連の塊として行う)が切れてしまう(間隔が開いてしまうと考えればいい)と拒否されることもあるだろう これはDelegateのSMTPサーバー云々というより普通にメーラーでも手動で受信操作を終えその後送信操作をしたという場合には送信拒否という形になるのかもですね 送れたときってのはメーラーで定期受信してるとかでたまたま認証された直後だったりしたってことはないのかな？ まぁ 普通にやるのが一番だて 普通にやるにもどう設定するか等調べることは山ほどあるだろうから > ちょっとめんどくさいので > # rm -r -f delegate8.5.4 > で、回避！？ rm -rf delegate8.5.4 と素直にやる rm --helpなりman rmなりですぐ解る筈 なんでできていたのかはエイリアスに設定されて「いなかったり」したのかな rm → rm -iとする つまりrm -rはrm -i -rとなる(ひとつひとつ聞いてくる) -iと-fは似ているが若干動作が違う aliasと打てば現在設定されているエイリアスのリストが出てくるでしょう 因みにls -lと打つ代わりにllと打てば同じ動作をしてくれたりする(環境によって或いは独自に設定していたりするので全てで同じとはならないので注意＠どう設定されているか/するかはユーザーの自由なのでそれぞれ違う) コメント>> |
|