大家安装好slack后做了哪些安全防备？

<---炯炯有神的看着大家怎么做...

did nothing

打开一切可以打开的网络服务,尽量使用有漏洞的版本

这里的老大真会开玩笑

＃updatepkg 相关软件
＃vi /etc/inetd.conf 把不必要的服务都注释掉
iptables做端口筛选

有没人做蜜罐的？

加了个网关

Slackware Linux Essentials-Second Edition节选

Security on any system is important; it can prevent people launching attacks from
your machine, as well as protect sensitive data. This chapter is all about how to start
securing your Slackware box against script kiddies, crackers and rogue hamsters
alike. Bear in mind that this is only the start of securing a system; security is a
process, not a state.

1-Disabling Services

The first step after installing Slackware should be to disable any services you don’t
need. Any services could potentially pose a security risk, so it is important to run as
few services as possible (i.e. only those that are needed). Services are started from
two main places - inetd and init scripts.
Services started from inetd
A lot of the daemons that come with Slackware are run from inetd(8). inetd is a
daemon that listens on all of the ports used by services configured to be started by it
and spawns an instance of the relevant daemon when a connection attempt is made.
Daemons started from inetd can be disabled by commenting out the relevant lines
in /etc/inetd.conf. To do this, open this file in your favorite editor (e.g. vi) and you
should see lines similar to this:
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
You can disable this service, and any others you don’t need, by commenting them
out (i.e. adding a # (hash) symbol to the beginning of the line). The above line would
then become:
#telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
After inetd has been restarted, this service will be disabled. You can restart inetd
with the command:
# kill -HUP $(cat /var/run/inetd.pid)
Services started from init scripts
The rest of the services started when the machine starts are started from the init
scripts in /etc/rc.d/. These can be disabled in two different ways, the first being to
remove the execute permissions on the relevant init script and the second being to
comment out the relevant lines in the init scripts.
For example, SSH is started by its own init script at /etc/rc.d/rc.sshd. You can disable
this using:
# chmod -x /etc/rc.d/rc.sshd
For services that don’t have their own init script, you will need to comment out the
relevant lines in the init scripts to disable them. For example, the portmap daemon
is started by the following lines in /etc/rc.d/rc.inet2:
# This must be running in order to mount NFS volumes.
# Start the RPC portmapper:
if [ -x /sbin/rpc.portmap ]; then
echo "Starting RPC portmapper: /sbin/rpc.portmap"
/sbin/rpc.portmap
fi
# Done starting the RPC portmapper.
This can be disabled by adding # symbols to the beginnings of the lines that don’t
already start with them, like so:
# This must be running in order to mount NFS volumes.
# Start the RPC portmapper:
#if [ -x /sbin/rpc.portmap ]; then
# echo "Starting RPC portmapper: /sbin/rpc.portmap"
# /sbin/rpc.portmap
#fi
# Done starting the RPC portmapper.
These changes will only take effect after either a reboot or changing from and back
to runlevel 3 or 4. You can do this by typing the following on the console (you will
need to log in again after changing to runlevel 1):
# telinit 1
# telinit 3

2-Host Access Control

iptables
iptables is the packet filtering configuration program for Linux 2.4 and above. The
2.4 kernel (2.4.5, to be exact) was first introduced into Slackware (as an option) in
version 8.0 and was made the default in Slackware 8.1. This section only covers the
basics of its usage and you should check http://www.netfilter.org for more
details. These commands can be entered into /etc/rc.d/rc.firewall , which has to be
set as executable for these rules to take effect at startup. Note that incorrect iptables
commands can essentially lock you out of your own machine. Unless you are 100%
confident in your skills, always ensure you have local access to the machine.
The first thing most people should do is set the default policy for each inbound chain
to DROP:
# iptables -P INPUT DROP
# iptables -P FORWARD DROP
When everything is denied, you can start allowing things. The first thing to allow is
any traffic for sessions which are already established:
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
So as not to break any applications that communicate using the loopback address, it
is usually wise to add a rule like this:
# iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
This rules allows any traffic to and from 127.0.0.0/8 (127.0.0.0 - 127.255.255.255)
on the loopback (
) interface. When creating rules, it is a good idea to be as specific
as possible, to make sure that your rules do not inadvertently allow anything evil.
That said, rules that allow too little mean more rules and more typing.
The next thing to do would be to allow access to specific services running on your
machine. If, for example, you wanted to run a web server on your machine, you
would use a rule similar to this:
# iptables -A INPUT -p tcp --dport 80 -i ppp0 -j ACCEPT
This will allow access from any machine to port 80 on your machine via the ppp0 interface.
You may want to restrict access to this service so that only certain machines
can access it. This rule allows access to your web service from 64.57.102.34
# iptables -A INPUT -p tcp -s 64.57.102.34 --dport 80 -i ppp0 -j ACCEPT
Allowing ICMP traffic can be useful for diagnostic purposes. To do this, you would
use a rule like this:
# iptables -A INPUT -p icmp -j ACCEPT
Most people will also want to set up Network Address Translation (NAT) on their
gateway machine, so ththrough it. You would use the following rule to do this:
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
You will also need to enable IP forwarding. You can do this temporarily, using the
following command:
# echo 1 > /proc/sys/net/ipv4/ip_forward
To enable IP forwarding on a more permanent basis (i.e. so that the change is kept
after a reboot), you will need to open the file /etc/rc.d/rc.inet2 in your favorite
editor and change the following line:
IPV4_FORWARD=0
...to this:
IPV4_FORWARD=1
For more information on NAT, see the NAT HOWTO2.
tcpwrappers
tcpwrappers controls access to daemons at the application level, rather than at the
IP level. This can provide an extra layer of security at times when IP-level access
controls (e.g. Netfilter) are not functioning correctly. For example, if you recompile
the kernel but forget to include iptables support, your IP level protection will fail but
tcpwrappers will still help protect your system.
Access to services protected by tcpwrappers can be controlled using /etc/hosts.allow
and /etc/hosts.deny The majority of people would have a single line in their
/etc/hosts.deny file to deny access to all daemons by default. This line would be:
ALL : ALL
When this is done, you can concentrate on allowing access to services for specified
hosts, domains, or IP ranges. This can be done in the /etc/hosts.allow file, which
follows the same format.
A lot of people would start by accepting all connections from localhost . This can be
achieved using:
ALL : 127.0.0.1
To allow access to SSHd from 192.168.0.0/24 you could use either of the following
rules:
sshd : 192.168.0.0/24
sshd : 192.168.0.
It is also possible to restrict access to hosts in certain domains. This can be done
using the following rule (note that this relies on the reverse DNS entry for the connecting
host being trustworthy, so I would recommand against its use on Internetconnected
hosts):
sshd : .slackware.com

3 -Keeping Current

slackware-security mailing list
Whenever a security problem affects Slackware, an email is sent to all subscribers
to the [email protected] mailing list. Reports are sent out for
vulnerabilities of any part of Slackware, apart from the software in /extra or /pasture
These security announcement emails include details on obtaining updated versions
of Slackware packages or work-arounds, if any.Subscribing to Slackware mailing lists
is covered in Section 2.2.2.The / HQW F26;EbRI1 directory
Whenever updated packages are released for a version of Slackware (usually only
to fix a security problem, in the case of already released Slackware versions), they
are placed in the /patches directory. The full path to these patches will depend on the
mirror you are using, but will take the form /path/to/slackware-x.x/patches
Before installing these packages, it is a good idea to verify the md5sum of the package.
md5sum(1) is a commandline utility that creates a “unique” mathematical hash
of the file. If a single bit of the file has been changed, it will generate a different
md5sum value.
% md5sum package-<ver>-<arch>-<rev>.tgz
6341417aa1c025448b53073a1f1d287d package-<ver>-<arch>-<rev>.tgz
You should then check this against the line for the new package in the checksum.md5 file
in the root of the slackware-$verison directory (also in the /patches directory for
patches) or in the email to the slackware-security mailing list.
If you have a file with the md5sum values in it, you can source it instead with the -c
option to md5sum.
# md5sum -c CHECKSUMS.md5
./ANNOUNCE.10_0: OK
./BOOTING.TXT: OK
./COPYING: OK
./COPYRIGHT.TXT: OK
./CRYPTO_NOTICE.TXT: OK
./ChangeLog.txt: OK
./FAQ.TXT: FAILED
As you can see, any files that md5sum evaluates as correct are listed “ OK” while files
that fail are labelled “ FAILED”. (Yes, this was an insult to your intelligence. Why do
you put up with me?)

一想 还真是
开个http，ftp，...
什么都不管...

我的做法是把 ROOT 的 UID 改成权限非常底,然后自己定义一个"管理员"

这样,哈哈 你破解我的 ROOT 去吧(可能手法有点 OLD)

可以教一下我吗？

有些hard code了root的程序就有麻烦了。

刚刚装了个firestarter（用来配置iptables很方便），再装了个snort。。。。
关了一些不要的服务，大概就这样了。。。。。。。。。。。

其实就是改了一下拥护的 UID，好象 ROOT 的默认 UID 都是 0，所以我们要做的就是吧 ROOT 的 UID 该成普通拥护的 UID，然后自己定义一个用户名字，将其 UID 该成 0。 GID 也是类似这样的操作。