How to take down SSLv3 in your network using iptables firewall? (POODLE)
Is there a way to drop/stop #SSLv3 handshake packets in iptables on routers? #POODLE #Linux #security — Gert van Dijk ⚠️ (@gertvdijk) October 15, 2014 TL;DR: Only do this if you can't change your application/device in your network and you want to kill SSLv3 on network level. Example for logging SSLv3 outbound connections on your host. Run: iptables -I OUTPUT 1 \ -p tcp \! -f --dport 443 \ -m state
DynamoDBやSQSといったAPIを高頻度に使うときに忘れずにセットしておきたいカーネルパラメータ - aws memo
DynamoDB, SQSなどは、Linux内部から高頻度に HTTP APIを叩きに行くことになる。( Fluentdやら、memcachedやらも同じかも) 通常のLinuxのカーネルパラメータ設定で、本番環境や、負荷テスト環境に使うと、おそらくネットワーク障害のような状況に陥るはず。 その時、「DynamoDBの IOPS不足？」「 SQSのAPI スロットリング？「AWSの限界？」と思う前に、これチェック！ netstat -an この結果に、大量のTIME_WAITが表示された場合は、 エフェメラルポートが枯渇して socket作れない状態に陥っている。つまり、DynamoDBやSQSまでパケット届いていない状態なのでAWS側は原因ではない。 ということで、エフェメラルポートを最大限使うようにカーネルパラメータを設定しておくことを忘れないようにするためのメモ。 $ sudo cp
TCP/IP エラー処理 connect 編
connect(2) のエラー TCP において connect(2) 呼出し時に発生する可能性のあるエラーは以下の通りです。 タイムアウト RST 受信 EHOSTUNREACH また ENETUNREACH シグナル受信 その他 まず、connect(2) 時の正常な流れをしっかり覚えておいてください。 (connect(2) を呼んで) SYN を送る SYN+ACK が返ってくる (ここで connect(2) から戻る) ACK を送る タイムアウト もし仮に、SYN を送ったものの、相手側から SYN+ACK が返ってこない場合は、 (ローカルの TCP スタックが) しつこく SYN を再送します。何度 SYN を送っても SYN+ACK が返ってこない場合はあきらめてタイムアウトします。 「SYN+ACK が返ってこない」というのは、例えば以下のようなケースが考えられます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
