1001コメント275KB

CentOS Part 38【RHEL Clone】

■ このスレッドは過去ログ倉庫に格納されています

0001login:Penguin

2013/03/16(土) 03:13:37.62ID:bjkHbqrL

CentOSはRed Hat Enterprise Linuxより同社の商標を削除して再コンパイルしたRHEL Cloneです。
Red Hatと無関係なコミュニティが無償配布しておりRed Hatのブランドとサポートはありません。
Fedora Core 6≒RHEL 5≒CentOS 5です。
Fedora 13≒RHEL 6≒CentOS 6です。
FC やRHEL用のノウハウや野良RPM、レポジトリはCentOSでほぼ通用します。

前スレ
CentOS Part 37【RHEL Clone】
http://engawa.2ch.net/test/read.cgi/linux/1345458070/

CentOS (The Community ENTerprise Operating System)
http://www.centos.org/

CentOS 配布ミラーサーバ
http://www.centos.org/modules/tinycontent/index.php?id=13

Wikipedia CentOS
http://ja.wikipedia.org/wiki/CentOS

0581login:Penguin

2013/07/26(金) NY:AN:NY.ANID:KIYoDUVO

echo ごめんなさい > /dev/null

0582login:Penguin

2013/07/26(金) NY:AN:NY.ANID:fum7U1RW

:q!が顔文字に見えた

0583login:Penguin

2013/07/27(土) NY:AN:NY.ANID:rF+OTqwe

>>580
初期の段階で設計ミスしてるだけだから
気にするな
へたにかまうと阿呆が存在意義を見出してしまうぞ

0584login:Penguin

2013/07/27(土) NY:AN:NY.ANID:pZPmxn99

ファイルシステムは名前をキーにしたデータベースなんだから
そのこと自体はおかしいってほどのことはないけどな

0585login:Penguin

2013/07/27(土) NY:AN:NY.ANID:d00r4S7m

実装依存の定義されない挙動がポータブルだと考えた時点でバカ

0586login:Penguin

2013/07/27(土) NY:AN:NY.ANID:pZPmxn99

ext4もdirectory hashをオフにできて順になるって解かったからそれでいいじゃん
他人をコケにするのは嬉しいのかもしれないが読まされるのは気持ちのいいものじゃない

0587login:Penguin

2013/07/27(土) NY:AN:NY.ANID:yvhUf5PM

誰もコケにしてないと思うが
本人がそう思うのは勝手だけど

0588login:Penguin

2013/07/28(日) NY:AN:NY.ANID:OXcrTTtG

この業界は知ったかが思い知ったかあと叱咤してナンボだからなあ。

ふつうによくある光景。

0589login:Penguin

2013/07/28(日) NY:AN:NY.ANID:txJKD98i

>>586
どうでもいいこと書いてある日記レスも
書いてる奴は自己満足に浸れるだろうけど、読まされるのは気持ちのいいものじゃない

0590login:Penguin

2013/07/28(日) NY:AN:NY.ANID:82l9VGW8

>>588
自分の性格の悪さを
「業界」と一括りにしないでくれw

0591login:Penguin

2013/07/28(日) NY:AN:NY.ANID:Dg0d9b/y

588は性格悪いやつを揶揄してんだろ
しかしこれだけ出てくるとなるとひとくくりにしていたとしても
間違いじゃないかもしれないな

0592login:Penguin

2013/07/28(日) NY:AN:NY.ANID:YlE8FnDQ

どの業界だろうと
知ったか君をいぢめて喜ぶのは
ほんの少しレベルが高いだけの別の知ったか君だな

所謂「目くそ鼻くそ」ってやつだ

0593login:Penguin

2013/07/28(日) NY:AN:NY.ANID:1jfYBAey

この話おわり。

0594login:Penguin

2013/07/28(日) NY:AN:NY.ANID:/dJSz/YY

>>592
野糞のお前が言うなよ

0595login:Penguin

2013/08/02(金) NY:AN:NY.ANID:DJ153YCX

さあさあこの下のスレが大活躍するときのご来臨
この紹介文を提供させてくれて本当にありがとうよ
ホントオマエラ懲りないねぇしてやったりでメシウマ状態だぜ
ヒャッハｧー　汚物は消毒だ～

> いっつも、あれがうまくいかねー、このコマンド使いづれーとか
> 文句ばっかりいいやがって、たまにはカーネルとかシェルの気持ち
> になってみやがれ
>

たまには、カーネル/シェルの気持ちになってみよう
ttp://engawa.2ch.net/test/read.cgi/linux/1051358586/l10

0596login:Penguin

2013/08/03(土) NY:AN:NY.ANID:Va0cnjFw

Ubuntuのターミナルでインストールしていないコマンドを叩いたときに
そのコマンドをインストールしますか？
って聞いてくるのは何て言う機能なんでしょうか？
CentOSでも使いたいと思っています。

0597login:Penguin

2013/08/03(土) NY:AN:NY.ANID:5r6f1AC5

まずはslをインストールするところから始めようか

0598login:Penguin

2013/08/04(日) NY:AN:NY.ANID:nbdvYLMO

しゅっぽっぽ～

0599login:Penguin

2013/08/04(日) NY:AN:NY.ANID:TjdVAETP

すみません。Linux質問スレから流れて来ました。

fc2vps OS:CentOS5.9 メモリ:2G CPU:Xeon (仮想)

svn 1.7.11
php 5.4.17 (apc, memcahce, pdo with mysql, mecab)
groonga 3.0.6
mysql 5.3.33 (mroonga 3.0.6)

上記の構成でサーバを構築してます。
質問したい問題は２つありまして

1つめは
svnでssh経由のサーバからプロジェクトをチェックアウトしている最中に下記のようなエラーになります。
svn: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
それ以降5分ほど通常のssh接続さえもできなくなります（時間がたつと接続可能になる）
なお、接続先のサーバには特に問題はないように見受けられます。

2つめは
バッチ処理にてgroongaエンジンのテーブル更新中にだいたい同じタイミングで
Lost connection to MySQL server during query
が発生してmysqlの接続が切断されてしまいます。
上記のエラーを確認した所、タイムアウトが原因の事が多いようで処理を調べてみたのですが
バッチ開始から約30分、エラーが発生するクエリは1分弱でエラーが発生しており
どのmysqlの設定が影響しているのかイマイチ不明です。
なお、構文エラー等は確認済みです。

何度となく再インストールやyumによる全updateなども行ったりしていますが症状は改善しません。

自鯖での動作は確認済みの構成とコードなので、Linux上の何らかの設定が問題ではないかと考えています。
何か考えられることはありますでしょうか？

0600login:Penguin

2013/08/04(日) NY:AN:NY.ANID:ZlWwztw7

敗因：Virtuozzo

0601login:Penguin

2013/08/04(日) NY:AN:NY.ANID:6kOKj9nq

>>599
症状からしてホスティング側の問題でしょ。まぁ板違いだが、以下に該当するんじゃねーの？

http://rentalserver.fc2.com/index.php?mode=faq
その他の質問
Q4. 転送量が無制限とありますが、実際は１日どれくらいまで許可されているのでしょうか？
A．サーバのリソースの５％未満でしたら問題ございません。ただし、リソースが５％以上に
　なりますとサービスを一時的に停止させていただくか、追加料金の支払い、...

0602login:Penguin

2013/08/04(日) NY:AN:NY.ANID:TjdVAETP

早速の回答ありがとうございます。
ホスティングの選択をミスった予感ですか
むむむ。
もう少し状況を調べてそれでもダメそうならサポートに、それでもダメなら
諦めてDB側はスペックだけは高い自鯖でどうにかする事も考慮しますです。

ありがとうございました

0603login:Penguin

2013/08/04(日) NY:AN:NY.ANID:5lu40znX

質問があるのですがよろしいでしょうか？

さくらVPSをレンタルし、CentOS 6 64bitで使用してるのですが
vsftpdをインストールしコンフィグファイルを設定し接続すると
自分は接続可能なのですが同じアカウントで他の人に試してもらうと接続出来ません

FTPクライアントは530 Login incorrectと表示しているようで
vsftpdのログを見てもFAIL LOGINとしか書いておらず原因が分かりません

hosts.allowやhosts.deny等で特に制限も行なっておらず
何が原因か分かる方いらっしゃいますでしょうか？

0604login:Penguin

2013/08/04(日) NY:AN:NY.ANID:QiYvFqmA

/etc/shellsとか？

0605login:Penguin

2013/08/04(日) NY:AN:NY.ANID:1qZBBeJs

パスワード間違えてるだけじゃね。

0606login:Penguin

2013/08/04(日) NY:AN:NY.ANID:5lu40znX

>>604
ftp用に作ったアカウントで自分も、もう一人も試していて
完全に同一アカウントなのでそれはないかと思うんですが・・・

>>605
それも何度も確認し、さらにもう一人に試してもらったのですが
その人も530 Login incorrectと出るという事でログイン出来ない様でした

完全に自分しかログイン出来ない状況で原因も不明な為、手詰まり状態で
vsftpの再インストールも試してみましたが結果変わらずです

0607login:Penguin

2013/08/04(日) NY:AN:NY.ANID:V8+cGy8i

>>603
自分と他の人は何が違うの？
ユーザー名/パスワードは同じってことだけど、他に違うのはIPアドレス? FTPクライアントのソフト?
クライアント側で verbose オプションみたいなのがあれば、それを有効にしてみた？
そのあたりも書かないとわからないんじゃない？

0608login:Penguin

2013/08/04(日) NY:AN:NY.ANID:5lu40znX

>>607
情報少なくてすいません
サーバはさくらVPS 2GB CentOS 6の64bit
FTP接続用のユーザー名、パスワードは同じ物を使用
FTPクライアントはお互い共にFFFTP v1.98g
お互い各自宅からなのでIPアドレスは違います

hosts.allowでお互いのIPアドレスをsshの許可をしてるのみで
hosts.deny等の設定は特にありません

verboseがあまり良くわからないのですがクライアント側のログでしょうか？
ログでしたら長くなるのでpastebinにコピペしました

ffftpクライアントのログ
http://pastebin.com/r8GHCg3y

vsftpd.conf
http://pastebin.com/wgkNCDh5

改めてよろしくお願い致します。

0609login:Penguin

2013/08/04(日) NY:AN:NY.ANID:0lBmXog2

>608
ダメなヤツは全角で入力している
大文字小文字が違う
ドットとカンマが間違っている
ゼロとオーが違っている
ファイヤーウォールがある
ウィルス対策ソフトにファイヤーウォールみたいのがある

0610login:Penguin

2013/08/04(日) NY:AN:NY.ANID:V8+cGy8i

ログイン認証のプロンプトは出てるから、接続はできてるね。
サーバー側のログ (アプリケーション、syslog、OSのセキュリティのログ) は？
前の人が言ってるように、パスワード間違えただけじゃない？伝え間違ったとか。コピペしたときに改行文字がはいっちゃったとか。パスワード変えてやってみた？

0611login:Penguin

2013/08/05(月) NY:AN:NY.ANID:r64goCsP

>>609
ユーザー名、パスワードは何度も確認し、パスワードは普段からお互いで使ってる物なので
間違える可能性はかなり低いかと思います。
念の為さらに第三者に接続を試してもらったのですが
第三者も同じく530 Login incorrectと出て接続出来ないようなので間違ってはいないかと思います。

さくらVPSを借りる前に使っていた共有サーバーでは普通に接続出来ていたのと
第三者も同じく接続出来ないというあたりからファイアーウォールソフトの問題は無さそうです。

>>610
syslogでは特にそれらしいログもなく、vsftpd.logには
Sun Aug 4 NY:AN:NY.AN13 [pid 4056] CONNECT: Client "相手のIPアドレス"
Sun Aug 4 NY:AN:NY.AN13 [pid 4055] [webmaster] FAIL LOGIN: Client "相手のIPアドレス"
という物くらいしかありません。

自分の場合は
Sun Aug 4 NY:AN:NY.AN13 [pid 4360] CONNECT: Client "自分のIPアドレス"
Sun Aug 4 NY:AN:NY.AN13 [pid 4359] [webmaster] OK LOGIN: Client "自分のIPアドレス"
といった感じです。

パスワード変更は試していないのでしてみます。

0612login:Penguin

2013/08/05(月) NY:AN:NY.ANID:r64goCsP

簡単なパスワードに変更してみた所、正しく接続出来たようです。
その後、元々のパスワードに再度戻した所うまく接続できるようになりました。

何度も何度もパスワードは確認していたので間違ってた可能性は低いですし
一体なにが原因だったのかわからずモヤモヤしますがとりあえず問題は解決しました。
ここまで長々とお付き合いして助言して頂き本当にありがとうございました。

0613login:Penguin

2013/08/05(月) NY:AN:NY.ANID:f9ic6mrV

>>612
どう考えてもパスワード間違ってただけでしょ
まあ解決して何より

0614login:Penguin

2013/08/05(月) NY:AN:NY.ANID:zjW2Dg2f

>>612
> 何度も何度もパスワードは確認していたので間違ってた可能性は低いですし
いや高いだろ。

0615login:Penguin

2013/08/05(月) NY:AN:NY.ANID:R02FbxpN

思い込みの無限ループが問題解決をずっと妨げるって事、よくあるよね

0616login:Penguin

2013/08/05(月) NY:AN:NY.ANID:+YwjqV8c

あるあるあるあるある

0617login:Penguin

2013/08/05(月) NY:AN:NY.ANID:2a8gK7va

それだけはっきりした症状が出てるのに
なんで「間違ってた可能性は低い」という結論に到るのか。
事実よりも脳内の前提を優先してしまうのでは
性格的に鯖缶に向いてないんじゃ。

「なぜ・どのように間違えたのか」を検証しておかんと
何度でも同じ間違いやらかすぞ。

0618login:Penguin

2013/08/05(月) NY:AN:NY.ANID:2a8gK7va

この手のトラブルで
通常のログで「何をどう間違えたのか」が分かりにくい場合には
結局のところパケットキャプチャで生データを確認するのが
解決は一番早いと思う

0619login:Penguin

2013/08/05(月) NY:AN:NY.ANID:rEA1lq55

右クリックでコピペすると正常にペーストできない仕様のアプリがある。
IEとか、IEとか、IEみたいなの。
昨日、それでハマったw

0620login:Penguin

2013/08/05(月) NY:AN:NY.ANID:pQkMWWbv

>>612
> 何度も何度もパスワードは確認していたので間違ってた可能性は低いですし
> 一体なにが原因だったのかわからずモヤモヤしますがとりあえず問題は解決しました。

だからパスワードを他の二人に伝えるときに間違っちゃったんでしょ。見えない改行文字だったり、空白文字だったり。間違ったパスワード伝えてるんなら何人試しても同じ結果だよ。

自分の失敗を認めることも大切だね。

0621login:Penguin

2013/08/05(月) NY:AN:NY.ANID:4b8DgGGa

パケットキャプチャって(笑)と思ったけどftpって平文だっけか
なぜscpにしないのか

0622login:Penguin

2013/08/05(月) NY:AN:NY.ANID:I3lL5N6T

>>621
sshポート解放はいやや

0623login:Penguin

2013/08/05(月) NY:AN:NY.ANID:+1B5Yt/e

解放せよ！

0624login:Penguin

2013/08/05(月) NY:AN:NY.ANID:2wnWn1P4

ポート２２でなくてもいや？　(今日び 5桁とかにするでしょ)
平文垂れ流しよりよっぽどマシだと思うが

0625login:Penguin

2013/08/05(月) NY:AN:NY.ANID:rEA1lq55

>>622
なんで？　大穴でも見つかった？

0626login:Penguin

2013/08/05(月) NY:AN:NY.ANID:agcgj4RB

シェル使われるとか思ってんじゃね？
Jailする技術もないし、そもそも対策方法自体知らんとか。

0627login:Penguin

2013/08/05(月) NY:AN:NY.ANID:MpEPbfaO

まず、/etc/hosts.deny　に
ALL: ALL
を書くのが基本だ。

0628login:Penguin

2013/08/05(月) NY:AN:NY.ANID:EKiczzFE

>>625
見つかってなくても開けなくて良いものは開けたくないわ

ほんとにみんなsshガッツリ開けてるの？？？
管理にはSCP使うけどVPN経由か最低でも接続元IPアドレスで制限してる

0629login:Penguin

2013/08/05(月) NY:AN:NY.ANID:zjW2Dg2f

接続元制限してるしポート変えてるよ。

0630login:Penguin

2013/08/05(月) NY:AN:NY.ANID:+YwjqV8c

ポートさえ変えとけばそれで十分じゃね

0631login:Penguin

2013/08/05(月) NY:AN:NY.ANID:zjW2Dg2f

おれしか使わないんで全開にする必要もないからなぁ。
まぁ全開にしたい人はすればいいんじゃね。

0632login:Penguin

2013/08/05(月) NY:AN:NY.ANID:3/jDCTIs

俺は普通にssh開けてるけど、パスワード認識は禁止にして、
公開鍵認識のみ許可してる

0633login:Penguin

2013/08/05(月) NY:AN:NY.ANID:zjW2Dg2f

認証と言いたいのか?

0634login:Penguin

2013/08/05(月) NY:AN:NY.ANID:+1B5Yt/e

認識？

0635login:Penguin

2013/08/05(月) NY:AN:NY.ANID:3/jDCTIs

携帯から打ったらミスった。。
認識→認証です

0636login:Penguin

2013/08/05(月) NY:AN:NY.ANID:qod/nI2N

エピステモロジー

0637login:Penguin

2013/08/05(月) NY:AN:NY.ANID:I7mdTaSp

元の話だと、FTPで接続できないとかの文脈からリテラシー低いユーザー相手の話じゃない？
勝手な憶測だけどWebのコンテンツみたいな平文で通信してもまあいいかって内容に読めた。
そんなユーザー相手にするためにSSHポート解放するのは嫌だなぁと思って書いたんだけどね。
ユーザーも使いなれたFTP使いたいって言いそう。
ポート変えるだけってのはちょっと、、、、、

0638login:Penguin

2013/08/05(月) NY:AN:NY.ANID:JOAhU0Vv

FTPなんて超絶使いにくい太古の技術を使い慣れてる人なんているのか？

0639login:Penguin

2013/08/05(月) NY:AN:NY.ANID:G8d6PAAy

俺

0640まあないとは言わないけどな

2013/08/06(火) NY:AN:NY.ANID:fpWmGagu

>>638
特定のクライアントが使いにくいとか言うならわかるが、ftp 自体は http とか smtp とかと対して変わらん
まあ、データコネクション張るところがちょっと面倒かな

0641login:Penguin

2013/08/06(火) NY:AN:NY.ANID:/SiB5Qrp

>>640
他にもうっかり改行コード変換されちゃったり
NLST で返すフォーマットがいろいろだったり
いろいろ面倒よ。

0642login:Penguin

2013/08/06(火) NY:AN:NY.ANID:rrNKWvj+

SSH外部に晒すの躊躇うとか自意識過剰過ぎw
公開鍵認証にするとか、hashlimitやlimitモジュール入れた
iptables有効にしておけば十分すぎるだろ。

0643login:Penguin

2013/08/06(火) NY:AN:NY.ANID:lSG48Wjf

>>642
鍵をリテラシー低いユーザーに配布するのは抵抗あるけどなぁ
サポートも含めてめんどくさい

0644login:Penguin

2013/08/06(火) NY:AN:NY.ANID:2JGgITp3

パスワード認証を有効にしてるのは論外として
ポート変えるのって、マイナスではないだろうけど、そこまで意味あるんだろうか
httpエラーページのバージョン隠すとか、そういう類の話な気がする

0645login:Penguin

2013/08/06(火) NY:AN:NY.ANID:dCAo7vKq

低性能なワームなどからの攻撃をかわす事は出来るだろうが、
ポートスキャンされたら発見されます。

接続元制限は必須だよ。

0646login:Penguin

2013/08/06(火) NY:AN:NY.ANID:/SiB5Qrp

>>644
ログ減らすくらいだね。

0647login:Penguin

2013/08/06(火) NY:AN:NY.ANID:zDjJbSea

ポート番号変更はログのノイズ抑制のためにやってる

サービススキャンの多くは大量のホストを調べる必要上
限られたポートしか調べないんで効果がある

0648login:Penguin

2013/08/06(火) NY:AN:NY.ANID:Esw5PjTQ

パスワード認証を禁止し、公開鍵認証のみの SSH (22/tcp)にすれば、問題解決

0649login:Penguin

2013/08/06(火) NY:AN:NY.ANID:/SiB5Qrp

別に22じゃなくてもいいじゃん。

0650login:Penguin

2013/08/06(火) NY:AN:NY.ANID:RXn0UO9u

ポート番は変更しようよ

0651login:Penguin

2013/08/06(火) NY:AN:NY.ANID:/SiB5Qrp

変更しなくてもいいじゃん。

0652login:Penguin

2013/08/06(火) NY:AN:NY.ANID:bOIV8XSC

httpで何か見る->そのアドレスだけ時限付きでsshのポートオープンってやってる

0653login:Penguin

2013/08/06(火) NY:AN:NY.ANID:EAk44+x3

俺はポート番号6502にしてるぜ！

0654login:Penguin

2013/08/07(水) NY:AN:NY.ANID:C1/Z1tP9

ポート変更が意味あるモノとはあんまし思わないんだけど

0655login:Penguin

2013/08/07(水) NY:AN:NY.ANID:C1/Z1tP9

>>652
こういうの良いけどhttp落ちたら終わるよね

0656login:Penguin

2013/08/07(水) NY:AN:NY.ANID:An94aaPv

>>654
sshdのログは見ないの？

>>655
http落ちたらとか言い回しが素人臭いなあ

0657login:Penguin

2013/08/07(水) NY:AN:NY.ANID:6jis9nzT

ルータとかで止めない限りBOTによるアタックが凄いからなぁ
ポート変更した方が何かと気楽に運用できるよ

0658login:Penguin

2013/08/07(水) NY:AN:NY.ANID:Xsa206Xl

逆に言えばそのくらいしか意味ないよね。
攻める側が本気出せばポート変えててもすぐバレる。

0659login:Penguin

2013/08/07(水) NY:AN:NY.ANID:Xsa206Xl

って話をずっとしてたんだけどな。
伝わってなかったのかな。

0660login:Penguin

2013/08/07(水) NY:AN:NY.ANID:6jis9nzT

まー別に好きにすりゃいいけど、変えた方が明らかにメリットがあるって話だな
本気でのアタックなんて受けることを想定しないでいいよ、そんなたいしたサーバ運用してねーだろ？っていう

まぁ>>647なんだわ、やればわかる

0661login:Penguin

2013/08/07(水) NY:AN:NY.ANID:Xsa206Xl

変えるとちょっとメリットはあるけど、
変えなくてもたいしたデメリットはないよ。

0662login:Penguin

2013/08/07(水) NY:AN:NY.ANID:An94aaPv

頻繁にやってくる広範囲のスキャンは悪用対象を広く浅く探すもので
限られたポートしか調べないのが普通だからログ減らしには役立つという話

ガチで全ポートスキャンなんてそうあることじゃないよ極論くん

0663login:Penguin

2013/08/07(水) NY:AN:NY.ANID:Xsa206Xl

>>662
そこには別に反論してないよ。

0664login:Penguin

2013/08/07(水) NY:AN:NY.ANID:An94aaPv

つまらんはぐらかしだな

0665login:Penguin

2013/08/07(水) NY:AN:NY.ANID:Xsa206Xl

はぐらかしたわけでもないけど。

>>662 の言うことはもっともだよ。
でも極論だから考えなくていい、って環境ばかりではない。
極論まで考えなきゃいけない環境もある。
ケースバイケースだよ。

0666login:Penguin

2013/08/07(水) NY:AN:NY.ANID:6jis9nzT

それともう少し想像力を働かせてみようか

広範囲に仕掛けられたポートスキャン＆アタックに対して、自分のサーバは100％大丈夫と言い切れる？
何かのサービスを導入したときにうっかり変なアカウントが出来てたりしないか？
パスワードを安易なものにしたアカウントで普段運用してないか？

このとき標準ポートでアタックを受けたときに乗っ取られる可能性が1/10000だったとしても、
ポート変更と組み合わせることで限りなく0に近づけることが出来ないか？

さて、メリットはちょっとだろうか、それとも

0667login:Penguin

2013/08/07(水) NY:AN:NY.ANID:Xsa206Xl

>>666
確率はある程度減らせると思う。
でもある程度しか減らせないと思う。

0668login:Penguin

2013/08/07(水) NY:AN:NY.ANID:6jis9nzT

長文書いてたらまたレスがあった

いい加減俺がウザイので最後にする

>>665
君は持論に固持しすぎててそろそろ整合性がとれてないぞ
極論＝全ポートスキャンなんでしょ？
それは標準だろうとそうでなかろうと同じ話、話題に上げる意味が全くない
仮に全ポートスキャンの場合22番以外の方が攻撃を受ける確率が上がる、っていうなら話は変わってくるけどね

よーくこのレスを読もうね

0669login:Penguin

2013/08/07(水) NY:AN:NY.ANID:Xsa206Xl

そんなたいした持論でもないけどなぁ。
ウザいログを減らすためにポート変更は有効。
でもポート変更したら万全ってものでもない。
ポート変更は絶対必要ってもんでもない。
おれの論はそのくらい。

0670login:Penguin

2013/08/07(水) NY:AN:NY.ANID:uBk7Uc0V

うざい

0671login:Penguin

2013/08/07(水) NY:AN:NY.ANID:Xsa206Xl

>>670
たいした話でもないのにスレ進めてごめんね。

0672login:Penguin

2013/08/07(水) NY:AN:NY.ANID:B7HzMzFH

>>656
たまに見るけどだいたいlastbで確認する程度かなぁー
syslog集約しててLogwatchで大体わかるし

http落ちたらとかそういうのは複数インスタンスあるからどれかにsshして治す。

てかそれ言ったらssh落ちたらどっちみち終わるだろ

0673login:Penguin

2013/08/07(水) NY:AN:NY.ANID:B7HzMzFH

ついでに言うとhttpじなくても良いし、
httpへのsyn付きが来た時点で時限オープンって手とあるからぶっちゃけhttpは起動してなくても良い

0674login:Penguin

2013/08/07(水) NY:AN:NY.ANID:Xsa206Xl

>>673
んじゃ iptables か何かでやってんの?

0675login:Penguin

2013/08/07(水) NY:AN:NY.ANID:iRGH4/fD

>>669
あんたのほうが普通だよ
確かにうざいけど、仕事頼むなら669だわw

0676login:Penguin

2013/08/07(水) NY:AN:NY.ANID:16hvQK1Q

不採用の理由は、PCに“詳しすぎる”から……だと？

http://topics.jp.msn.com/digital/pc/article.aspx?articleid=1986638

0677login:Penguin

2013/08/07(水) NY:AN:NY.ANID:Q0ZLUPgb

>>666
それ、話の前提がパスワード認証を有効にしてる場合だろ
何で、いきなりそんな設定を前提にしようとしてんの
議論のやり方も習ったことないの？
あほなの？ねぇ、答えて。あほなの？

0678login:Penguin

2013/08/07(水) NY:AN:NY.ANID:Q0ZLUPgb

ポート変えて防げるのは
デフォルトのポートで運用している脆弱性を抱えたサービスへの攻撃であって、
それを防ぐためにポート変えますっていうのには別に異論はないけど
じゃあ、ほかにデフォルトのポート設定で運用してるサービスはどうなの？ってなるよね
ポート変えるっていう発想自体がおかしいんだよ
接続元を制限する方法、脆弱性を突かれた場合に被害を少なくする方法を考える方が妥当だわ

そんなのできない上にサービスも止められないってなった時に、もうポート変えるぐらいしかできることないよねぇ・ってなるのならまだわかる。

0679login:Penguin

2013/08/07(水) NY:AN:NY.ANID:UyEloyGl

ポート変更闘争とか、バージョン隠蔽闘争なんかは
20世紀にケリが付いたとばかり……
未だに熱い戦いが続いていたとは

0680login:Penguin

2013/08/07(水) NY:AN:NY.ANID:B7HzMzFH

>>674
yes
apacheユーザーにiptables叩かせるなんて本末転倒な気がするので

■ このスレッドは過去ログ倉庫に格納されています