アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
部門名の意味がわからないのですが (スコア:0)
おそらく、outboud は outbound だとして、
ISPにどういうことを求めているのでしょうか。
ISPにとっての末端=ユーザのPC、だと思いますが、
そこでどういうフィルタをすればDoSが防げるのでしょうか。
緩いフィルタでは無意味に終わるし、厳しくしたら、恐らくは
弊害の方が多いフィルタになると思います。
Re:部門名の意味がわからないのですが (スコア:1, すばらしい洞察)
アドレスブロックに該当しないアドレスがソースとなっている
パケットをdenyするACLをインターフェイスのout側に張れって
ことだと思いますが。
Re:部門名の意味がわからないのですが (スコア:0)
Re:部門名の意味がわからないのですが (スコア:1)
という事は分かりますよね?
どこにフィルタを掛けるかで変わっては来るが。
FFのIP偽装しててもISPとの協力で…というのはそういう事でしょうけど。
Re:部門名の意味がわからないのですが (スコア:2, 興味深い)
受信側じゃなくって、IPアドレスを偽装したパケットを送信した側の末端でブロックしろ、という話ですね。
ちなみに、私の実体験ですが、OCN の場合、そういう制御がされてます。
昔、OCN エコノミー からフレッツADSLに移行しようとした時、
デフォルトルータを OCN エコノミー側にしてしまい、
フレッツADSL側に繋いだプロバイダの方で割り当てられたIPアドレスをsrcにしたパケットも
OCNエコノミー側から送り出されるようになってしまったのですが、
その場合、見事にブロックされてパケットはまったく相手に届かなくなりました。
ちなみに、その後、ADSL側をOCN ADSLアクセスにした所、そこで貰ったIPアドレスだと、OCN エコノミー側からも普通に出て行きました。
ですので、個々の契約レベルでの割り当てIPアドレスでのチェックではなく、
自社割り当てのものかどうか、レベルのおおざっぱなチェックのようです。
そのため、OCN は一応の対策はされていますが、
OCNから発信する場合、OCN管轄のIPアドレス群を使えば、
偽装パケットの発信は可能だと思います。
(もっとも、これは5年ほど前の話ですので、今はもうちょっと厳しいチェックになってるかもしれません)
Re:部門名の意味がわからないのですが (スコア:1, 参考になる)
>という事は分かりますよね?
uRPF [google.com]という一見便利な技術があるのですが、それほど広く使われていないのが現状です
実際、正しく運用するのはそれなりに難しい上に、実装自体にバグがあったりして、難儀なんですが
# せめてlooseでいいから入れて欲しい
Re:部門名の意味がわからないのですが (スコア:0)
というか、Spoofingされてるのに、どのISPから来たかって調べられるものなの?
判ったとしても、その費用を誰が持つかとか、もめそうだな~