At a given time it was superseded by the "Linux Security Knowledge
Base". This documentation is also provided in Debian through the
lskb package. Now it's back as the Lasg again.
A very good example of this kind of attacks using /tmp is detailed in The
mysteriously persistently exploitable program (contest) and The
mysteriously persistently exploitable program explained (notice that
the incident is Debian-related). It is basicly an attack in which a local user
stashes away a vulnerable setuid application by making a hard link to
it, effectively avoiding any updates (or removal) of the binary itself made by
the system administrator. Dpkg was recently fixed to prevent this (see
225692) but other
setuid binaries (not controlled by the package manager) are at risk if
partitions are not setup correctly.
The footprint in Debian 3.0 and earlier releases wasn't as tight, since some
inetd services were enabled by default. Also standard
installations of Debian 2.2 installed the NFS server as well as the telnet
server.
This is desirable if you are setting up a development chroot, for example.
For example, in Debian woody it is around 400-500 Mbs, try this:
$ size=0
$ for i in `grep -A 1 -B 1 "^Section: base" /var/lib/dpkg/available |
grep -A 2 "^Priority: required" |grep "^Installed-Size" |cut -d : -f 2
`; do size=$(($size+$i)); done
$ echo $size
47762
Many intrusions are made just to get access to resources to do illegitimate activity (denial of service attacks, spam, rogue ftp servers, dns pollution...) rather than to obtain confidential data from the compromised system.
You can make (on another system) a dummy package with equivs.
In etch and later releases
Even though the libraries have been removed from the filesystem the inodes will not be cleared up until no program has an open file descriptor pointing to them.
Depending on your lsof version you might need to use $8 instead of $9
This happened, for example, in the upgrade from libc6 2.2.x to 2.3.x due to NSS
authentication issues, see http://lists.debian.org/debian-glibc/2003/debian-glibc-200303/msg00276.html.
Unless you have installed a kernel metapackage like
kernel-image-2.4-686 which will always pull in the latest kernel
minor revision for a kernel release and a given architecture.
A sample script called testnet
is available in the Remotely rebooting
Debian GNU/Linux machines article. A more elaborate network
connectivity testing script is available in the Testing network
connectivity article.
Setting up a serial console is beyond the scope of this document, for more
information read the Serial HOWTO and
the Remote
Serial Console HOWTO.
The /etc/securetty is a configuration file that belongs to the
login package.
Or ttyvX in GNU/FreeBSD, and ttyE0 in GNU/KNetBSD.
Or comX in GNU/Hurd, cuaaX in GNU/FreeBSD, and ttyXX in GNU/KNetBSD.
The default configuration in woody includes 12 local tty and vc consoles, as well as the console device but does not allow remote logins. In sarge the default configuration provides 64 consoles for tty and vc consoles. You can safely remove this if you are not using that many consoles.
Look for the getty calls.
Some of this includes the package manager dpkg since the
installation (post,pre) and removal (post,pre) scripts are at
/var/lib/dpkg/ and Smartlist
This dependency is not fixed, however, in the Debian 3.0 package. Please see
Bug #112965.
libpam-chroot has not been yet thoroughly tested, it does work for
login but it might not be easy to set up the environment for other
programs
Setting HISTSIZE to a very large number can cause issues under some shells since the history is kept in memory for every user session. You might be safer if you set this to a high-enough value and backup user's history files (if you need all of the user's history for some reason)
Without the append-only flag users would be able to empty the contents of the history file running > .bash_history
Ttys are spawned for local logins and remote logins through ssh and telnet
As defined in /etc/adduser.conf (USERGROUPS=yes). You can change
this behaviour if you set this value to no, although it is not recommended
Chpasswd cannot handle MD5 password generation so it needs to be
given the password in encrypted form before using it, with the -e
option.
On older Debian releases you might need to do this:
$ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \
sed 's/,libwrap0$//;s/^[[:space:]]\+//'
be sure to use uppercase here since spawn will not work
there's a very good article on it written by Lance Spitzner
Notice that this patch conflicts with patches already included in Debian's 2.4 kernel source package. You will need to use the stock vanilla kernel. You can do this with the following steps:
# apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22
# tar xjf /usr/src/kernel-source-2.4.22.tar.bz2
# cd kernel-source-2.4.22
# /usr/src/kernel-patches/all/2.4.22/unpatch/debian
For more information see #194225, #199519, #206458, #203759, #204424, #210762, #211213, and the discussion
at debian-devel
So common, in fact, that they have been the basis of 20% of the reported
security vulnerabilities every year, as determined by statistics from ICAT's
vulnerability database
In previous releases, checksecurity was integrated into cron and the file was
/etc/cron.daily/standard
In Debian the kernel-source-version packages copy the
sources to /usr/src/kernel-source-version.tar.bz2, just
substitute version to whatever kernel version sources you have
installed
To reproduce this (example provided by Felix von Leitner on the Bugtraq mailing list):
host a (eth0 connected to eth0 of host b):
ifconfig eth0 10.0.0.1
ifconfig eth1 23.0.0.1
tcpserver -RHl localhost 23.0.0.1 8000 echo fnord
host b:
ifconfig eth0 10.0.0.2
route add 23.0.0.1 gw 10.0.0.1
telnet 23.0.0.1 8000
It seems, however, not to work with services bound to 127.0.0.1, you might need to write the tests using raw sockets.
The fact that this behavior can be changed through routing was described by Matthew G. Marsh in the Bugtraq thread:
eth0 = 1.1.1.1/24
eth1 = 2.2.2.2/24
ip rule add from 1.1.1.1/32 dev lo table 1 prio 15000
ip rule add from 2.2.2.2/32 dev lo table 2 prio 16000
ip route add default dev eth0 table 1
ip route add default dev eth1 table 2
There are some patches available for this behavior as described in Bugtraq's
thread at http://www.linuxvirtualserver.org/~julian/#hidden
and http://www.fefe.de/linux-eth-forwarding.diff.
An attacker might have many problems pulling the access through after configuring the IP-address binding if he is not on the same broadcast domain (same network) as the attacked host. If the attack goes through a router it might be quite difficult for the answers to return somewhere.
Gdm will not append -nolisten tcp if it finds a -query or -indirect on the command line since the query wouldn't work.
To retrieve the list of mailer daemons available in Debian try:
$ apt-cache search mail-transport-agent
The list will not include qmail, which is distributed only as
source code in the qmail-src package.
A list of servers/daemons which support these protocols in Debian can be retrieved with:
$ apt-cache search pop3-server
$ apt-cache search imap-server
Note that depending on your bind version you might not have the -g option, most notably if you are using bind9 in sarge (9.2.4 version).
This setup has not been tested for new release of Bind yet.
Unless you use the instdir option when calling dpkg
but then the chroot jail might be a little more complex.
It does try to run them under minimum priviledge which includes running daemons with their own users instead of having them run as root.
Available since the kernel version 2.4 (which was the default kernel in Debian
3.0). Previous kernel versions (2.2, available in even older Debian releases)
used ipchains. The main difference between ipchains
and iptables is that the latter is based on stateful packet
inspection which provides for more secure (and easier to build) filtering
configurations. Older (and now unsupported) Debian distributions using the 2.0
kernel series needed the appropriate kernel patch.
Unlike personal firewalls in other operating systems, Debian GNU/Linux does not
(yet) provide firewall generation interfaces that can make rules limiting them
per process or user. However, the iptables code can be configured to do this
(see the owner module in the iptables(8) manpage).
Translations are available in up to ten different languages.
The full capability
questionnaire is available at CVE
Some operating systems have already been plagued with automatic-updates
problems such as the Mac OS X
Software Update vulnerabity.
FIXME: probably the Internet Explorer vulnerability handling certificate chains has an impact on security updates on Microsoft Windows.
Older releases, such as Debian 3.1 sarge can use this feature by using backported versions of this package management tool
Until an automatic mechanism is developed.
Technically speaking, this is an ASCII-armored detached gpg signature.
Or has poisoned your DNS, or is spoofing the server, or has replaced the file in the mirror you are using, etc.
"ziyi" is the name of the tool used for signing on the Debian
servers, the name is based on the name of a Chinese actress.
Not all apt repository keys are signed at all by another key. Maybe the person setting up the repository doesn't have another key, or maybe they don't feel comfortable signing such a role key with their main key. For information on setting up a key for a repository see Release check of non Debian sources, Section 7.4.4.
Either because you are using the stable, sarge, release or an older release or because you don't want to use the latest apt version, although we would really appreciate testing of it.
Some of them are provided when installing the harden-remoteaudit
package.
If you use this last package and are running an official Debian, the database
will not be updated with security updates. You should either use
clamav-freshclam, clamav-getfiles to generate new
clamav-data packages or update from the maintainers location:
deb http://people.debian.org/~zugschlus/clamav-data/ /
deb-src http://people.debian.org/~zugschlus/clamav-data/ /
Actually, there is an installer package for the F-prot antivirus,
which is non-free but gratis for home users, called
f-prot-installer. This installer, however, just downloads
F-prot's
software and installs it in the system.
For more examples of how to configure gnupg check
/usr/share/doc/mutt/examples/gpg.rc.
Some relevant threads discussing these drawbacks include http://lists.debian.org/debian-mentors/2004/10/msg00338.html
and http://lists.debian.org/debian-devel/2004/05/msg01156.html
This might eventually be introduced as a dh_adduser in debhelper.
See #81967, #291177 and #118787.
You can even provide a SELinux policy for it
You may also want to use the --quiet (-q) option to
reduce the output of apt-get, which will stop the generation of
any output if no packages are installed.
Note that some packages might not use debconf and updates
will stall due to packages asking for user input during configuration.
This is a common issue since many users want to maintain a stable system while updating some packages to unstable to gain the latest functionality. This need arises due to some projects evolving faster than the time between Debian's stable releases.
An easy way to do this is using a Live CD, such as Knoppix Std which includes both
the file integrity tools and the integrity database for your system.
There are over 28 capabilities including: CAP_BSET, CAP_CHOWN, CAP_FOWNER, CAP_FSETID, CAP_FS_MASK, CAP_FULL_SET, CAP_INIT_EFF_SET, CAP_INIT_INH_SET, CAP_IPC_LOCK, CAP_IPC_OWNER, CAP_KILL, CAP_LEASE, CAP_LINUX_IMMUTABLE, CAP_MKNOD, CAP_NET_ADMIN, CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_SETGID, CAP_SETPCAP, CAP_SETUID, CAP_SYS_ADMIN, CAP_SYS_BOOT, CAP_SYS_CHROOT, CAP_SYS_MODULE, CAP_SYS_NICE, CAP_SYS_PACCT, CAP_SYS_PTRACE, CAP_SYS_RAWIO, CAP_SYS_RESOURCE, CAP_SYS_TIME, and CAP_SYS_TTY_CONFIG. All of them can be de-activated to harden your kernel.
You don't need to install lcap to do this, but it's easier than
setting /proc/sys/kernel/cap-bound by hand.
You will typically use a bridge firewall so that the firewall itself is not detectable, see Setting up a bridge firewall, Appendix D.
If you are adventurous, you can login to the system and save information on all running processes (you'll get a lot from /proc/nnn/). It is possible to get the whole executable code from memory, even if the attacker has deleted the executable files from disk. Then pull the power cord.
In fact, this is the tool used to build the CD-ROMs for the Gibraltar project (a firewall on a
live CD-ROM based on the Debian distribution).
This is a list of some CERTs, for a full list look at the FIRST Member
Team information (FIRST is the Forum of Incident Response and
Security Teams): AusCERT
(Australia), UNAM-CERT
(Mexico) CERT-Funet
(Finland), DFN-CERT
(Germany), RUS-CERT
(Germany), CERT-IT
(Italy), JPCERT/CC (Japan),
UNINETT CERT (Norway),
HR-CERT (Croatia) CERT Polskay (Poland), RU-CERT (Russia), SI-CERT (Slovenia) IRIS-CERT (Spain), SWITCH-CERT (Switzerland),
TWCERT/CC (Taiwan), and
CERT/CC (US).
Be very careful if using chroots, since if the binary uses a kernel-level exploit to increase its privileges it might still be able to infect your system
For example, based on some data, it might seem that Windows NT is more secure
than Linux, which is a questionable assertion. After all, Linux distributions
usually provide many more applications compared to Microsoft's Windows NT.
This counting vulnerabilities issues are better described in Why Open Source
Software / Free Software (OSS/FS)? Look at the Numbers! by David A.
Wheeler
Without diminishing the fact that some distributions, such as Red Hat or Mandrake, are also taking into account security in their standard installations by having the user select security profiles, or using wizards to help with configuration of personal firewalls.
Note that this is 'security by obscurity', and will probably not be worth the effort in the long term.
Be careful, as this will traverse your whole system. If you have a lot of disk and partitions you might want to reduce it in scope.
There has been a declassification decision, voted in GR-2005-002, that
might make some posts available in the future, however.
Typically the needed packages will be installed through the dependencies
It can also be downloaded from http://www.cert.org/kb/acid/,
http://acidlab.sourceforge.net
or http://www.andrew.cmu.edu/~rdanyliw/snort/.
Since version 9.2.1-5. That is, since Debian release sarge.
Such as knockd. Alternatively, you can open a different console and have the system ask for confirmation that there is somebody on the other side, and reset the firewall chain if no confirmation is given. The following test script could be of use:
#!/bin/bash
while true; do
read -n 1 -p "Are you there? " -t 30 ayt
if [ -z "$ayt" ] ; then
break
fi
done
# Reset the firewall chain, user is not available
echo
echo "Resetting firewall chain!"
iptables -F
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
exit 1
Of course, you should disable any backdoors before getting the system into production.
You can use the debug option to have it send the progress of the module to the authpriv.notice facility
You can create a very limited bash environment with the following python
definition for makejail, just create the directory
/var/chroots/users/foo and a file with the following contents and
call it bash.py:
chroot="/var/chroots/user/foo"
cleanJailFirst=1
testCommandsInsideJail=["bash ls"]
And then run makejail bash.py to create the user environment at
/var/chroots/user/foo. To test the environment run:
# chroot /var/chroots/user/foo/ ls
bin dev etc lib proc sbin usr
In some occasions you might need the /dev/ptmx and
/dev/pty* devices and the /dev/pts/ subdirectory.
Running MAKEDEV in the /dev directory of the chrooted environment
should be sufficient to create them if they do not exist. If you are using
kernels (version 2.6) which dynamically create device files you will need to
create the /dev/pts/ files yourself and grant them the proper privileges.
If you are using a kernel that implements Mandatory Access Control (RSBAC/SElinux) you can avoid changing this configuration just by granting the sshd user privileges to make the chroot() system call.
Notice that there are no SETUID files. This makes it more difficult for remote
users to escape the chroot environment. However, it also prevents
users from changing their passwords, since the passwd program
cannot modify the files /etc/passwd or /etc/shadow.
Securing Debian Manual
[email protected]