A Guide To Secure Arch

RobF · 2006-11-27 19:38:10

broch wrote:

1) no advantage of sudo over su
2) hiding essid is not a security measure: good sniffer will find it anyway broadcasted or not, but some devices may not work properly without essid. So this is not security measure but may cause problems
3) MAC address filtering useless, it takes only one line to change MAC address (after you sniff it)
read this:
http://blogs.zdnet.com/Ou/index.php?p=43
ESSID hiding (use kismet), MAC filtering (use kismet) and WEP (12*-bit) (use airsnort)

Opinions seem to differ on whether using sudo is more secure than using su + password. Evi Nemeth in the "Linux Bible" (Linux Administration Handbook, 2nd edition) seems to prefer using sudo (p.46-51). Somewhere in the book, if I remember correctly, she counters criticism of using sudo by saying that she emphatically recommends using it (I can't find the exact reference now.) "Running Linux" (5th ed., p.832) says "Do not succumb to the temptation to use the root account for everything! ... Always use a normal user account, and use the su or sudo commands to temporarily obtain root access when you need to undertake privileged tasks." Personally, I always use su + password when it's needed and close the root shell as soon as I'm done with the job.

Thanks for the link http://blogs.zdnet.com/Ou/index.php?p=43 ; that made for very interesting reading. I was well aware of the weakness of the WLAN security measures that I mentioned. However, the author of that article says "The top six [including hiding essid and using MAC filtering] require no skills, take less than a minute to crack" and "it takes only a few minutes to break a WEP based network which makes WEP completely ineffective". I disagree that it takes no skills to do these "one-minute crack jobs"; it does take some knowledge and time to install, configure and run Kismet and to use WLAN adapters in monitor mode with native Linux drivers.

If a cracker has his pick from half a dozen access points that his antenna receives, he is unlikely to spend the (absolute minimum of) 10 minutes that according to Ou would be needed to crack the admittedly lightly protected connection when he can crack other connections that are not so protected. Hence, the measures that I mentioned do offer some protection and only minimal effort is required to implement them. Of course using WPA PSK would be better - if your equipment and software supports it.

FWIW, here is the list of the "Top Ten Things You Should Never Do" (well, they add up to less than ten) from "Running Linux" (p.831):

1. Never use simple or easily guessed passwords.
2. Don't use the root account unless you have to.
3. Don't share your passwords.
4. Don't blindly trust binaries that have been given to you.
5. Don't ignore your logfiles.
6. Don't let your system get too far out of date.
7. Don't forget about physical security.

Robert

broch · 2006-11-27 20:19:20

sudo:
I mentioned this before: ubuntu got huge problem with sudo (so called bigest security hole in linux history) as did freespire + privilege escalation in the past.

In general sudo does not offer any extra security over su. Use whichever you like, but this will not enhance decrease box security.

However, the author of that article says "The top six [including hiding essid and using MAC filtering] require no skills, take less than a minute to crack" and "it takes only a few minutes to break a WEP based network which makes WEP completely ineffective". I disagree that it takes no skills to do these "one-minute crack jobs"; it does take some knowledge and time to install,

this shows that you never run sniffer.

If you are well aware of essid/mac trick then you know that for kismet there is no diference betwen hidden or published essid. kismet will show both without any distinction at the same time. So you need time only to fire up sniffer.
When you run kismet/airsnort/arpwatch, then you that on average you have plenty of time to get to someone's network "secured" with tricks like hidden essid or MAC filtering and cracking wep is not difficult. In fact you will need more time to copy screen than to find mac (in kismet hit ss to sort by SSID (including those "hidden", and press arrow to scroll down if plenty of WLANs) and then view the associated clients (hit c). Voila, you have a list of MAC addresses for clients that are using the network, and presumably are on the permitted MAC table.
Next fire up airsnort, collect data and there you have it. Honestly though this may take several hours, but still, at the end you "own" someone's WLAN. Unless you run airsnort in realtime. Then it is faster.

Finally you will need tcpdump

if you have old wep only card then either switch to wpa capable or don't bother at all.
If you are paranoid then switch to WPA2 with RADIUS

People who use these tricks (hidden essid mac filtering wep encryption do not even know that someone is using their bandwidth).
One can say that a rule of security is to use methods that are as efficient as possible.

iphitus · 2006-11-28 08:00:16

on wireless security, if you have an open source router, you could setup a VPN -- which would have the added benefit of remote access if you wished.

James

pmv · 2006-11-28 14:09:46

One addition to this thread.
Install and configure properly fail2ban or denyhosts. They are good for stopping brute force attacks.

I installed one server last friday. (sorry guys, no Arch there) Yesterday denyhosts had already blocked 5 different ip:s that had tried brute force attack. Quite lot for just few days.

japetto · 2006-11-28 14:21:01

In the sudo vs. su debate I also think that on a multiuser workstation sudo should be setup if you need to give root privileges to another user. If you are the only user that needs root then 'su -c' is a good alternative.

broch · 2006-11-28 15:17:27

as I mentioned before:
1) sudo had/still has some security problems in past caused by real security holes, now mostly by incorrect configuration. This tells that proper settings for sudo are not really obvious (not only for newbies)
2) sudo is limited: try to
make clean && make mrproper
on kernel sources (after compiling) with sudo. This will fail miserably (I explained before why).

convictions do not make security

Personally I am using both on single user machine. On multiuser boxes, users don't have access neither to sudo or su. This is administrator's right. Forget about security if you are going to give extended privileges to everybody.

broch · 2006-11-28 17:53:39

A

nd how many people still compile their kernel sources from scratch these days?

kernel was an example

The only "sudo security problem" you have mentioned thus far is the root password being viewable in the ubuntu install log file.

actually no, check out freespire for sudo problems too (I mentioned this before). All this has to do a lot with sudo, because it simply shows that when using sudo one needs to take care of extra files too.

Even the OpenBSD folks got it wrong once, and they're total security nuts.

well, being wrong only once would be some relief. I would refrain from comparing ubuntu to Openbsd. Besides, these are completely different issues.

sudo sh -c 'make && make install'

or shortly use su

Even in this fictional scenario, the sudo approach reduces the likelihood of a root shell being left open indefinitely, and encourages the user to minimize their use of root privileges. This is a good thing that should be encouraged!

why ordinary users need any extra privileges?
take look here:
http://www.friedhoff.org/fscaps.html
these patches allow to run servers with ordinary user privileges.
In other words, don't give anyone except root extra privileges. That is how security works. I don't understand why ordinary users "may need" to use any of root rights?
If admin is stupid enough to leave root account on, then sudo will not help. Sooner or later OS will have to be reinstalled.

Sudo's been around for 26 years (1980), and is STILL being used to secure unix, Mac OS/X and GNU/Linux installs.

this is really bad argument:
sendmail or bind are older than sudo, utterly insecure and widely used. Besides sudo past is not really clean (last three serious security problems in 2005: race condition vulnerability, pathname validation race condition, local privilege escalation).
This does not shows that sudo is insecure. It shows though that sudo is not better security measure.

I don't see any advantage of switching from su to sudo. This is up to user, but definitely not a security enhancement.
I would consider sudo as a convenience... for root

STiAT · 2006-11-29 08:33:03

Hello,

I've a quite short question.
I'm working since some time (uh - about one and a half year now) in arch without a root account, having it disabled - using sudo.

I've set the group wheel to my sudoer group using

%wheel  ALL=(ALL) ALL

Bad practice? creating an own sudoer group, or is wheel just like okay..

// STi

broch · 2006-11-29 14:52:11

well whole point of using sudo is to give users some, not all privileges. But i think that if wheel is trusted completely, then your settings are o.k.

maybe this will help with sudo settings:
http://www.gentoo.org/doc/en/sudo-guide.xml

ravisghosh · 2006-12-10 07:06:33

Arno's script is in AUR and not marked safe.
Bastille is not there neither in repos nor in AUR.

For people like me, gui is really a requirement to setup a firewall. I tried firestarter, but it doesnt give much options which one to block and which one to leave. I tried kmyfirewall, but it has that init path thing and there is no init path in arch i suppose. Then, it was guarddog (with iptables in rc.conf) which i tried but after selecting all the protocols i want to work and then Apply>OK, it still does not work. Going to http://www.grc.com/default.htm and then ShieldsUp gives me the message that firewall is not working.

I tried tripwire and followed the instruction to enter password, but then it was stuck at "generating key (this may take several minutes).. Is there any other option for checking spyware, malware, and other threats.

ravisghosh · 2006-12-10 07:33:01

For firewall, i then tried quicktables http://bbs.archlinux.org/viewtopic.php? … s+firewall though devlopment in quicktables have been stopped. It was quite easy to setup but again http://www.grc.com/default.htm >ShieldsUp gives the same thing that firewall is not working.

ravisghosh · 2006-12-10 07:54:44

huh, firestarter also gives the same thing. are no firewall gui working on arch...

RobF · 2006-12-11 05:00:50

You don't have to install Arno's firewall from the AUR package. Simply download and install it from his website, i.e.

1. Install iptables. (pacman -Sy iptables)
2. Download arno-iptables-firewall v.1.8.8c as a tarball from http://rocky.molphys.leidenuniv.nl/, extract it and put arno-iptables-firewall into /etc/rc.d/. Make sure it's executable.
3. # mkdir /etc/arno-iptables-firewall
4. Put firewall.conf, firewall.conf.example and custom-rules into /etc/arno-iptables-firewall/ (owner/group=root/root)
5. Edit firewall.conf as root. See firewall.conf.example for an example configuration.
The only things I found necessary to edit were:
IPTABLES="/usr/sbin/iptables"
EXT_IF="wlan0"
EXT_IF_DHCP_IP=1
FIREWALL_LOG=/var/log/firewall
LOGLEVEL=debug
OPEN_TCP="12345" # I use this port for the bittorrent protocol
OPEN_UDP="12345"
6. To have the firewall start on bootup put "/etc/rc.d/arno-iptables-firewall start" into /etc/rc.local
To start/stop/restart/show-status of FW run "/etc/rc.d/arno-iptables-firewall start|stop|restart|status".
7. To log firewall messages to /var/log/firewall instead of /var/log/messages replace existing /etc/syslog.conf and /etc/logrotate.d/syslog files with the supplied .new versions.
# touch /var/log/firewall
Root can inspect firewall logs with cat /var/log/firewall | arno-fwfilter.makepkg

If you suspect a connect problem may be due to the firewall blocking the connection, simply take it down temporarily with # /etc/rc.d/arno-iptables-firewall start

The following are the most popular firewalls (or iptables config scripts/GUI's) according to Freshmeat:
Firewall Builder, Arno's Firewall, Shoreline (formerly Shorewall), FireHOL, Firestarter, Knetfilter. According to the output from "pacman -Ss firewall" of these six the following are available as Arch packages: fwbuilder, firestarter, shorewall (also kmyfirewall, guarddog). Arno's FW and FireHOL can be found in AUR.

Robert

ravisghosh · 2006-12-11 12:18:41

how do u check whether the firewall is working properly or not and how effective is that. i"ve got a eth0 to which router is connected (single comp) and it is over pppoe. then what "EXT_IF=" will be, ppp+ or eth0?

RobF · 2006-12-11 18:40:49

You can figure out whether you should use EXT_IF="ppp+" or EXT_IF="eth0" by reading the Arno's firewall README and the comments in firewall.conf.example. If you can't, then try both options.

You can test whether the firewall is working by bypassing your router, i.e. hooking up your computer directly to the (A)DSL modem ethernet output and then running a port scan on it from a remote host using nmap or one of the online port scan services from the links listed below:

http://www.linux-sec.net/Audit/nmap.test.gwif.html
https://www.grc.com/x/ne.dll?bh0bkyd2
http://www.pcflank.com/
http://secwatch.org/probe.php
http://www.auditmypc.com/firewall-test.asp

Robert

PingFloyd · 2006-12-16 03:51:44

You want some security tips. I have a few that are very simple and go a very long way toward making a Linux box secure. Perhaps farther in of themselve's than most other tips can.

1. Don't run as root except where absolutely necessary. This is the simplest and most fundimentally important rule that has the biggest impact on everything else.

2. Don't run/execute anything under root privileges, other than binaries, scripts, etc. that you can trust. Trust is a subjective thing though. One way or another there are assumptions that have to be made unless you have the time to go through every line in the source code of the program you're considering trusting (consider that there are tons of people on the internet that may be combing through just even one project's source code looking for bits and pieces that are insecure or malicious etc.). Again though, apply what is outlined in '1.' above, regardless of how much you feel you can trust said executable or script etc. Security is all about trying to sway odds for favorable results.

3. Never log into X (this include display managers such as gdm, xdm, and kdm), regardless of what WM or DE you use, as root. X brings a whole other world of ramifications to the security equation. Also, X has always been something that cannot really be considered very secure in relation to the broad scope of Linux (actually *nix for that matter). It brings with it many extra considerations about securing your screen (as in your combination of input devices and output devices) from snooping eyes. Xauth (and the concept of magic cookies), at one point came along and help button down some of these issues, but it is still a good idea to consider that the extra abstraction involved, leaves the door open for more possible exploits (this is especially true since it seems there are many users out their giving instruction in how-tos and advising procedures that circumvent some of this). So common sense mandates to not log into X as root. If you need to do anything within X that requires root privileges, use things like 'su', 'sudo', 'gksu', gksudo', etc. If you are the type that is bugged by having to type in the root password a million times a day, then you would be far more secure keeping a terminal open (or logging in as root at a virtual console), that you SU'd into, than you ever would be loggin in as root. However, you have to consider the issues of local and/or physical security issues (i.e. do you need to worry about a co-worker walking by and using the 'root' logged terminal) and possible unavoidable user-error brain farts (happens to the best of us) like forgetting that a terminal is logged in as root and making a bad typo or serious mistake (regardless, you always have to worry about this under root privileges) etc.

3. When doing anything under root privileges, be extra careful. Be sure you're typing what you think you are. No matter how much of a guru you are, you're bound to have a brain fart sooner or later. Something as small as a misplaced '/' can spell the difference between success and castrophic disaster for the system. It pays to take your time and pace yourself, and take extra precaution, as root. An ounce of prevention is worth a pound of cure.

The bottom line is that by exercising good discretion and habits when it comes to root privileges, it's a simple concept that goes a very long way into securing your Linux system. By doing this vs. not doing this, my guess is that's it's a difference in security somewhere around 90% (not necessarily, there are so many factors in security like what your goals and environment are etc. etc. It really isn't that easy to evaluate, but just wanted to make a point.). That is definitely a figure that is very open to debate of course, but the idea is that it's a small simple thing that goes a long way in making a difference in how secure your system is. For instance, all the firewalling and security patching in the world is all a moot point if the driver behind the wheel inadvertantly executed some malicious code, that at that point, doesn't even require exploitive design to circumvent Linux's security.

Security is something that doesn't really have a pat answer. There are so many factors involved. There is also the balance between accessiblity vs. security. One security policy may be out of place in one person's situation where it's ideal for another. This makes it very hard to make something, such as a wiki, that just gives 'good' step by step instructions. That being said, I've always been an advocate for the concept of 'secure by default', meaning that everything is locked down out of the box and that it's up to the administrator to open up what is necessary based upon their needs. Though, even that is not what could be a considered a good 'rule of thumb' in how to approach things, by many others.

There of course is flip side of the coin to all of this -- how productive is it to live in paranoia or fear? That's always a good question, but it is also a very subjective one. One person's 'paranoia' is another's 'common sense'. Much like the concept of security, I feel this is another balancing act where the 'right balance' varies from circumstance and individual.

PingFloyd · 2006-12-16 04:09:53

The trojan was of course an admin related occurrence because you can't download an SP2 upgrade without being admin. The trojan came along with the SP2 during the initial 15 minutes of download from windows source....not from IRC or "hacker's heaven, Internet Explorer". The system has no trojan nor virus at this time (windows that is) but I don't use it anyhow.

That serves as a good example of the point, that I think, the person that is in reply to, was trying to drive at.

Windows is a great example here. With Windows you had a situation where it required an account with root-like privileges to log into the internet to download (I'm not sure if this part it's necessary to have those privileges though) and install the update (mostly likely definitely necessary here). And here it's a system that is designed by supposed 'experts'. You were even following their recommended procedure.

The result was that the trojan wreaked havoc on your system due to it being allowed to run under root-like privileges. This is a good example of why most Linux users and admins are so adamant about using root account only when and where it's necessary.

In the case of Windows you didn't make the mistake (not sure about using a web browser as admin part or not). The problem is that Windows has a glaring and fundimental security flaw in it's design -- root-like privileges being required for many tasks they shouldn't be. Granted, in this particular case, the equivilent situation happenning on Linux would have had bad results too (a binary based update from the original devs being infected with malware that was designed to attack the system the update was intended for). But it kind of stops and makes you think, 'hmm, Microsoft must use Windows too'. Afterall, even them, the creators of the OS, got infected thanks to poor practice of root privileges (in their case, intregrated into the design of the OS itself!!!).

So it really serves to demonstrate why the concept of using root privileges as little as possible, is such an important one. Microsoft, in this case, hasn't seemed to figure this out, and they of all people should know better considering they're designing and operating system.

ravisghosh · 2006-12-16 20:15:38

could not set up arno's firewall. Finally, settled down with guarddog (its quite heavy though). Its gui interface is really nice for a noob to make things easy. but in rc.conf only iptables is there. Do one need to put guarddog there. When the computer boots up, it says something about "missing iptables rules." Is that fine, given that I've got guarddog. Also, a fix for init path thing in kmyfirewall would be really appreciated.

broch · 2006-12-16 23:09:59

1) remove iptables from rc.conf (if using guarddog)
2) add to rc.local
# Guarddog
if [ -r /etc/rc.firewall ]; then
. /etc/rc.firewall
fi
#

restart box and configure guarddog

ravisghosh · 2006-12-18 10:18:14

In order to test how your firewall is working, how do you bypass the mode or router. What changes r required to be made in rc.conf and where else. Here is the network section of my rc.conf:

#
# -----------------------------------------------------------------------
# NETWORKING
# -----------------------------------------------------------------------
#
HOSTNAME="bluehead"
#
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
#   - prefix an entry in INTERFACES with a ! to disable it
#   - no hyphens in your interface names - Bash doesn't like it
#
# Note: to use DHCP, set your interface to be "dhcp" (eth0="dhcp")
#
lo="lo 127.0.0.1"
eth0="eth0 192.168.1.5 netmask 255.255.255.0 broadcast 192.168.1.255"
INTERFACES=(lo eth0)
#
# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
#   - prefix an entry in ROUTES with a ! to disable it
#
gateway="default gw 192.168.1.1"
ROUTES=(gateway)
#
# Enable these network profiles at boot-up.  These are only useful
# if you happen to need multiple network configurations (ie, laptop users)
#   - set to 'menu' to present a menu during boot-up (dialog package required)
#   - prefix an entry with a ! to disable it
#
# Network profiles are found in /etc/network-profiles
#
#NET_PROFILES=(main)

#

mine is a broadband connection with a router and non-static ip.

broch · 2006-12-18 14:01:01

I simply connect box directly to the modem.
Your box has static ip, so to make it work you will have to change in rc.conf
from
lo="lo 127.0.0.1"
eth0="eth0 192.168.1.5 netmask 255.255.255.0 broadcast 192.168.1.255"
INTERFACES=(lo eth0)
to
lo="lo 127.0.0.1"
eth0="dhcp"
INTERFACES=(lo !eth0)

before you will be able to connect to the net.
You may to set dhcp on your lan first to see if it works.

ravisghosh · 2006-12-20 12:14:18

I use aria2 in pacman and after installing guarddog. I have kept ftp ports open in guardog and pacman without aria2 is working fine but with aria2, it is not working. It seems aria2 uses any other service (other than ftp, http, etc) or port. Could anyone please point that out.

broch · 2006-12-20 17:19:03

for client of any server (some exceptions apply, e.g. ipsec, vpn tunneling), you don't need to open any particular port. Neither for ftp, or cups or samba
On my laptop I have all ports closed with exception of vpn related. pacman/aria works fine, so it must be some other problem with configuration.

lumiwa · 2006-12-20 18:57:43

I read all postings but anywhere I have one question.
I have standalone computer, just Arch is on, connected to the Internet with cable modem. I use Skype, Ekiga and Konqueror, Firefox.
I have and run rkhunter and chkrootkit, never start KDE as root and I have Shorewall firewall. I didn't have problem yet but who knows . Usually I turn computer off once a week If we are going somewhere.
Do I need something more?
Thanks.

ravisghosh · 2006-12-21 12:10:02

broch wrote:

for client of any server (some exceptions apply, e.g. ipsec, vpn tunneling), you don't need to open any particular port. Neither for ftp, or cups or samba
On my laptop I have all ports closed with exception of vpn related. pacman/aria works fine, so it must be some other problem with configuration.

initially after installing guardog, pacman with aria or wget was not working too, but after I checked ftp box in guarddog, pacman started working but without aria2.

Arch Linux

#26 2006-11-27 19:38:10

Re: A Guide To Secure Arch

#27 2006-11-27 20:19:20

Re: A Guide To Secure Arch

#28 2006-11-28 08:00:16

Re: A Guide To Secure Arch

#29 2006-11-28 14:09:46

Re: A Guide To Secure Arch

#30 2006-11-28 14:21:01

Re: A Guide To Secure Arch

#31 2006-11-28 15:17:27

Re: A Guide To Secure Arch

#32 2006-11-28 17:53:39

Re: A Guide To Secure Arch

#33 2006-11-29 08:33:03

Re: A Guide To Secure Arch

#34 2006-11-29 14:52:11

Re: A Guide To Secure Arch

#35 2006-12-10 07:06:33

Re: A Guide To Secure Arch

#36 2006-12-10 07:33:01

Re: A Guide To Secure Arch

#37 2006-12-10 07:54:44

Re: A Guide To Secure Arch

#38 2006-12-11 05:00:50

Re: A Guide To Secure Arch

#39 2006-12-11 12:18:41

Re: A Guide To Secure Arch

#40 2006-12-11 18:40:49

Re: A Guide To Secure Arch

#41 2006-12-16 03:51:44

Re: A Guide To Secure Arch

#42 2006-12-16 04:09:53

Re: A Guide To Secure Arch

#43 2006-12-16 20:15:38

Re: A Guide To Secure Arch

#44 2006-12-16 23:09:59

Re: A Guide To Secure Arch

#45 2006-12-18 10:18:14

Re: A Guide To Secure Arch

#46 2006-12-18 14:01:01

Re: A Guide To Secure Arch

#47 2006-12-20 12:14:18

Re: A Guide To Secure Arch

#48 2006-12-20 17:19:03

Re: A Guide To Secure Arch

#49 2006-12-20 18:57:43

Re: A Guide To Secure Arch

#50 2006-12-21 12:10:02

Re: A Guide To Secure Arch

Board footer