㈠ selinux怎么开放对samba的限制
方法一：关闭SELinux，并修改配置文件，使系统启动时不启动SELinux。（我采用的是这种方法）
Disable selinux
[root@Jie ~]# vi /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
把 SELINUX设定为disable, 下次启动系统后将会停止SElinux。
Linux核心参数(Kernel Parameter)
或者可以在核心参数后加上： selinux=0 （停止） 或 selinux=1 (开启）参数
档案/boot/grub/menu.lst
title Fedora Core (2.6.18-1.2798.fc6)
root (hd0,0)
kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=LABEL=/ rhgb quiet selinux=0
initrd /initrd-2.6.18-1.2798.fc6.img
检查SELinux现时况态
要知到你现在是否使用 SELinux:
# getenforce
disabled
方法二：不关闭SELinux配置 samba的方法（未测试）
将smb.conf中如下这两行启用（去掉行首的；号就可以了）
setsebool -P samba_domain_controller on setsebool -P samba_enable_home_dirs on这两行生效后，自己的home目录就可以正常读写了。
如果想将/home/samba/temp目录设置成完全的共享就应该在字符状态写输入：chcon -t samba_share_t /home/samba/temp 同时不要忘记将/home/samba/temp目录属性设置成777 就可以了。其它和以前的FC版本应该没有什么区别了。
默认的，SELinux禁止网络上对Samba服务器上的共享目录进行写操作，即使你在smb.conf中允许了这项操作。
假设你已经配置了共享目录/share并允许用户进行读写，而你又不想关闭SELinux的话，可以试试以下操作：
程序代码:
#/usr/sbin/setsebool -P allow_smbd_anon_write=1
#chcon -t public_content_rw_t /share
其中第一条语句设置SELinux放行标记了public_content_rw_t的内容，第二条语句把欲共享的/share目录标记为public_content_rw_t。
附SELinux资料：
selinux简介
SElinux 在linux内核级别上提供了一个灵活的强制访问控制系统(MAC)，这个强制访问控制系统是建立在自由访问控制系统(DAC)之上的。
DAC是指系统的安全访问控制都是由系统管理员root自由管理的，不是系统强制行为
MAC运行的时候，比如一个应用程序或者一个线程以某个用户UID或者SUID运行的时候同样对一些其他的对象拥有访问控制限制，比如文件,套接子（sockets）或者其他的线程
通过运行SElinux MAC内核可以保护系统不受到恶意程序的侵犯，或者系统本身的bug不会给系统带来致命影响（把影响限定在一定范围内）
SElinux为每一个用户，程序，进程，还有文件定义了访问还有传输的权限。然后管理所有这些对象之间的交互关系
对于SELinux设定的对象全限是可以根据需要在安装时候规定严格程度，或者完全禁用
在大多数情况下，SElinux对于用户来说是完全透明的，普通用户根本感觉不到 Selinux的存在，只有系统管理员才需要对这些用户环境，以及策略进行考虑。这些策略可以按照需要宽松的部署或者应用严格的限制，Selinux提供 了非常具体的控制策略，范围覆盖整个linux系统
比如，当一个对象如应用程序要访问一个文件对象，内核中的控制程序检查访问向量缓存 (AVC),从这里寻找目标和对象的权限，如果在这里没有发现权限定义，则继续查询安全定义的上下关联，以及文件权限，然后作出准许访问以及拒绝访问的决 定。如果在var/log/messages出现avc: denied信息,则表明访问拒绝。
目标和对象通过安装的策略来决定自身的安全关联，同时这些安装的策略也负责给系统产生安全列表提供信息。
除了运行强制模式以外，SELinux可以运行在许可模式，这时候，检查AVC之后，拒绝的情况被记录。Selinux不强制使用这种策略.
以下介绍一下SELinux相关的工具
/usr/bin/setenforce 修改SELinux的实时运行模式
setenforce 1 设置SELinux 成为enforcing模式
setenforce 0 设置SELinux 成为permissive模式
如果要彻底禁用SELinux 需要在/etc/sysconfig/selinux中设置参数selinux=0 ，或者在/etc/grub.conf中添加这个参数
/usr/bin/setstatus -v
㈡ SELinux权限
在了解SELinux之前，我们先来了解一下Linux的两种访问控制策略：DAC和MAC
DAC，自主访问控制（Discretionary Access control）。系统只提供基本的验证, 完整的访问控制由开发者自己控制。
DAC将资源访问者分成三类：Owner、Group、Other 。
将访问权限也分成三类：read、write、execute
资源针对资源访问者设置不同的访问权限。访问者通常是各个用户的进程，有自己的uid/gid，通过uid/gid 和文件权限匹配, 来确定是否可以访问。DAC机制下，每一个用户进程默认都拥有该用户的所有权限。
DAC 有两个严重问题：
问题一：
因为Root用户是拥有所有权限的，所以DAC对Root用户的限制是无效的。并且在Linux Kernel 2.1以后，Linux将Root权限根据不同的应用场景划分成许多的Root Capabilities, 普通用户也可以被设置某个Root Capability。普通用户如果被设置了CAP_DAC_OVERRIDE， 也可以绕过 DAC 限制。
问题二：
用户进程拥有该用户的所有权限，可以修改/删除该用户的所有文件资源, 难以防止恶意软件。
可见，DAC 有明显的缺陷，一旦被入侵，取得Root权限的用户进程就可以无法无天，胡作非为，早期android版本就深受其害。
MAC， 强制性访问控制（Mandatory Access control）。 系统针对每一项访问都进行严格的限制, 具体的限制策略由开发者给出。
Linux MAC 针对DAC 的不足, 要求系统对每一项访问, 每访问一个文件资源都需要根据已经定义好了的策略进行针对性的验证。系统可以针对特定的进程与特定的文件资源来进行权限的控制。即使是root用户，它所属的不同的进程，并不一定能取得root权限，而得要看事先为该进程定义的访问限制策略。如果不能通过MAC 验证，一样无法执行相关的操作。
与DAC相比，MAC访问控制的“主体”变成了“进程”而不是用户。这样可以限制了Root 权限的滥用，另外要求对每一项权限进行了更加完整的细化, 可以限制用户对资源的访问行为。
SELinux就是目前最好的MAC机制，也是目前的行业标准。
SELinux，安全增强Linux（Security-Enhanced Linux），是由美国国家安全局(NSA)发起, 多个非营利组织和高校参与开发的强制性安全审查机制（Mandatory Access control，简称MAC）。SELinux最早于2000年12月采用GPL许可发布。目前，Linux Kernel 2.6 及以上的版本都已经集成了SELinux。
SELinux 分成三种模式：
Android 5.x及以上强制开启，因此，disabled(关闭)模式并没有什么用了。 通常在调试时，我们会启用Permissve(宽容模式), 以便尽可能的发现多的问题, 然后一次修正。 在量产时启用Enfocing mode(强制模式)来保护系统。
查看SELinux模式：adb shell getenforce
设置SELinux模式：adb shell setenforce 1 //0是Permissve，1是Enfocing
SELinux 的访问控制示意图：
通常我们开发的过程中，就是配置Subject、Object、Security Policy。
SELinux 给Linux 的所有对象都分配一个安全上下文(Security Context)， 描述成一个标准的字符串。
安全上下文的标准格式： user:role:type[:range]
Security Label 用来绑定被访问资源和安全上下文，描述它们的对应关系。标准格式为：resource security_context。即：res user:role:type[:range]。这里也可以使用通配符，例如 net.就可以绑定所有以net.开头的属性，除此之外，还有类似正则表达式的*、？等等通配符。Security Label 都定义在type_contexts当中，例如file的定义在file_contexts中，service定义在service_contexts中，property定义在property_contexts中。
举例：
file_contexts:
service_contexts:
查看进程安全上下文： ps -AZ 。例如，查看Settings进程的安全上下文，ps -AZ | grep settings：
u:r:system_app:s0 system 1381 585 4234504 201072 0 0 S com.android.settings
查看文件安全上下文： ls -Z 。例如，查看文件build.prop的安全上下文：
u:object_r:system_file:s0 build.prop
Type Enforcement (TE) 是根据Security Context中的 type 进行权限审查, 审查 subject type 对 object type 的某个class 类型中某种permission 是否具有访问权限，是目前使用最为广泛的MAC 审查机制, 简单易用。
TE控制语句格式 : rule_name source_type target_type : class perm_set
Type Enforcement规则说明：
举个例子，logd.te、tombstoned.te中定义的TE规则：
allow logd runtime_event_log_tags_file:file rw_file_perms;
dontaudit domain runtime_event_log_tags_file:file { open read };
auditallow tombstoned anr_data_file:file { append write };
neverallow logd { app_data_file system_data_file }:dir_file_class_set write;
SELinux 中每一个进程或者文件都对应一个type, 而每一个type 都对应有一个或几个attribute。所有常见的attribute定义在以下文件中：
system/sepolicy/public/attributes
system/sepolicy/prebuilts/api/[build version]/public/attributes
system/sepolicy/prebuilts/api/[build version]/private/attributes
其中的[build version]即为android版本号，例如android O为28.0。常见的attribute定义：
Type对应一个或者几个attribute，Type的定义格式：
type type_name, attribute1, attribute2；
Type的定义通常分散在各个te文件中。例如，常用普通文件的type定义在file.te中：
SEAndroid对于不同的资源类型，定义了不同的Class。比如普通的file、socket等等，比如SELinux 使用的security, 比如针对每个process 参数的process 等定义相关的class。这些class，每一个class 都有相对应的permissions。 比如file 就有 read, write, create, getattr, setattr, lock, ioctl 等等. 比如process 就有fork, sigchld, sigkill, ptrace, getpgid, setpgid 等等。这些相关的class, 以及他们具有那些Permissions都定义在以下文件中：
system/sepolicy/private/access_vectors
system/sepolicy/reqd_mask/access_vectors
system/sepolicy/prebuilts/api/版本号/private/access_vectors
例如：
定义完之后，在以下对应的security_classes 文件中声明定义的classes。
system/sepolicy/private/security_classes
system/sepolicy/reqd_mask/security_classes
system/sepolicy/prebuilts/api/版本号/private/security_classes
例如：
注意，Classes 和Permissions的定义与Kernel 中相关API是强相关的，普通用户严禁修改。
在SELinux 中, 我们通常称一个进程是一个domain, 一个进程fork 另外一个进程并执行(exec) 一个执行档时, 我们往往会涉及到domain 的切换. 比如init 进程, SELinux 给予了它很大的权限, 而它拉起的服务, 我们要限制这个服务的权限，于是就涉及到从一个domain 切换到另外一个domain, 不然默认就使用init 进程的domain.
在SELinux 里面有专门的一条语法: type_transition statement.
在准备切换前我们先要确保有相关的权限操作：
如下面的demo, init 拉起apache 并且切换到 apache 的domain.
(1). 首先，你得让init_t域中的进程能够执行type为apache_exec_t的文件
allow init_t apache_exec_t : file {read getattr execute};
(2). 然后，你还得告诉SELinux，允许init_t做DT切换以进入apache_t域
allow init_t apache_t : process transition;
(3). 然后，你还得告诉SELinux，切换入口（对应为entrypoint权限）为执行apache_exec_t类型 的文件
allow apache_t apache_exec_t : file entrypoint;
(4).最后，Domain Transition
type_transition init_t apache_exec_t : process apache_t;
可以看到，整个domain切换过程写起来非常麻烦。因此，Google 为了使用方便, 在system/sepolicy/public/te_macros 文件中定义了宏：
我们可以使用这些宏来完成domain切换。
举例：
kernel启动init进程切换domain:
domain_auto_trans(kernel, init_exec, init)
init启动netd、vold、zygote、installd切换domain:
init_daemon_domain(netd)
init_daemon_domain(vold)
init_daemon_domain(zygote)
init_daemon_domain(installd)
一个进程创建在一个目录下创建文件时, 默认是沿用父目录的Security Context, 如果要设置成特定的Label, 就必须进行Object Transitions.
同样是使用：type_transition statement.
对应的必须有两个前提条件:
下面是一个demo, ext_gateway_t 这个domain 在类型为in_queue_t 的目录下，创建类型为 in_file_t 的文件.
(1). 首先，你得让ext_gateway_t 对in_queue_t 目录具备访问权限
allow ext_gateway_t in_queue_t : dir { write search add_name };
(2). 然后，你还得告诉SELinux，允许ext_gateway_t 访问in_file_t的文件
allow ext_gateway_t in_file_t : file { write create getattr };
(3).最后，Object Transition
type_transition ext_gateway_t in_queue_t : file in_file_t;
同样的，为了方便使用，Google 也在system/sepolicy/public/te_macros 文件中定义了宏:
使用举例：
file_type_auto_trans(factory, system_data_file, factory_data_file)
android O 以前sepolicy 集中放在boot image 。前面提到SELinux在Android的主要变更历史时，有提到android O 开始，Google将system image 和 vendor image 分离。因此，sepolicy 也相应的被分离存放到system image 以及 vendor image。与system 相关的sepolicy 就存放system image, 与SoC vendor 相关的sepolicy 就存放在vendor image。
对于原生AOSP，Google 设定了不同的存放目录, 以便进行分离, 以Google 默认的sepolicy 为例，sepolicy主目录为 /system/sepolicy，我们主要关注三个子目录：
对于不同的平台，不同平台厂商也设定了不同的存放目录，以MTK平台为例：
首先，根据不同的platform共用sepolicy、platform独有、project独有，分为：
对应的，不同版本会导入不同目录下的sepolicy配置
以mt6763平台为例，导入时：
[common] 路径为：/device/mediatek/sepolicy
[platfrom] 路径为：/device/mediatek/mt6763/sepolicy/
具体的定义在BoardConfig.mk文件中:
然后，basic、bsp、full又可以主要细分为：
Google 在system/sepolicy 中定义了相关的neverallow 规则, 对SELinux Policy 的更新进行了限制, 以防止开发者过度开放权限，从而引发安全问题。并且还会通过CTS测试检测开发者是否有违法相关的规则。
因此，我们需要注意以下几点：
出现SELinux Policy Exception时常见的两种解决方案：
(1). 修改对应节点的SELinux Security Label, 为特定的Subject，如system_app、platform_app、priv_app，例如Settings，SystemUI等内置APP开启权限, 但严禁为untrsted app 开启权限。
(2). 通过system server service 或者 init 启动的service 读写操作, 然后app 通过binder/socket 等方式连接访问. 此类安全可靠, 并且可以在service 中做相关的安全审查, 推荐这种方法.
情景: 定义由 init 进程启动的service, factory, 其对应的执行档是 /vendor/bin/factory。
(1). 在device/mediatek/mt6763/sepolicy/basic/non_plat 目录下创建一个factory.te , 然后将te文件加入编译，如放到这种指定目录下不需要额外配置，sytem/sepolicy/Android.mk中定义的build_policy函数会遍历指定目录导入te文件。
(2). 在factory.te 中定义factory类型，init 启动service 时类型转换,
type factory, domain;
type factory_exec, exec_type, file_type, vendor_file_type;
init_daemon_domain(factory)
(3). 在file_contexts中绑定执行档
/(system/vendor|vendor)/bin/factory u:object_r:factory_exec:s0
(4). 根据factory需要访问的文件以及设备, 定义其它的权限在factory.te 中.
#Purpose: For key and touch event
allow factory input_device:chr_file r_file_perms;
allow factory input_device:dir rw_dir_perms;
情景: 添加一个自定义的system property： persist.demo，并为platform_app设置读写权限
(1). 在property.te中定义system property类型
type demo_prop, property_type
(2). 在property_contexts中绑定system property的安全上下文。
persist.demo u:object_r:demo_prop:s0
(3). 在platform_app.te 中新增写权限，可以使用set_prop宏。
set_prop(platform_app, demo_prop)
(4). 在platform_app.te 中新增读权限，可以get_prop 宏。
get_prop(platform_app, demo_prop)
情景: 有一个设备节点/dev/demo，有一个platform_app进程需要读写这个设备节点。
(1). 在device.te中定义device 类型
type demo_device dev_type;
(2). 在 file_contexts中绑定demo_device
/dev/demo u:object_r:demo_device:s0
(3). 在platform_app.te中，允许platform_app使用demo device 的权限
allow platform_app demo_device:chr_file rw_file_perms;
情景: 有一个扩展的系统服务demo_service供APP调用。
(1). 在service.te 中定义service 类型
type demo_service, app_api_service, system_server_service, service_manager_type;
(2). 在service_contexts 中绑定service
demo u:object_r:demo_service:s0
(3). 在frameworks/base/core/java/android/content/Context.java中定义服务常量
public static final String DEMO_SERVICE = "demo";
(4). 在frameworks/base/core/java/android/app/SystemServiceRegistry.java中，参照其它系统服务注册demo_service
(5). 在frameworks/base/services/java/com/android/server/SystemServer.java中，启动DemoService，添加到service_manager进行管理。
(6). 最后一步，参考其它系统服务，实现DemoManager、DemoService，并定义如IDemoService等等的AIDL接口。
情景: 一个native service 通过init 创建一个socket 并绑定在 /dev/socket/demo, 并且允许某些process 访问.
(1). 在file.te中定义socket 的类型
type demo_socket, file_type;
(2). 在file_contexts中绑定socket 的类型
/dev/socket/demo_socket u:object_r:demo_socket:s0
(3). 允许所有的process 访问，使用宏unix_socket_connect(clientdomain, socket, serverdomain)
unix_socket_connect(appdomain, demo, demo)
(1). 在device/mediatek/mt6763/sepolicy/basic/non_plat目录下创建一个demo.te。
(2). 在demo.te 中定义demo 类型，init 启动service 时类型转换。并可以根据demo 需要访问的文件以及设备, 定义其它的权限在demo.te 中。
type demo, domain;
type demo_exec, exec_type, file_type;
init_daemon_domain(demo)
(3). 绑定执行档 file_context 类型
/vendor/bin/demo u:object_r:demo_exec:s0
(4). 创建demo的入口执行档demo_exec、并配置相应的权限。
(1). 将SELinux 调整到Permissive 模式复测
使用eng/userdebug 版本，adb shell setenforce 0 将SELinux 模式调整到Permissive 模式，然后复测。如果还能复现问题，则与SELinux 无关； 如果原本很容易复现, 而Permissive mode 不能再复现, 那么就可能与SELinux相关。
(2). 查看LOG 中是否有标准的SELinux Policy Exception.
在Kernel LOG / Main Log 中查询关键字 "avc: denied" 看看是否有与目标进程相关的SELinux Policy Exception, 并进一步确认这个异常是否与当时的逻辑相关。
一般情况我们在符合Google sepolicy策略及neverallow策略的前提下，根据LOG中的内容，需要什么权限就加什么权限。例如LOG：
2020-03-27 14:11:02.596 1228-1228/com.android.systemui W/FaceIdThread: type=1400 audit(0.0:481): avc: denied { read } for name="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0
LOG说明如下：
一般我们需要重点关注的是四个：permission、source type、target type、target class
根据这四个就可以配置出的所需要的selinux权限：
allow [source type] [target type]: [target class] [permission]
例1：
03-27 03:45:22.632 2958 2958 W Camera: type=1400 audit(0.0:314): avc: denied { read } for name="u:object_r:graphics_debug_prop:s0" dev="tmpfs" ino=2649 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:graphics_debug_prop:s0 tclass=file permissive=0
解决方案：
按正常的套公式，应该是这样修改platform_app.te，增加：
allow platform_app graphics_debug_prop:file r_file_perms;
这里我们利用system/sepolicy/te_macros中定义的宏get_prop：
更多相关的宏定义请参考：system/sepolicy/public/te_macros。
所以最终简化后，修改platform_app.te，增加：
get_prop(platform_app, graphics_debug_prop)
例2：
03-27 14:11:02.596 1228-1228/com.android.systemui W/BackThread: type=1400 audit(0.0:481): avc: denied { read } for name="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0
解决方案：
修改platform_app.te增加：
allow platform_app als_ps_device:chr_file r_file_perms;
(1). 不符合neverallow规则或者修改了neverallow规则
编译报错：
neverallow check failed at xxx
CTS测试项failed：
android.cts.security.SELinuxNeverallowRulesTest#testNeverallowRulesXXX
这类问题在android O vendor和system分离之后，尤其容易出现。基本上这类问题都是因为修改或者增加的te配置不符合neverallow规则，导致编译报错。而为了解决编译报错，又修改了neverallow规则，最终在跑CTS时，没法通过相关的测试项。
解决思路：
(2). init进程fork新进程没有做domain切换
CTS测试项failed：
android.security.cts.SELinuxDomainTest # testInitDomain
解决思路：
fork进程时，参考3.4节中做domain切换。
本文主要参考了MTK-Online的Quick-start中《SELinux 问题快速分析》的内容，感谢原作者们的辛勤付出。另外，结合源码和自身开发实践，增加了一些自身理解和实践内容。
㈢ 在linux系统安装tomcat后，bin文件下startup.sh启动不了，这是什么原因
Permission denied 许可被拒绝
回答人的补充 2009-08-18 12:51
在linux上安装有些东西时会出现 Permission denied 的情况：以下就是解决它的办法之一
编辑/etc/selinux/config，找到这段：
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=enforcing
把 SELINUX=enforcing 注释掉：#SELINUX=enforcing ，然后新加一行为：
SELINUX=disabled
保存，关闭。
......
编辑/etc/sysconfig/selinux，找到:
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=enforcing
如果SELINUX已经是 SELINUX=disabled，那么就不用改了，否则就把SELINUX=enforcing 注释掉，新加一行：
SELINUX=disabled
保存，退出。
如果你碰到其他类似提示：
cannot restore segment prot after reloc: Permission denied
哪应该是SELinux的问题，可以考虑把它关闭。
-------------------------------------------------------------------------------------
在你保证SElinux 被disable后.还执行下
chcon -t texrel_shlib_t
如: chcon -t texrel_shlib_t /路径/路径/名字.so (这个文件视具体执行文件.)
以上两步.已经解决了很多server的问题了.
这是我以前还有linux的时候网络的方法，你可以试一试，不知道对你管不管用，另外，你有操作权限吗？
㈣ Linux的系统的安全如何保障保护Linux系统安全的九个常用方法
在现在这个世道中，保障基于Linux的系统的安全是十分重要的。但是，你得知道怎么干。一个简单反恶意程序软件是远远不够的，你需要采取其它措施来协同工作。那么Linux的系统的安全如何保障？今天小编就为大家总结九个常用方法来保护Linux系统安全，希望能帮助到大家。
1. 使用SELinux
SELinux是用来对Linux进行安全加固的，有了它，用户和管理员们就可以对访问控制进行更多控制。SELinux为访问控制添加了更细的颗粒度控制。与仅可以指定谁可以读、写或执行一个文件的权限不同的是，SELinux可以让你指定谁可以删除链接、只能追加、移动一个文件之类的更多控制。(LCTT译注：虽然NSA也给SELinux贡献过很多代码，但是目前尚无证据证明SELinux有潜在后门)
2禁用不用的服务和应用
通常来讲，用户大多数时候都用不到他们系统上的服务和应用的一半。然而，这些服务和应用还是会运行，这会招来攻击者。因而，最好是把这些不用的服务停掉。(LCTT译注：或者干脆不安装那些用不到的服务，这样根本就不用关注它们是否有安全漏洞和该升级了。)
3 订阅漏洞警报服务
安全缺陷不一定是在你的操作系统上。事实上，漏洞多见于安装的应用程序之中。为了避免这个问题的发生，你必须保持你的应用程序更新到最新版本。此外，订阅漏洞警报服务，如SecurityFocus。
4 使用Iptables
Iptables是什么?这是一个应用框架，它允许用户自己为系统建立一个强大的防火墙。因此，要提升安全防护能力，就要学习怎样一个好的防火墙以及怎样使用Iptables框架。
5 检查系统日志
你的系统日志告诉你在系统上发生了什么活动，包括攻击者是否成功进入或试着访问系统。时刻保持警惕，这是你第一条防线，而经常性地监控系统日志就是为了守好这道防线。
6 考虑使用端口试探
设置端口试探(Port knocking)是建立服务器安全连接的好方法。一般做法是发生特定的包给服务器，以触发服务器的回应/连接(打开防火墙)。端口敲门对于那些有开放端口的系统是一个很好的防护措施。
7. 默认拒绝所有
防火墙有两种思路：一个是允许每一点通信，另一个是拒绝所有访问，提示你是否许可。第二种更好一些。你应该只允许那些重要的通信进入。(LCTT译注：即默认许可策略和默认禁止策略，前者你需要指定哪些应该禁止，除此之外统统放行;后者你需要指定哪些可以放行，除此之外全部禁止。)
8.使用全盘加密
加密的数据更难窃取，有时候根本不可能被窃取，这就是你应该对整个驱动器加密的原因。采用这种方式后，如果有某个人进入到你的系统，那么他看到这些加密的数据后，就有得头痛了。根据一些报告，大多数数据丢失源于机器被盗。
9.使用入侵检测系统
入侵检测系统，或者叫IDS，允许你更好地管理系统上的通信和受到的攻击。Snort是目前公认的Linux上的最好的IDS。
以上就是保护Linux系统安全的九个常用方法，希望能帮助到大家！