技術

2020年07月14日
ここ最近はずっと大丈夫だったように思うのですが、またスパムメールを大量に送信されてしまうサーバーが出てしまいました。
理由としては非常に単純で、ユーザーが簡単なパスワードを利用していたというもののようです。

まずはスパムの送信を止めたり、ユーザーのパスワードを変更したり。そういうのを最初に行いました。

続いて今後は以下の方法でログを調べていこうと思います。
# grep sasl_username /var/log/maillog |egrep -v 'google.com|192.168' |awk '{print $1,$2,$7,$9}' |sort |uniq -c|sort
※ SMTP認証のときに、sasl_username を含んだログが出ます。この結果から、どのメールアドレスからメールが送信されているのかわかります。

以下のような感じで、集計を行った時点までで、どのぐらいのメールを送信しているのかわかります。
1 Jul X client=プロバイダ名[IP], sasl_username=[メールアドレス]
2 Jul X client=プロバイダ名[IP], sasl_username=[メールアドレス]
4 Jul X client=プロバイダ名[IP], sasl_username=[メールアドレス]
6 Jul X client=プロバイダ名[IP], sasl_username=[メールアドレス]

同様にスパムを送信していたときは、以下のようになっていました。
577 Jul X client=unknown[IP], sasl_username=[メールアドレス]
596 Jul X client=unknown[IP], sasl_username=[メールアドレス]
605 Jul X client=unknown[IP], sasl_username=[メールアドレス]
上位3件だけで抜きましたが、送信量がぜんぜん異なっています。

毎日ログをチェックし、ある日いきなり送信件数が増えていた場合にはすぐに対応したいと思います。




stock_value at 11:56|この記事のURLComments(0)
2020年07月07日
Yamahaのルーターを利用しています。
そして SSH で外部からコントロールできるようにしたい場面が多々あります。

もちろん VPN などを行ってから SSH するのがいいと思うのですが、そうできない場合もあります。

そうして設定しているのですが、SSHに接続できない場面が結構あります。そのときは保険の接続方法・・・VPNやTelnet接続を利用するのですが、なぜ接続できなくなってしまうのでしょうか。

調べてみたところ、以下のページがありました。
YAMAHAルーター 外部からSSHへの接続に失敗する

この方のページにあるように、SSHクライアントを変更したり、アルゴリズムや known_hosts などさまざまやってみましたが、同じようにダメでした。
たしかに SSH をデフォルトのまま Listen させていると多数の不正なアクセスがあります。

これが原因でダメだったのでしょうか?
確かにポートを変更したら問題無く接続できました。
※ただしただ変更しただけではどうもダメっぽいようで、ルーター再起動まですると確実に大丈夫でした。

しばらくは様子を見たいと思います。

stock_value at 07:57|この記事のURLComments(0)
2020年07月06日
アルバのアクセスポイントが設定が簡単で、いろいろなこともできるので、最近はよく提案しています。
設定をしていたところ、アクセスポイントが1Gでリンクアップしていないことに気づきました。

リンクアップをオートネゴから手動に設定するなど、いろいろ試行錯誤したのですが、結局ダメでした。

原因としては、LANケーブルを交換することで解決しました。


stock_value at 14:37|この記事のURLComments(0)
2020年07月05日
なんとOSが付属していませんでした。確認していなかったので大変に驚きました。
ライセンスを購入し、OSのインストールを行おうとしたところ、初期設定ではUSBからブートしないこと、ディスクをまったく認識していないことがわかりました。

以下のサイトが参考になりました。
スティックPC「intel Compute Stick」(m5モデル)を買ってみた〜後編〜

以下引用です。
> ・USB boot → Enable ※デフォルト
> ・UEFI boot → Disable ※Enableから変更
> ・Legacy boot → Enable ※Disableから変更

これでUSBブートするようになりました。助かった。

stock_value at 15:20|この記事のURLComments(0)
2020年07月04日
SSHのログを見ていたところ、Did not receive identification string from X.X.X.X というログが定期的に出ていました。

あまり見慣れないログだったのでとても気になりました。
結論としては非常に単純な原因でした。

このサーバーはロードバランサー配下なのですが、ロードバランサから死活監視を行っています。サーバーの応答が無くなった場合には、別のサーバーで処理を引き継ぐ必要があるためです。この死活監視パケットが原因でエラーになっているようでした。ping での監視に変更して解決しました。

死活監視での似たような事例としては、以下のサイトがありました。
監視対象装置のSyslogで「Did not receive identification string from 」のメッセージが表示される

stock_value at 17:59|この記事のURLComments(0)
2020年06月06日
※サーバーの設定をしているときには、デフォルトゲートウェイを変更すると、SSH等切断される可能性が考えられます。必ず代替手段があることを確認しましょう。
私の場合には、デフォルトゲートウェイを一旦削除したところクラウド環境から切断されてしまいました。
同じ環境内に別サーバーがあり、そこからプライベートIPで接続することで事なきを得ました。

以下のどの方法でもできるようです。

ゲートウェイの削除
route delete default

ゲートウェイの設定(どちらか)
nmcli con mod "System eth0" ipv4.gateway X.X.X.X
route add default gw X.X.X.X

そのほか
インターフェースを表示
nmcli con

# nmcli con
NAME UUID TYPE DEVICE
System eth0 XX ethernet eth0
System eth1 XX ethernet eth1
Wired connection 1 XX ethernet eth2

インターフェースの設定値を表示
#nmcli con show "System eth0"

stock_value at 18:41|この記事のURLComments(0)
2020年05月23日
ubuntu + Plesk を運用していますが、定期的に boot が枯渇します。
以下のコマンドを実行して、 boot 領域を確保しました。
# apt autoremove

念のためということで、上記コマンドを複数回実行したのです。
すると1回目は特に正常に処理が行われたように思ったのですが、2回目はなんだかエラーになりました。

~# apt autoremove
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
アップグレード: 0 個、新規インストール: 0 個、削除: 0 個、保留: 33 個。
N: ディレクトリ '/etc/apt/sources.list.d/' の 'plesk.list.ai_back' が無効なファイル名拡張子を持っているため、無視します

調べてみると、確かに上記フォルダ内に plesk.list.ai_back' ファイルがありました。
中身は apt 関連の設定のようです。

調べてみると、これは lesk.list ファイルの一時的なバックアップファイルだと言うことです。
放置してもいいのかもしれませんが、とりあえず上記フォルダからは移動させ、エラーが出なくなることを確認しました。


stock_value at 10:31|この記事のURLComments(0)