A Guide To Secure Arch

ravisghosh · 2006-11-23 22:06:57

Hi Friends,

Its a definite need for newb, a guide to secure a fresh or not so fresh install of arch. I understand that a basic install of arch is pretty safe, but as you keep using it, you keep adding new stuff to which definitely makes it less secure and precautions need to be taken like firewall and intrusion detection.

Iptables guides that are there in wiki or forums are really not of much help since a newb with little technical knowledge is often at times unaware of the services that are running, which one to block and which one to leave!!! So, little more description about services in wiki would really be helpful.

Second line of defence, intrusion detection/antivirus, etc. is also very important and there is little documentation in wiki/forum especially given that many pkgs are installed from AUR which may contain malacious stuff. Snort is very difficult thing to understand and use for a newb. Are there any easy/effective alternative?

Are there any other aspects other than firewall and intrusion detection that need to be addressed?

Please make this post a guide towards a secure arch for a newb.

lilsirecho · 2006-11-24 01:58:32

Regarding security in archlinux.

I have been an archuser since 2003, have made a thousand or more posts in arch.

I operate arch as root, never as user.

I have never had a security problem of any kind and have used arch most of the four years I have been in Linux.

What's a security problem?

I operated windows once a few months ago and had a trojan in fifteen minutes while waiting for SP2 to load.

Arch compared to Windows is like a mouse compared to an elephant!!!!

ravisghosh · 2006-11-24 02:11:43

Well, the problem is that >>> "how do one knows that a security problem is there or not."

In windows, if you do not have antivirus, anti-malware, etc., a security problem (trojan, spy, etc.) will continue to live with you without one noticing anything and only making the box vulnerable and may be providing info to others.

Gullible Jones · 2006-11-24 03:09:06

lilsirecho wrote:

Regarding security in archlinux.
I have been an archuser since 2003, have made a thousand or more posts in arch.
I operate arch as root, never as user.

Security tip #1: don't run your desktop as root. Please. Just don't. You may not come to harm from it, but trust me, it's just bad practice.

I have never had a security problem of any kind and have used arch most of the four years I have been in Linux.
What's a security problem?
I operated windows once a few months ago and had a trojan in fifteen minutes while waiting for SP2 to load.
Arch compared to Windows is like a mouse compared to an elephant!!!!

Security tip #2: In spite of its relatively good design, Linux is not flawless. Paranoia is not necessary, but it helps to keep your wits about you.

Gullible Jones · 2006-11-24 03:12:16

ravisghosh wrote:

Well, the problem is that >>> "how do one knows that a security problem is there or not."
In windows, if you do not have antivirus, anti-malware, etc., a security problem (trojan, spy, etc.) will continue to live with you without one noticing anything and only making the box vulnerable and may be providing info to others.

System logs, rootkit scanners (chkrootkit and rkhunter), intrusion detection systems (tripwire), and network intrusion detection systems (snort).

(There's probably other stuff too - I'm not a security guy by any stretch. See what other folks have to say...)

F · 2006-11-24 03:35:38

lilsirecho wrote:

Regarding security in archlinux.
I have been an archuser since 2003, have made a thousand or more posts in arch.
I operate arch as root, never as user.
I have never had a security problem of any kind and have used arch most of the four years I have been in Linux.

Uhm, how do you know? A good hack means you would be completely oblivious of any problem of any kind. You running everything as root is pretty much an "okay go!" for hackers. I hope you don't IRC often...

What's a security problem?

Running everything as root.

I operated windows once a few months ago and had a trojan in fifteen minutes while waiting for SP2 to load.

Thats because the trojan infected an Administrator's account. If it had infected a lowly user's account, your machine would probably still be alive and healthy right now.

Borosai · 2006-11-24 05:33:27

Up until now, the only step I've taken toward securing my system is setting up a stateful firewall using iptables by following the HOWTO in the wiki (http://wiki.archlinux.org/index.php/Sim … wall_HOWTO). That's it, and I too would like to know what additional steps I can take...which is what I'm assuming this thread is supposed to be about.

Therefore, if those of you who know more about security could offer suggestions on what a typical user "should" (as in recommended) and "could" (as in optional) do, that would be great. Just a small, concise list...point us in the right direction.

mucknert · 2006-11-24 06:18:28

The best practice against malovence is, IMHO, still to have no open ports in the way that you do not have services listening, to stay up to date in terms of software and bug-fixes and to sport some good old human sense, e.g. not trusting strange mails or websites. And for the rest, sensible configuration is the key. You say that you do not find iptables a viable way since you are a "newb" but I say: when you want to be serious about security you have to strip yourself from your "newbishness" and read some good tutorials and Do It Yourself instead of relying on "easy" solutions. So much for that.

lilsirecho · 2006-11-24 06:23:44

F wrote:

lilsirecho wrote:
Regarding security in archlinux.
I have been an archuser since 2003, have made a thousand or more posts in arch.
I operate arch as root, never as user.
I have never had a security problem of any kind and have used arch most of the four years I have been in Linux.
Uhm, how do you know? A good hack means you would be completely oblivious of any problem of any kind. You running everything as root is pretty much an "okay go!" for hackers. I hope you don't IRC often...
What's a security problem?
Running everything as root.
I operated windows once a few months ago and had a trojan in fifteen minutes while waiting for SP2 to load.
Thats because the trojan infected an Administrator's account. If it had infected a lowly user's account, your machine would probably still be alive and healthy right now.

F.

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.

I enjoy the freedom of archlinux and four years with no trouble says security is acceptable in my system. Much has been said on the subject especially to use firewalls and anti-virus and stay away from the bad URL's (IRC?) but it applies very much to windows and windows experiences, not much has appeared regarding linux. Perhaps the request for coverage of the subject is due as requested by Borosai. I would be interested in a listing of all the viruses or other vermin which has attacked archlinux in the past four years......all of which I have not encountered.

I have Larch live DVD which loads copy-to-ram ~750MB. This live DVD has 7.6GB of d/l data consisting of 3200 archlinux .tar.gz packages any of which can load at normal install speed as desired by the user. This is my backup for archlinux which loads these programs as r/w in the mounted Larch Live DVD. It would recover at next boot should any intrusion occur

Long live arch!!!

broch · 2006-11-24 06:36:01

1) install firewall
2) never login as root
3) close all the ports. This concerns also servers: close all ports, next configure server and then, when you are sure that your servers are secured best to your knowledge run it. This is also the way how secure systems work e.g. Free/Net/OpenBSD, Engarde
By default Arch is running with open tcp 6000 and udp 68 (wireless specific?). Close them (tcp 6000 is easy to close, not sure about udp 68, but definitely to point to run it open).
4) keep software up to date:
monitor
http://www.linuxsecurity.com/index.php? … Itemid=188
5) you can harden kernel (grsec is easy and good enough for workstation, otherwise get RSBAC for server)

regarding tripware:
any tool useful for monitoring and alerting on specific file change(s) must be installed first before connecting to network, before installation of anything more than from installation cd

Installing tripware (or any similar tool) now, after you did connect your system to net is quite useless.

To make workstation secure is much easier than securing server obviously.

If you are paranoid, run everything that is connected to network chrooted (including web browsers)[/url]

PJ · 2006-11-24 08:57:34

Limit su to the "wheel" group http://bbs.archlinux.org/viewtopic.php?t=19426

I am not sure if it is already preconfigured in Arch nowadays. Never had a need to check if it is changed, since I haven't reinstalled my system in approximate a year.

elasticdog · 2006-11-24 21:29:12

I've been interested in learning more about <code>iptables</code> and the like but find it all a bit daunting. Googling turns up a huge number of resources, but does anyone have any recommendations on good sites or books even about it?

ravisghosh · 2006-11-25 01:36:29

broch wrote:

1)
regarding tripware:
any tool useful for monitoring and alerting on specific file change(s) must be installed first before connecting to network, before installation of anything more than from installation cd
Installing tripware (or any similar tool) now, after you did connect your system to net is quite useless.

I did not understand this. I have installed arch and had been working on it without any iptables or intrusion detection system for a while now. Does that mean that tripware will not detect any buggy stuff in my system now?

elasticdog · 2006-11-25 02:21:29

He's basically saying that since you can't install it from a guaranteed state on your system, then the results may not be reliable. The very act of having your machine connected to an untrusted source (aka the internet) means that stuff could be going on that you don't know about since you didn't have intrusion detection in place before connecting with that source. Realistically though, you'd probably be just fine...

broch · 2006-11-25 02:56:12

tripwire(like) software, when it runs first time makes image of current state of your OS, then it compares it to the each subsequent runs. If your system is compromised before you install tripware, then for monitoring software, this is healthy state. In other words changes made after installation tripware are easy to spot, changes made before installation ara practically will not be reported by software.

xterminus · 2006-11-25 02:58:32

PJ wrote:

Limit su to the "wheel" group http://bbs.archlinux.org/viewtopic.php?t=19426
I am not sure if it is already preconfigured in Arch nowadays. Never had a need to check if it is changed, since I haven't reinstalled my system in approximate a year.

Another alternative is to disable the root account entirely and use sudo.

Why use sudo?

* Least privilege : Some users need to be able to change network configs, or shutdown the pc without root. Sudo allows specific users (or groups of users) to run specific commands, and not any others.
* Logging : Every single command used through sudo is logged. This enables you to see who did what which is great from a security point of view, and essential from a troubleshooting point of view. When used in tandem with syslog, you can log all restricted commands to a central "log host".
* Timestamping : Sudo uses timestamp files to implement a "ticketing" system. When a user invokes sudo and enters their password, they are granted a ticket for 5 minutes. Each subsequent sudo command updates the ticket for another 5 minutes. This avoids the problem of leaving a root shell where others can physically get to your keyboard. There is also an easy way for a user to remove their ticket file, useful for placing in a .logout file.
* Shared Configuration : Sudo's configuration file, the sudoers file, is setup in such a way that the same sudoers file may be used on many machines. This allows for central administration while keeping the flexibility to define a user's privileges on a per-host basis.
* Root Shells : Sudo avoids the "I can do anything" interactive login by default - you will be prompted for a password before major changes can happen, which should make you think about the consequences of what you are doing. If you were logged in as root, you could just delete some of those "useless folders" and not realize you were in the wrong directory until it's too late.
* Script Kiddies : Every cracker trying to brute-force their way into your box will know it has an account named root and will try that first. What they don't know is what the usernames of your other users are.
* Box Ownership : Sudo allows easy transfer for admin rights, in a short term or long term period, by added and removing users from groups, while not compromising the root account.

to setup sudo, run visudo initially as root and create something like this:

root ALL=(ALL) ALL
cmauch ALL=(ALL) ALL
%users localhost=NOPASSWD: /sbin/mount /cdrom,/sbin/umount /cdrom
%users localhost=NOPASSWD: /sbin/shutdown -h now

change cmauch to whatever your normal user account name is. Login as your username, and test.

sudo vi /etc/X11/xorg.conf

if it works, you should be in your xorg.conf file, and you should see something like this in your syslog file.

Nov 25 03:30:33 redbox sudo: cmauch : TTY=pts/5 ; PWD=/home/cmauch ; USER=root; COMMAND=/usr/bin/vim /etc/X11/xorg.conf

Now ... to disable the root account... do a

passwd -l root

This changes the root password to a value which matches no possible encrypted value. Now log out of root and login as yourself.

Caveats/Warnings:

* User accounts typically don't have /sbin or /usr/sbin in the default $PATH. As a result, you may need to add those directories to a users' path, or better - create a symbolic link between the command you'd like them to be able to use (/sbin/shutdown) and (~/bin/shutdown).
* Some tools like webmin require both root access and a root password. There isn't a great workaround for this except to perhaps use other tools which do not require root access. Besides, It is kind of creepy to allow any piece of software root access over the web.
* When your filesystem becomes completely corrupted and your machine drops into single user mode on boot, you might find yourself locked out of your computer and unable to boot into single-user mode at all because this requires the root password. You can either patch sulogin to handle this, or you can do as I do and simply boot from a USB or CDROM drive to fix things up.

Other non-sudo things you should probably do that I have not seen covered in this thread.

Password security. Probably the most important thing you should consider, which hardly anybody does.

* Change passwords/passphrases once a month, or at least every quarter.
* Ensure passwords are at least 8 characters long, and contain some digits. I like the environ password scheme, which looks like consanant-vowel-consanant-vowel-conanant-vowel-digit-digit. Easy to remember, and proven to be secure (or at least appropriate for securing a workstation). Example environ passphrases: nukiji92, lovudu73, badiki28, tenisi14. If you can remember random alphanumeric strings, then do that, but I change my password 1x a month, and find it hard to remember completely random passwords.
* Never use the same password for two different authentication systems.

Firewalls. It's trivial to setup a gui to handle iptables for you. For a linux workstation, I like firestarter. If you need something more complex, you can use something like shorewall or roll your own iptables solution. Just be sure to block all inbound connections by default. If your running a linux router, it probably would not hurt to drop outboud connections by default too (to protect infected windows machines from themselves).

VPNs: For end users, OpenVPN can be fun setup between your linux buddies to share files. If you have a lot of newbie types who want to share files, there is a neat freeware (not opensource), tool called hamachi that's easy to setup on both linux and windows to establish small VPNs.

Snort and other IDS systems. Probably overkill for a workstation, but fun on routers. If your going to setup snort, you'll probably be playing with honeypots and other "advanced" security tools too.

That's all i can think of off the top of my head.

broch · 2006-11-25 04:30:33

When someone know your password (or you left box unattended logged on), then he also can use sudo.
Sudo has serious limitations (e.g access denied, though it should be granted:
if operation is being executed by your shell, not by you/sudo, you don't have permissions to edit the file.), in some cases it is not clear even where sudo command goes.

how you distingusish between user and sudo (root) commands? All is dumped in user bash_history.

sudo is good for ubuntu newbies.

xterminus · 2006-11-25 05:47:22

broch wrote:

When someone know your password (or you left box unattended logged on), then he also can use sudo.

If you had bothered to read what I wrote, you would have read this snippet.

xterminus wrote:

* Timestamping : Sudo uses timestamp files to implement a "ticketing" system. When a user invokes sudo and enters their password, they are granted a ticket for 5 minutes. Each subsequent sudo command updates the ticket for another 5 minutes. This avoids the problem of leaving a root shell where others can physically get to your keyboard. There is also an easy way for a user to remove their ticket file, useful for placing in a .logout file.

broch wrote:

Sudo has serious limitations (e.g access denied, though it should be granted:

That's the point, you can tweak the sudoers to allow or dissallow whatever you want. With the default of "username ALL=(ALL) ALL", the user "username" has all the permissions of the root user anyway, assuming they authenticate with sudo with their own password. What you get in return typing four extra letters (and a space) is auditing, accountability, and an easy way to centralize security polices across any unix/linux boxes you own/maintain.

I fail to see a "serious limitation" here.

broch wrote:

if operation is being executed by your shell, not by you/sudo, you don't have permissions to edit the file.), in some cases it is not clear even where sudo command goes.

If you need a script to run as root, just sudo /path/to/script. Cron jobs are not affected by sudo.

And if you need to share files between users, a better alternative to giving both users the root password would be to make both users a part of a common group, and make the file's ownership reflect that.

broch wrote:

how you distingusish between user and sudo (root) commands? All is dumped in user bash_history.

User commands end up in .bash_history. sudo commands end up in syslog. How to distinguish them? sudo commands are prefixed by the word "sudo".

broch wrote:

sudo is good for ubuntu newbies.

Ubuntu can under some circumstances be considered a distribution targeted at "newbies", but they certainly got the idea of least-priveledge security right. Other distributions like Fedora should follow their example, but since I'm not involved in those communities other than as a lurker, the question becomes:

Does Arch need a sudo as a default? I'd say no. Mostly because one of the things I value in arch is that it "gets out of the way" and assumes I'm competent enough to figure out how I want to configure (and secure) my own system.

broch · 2006-11-25 06:36:44

I am talking about different limitations:
try to run make clean && make mrproper on /usr/src/linux
at some point you will get access denied, not because user is not granted access to specific file, but because two instances are trying to get and modify it.
this is a consequence of understanding this:
[quore]if operation is being executed by your shell, not by you/sudo, you don't have permissions to edit the file[/quote]

as a whole problem, not two as you suggest

I don't see a point co complicate my life and writing scripts for each command sudo can't directly deal with. su is easier.

5 min? well if you left and left box open 5 min is enough.

Personally I don't think that sudo adds any extra security (this summer freespire problems with incorrectly configured sudoers only point that in fact sudo is not that easy to configure or that it is easy to make mistakes).

ubuntu and security? nope they have word readable root (sudo) passwords in their past for pretty long time (so one could get sudo password from installation log) this points to really bad auditing.
besides, security is difficult at the server level, hardened kernel, hardened jails and services.
but this (ubuntu PR/security) is another tread not related to Arch.

ravisghosh · 2006-11-26 20:47:26

So what about installing a proper intrusion (trojan, virus, spyware, etc.) detection system. Tripware and like are not reliable if you install them some time after installation. Do we have any better option??????????

Kenetixx · 2006-11-26 23:02:29

If you want really good security buy a Firebox
The best you can get IMO , but a bit ppricey aswell

RobF · 2006-11-27 05:02:57

Here are some tips on how you can make your Linux system more secure that I've been following for a while. Implementing them doesn't require much effort. I haven't gone through all the posts in this thread as yet; hence quite a bit of what I'm suggesting may duplicate what has been said here before.

1. Don't log in unnecessarily as root. Also, rather than opening a shell with su + password, it might be preferable to run sudo.

2. Use secure passwords, e.g. those generated from the first letters of a phrase that's meaningful to you and that includes alphanumeric characters as well as special symbols, e.g. "Joe lives on 147 Huron Avenue & likes Sun Crisp apples" -> Jlo147HA&lSCa. Then check your passwords with John the Ripper. It's highly improbable that it would be able to crack a password such as the one above. Don't put your passwords on a sticky that you then tag to your computer or put anywhere else in a non-secure location!

3. Put a double firewall between your machine and the Internet, e.g. by using a NAT router and a software firewall. If you're using a broadband connection, putting your host behind a NAT router gives you the best bang for the buck in increasing system security. Adequate NAT routers such as the D-link DI-524 or its Linksys or Netgear equivalents can be had for US$30.

As to a software firewall, install iptables and a good iptables configuration script. I recently looked into what's available in OSS and settled on Arno's firewall (arno-iptables-firewall from http://rocky.molphys.leidenuniv.nl) which is the most popular and one of the most highly rated firewall scripts on freshmeat.net and which is fairly easy to configure. Shorewall is also quite good. Among the iptables config utilities with GUI Firestarter is good.

4. Frequently check for recent security patches that have been issued for the software installed on your system. With Arch, I suppose, frequent upgrades (pacman -Syu) will take care of much of that.

5. Scan your system with nmap from a remote host to check which ports are open, and then disable all services that are not absolutely necessary. The default install of Arch appears to be quite frugal; it activates no system services that are not essential.

6. Install and regularly run the following security software: a. rootkit probes such as Rootkit Hunter (rkhunter) and chkrootkit (get the most recent versions of these from their websites), b. an intrusion detection system such as Samhain or Snort. An antivirus program such as clamav may not really be necessary; I believe it mostly scans for Windows viruses/worms/trojans in Windows files that you may have on your Linux system.

7. Install and run Bastille. It probes your system for vulnerabilities and based on that makes recommendations on how you can harden it. I must say though that I've run it on different Linux installs and always chose not to follow any of its recommendations (I don't remember why; possibly I was simply too lazy or too ignorant then).

8. Regularly monitor the health of your system with: a. top or htop or Process Table (CTRL-ESC), b. lsof or glsof, c. netstat and ntop, etc.

9. Be alert to security hazards that are OS-independent, e.g. phishing, pharming, DNS poisoning etc.

10. Specific security measures that should be implemented for wireless networking:
a. Encrypt your wireless traffic with at least 128-bit WEP encryption, or better still with WPA.
b. Turn off broadcasting your access point essid.
c. Implement MAC address filtering.
d. Periodically check the router logs for funny business.

Robert

japetto · 2006-11-27 14:22:14

Nice post RobF, I concur. Perhaps you can wikify your post?

The security section of archwiki is a bit weak ATM...

http://wiki.archlinux.org/index.php/Cat … English%29

broch · 2006-11-27 14:55:24

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)

obviously kismet and airsnort require turning on monitoring on your wireless (usually off), so you will have to re-compile wireless driver.

4) if on wireless simply use sniffer to scan periodically your network for uninvited guests and monitor log files

To answer question about tripware:
you can install it of course, however this is not really workstation tool. Simply be sure what you are installing.

If you are paranoid about security, then it requires planning and consequence.
this means that before you install anything (starting with OS) on your hard drive, you need to know what steps you are going to take. At the end someone smart and persistent still can break into your box.

The point is that you have to know what is real security measure and what is not (see wireless example), what will help you secure your box and what will not really.

Personally I never used tripware on workstation.
this is what I do (laptop)
1) close all ports
2) install firewall
3) harden kernel
4) install kismet/airsnort (if wireless), rkhunter
5) always install software from trusted sources
6) read about security holes and update system
7) if using remote desktop, then limited to ssh (secured) running only when needed
8) use vpn or WPA (if possible)
8) try to be sane

Know what is real security and what is not. Obviously there is no way to be 100% secure.

PJ · 2006-11-27 17:00:35

broch wrote:

Personally I never used tripware on workstation.
this is what I do (laptop)
1) close all ports
2) install firewall
3) harden kernel
4) install kismet/airsnort (if wireless), rkhunter
5) always install software from trusted sources
6) read about security holes and update system
7) if using remote desktop, then limited to ssh (secured) running only when needed
8) use vpn or WPA (if possible)
8) try to be sane

Another thing would be to use encryption on files/filesystems that contain sensitive/secret information, just in case the laptops get stolen or something similar.

broch wrote:

Know what is real security and what is not. Obviously there is no way to be 100% secure.

The closest thing would probably be to put the computer inside a safe without a power connection and a network connection, but that wouldn't be that useful.

Arch Linux

#1 2006-11-23 22:06:57

A Guide To Secure Arch

#2 2006-11-24 01:58:32

Re: A Guide To Secure Arch

#3 2006-11-24 02:11:43

Re: A Guide To Secure Arch

#4 2006-11-24 03:09:06

Re: A Guide To Secure Arch

#5 2006-11-24 03:12:16

Re: A Guide To Secure Arch

#6 2006-11-24 03:35:38

Re: A Guide To Secure Arch

#7 2006-11-24 05:33:27

Re: A Guide To Secure Arch

#8 2006-11-24 06:18:28

Re: A Guide To Secure Arch

#9 2006-11-24 06:23:44

Re: A Guide To Secure Arch

#10 2006-11-24 06:36:01

Re: A Guide To Secure Arch

#11 2006-11-24 08:57:34

Re: A Guide To Secure Arch

#12 2006-11-24 21:29:12

Re: A Guide To Secure Arch

#13 2006-11-25 01:36:29

Re: A Guide To Secure Arch

#14 2006-11-25 02:21:29

Re: A Guide To Secure Arch

#15 2006-11-25 02:56:12

Re: A Guide To Secure Arch

#16 2006-11-25 02:58:32

Re: A Guide To Secure Arch

#17 2006-11-25 04:30:33

Re: A Guide To Secure Arch

#18 2006-11-25 05:47:22

Re: A Guide To Secure Arch

#19 2006-11-25 06:36:44

Re: A Guide To Secure Arch

#20 2006-11-26 20:47:26

Re: A Guide To Secure Arch

#21 2006-11-26 23:02:29

Re: A Guide To Secure Arch

#22 2006-11-27 05:02:57

Re: A Guide To Secure Arch

#23 2006-11-27 14:22:14

Re: A Guide To Secure Arch

#24 2006-11-27 14:55:24

Re: A Guide To Secure Arch

#25 2006-11-27 17:00:35

Re: A Guide To Secure Arch

Board footer