Crontabを編集

昨日のntpの件があるので今日はcrontabを編集。
普通は使用するユーザーでcrontab -eで編集。ちなみに現在登録されている内容を見るのはcrontab -l

# crontab -e

下記のように追加して
0 * * * * /usr/sbin/ntpdate ntp.nict.jp

# crontab -l

# DO NOT EDIT THIS FILE – edit the master and reinstall.
# (/tmp/crontab installed on Tue Nov 29 21:14:30 2005)
# (Cron version — $FreeBSD: src/usr.sbin/cron/crontab/crontab.c,v 1.22 2004/09/14 19:01:19 dds Exp $)
0 * * * * /usr/sbin/ntpdate ntp.nict.jp

こんな風にファイルができます。
出来たファイルは/var/cron/tabs/rootです。rootの部分は作成したユーザーです。
これはFreeBSDの場合ですが、Redhatだと/var/spool/cron/rootという風に保存されるディレクトリが違います。

また、システムで使用するcrontabは/etc/crontabです。
とりあえず出力

# /etc/crontab – root’s crontab for FreeBSD
#
# $FreeBSD: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $
#
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
HOME=/var/log
#
#minute hour mday month wday who command
#
*/5 * * * * root /usr/libexec/atrun
#
# Save some entropy so that /dev/random can re-seed on boot.
*/11 * * * * operator /usr/libexec/save-entropy
#
# Rotate log files every hour, if necessary.
0 * * * * root newsyslog
#
# Perform daily/weekly/monthly maintenance.
1 3 * * * root periodic daily
15 4 * * 6 root periodic weekly
30 5 1 * * root periodic monthly
#
# Adjust the time zone if the CMOS clock keeps local time, as opposed to
# UTC time. See adjkerntz(8) for details.
1,31 0-5 * * * root adjkerntz -a

見たかぎりlinuxと同じような構成の部分がありますね。daily,weekly,monthlyの部分がBSDではperiodicを使い、/etc/periodic/以下にdaily,weekly,monthlyのディレクトリがあってその中にスクリプトを置いています。redhat linuxの場合は/etc/の下にcron.daily, cron.weekly, cron.monthlyとディレクトリがあってその中にスクリプトが入っています。

2013-03-14追記:
NTPサーバを福岡大学からNICTに変更しました。

時計あわせを忘れてた

今気づいたのがサーバーの時計が3分遅れていること、サーバーの時計が狂っているのは致命傷なのですぐに対策します。
運よくntpdateは入っていたのでこれを利用。

# ntpdate ntp.nict.jp

…とおもったらうまく行かない。ファイヤーウォールだな。

# vi /etc/ipf.rules
#ipf -Fa -Z -f /etc/ipf.rules

ちなみに使用しているのは123番ポートです。
あとはcrontabかな

2013-03-14追記:
当時の記事ではntpdateの指定先に福岡大学を指定してましたので、NICTに変更しました。

昔の話ですが福岡大学のNTPサーバが早くから公開されていて知名度もあったためか市販されているルータ機器の時刻合わせ先に福岡大学を指定している物がありアクセス集中による問題が発生していました。

今時はNICTですが、NICT内で負荷分散しているとは言え無闇に設定してアクセス集中させるのはよろしくないので、検証用のVPS等はリブートによる時刻修正か手動によるntpdateコマンド発行等にしましょう。VPSが時計のズレを起こしやすいのはしょうがないですが。。。

 

ファイヤーウォールの設定

本当はサーバーの前段に設置したいのですが余裕ないのでサーバーに組み込み。なぜ前段にしないといけないのかというとDos攻撃によって回線がパンクするだけならまだしもログでパーティションがパンクしたりCPUの過負荷でデーターが破損したりと二次災害の危険があるからです。

ファイヤーウォールの設定はカーネルの再構築かカーネルモジュールの組み込みが必要になるので慎重に作業を進めてください。(リモートで接続できなくなっても保証できませんよ)

まずは、カーネルに組み込まれているか確認

# kldstat
Id Refs Address Size Name
1 7 0xc0400000 63070c kernel
2 16 0xc0a31000 568dc acpi.ko
3 1 0xc15af000 15000 linux.ko

# kldstat -v | grep ip
106 ips/ipsd
107 pci/ips
119 miibus/ciphy
160 ppbus/plip
# kldstat -v | grep fw
91 fwohci/firewire
92 pci/fwohci
93 cardbus/fwohci
94 firewire/fwe

カーネルモジュールがあるか確認

# find / -name ipl.ko
/boot/kernel/ipl.ko

設定ファイルがあるか確認

# find /etc -name ipf.rules

いきなり有効にするとSSHが切断されるので
ipf.rulesを編集してlocalhostとSSHの経路のみ確保。
ifconfigコマンドでインターフェースを確認を忘れずに

fxp0:WAN
lo0:localhost

# プログラム本体があるかどうか
# which ipf
/sbin/ipf

# vi /etc/ipf.rules

rc.confに記述を追加
# vi /etc/rc.conf

ipfilter_enable=”YES”
ipfilter_rules=”/etc/ipf.rules”
ipmon_enable=”YES”
ipmon_flags=”-D /var/log/ipf.log”
/boot/loader.confに記述を追加(最小環境では空でした)
ipl_load=”YES”

モジュール組み込み
# kldload ipl

上手くいったかな?すぐに確認
# kldstat
Id Refs Address Size Name
1 8 0xc0400000 63070c kernel
2 16 0xc0a31000 568dc acpi.ko
3 1 0xc15af000 15000 linux.ko
4 1 0xc1aa0000 2a000 ipl.ko

とりあえず切断はされていない。

運命の再起動
# reboot

SSHでまったく問題なしに入れた。
ここまで楽にできると本当にファイヤーウォールが機能しているか不安だ。

PostgreSQLが起動しているのでtelnetで不正アクセスしてみる。
反応しました、全然機能していません。orz…

起動しているか確認
# /etc/rc.d/ipfilter status
ipf: IP Filter: v4.1.8 (416)
Kernel: IP Filter: v4.1.8
Running: yes
Log Flags: 0 = none set
Default: pass all, Logging: available
Active list: 0
Feature mask: 0x10f

フィルターの確認(-iはイン、-oはアウト)
# ipfstat -i
# ipfstat -o

全然フィルタリングされていませんでした。orz…
設定ファイルの修正
# vi /etc/ipf.rules

設定を反映
# ipf -Fa -Z -f /etc/ipf.rules

2005年12月 1日 07:51
/var/log/auth.logを見ると見知らぬIPからSSHを狙われているのを発見。どうもファイアーウォールが効いてない。実際にログインされた形跡はないので実害はありませんがipf.rulesを見直し。

『全ブロックの後に必要なIPとポートのみ受け入れ』のつもりが『全パスの後に…』になっていた。orz…

要するに単なる設定ミスだが、初めてLinuxサーバー立てたときに漏れクシを作ってしまった以上に恥ずかしい失敗をしてしまった。二段階に予防しておいて良かったと思ったのはSSHハッキングを受けるときに使用されたユーザー名がwww, web, root, test, bin等システムで登録されている事が多いアカウントでした。SSH側でログインユーザーを限定し、システムで不要なユーザーは削除していたので助かったもののこれがLinuxでパッケージに入れたままの状態ならログイン成功してサーバーを破壊されていたかもしれません。

こわいこわい・・・。