いまどきは、あからさまに ssh のポートにちょっかいを出して
いるのは、大バカ者か bot しか居ないはずですから、期待した
程の効果は無いのではないかと。
# スキャンを仕掛けてきた奴がどれくらい bot (a.k.a. 踏み台)
# なのかということを検証するためには有効かもしれませんが :P
On 2008/07/09, at 22:06, kouya wrote:
> で此処で、挑発的行為ですが pipe 7 に入り 218.44.161.150:22 に挑戦された方
> に nmap の贈り物が出来ないか考えています。
--
% finger
[メールアドレス保護]
L
もう少し問題の切り分けと、それに関連した情報がないと、
原因を特定するのは正直難しいわけですが…
telnet(1) のような「枯れている」はずのプログラムが
core 吐いて死ぬ
ということですと，ハードウェア的に何か障害が起きている
可能性があるかも知れません。
私自身の限られた経験では、HDD のコネクタに発生した接触
不良が原因で、起動しようとしたプログラムが軒並み core
吐いて即死するという障害に遭遇したことはあります。
カーネルパニックが発生するような明白な接触不良ではなく、
微妙に起動したプログラムだけがお亡くなりになるという
ことで、原因を特定するのに結構手
太田＠自己フォロー
# 某所で識者の方に指摘をいただいたので、追補
On 2008/04/17, at 17:17, 太田 敏文 wrote:
> 太田＠アリス です
>
> On 2008/04/17, at 16:52, Takahiro Kambe wrote:
>
>>> n-kogane> もったいないので、私が譲り受けようと考えているのですが、データ消去フログラ
>>> n-kogane> ムは、手もとにありません。
>> 引き続き使用を継続する場合も、そこまで行う必要があるのでしょうか?
太田＠アリス です
On 2008/04/17, at 16:52, Takahiro Kambe wrote:
>> n-kogane> もったいないので、私が譲り受けようと考えているのですが、データ消去フログラ
>> n-kogane> ムは、手もとにありません。
> 引き続き使用を継続する場合も、そこまで行う必要があるのでしょうか?
>
> 1度全セクタ書き込みをしてしまえば、少なくともオペレーティング・システ
> ムというか、IDEなりのインターフェイスからデータを読もうとしている限り
> は消されたデータを読み出すのは難しそうの思えますが、如何でしょう?
技術的にそう主張する
太田＠アリス です
# かなり昔にも一度話題になったと思いますが :)
結論から言いますと newfs だけでは不充分です。
記録されていたデータを完全に破壊するためには、ハードディスク
の全セクタに対して最低でも数回以上、ランダムなデータを上書き
する必要があるからです。
また、中古の HDD の場合、未使用で顕在化していない不良セクタ
を検出して代替セクタへの切り替えを促しておく（いまどきは、HDD
上のコントロールボードが、そこらへんをよしなにやってくれます）
という意味でも、こうしたデータの上書きは有効です。
ports/security にそう云うツールがあったはずです。
太田 ともうします
On 2007/12/20, at 21:11,
[メールアドレス保護]
wrote:
> *> ありません。
> *> /usr/src/usr.sbin/pw/pw_user.cの次の行を見る限り、
> *> プログラムによって長さが8〜15文字にされているようです。
>
> やはり、そうですか
>
> 15文字(最大長)のランダムパスワードは、初期パスワードだと
> わかっていても、それを割り当てられたユーザにとっては、か
> なり抵抗感があるようです。
>
> でも、そういうもの(初回のみ)と割り切ってもらうしかないで
> すね。
いや。『
