Entering Passive Mode

カテゴリ 'Unclassified' の記事
< 1 2 >

やっちゃった

あれだけ念入りに確認していたにも関わらず
Dropbox の lansync パケットが止まってない機械があった。
同じブロードキャストドメインのサーバーの管理者の皆様
ご迷惑をお掛けして申し訳ありませんでした。

ファイアウォールの外向きルール、強化しよう。

さくらインターネットの VPS リニューアル

さくらインターネットの VPS がリニューアルした。
価格は上がらず、メモリもディスクも増量している。
基盤がどう変わったかどうかは分からないけど
今までの実績から考えると、ありがたいニュースだ。

新規契約なら、ね。

さくらインターネットは、既存の VPS 利用者に対して乗り換え優遇施策を発表した。
http://www.sakura.ad.jp/news/sakurainfo/newsentry.php?id=628

が、結論から言うと移行期間を十分に欲しい人以外には
特にメリットがないように見えるのだが。

SSHD への攻撃を分析してみた

ここ 3 週間、SSH でどんな攻撃されているのか
ちょいとデータを取ってみた。

■攻撃パスワード TOP 5

  1. 123456
  2. changeme
  3. password
  4. 1234
  5. mixmixtalentat

言うまでもなくユーザーは root が狙われてるが
root ログイン狙いは全体の攻撃の 56% 程度。
最近は PermitRootLogin no も考慮してるのかも。

■攻撃国 TOP 5

キーボードの過酷さ

キーロガーを仕込んで 4 ヶ月。
ちょっと手元のログを分析してみた。

総物理打鍵数: 3,110,842

被害キートップ 3 は Down, Up, Right で
それぞれ 14.7%, 7.9%, 6.5%。
Down キーは 4 ヶ月で 456,642 回しばかれたらしい。

phpMyAdmin への攻撃

今日に限った話ではないが Apache HTTPD のアクセスログに
/phpMyAdmin 系の URL へのアクセスが大量に記録されている。

FTP や SCP で Web サーバーのディレクトリにアップロードし
セットアップ用のURL をブラウザで開いて初期設定を行い
インストールを完了とするタイプのシステム全てに言えることだが
ディレクトリにアップロードした「直後」が一番危ないわけだ。

phpMyAdmin 系のパスへのアクセスが未だに多いのは
今も昔も良く使われている(もしくは脆弱?)という証拠なんだろな。

ミイラ取りがミイラになりかけた

Web システムのテストをしている最中
ブラウザに自分のルーターの設定画面が突然現れて面食らった。
ルーターとは全然関係ない URL であるにも関わらず、だ。

実は、自身の管理する Web サーバーは、予期しないアクセスがあった場合
アクセス元のリモートホストに 303 でリダイレクトするように設定している。

これは、主にロボット等で不正アクセスを行う者に対する
ちょっとしたいたずらなんだが、忘れていて自分が引っかかってしまったようだ。

URL を知らなければ安全だと?

最近はコンテンツの保管 URL を複雑にすることによって 「アクセス制限」とみなすケースが増えてきた。

正規の利用者にしかその URL を知る方法がないため 他者には「事実上アクセスできない」という事なんだろう。

ユーザー名やパスワードを知られるとダメなのは、まあ当然として Web システムの仕組み上 Cookie を盗まれたらダメ セッション ID を知られたらダメってのも、ある意味仕方ないと思う。

でも、URL を知られてはダメってのはちょっとねぇ。

決意

新しい物を作るのは難しい。
探せば既にあるかもしれない。
技術だと車輪の再発明になりかねない。
それでもやるからには、強い意志を持ってやろう。

出尽くした感は常に付きまとう。
実際、大半は既存のもので代用が効いてしまう。

でも既存のものから余計なものを削ぎ落として使うより
必要なものだけを選び抜き、新しく創造するほうが良い。
汎用的なものなんていらない。そう強く思う。

ルーターの UPnP 対応状況

家庭だけでなく業務も含めると、ルーターの UPnP 対応はまだまだ進んでいないようだ。
Peer to Peer の活用を視野に入れたサービスを展開しようとしても
まだまだネットワークインフラが足枷になるね。

でも、結局中央集権型になるってのは負けたみたいで嫌だなぁ。
頑張って何か考えよう。

無限リダイレクトと Cookie

最近、無限に自分自身にリダイレクトを続ける Web サイトが多いと思ったら
Cookie を受け入れないとそうなる作りになってるようだ。

最初はそれって手抜きじゃねっと思ったけど
ログインセッション等は基本 Cookie によって維持されているわけで
認証を行うサイトでは Cookie はほぼ必須になる。
(PHP や Java の URL rewriting を使わなければね)

私は Cookie オフな人間なので多くの Web サイトが利用できないわけだ。
セッション用の Cookie とそれ以外の Cookie を分ける良い方法はないだろうか。

< 1 2 >
このページのトップへ戻る
© 2008 Project Loafer/Project Fireball and all blog writers. Powered by Nucleus CMS