タグ

ブックマーク / ya.maya.st (5)

  • Google Public DNS - どさにっき

    2009年12月1日(火) ■ freebsd local exploit _ なんかメールきた。セキュリティまわりのいつものアナウンスとはまったく違う形式なんだけど、もう exploit code が出回ってるのでちゃんとした SA は後回しにしてとりいそぎ パッチ出すよ、ということらしい。 _ んーと、修正内容を見ると、unsetenv(3) の返り値をチェックしていないため、危険な環境変数を除去しようとして失敗してもそのまま突っ走ってしまって LD_PRELOAD からコードを注入できてしまう、ということかな。よりにもよって ld-elf.so.1 の中だし。 _ ……え、返り値ってなにそれ? unsetenv() って void を返すんじゃないの? _ 調べてみると、どうやらちょっと前(freebsd は 6、glibc だと 2.2.2)までは void だったけど、最近では成

    yugui
    yugui 2009/12/10
  • どさにっき: CGI と 304

    2007年1月1日(月) 元日 ■ 賀春 _ あけましておめでとうございます。今年の目標。 自分じゃなくてもできることは他の人にまかせる。 自分じゃできない難しいことは無理せず他の人にがんばってもらう。 自分でやるときはカンタンなことでもさも難しいかのように演じて恩を売る。 そんなかんじでてきとーでゆるゆるにやっていこうと思います。そんなわけで今年もよろしく。 _ 年明け早々から生活リズムが乱れっぱなしであかんわ。寝る。 2007年1月4日(木) ■ ハニーポットへの spam _ 昨年(といっても1週間前だが)の 「“おとりマシン”で受信したメールの87%はスパム」---McAfeeという記事。これ、spam が 87% だった、という調査じゃないよね。ハニーポットに届いたメールを調べてみたら 13% がウィルスとかトロイとかだった(だから残りの 83% は spam だ)という調査だよ

    yugui
    yugui 2007/01/13
  • どさにっき - #!/usr/bin/env

    2006年6月21日(水) ■ DomainKeys _ えーと、DomainKeys ってのは要するに電子署名なので、署名された後でヘッダや文が改変されると検証に失敗する。DomainKeys はメーリングリストに弱いと言われる理由のひとつですな。 _ 自宅 postfix に milter を導入したので、DomainKeys を検証できるようにしてこのあたりの動作を注意深く観察してるのだが、このまえはじまった DNSOPS.JPのメーリングリストからのメール。 Authentication-Results: mx.maya.st sender=ロボットによる収集回避@dnsops.jp; domainkeys=pass なんで pass しとんねん。ML が Subject をいじってるんだから fail になるはずなんだが。Subject をいじらないメーリングリストとか、いじっ

    yugui
    yugui 2006/06/27
    Shebangにおけるenvの使用。激しく同意。
  • NSD

    ここに書いてある情報はクソ古いです。「昔の NSD はこうだったんだ」と懐しむ以外の役には立ちません。NSD 家を見ましょう。 maya.st の情報を管理している DNS は BIND や djbdns でなく、NSD で動いております。NSD なんてぜんぜん知らない、あるいは知っていてもせいぜい名前だけ、という人が現状ではほとんどだと思われるので、ちょっとした紹介など。 NSD って? DNS コンテンツサーバ。どこの馬の骨とも知らぬ怪しげなプロダクトではなく、13個の DNS ルートサーバの一部({h,k}.root-servers.net)を担っているという十分な実績を持っている。開発元はオランダの NLnetLabs というところ。 メリットは、速い、軽い、簡単。UNIX 系 OS では BIND8 が高速だと言われているが、その数倍のパフォーマンスが出るらしい。設定ファイルも

    yugui
    yugui 2006/05/05
    root serversにも使われているname server
  • MTA のアクセス制御

    MTA の各種のアクセス制御手法について思いつくままにメモしたもの。ほとんどは spam 対策だが、こうすれば spam を撃退できる、というガイドではない。絶大な効果があるものから、ほとんど効果がないどころか多大な副作用をもたらすものまで、さまざまな手法をとにかく列挙する。筆者は spam 対策については「やりすぎるぐらいならば何もしない方がマシ」という立場を取っているので、メリットよりもデメリットを重視する。なお、分量はわずかだが DoS 対策や内部ユーザによる abuse を防止する手法についても触れる(この文書は spam 対策技術のメモではなく MTA のアクセス制御手法のメモである)。 ローカル配送された後にユーザごとで選別する方法についてはほとんど取り上げない。携帯電話向け spam についても触れない。特定の MTA や対策ツールにかたよった記述はほとんどしないし、特に必要

  • 1