« March 2004 | Main | May 2004 »

Entries posted within April 2004

[IT]  Looking Glass

http://wwws.sun.com/software/looking_glass/demo.html
Sunが最近発表した統合デスクトップ環境Java Desktop Systemの今後の目玉となる機能の一つ。
2次元でなく3次元のデスクトップでSF映画みたいに画面を自在に操れるのは面白そう。

Author yasu : April 26, 2004 11:02 PM | Comment (3) | Trackback (0)

[business]  最後の給料

会社に着いたら給与明細発見。
開けてみたら、、、控除額10万・・・
一番額面が大きいのが所得税と月末退職者社会保険料とやら。

月末退職者社会保険料は先月分と退職月の2か月分をまとめて払うから。ということらしい。
それにしても10万はひどい。

Author yasu : April 23, 2004 1:52 PM | Comment (0) | Trackback (0)

[IT]  TCP欠陥

昨日の夜にUS-CERTからTCPそのものに対して脆弱性アラート。
そのうち、(一時的に)Internetにつながらない地域、ISPが出てくるかもしれない。
ネットワークエンジニアの人たち、、しばらく大変そうだ。

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Technical Cyber Security Alert TA04-111A archive

Vulnerabilities in TCP

Original release date: April 20, 2004
Last revised: --
Source: US-CERT

Systems Affected

* Systems that rely on persistent TCP connections, for example
routers supporting BGP

Overview

Most implementations of the Border Gateway Protocol (BGP) rely on the
Transmission Control Protocol (TCP) to maintain persistent
unauthenticated network sessions. There is a vulnerability in TCP
which allows remote attackers to terminate network sessions. Sustained
exploitation of this vulnerability could lead to a denial of service
condition; in the case of BGP systems, portions of the Internet
community may be affected. Routing operations would recover quickly
after such attacks ended.

I. Description

In 2001, the CERT Coordination Center released CA-2001-09, describing
statistical weaknesses in various TCP/IP Initial Sequence generators.
In that document (),
it was noted by Tim Newsham:

[I]f a sequence number within the receive window is known, an
attacker can inject data into the session stream or terminate the
connection. If the ISN value is known and the number of bytes sent
already sent is known, an attacker can send a simple packet to
inject data or kill the session. If these values are not known
exactly, but an attacker can guess a suitable range of values, he
can send out a number of packets with different sequence numbers in
the range until one is accepted. The attacker need not send a
packet for every sequence number, but can send packets with
sequence numbers a window-size apart. If the appropriate range of
sequence numbers is covered, one of these packets will be accepted.
The total number of packets that needs to be sent is then given by
the range to be covered divided by the fraction of the window size
that is used as an increment.

Paul Watson has performed the statistical analysis of this attack
when the ISN is not known and has pointed out that such an attack
could be viable when specifically taking into account the TCP
Window size. He has also created a proof-of-concept tool
demonstrating the practicality of the attack. The National
Infrastructure Security Co-Ordination Centre (NISCC) has published
an advisory summarizing Paul Watson's analysis in "NISCC
Vulnerability Advisory 236929," available at
.

Since TCP is an insecure protocol, it is possible to inject
transport-layer packets into sessions between hosts given the right
preconditions. The TCP/IP Initial Sequence Number vulnerability
(http://www.kb.cert.org/vuls/id/498440) referenced in CA-2001-09 is
one example of how an attacker could inject TCP packets into a
session. If an attacker were to send a Reset (RST) packet for
example, they would cause the TCP session between two endpoints to
terminate without any further communication.

The Border Gateway Protocol (BGP) is used to exchange routing
information for the Internet and is primarily used by Internet
Service Providers (ISPs). For detailed information about BGP and
some tips for securing it, please see Cisco System's documentation
(
or Team Cymru (). A vulnerable situation
arises due to the fact that BGP relies on long-lived persistent TCP
sessions with larger window sizes to function. When a BGP session
is disrupted, the BGP application restarts and attempts to
re-establish a connection to its peers. This may result in a brief
loss of service until the fresh routing tables are created.

In a TCP session, the endpoints can negotiate a TCP Window size. When
this is taken into account, instead of attempting to send a spoofed
packet with all potential sequence numbers, the attacker would only
need to calculate an valid sequence number that falls within the next
expected ISN plus or minus half the window size. Therefore, the larger
the TCP Window size, the the larger the range of sequence numbers that
will be accepted in the TCP stream. According to Paul Watson's report,
with a typical xDSL data connection (80 Kbps, upstream) capable of
sending of 250 packets per second (pps) to a session with a TCP Window
size of 65,535 bytes, it would be possible to inject a TCP packet
approximately every 5 minutes. It would take approximately 15 seconds
with a T-1 (1.544 Mbps) connection. These numbers are significant when
large numbers of compromised machines (often called "botnets" or
"zombies") can be used to generate large amounts of packets that can
be directed at a particular host.

To protect against such injections, RFC 2385 provides a method of
using MD5 signatures on the TCP Headers. If this form of verification
is supported and enabled between two peers, then an attacker would
have to obtain the key used to transmit the packet in order to
successfully inject a packet into the TCP session. Another alternative
would be to tunnel BGP over IPSec. Again, this would provide a form of
authentication between the BGP peers and the data that they transmit.
The lack of authentication when using TCP for BGP makes this type of
attack more viable.

US-CERT is tracking this issue as VU#415294. This reference number
corresponds to CVE candidate CAN-2004-0230. NISCC is tracking this
issue as Advisory 236929.

II. Impact

Sustained exploitation of the TCP injection vulnerability with regard
to the BGP vulnerability could lead to a denial-of-service condition
that could affect a large segment of the Internet community. Normal
operations would most likely resume shortly after the attack stopped.

Since the TCP/IP Initial Sequence Number vulnerability (VU#498440) has
been proven more viable of an attack, any services or sites that rely
on persistent TCP sessions could also be affected by this
vulnerability. Impacts could range from data corruption or session
hijacking to a denial-of-service condition.

III. Solution

Apply a patch from your vendor

Please see you vendor's statement regarding the availability of
patches, updates and mitigation strategies.

Workaround

Deploy and Use Cryptographically Secure Protocols

TCP initial sequence numbers were not designed to provide proof
against TCP connection attacks. The lack of cryptographically-strong
security options for the TCP header itself is a deficiency that
technologies like IPSec try to address. It must be noted that in the
final analysis that if an attacker has the ability to see unencrypted
TCP traffic generated from a site, that site is vulnerable to various
TCP attacks - not just those mentioned here. A stronger measure that
would aid in protecting against such TCP attacks is end-to-end
cryptographic solutions like those outlined in various IPSec
documents.

The key idea with an end-to-end cryptographic solution is that there
is some secure verification that a given packet belongs in a
particular stream. However, the communications layer at which this
cryptography is implemented will determine its effectiveness in
repelling ISN based attacks. Solutions that operate above the
Transport Layer (OSI Layer 4), such as SSL/TLS and SSH1/SSH2, only
prevent arbitrary packets from being inserted into a session. They are
unable to prevent a connection reset (denial of service) since the
connection handling will be done by a lower level protocol (i.e.,
TCP). On the other hand, Network Layer (OSI Layer 3) cryptographic
solutions such as IPSec prevent both arbitrary packets entering a
transport-layer stream and connection resets because connection
management is directly integrated into the secure Network Layer
security model.

The solutions presented above have the desirable attribute of not
requiring any changes to the TCP protocol or implementations to be
made. Some sites may want to investigate hardening the TCP transport
layer itself. RFC2385 ("Protection of BGP Sessions via the TCP MD5
Signature Option") and other technologies provide options for adding
cryptographic protection within the TCP header at the cost of some
potential denial of service, interoperability, and performance issues.

Ingress filtering

Ingress filtering manages the flow of traffic as it enters a network
under your administrative control. You can configure your BGP routers
to only accept packets on a specific network connection. Servers are
typically the only machines that need to accept inbound connections
from the public Internet. In the network usage policy of many sites,
there are few reasons for external hosts to initiate inbound
connections to machines that provide no public services. Thus, ingress
filtering should be performed at the border to prohibit externally
initiated inbound connections to non-authorized services. In this
fashion, the effectiveness of many intruder scanning techniques can be
dramatically reduced.

Network Isolation

Complex networks can benefit by separating data channels and control
channels, such as BGP, into different logical or physical networks.
Technologies such as VLANs, VPNs, leased links, NAT may all be able to
contribute to separating the tranmission of control information from
the transmission of the data stream.

Egress filtering

Egress filtering manages the flow of traffic as it leaves a network
under your administrative control. There is typically limited need for
machines providing public services to initiate outbound connections to
the Internet.

In the case of BGP, only your BGP routers should be establishing
connections to your peers. Other BGP traffic generated on your network
could be a sign of an attempted attack.

Appendix A. Vendor Information

For vendor information, please see NISCC Vulnerability Advisory 236929
"Vulnerability Issues in TCP"
(http://www.uniras.gov.uk/vuls/2004/236929/index.htm) or Vulnerability
Note VU#415294 (http://www.kb.cert.org/vuls/id/415294#systems. As
vendors report new information to US-CERT, we will update the
vulnerability note. If a particular vendor is not listed in either the
NISCC advisory, or the vulnerability, we recommend that you contact
them for their comments.
_________________________________________________________________

US-CERT thanks Paul Watson, Cisco Systems and NISCC for notifying us
about this problem and for helping us to construct this advisory.
_________________________________________________________________

Feedback can be directed to the US-CERT Technical Staff.
_________________________________________________________________

Copyright 2004 Carnegie Mellon University. Terms of use

Revision History

April 20, 2004: Initial release
Last updated April 20, 2004
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAhXn2XlvNRxAkFWARAjKIAKDPl3a6RADvUASZJnIz5MAolUygqACgvUXz
crcQkqHTAxSVkcKnMMYLYU0=
=54p4
-----END PGP SIGNATURE-----

Author yasu : April 21, 2004 9:22 AM | Comment (0) | Trackback (0)

[IT]  データ抹消

客先で使っているPCのデータをそろそろ消さなければいけないのでソフトを探してみた。
客先PCはユーザだけ消したいので、ファイル単位で消せるプログラムがいい。
http://safechaos.com/cs.htm

会社の個人PCはディスクごと全部消したいので、以前日記で紹介したCD-LinuxDistributionを使う予定。
http://www.knoppix-std.org/
このLinuxを起動させて、wipeってプログラムを実行するだけ。

これらのプログラムはディスクに0を書き込むだけでなく、ランダム生成したデータで上書きを行うので、データを復元するのは物理的に不可能になる。

Author yasu : April 20, 2004 1:04 PM | Comment (0) | Trackback (0)

[etc]  野毛

ショットバーがあつい。
東急線が桜木町に乗り入れなくなったので、この機会にちょっと野毛を探検してみることに。
ほとんどのバーが奥まったところにあったり、怪しさ満点の場所にあったりと初めての店は結構入りづらいかも。
結局選んで入った店では、客が他にいなくて静か過ぎた。けど、バーテンさんが細かいところに気を使っている感じで、いい店だった。名前は思い出せない。。

Author yasu : April 19, 2004 12:58 PM | Comment (2) | Trackback (0)

[etc]  テンピュールピロー

昨日家に帰ったら宅配ボックスに枕が届けられてた。<-何気に宅配ボックス便利

ネック ピローMサイズってのを買ったんだけど、頭に合わせて枕がフィットするからサイズはそれほど関係ないかも。
使い始めてまだ1日目だから驚く効果はないけど、それでも横になった瞬間に爆睡。あと首がすごく軽くなった感じで肩こりにもよさげ。

ただしテンピュールは基本的に洗えないので大量ヨダレには要注意。<-3年保証対象外?

Author yasu : April 15, 2004 9:34 AM | Comment (0) | Trackback (0)

[IT]  最近の買い物

日経ITプロフェッショナル縮刷版CD-ROM2002-2003
PDFなので印刷して読んだり、PDAにコピーして読んだりしてる。ちなみにこの雑誌の定期購読はしていない。

基本的に記事が古いのでニュース記事はあまり役に立たないかもしれないが、それ以外の記事はいつ読んでもためになりそう。
この雑誌、基本的には管理職向けのような感じが一見するけど、実際は管理職以外の人も知るべき事が多く書かれてる。なにより、色々な分野の記事があるので、自分のようにいろんなところに目が行ってしまう人向け。

Author yasu : April 14, 2004 9:27 AM | Comment (1) | Trackback (0)

[darts]  筋肉痛

最近夜の遊びはダーツ。金曜に数百回投げたせいで筋肉痛3日目。。
ルールはやったことないものを新たに4種類ほど試しにやってみたらはまった。そろそろマイダーツ購入か?

Author yasu : April 13, 2004 1:02 PM | Comment (0) | Trackback (0)

[business]  作業の進め方

仕事で少々お客さんと認識のズレが生じた。
━━━━━━━━━━━━━━━━━━━━━━━━
1.他モジュールのバグ対応のため担当モジュールに追加機能を頼まれる。
   ↓
2.工数2日程度で、具体的な依頼内容で、しかもバグ対応機能なので設計書を書かずにスピード実装。
   ↓
3.完成後ずるずるとお客さんから更に追加機能仕様が増大していく。
   ↓
4.きりが無いのでこっちからお客さんに現在の処理内容を文書化して提示し、最終仕様決定を求める。
   ↓
5.その結果、大きなズレがあることが分かり再び修正。
   ↓
6.なんとか締め切りに間に合う。
━━━━━━━━━━━━━━━━━━━━━━━━
このケースでの教訓。
2番の時点で4番のことをやっていれば余裕を持って作業を終わらせることができたはず。
どんなにお客さんの要求が詳細で簡単であっても、こっちで仕様・処理内容をドキュメント化し、それについてレビューを開く必要があった。
今回はお客さんが謝ってくれたけど、人やケースによっては逆にクレームをつけられることもある。

いい勉強になりました。

Author yasu : April 9, 2004 2:30 PM | Comment (0) | Trackback (0)

[etc]  Michelle Branch Player

ミッシェルブランチプレイヤー発見:)
少なくとも下の2つのサントラで使われてるBreatheって曲をやっと見つけた。
The Prince and Me
13 Going on 30

すっきり。

Author yasu : April 6, 2004 9:55 PM | Comment (0) | Trackback (0)

[IT]  AVGサーバ不調?

AVG=Free Anti-Virus
ここ最近ウイルス定義ファイルが全く自動で落とせなくなっていて、無料だからかな?と諦めていた。
でもどうもおかしいと思ってちょっと設定ファイルをいじってみることに。
C:\Program Files\Grisoft\AVG6\url.ini
というファイルがサーバ設定ファイルなのでここを、

[SERVER_NAME]
1=free.grisoft.cz
2=free.grisoft.com

[SERVER_URL]
1=http://www.grisoft.cz/softw/60/uk
2=http://www.grisoft.com/softw/60/uk
Actual URL=1

こんな感じに変更してみる。
すると驚くほどすんなりアップデートできるではないか!
原因は全く不明だが、とりあえずめでたしめでたしと。

Author yasu : April 5, 2004 10:22 PM | Comment (0) | Trackback (0)

[business]  名刺作成

名刺はやはり必須アイテムだと感じるこの頃。
試しに業者(vistaprint.jp)に頼んでみることに。
製作費用がかなり安いのに送料が高めなのと、納期が長いのが少々残念。だけど14日後に名刺の出来を確認するのが今から楽しみ。

あまり関係ないけど、名刺業者探してるときに「QRコード」という存在を初めて知った。
名刺に携帯でデータを取り込めるように2次元コードを印刷するサービスがあったけど、なぜかJISでQRコードが規定されてるはずなのにDOCOMO用とVODAFONE,AU用のQRコードが別に用意されてる・・・ これは混乱の元では?? それに名刺の裏面ならQRコードあってもいいけど、表面に印刷されると見た目が悪くなるので自分的にはボツ。

Author yasu : April 4, 2004 5:53 PM | Comment (0) | Trackback (0)