CentOS6とCentOS7でのプロセス管理コマンドの比較

CentOS6で使えたプロセス管理の「service」コマンドがCentOS7では使えなくなり、代わりに「systemctl」コマンドになりました。プロセスの起動、停止、再起動などCentOS6と7とでプロセス管理コマンドの比較をしてみました。なお、CetOS7ではsystemdデーモンが各プロセスを管理する際にユニット、ターゲットという括りで管理していて、httpdやsshdなどのプロセスはserviceユニットとして管理されています。言い回しも「プロセス管理」ではなく「サービス制御」と言われているようですので、それにあわせて記載します。以下のプロセス名とサービス名は言い方は違いますが同じ意味と捉えてください。

httpdやsshdのことを、
CentOS6の場合はプロセスと、ここでは呼ぶ。
CentOS7の場合はサービスと、ここでは呼ぶ。

起動、停止、再起動など

■CentOS6の場合
# service プロセス名 start(起動)
# service プロセス名 stop(停止)
# service プロセス名 restart(再起動)
# service プロセス名 reload(リロード)
# service プロセス名 status(状態の確認)

■CentOS7の場合
# systemctl start サービス名(起動)
# systemctl stop サービス名(停止)
# systemctl restart サービス名(再起動)
# systemctl reload サービス名(リロード)
# systemctl is-active サービス名(状態の確認)
# systemctl status サービス名(状態の確認)

※CentOS7の場合、状態の確認にis-activeとstatusの2種類があるがstatusのほうがより詳細な情報が表示される。

自動起動の確認、設定、解除

■CentOS6の場合
# chkconfig --list(自動起動の確認)
# chkconfig プロセス名 on(自動起動の設定)
# chkconfig プロセス名 off(自動起動の解除)

■CentOS7の場合
# systemctl list-unit-files(自動起動の確認)
# systemctl enable サービス名(自動起動の設定)
# systemctl disable サービス名(自動起動の解除)

ランレベル確認、変更

■CentOS6の場合
ランレベルの確認は「/etc/inittab」ファイルを開いて「id:○:initdefault:」を見て確認します。○のところにランレベルが記載されています。「id:3:initdefault:」となっていればランレベルは「3」となります。
ランレベルの変更は「/etc/inittab」ファイルの○の部分を書き換えてください。

■CentOS7の場合
# systemctl get-default(ランレベルの確認)
# systemctl set-default ターゲット名(ランレベルの設定)

CentOS7の場合、ランレベルの変更は「systemctl」コマンドで実施できます。ランレベルとターゲットの対比は以下となります。

ランレベル ターゲット名 別名
0 poweroff.target runlevel0.target
1 rescue.target runlevel1.target
2 multi-user.target runlevel2.target
3 multi-user.target runlevel3.target
4 multi-user.target runlevel4.target
5 graphical.target runlevel5.target
6 reboot.target runlevel6.target

これらの設定は次回起動時から有効になります。

なお、即時でランレベルの変更するにはCentOS6では「init」コマンドを使用、CentOS7では「isolate」オプションを使用します。

# init ランレベル(CentOS6の場合)
# systemctl isolate ターゲット名(CentOS7の場合)

ubuntuのプロセス制御

CentOSについてプロセスの起動、停止、再起動やランレベルの変更方法を書いてみましたが、ubuntuの場合も書いておこうと思います。ubuntu 18.04 LTSの場合ですが「service」コマンドや「chkconfig」コマンドは使えません。代わりに「systemctl」が使用できますのでCentOS7と同様の方法でプロセスの起動、停止、再起動やランレベルの変更が行なえます。「man systemctl」で詳細が見られますので確認してみてください。

※systemctlを含めCentOS7についての詳細本。

Firewalldにダイレクトルールを設定する。

CentOS7.4のFirewalldにダイレクトルールを設定してみます。以下の方法で設定できると思います。

まず、ダイレクトルールを設定するユーザー定義チェインを作成します。組み込みチェインに直接設定を追加することもできますが管理しやすくするためユーザー定義チェインを利用するほうが良いでしょう。ユーザー定義チェインは「INPUT_custom」という名前で作るとします。

ユーザー定義チェインの作成
# firewall-cmd --direct --add-chain ipv4 filter INPUT_custom

次に、ダイレクトルールをユーザー定義チェインに追加します。例として「SYNflood攻撃と思われる接続を破棄する」ルールの設定です。「-p tcp ! --syn -m state --state NEW -j DROP」の部分がこれに該当します。

ダイレクトルールの作成
# firewall-cmd --direct --add-rule ipv4 filter INPUT_custom 1 -p tcp ! --syn -m state --state NEW -j DROP

最後に、ダイレクトルールを設定したユーザー定義チェインの適用をします。適用先はINPUTチェインです。

ユーザー定義チェインの適用
# firewall-cmd --direct --add-rule ipv4 filter INPUT 1 -j INPUT_custom

以上でFirewalldにダイレクトルールが設定できるはずです。「はずです」と書いているのは、これをまだ試していないからです。このようにやろうと思ったのですが以下の理由により別の方法にしました。

  • Firewalldが導入されているからかなのか、組み込まれているチェインがもともと多く、新たに追加する必要がない気がした。
  • fail2banが「INPUT_direct」のチェインに動的にダイレクトルールを優先度「0」で書き込んでいた。

参考:fail2banを導入したときの記事はこれです。

FirewalldがインストールされているCentOS7.4で「iptables -L」を実行してチェインの内容を確認すると、INPUT、FORWARD、OUTPUT以外にも以下のようなものがありました。

Chain INPUT
Chain FORWARD
Chain OUTPUT
Chain FORWARD_IN_ZONES
Chain FORWARD_IN_ZONES_SOURCE
Chain FORWARD_OUT_ZONES
Chain FORWARD_OUT_ZONES_SOURCE
Chain FORWARD_direct
Chain FWDI_public
Chain FWDI_public_allow
Chain FWDI_public_deny
Chain FWDI_public_log
Chain FWDO_public
Chain FWDO_public_allow
Chain FWDO_public_deny
Chain FWDO_public_log
Chain INPUT_ZONES
Chain INPUT_ZONES_SOURCE
Chain INPUT_direct
Chain IN_public
Chain IN_public_allow
Chain IN_public_deny
Chain IN_public_log
Chain OUTPUT_direct

何がどういう用途なのかはわからないのですが、fail2banを起動させたあとにFirewalldのダイレクトルールの確認、および、iptablesの確認をすると以下でした。

Firewalldのダイレクトルールを確認してみる。


# firewall-cmd --direct --get-all-rules
ipv4 filter INPUT 0 -p tcp -m multiport --dports 50000 -m set --match-set fail2ban-sshd src -j REJECT --reject-with icmp-port-unreachable

iptablesの確認をしてみる。


# iptables -L
 :
Chain INPUT_direct (1 references)
target     prot opt source               destination         
REJECT     tcp  --  anywhere             anywhere             multiport dports 50000 match-set fail2ban-sshd src reject-with icmp-port-unreachable
 :

[広告]

fail2banのダイレクトルールの設定と同じになるようにダイレクトルールは「INPUT_direct」チェインに設定することにします。fail2banのダイレクトルールの優先度は「0」だったので、ここで設定するダイレクトルールの優先度は「1」とします(fail2banのダイレクトルールの優先度のほうを高くしておく)。設定するダイレクトルールは以下です。

①データを持たないパケットの接続を破棄する。
②SYNflood攻撃と思われる接続を破棄する。
③ステルススキャンと思われる接続を破棄する。

※さくらのVPSのサポートページ(閉鎖されました)を参考にさせてもらいました。

①データを持たないパケットの接続を破棄する。
# firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct 1 -p tcp --tcp-flags ALL NONE -j DROP

②SYNflood攻撃と思われる接続を破棄する。
# firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct 1 -p tcp ! --syn -m state --state NEW -j DROP

③ステルススキャンと思われる接続を破棄する。
# firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct 1 -p tcp --tcp-flags ALL ALL -j DROP

永年設定の再読み込み。
# firewall-cmd --reload

ダイレクトルールが設定されているか「/etc/firewalld/direct.xml」の中身を確認してみます。

direct.xmlの確認
# cd /etc/firewalld
# cat direct.xml

以下が設定内容です。


<?xml version="1.0" encoding="utf-8"?>
<direct>
  <rule priority="1" table="filter" ipv="ipv4" chain="INPUT_direct">-p tcp --tcp-flags ALL NONE -j DROP</rule>
  <rule priority="1" table="filter" ipv="ipv4" chain="INPUT_direct">-p tcp '!' --syn -m state --state NEW -j DROP</rule>
  <rule priority="1" table="filter" ipv="ipv4" chain="INPUT_direct">-p tcp --tcp-flags ALL ALL -j DROP</rule>
</direct>

また、iptablesの内容も確認してみます。


# iptables -L
 :
Chain INPUT_direct (1 references)
target     prot opt source               destination         
REJECT     tcp  --  anywhere             anywhere             multiport dports 50000 match-set fail2ban-sshd src reject-with icmp-port-unreachable
DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE
DROP       tcp  --  anywhere             anywhere             tcp flags:!FIN,SYN,RST,ACK/SYN state NEW
DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
 :

ダイレクトルールの設定が追加されています。これで、①〜③のような接続があった場合はFirewalldが遮断をしてくれると思います。

補足:
上記①〜③のパケットを実際に投入したわけではないのでこのルールが機能しているのかはまだ確認できていないのですが(汗)。