Post Your (linux)Workstation and/or Server Security Practices

Sjoden · 2008-06-17 18:47:02

I'm very interested in hearing other archers security practices/guidelines/policies. It would be a great learning exercise, and probably benefit the community as a whole. Anything from different A/V, rootkit detection, firewalls, iptables rules, etc.

Zack

Sjoden · 2008-06-17 18:50:00

For me, I'm always behind a physical firewall, either our Secure Computing firewall here at work, or my router at home. I have firefox prompt me whenever a website tries to set a cookie. Then I can Accept, Accept for Session, or Decline, very useful. Then, I have a simple iptables firewall, maybe someone could help me out a bit and give me some tips to make it better.

-A INPUT -p icmp -m icmp --icmp-type 18 -j DROP 
-A INPUT -p icmp -m icmp --icmp-type 17 -j DROP 
-A INPUT -p icmp -m icmp --icmp-type 10 -j DROP 
-A INPUT -p icmp -m icmp --icmp-type 9 -j DROP 
-A INPUT -p icmp -m icmp --icmp-type 5 -j DROP 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -j interfaces 
-A INPUT -j open 
-A INPUT -p tcp -j REJECT --reject-with tcp-reset 
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable 
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP 
-A INPUT -f -j DROP 
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP 
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP

Zack

edit

For some reason, my rule that says

-A interfaces -i lo -j ACCEPT

isn't showing up...

And

iptables -L interfaces

shows

Chain interfaces (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere

Maybe someone could help me, cause I know I'm not accepting everything, that rule should only apply to the loopback interface...

Last edited by Sjoden (2008-06-17 18:53:31)

Daenyth · 2008-06-17 19:48:35

I generally lock sshd to PermitRootLogin No, and Allowgroup sshusers. That way brute force attemps usually can't get into anything. Changing the port would help too, but i don't bother usually.

sniffles · 2008-06-17 20:30:57

Sjoden wrote:

Maybe someone could help me, cause I know I'm not accepting everything, that rule should only apply to the loopback interface...

iptables -L -v

(man iptables FTW !)

Last edited by sniffles (2008-06-17 20:31:50)

Sjoden · 2008-06-17 20:35:44

@sniffles, thanks! So I don't actually have an insecure iptables rule set?

Bebo · 2008-06-17 23:47:25

IMHO, that iptables ruleset looks a bit, uhm, odd. What policy do you have on the INPUT chain? It looks like you only DROP very specific things, and that's not how I'd do it. One of the absolutely simplest rulesets is something like

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i ! lo -m state --state ESTABLISHED,RELATED -j ACCEPT

This ruleset works well if you don't want to have anything accessible from the outside. If you want be able to use for instance ssh, just add a line like

iptables -A INPUT -i ! lo -p tcp --syn -m state --state NEW --dport 22 -j ACCEPT

the --syn meaning exactly --tcp-flags SYN,RST,ACK,FIN SYN.

This was just a very simple example, but IMO it's best to have a DROP policy on the INPUT chain and then add ACCEPT (or other) rules for stuff you want to treat differently.

Anyway, (other) things I usually do... Hm, for instance I never run services on their assigned ports, but that's because I only want me or a very limited number of people to reach my box. What I do is that I (let's take ssh as an exampe) add a port forwarding rule on my router, that forwards a nonstandard port to port 22 on a box on my LAN. That way I run the standard ports on my LAN, but from the outside nothing is where it is supposed to be. I usually choose (very) high ports for those services. A simple default (port-wise) nmap scan from the outside would not detect those services.

Continuing on ssh, I disable protocol 1 completely ("Protocol 2", instead of "Protocol 1,2"), disable root logins, and if I'm feeling picky (or if I haven't specified in iptables what IPs are allowed to access ssh) only allow key authentication. Also, like Daenyth, I like to restrict the ssh access to a specific group of users.

Back to the firewall, sometimes I restrict services to bind to localhost or to my computer's LAN IP address, but occasionaly I feel lazy and skip that IP binding. Instead I let the firewall take care of what is allowed and not. This filtering in iptables also makes a full host scan not show anything at all for hosts not allowed to gain access.

For my web server, I've specified a number of virtual hosts, most of them only accessible from the LAN or from localhost. When it comes to a completely public web server/virtual host I'm a bit at a loss as how to make it as secure as possible. Disabling as much as possible may be a good idea, but will probably not work in some (most?) cases, using mod_security is probably good (I have no idea, really), but chrooting is probably the best idea. ...which I haven't done, ergo my web server is not publicly accessible...

Sjoden · 2008-06-18 00:02:46

INPUT and FORWARD are set to DROP.

[root@boxxy zack]# iptables -L -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       icmp --  any    any     anywhere             anywhere            icmp address-mask-reply 
    0     0 DROP       icmp --  any    any     anywhere             anywhere            icmp address-mask-request 
    0     0 DROP       icmp --  any    any     anywhere             anywhere            icmp router-solicitation 
    0     0 DROP       icmp --  any    any     anywhere             anywhere            icmp router-advertisement 
    0     0 DROP       icmp --  any    any     anywhere             anywhere            icmp redirect 
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere            
62714   45M ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED 
22606 2426K interfaces  all  --  any    any     anywhere             anywhere            
22598 2426K open       all  --  any    any     anywhere             anywhere            
   75  3600 REJECT     tcp  --  any    any     anywhere             anywhere            reject-with tcp-reset 
22523 2422K REJECT     udp  --  any    any     anywhere             anywhere            reject-with icmp-port-unreachable 
    0     0 DROP       tcp  --  any    any     anywhere             anywhere            tcp flags:!FIN,SYN,RST,ACK/SYN state NEW 
    0     0 DROP       all  -f  any    any     anywhere             anywhere            
    0     0 DROP       tcp  --  any    any     anywhere             anywhere            tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG 
    0     0 DROP       tcp  --  any    any     anywhere             anywhere            tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 51187 packets, 6877K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain interfaces (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    8   528 ACCEPT     all  --  lo     any     anywhere             anywhere            

Chain open (1 references)
 pkts bytes target     prot opt in     out     source               destination         
[root@boxxy zack]#

I got most, I think all of that from http://wiki.archlinux.org/index.php/Sim … wall_HOWTO

Last edited by Sjoden (2008-06-18 00:05:23)

sniffles · 2008-06-18 07:43:11

Sjoden wrote:

@sniffles, thanks! So I don't actually have an insecure iptables rule set?

Uhh.. yeah.. sure.. if you say so

Anyway, when it comes to securing your computer I am of the opinion that simply visiting some web pages and copy/pasting some scripts to set up iptables is not a good thing. First of all, the user probably has no idea what those scripts -actually- do. Those scripts are also not tweaked for your computing needs. Another bad side: the action of copy/pasting and running those scripts provides the user with a false sense of security. Better to be out in the open and -know it- than to think/assume you're safe.

Sure, read scripts, how-tos and tutorials. But make sure you understand them, read the appropriate man pages. Eventually find a good book on the subject. Write -your own- scripts build for -your- needs.

Would you now blindly follow a how-to named "Installing a desktop environment on Linux" which teaches you, step by step (or eventually provides a script) to (for example) download GNOME related sources and install GNOME (without the use of Pacman, etc.) ? Probably not, because you know better than that.

But when it comes to security, blindly accepting instructions (which is a bad security practise in itself) is no problem for some users.

Bebo · 2008-06-18 10:45:49

Sjoden wrote:

INPUT and FORWARD are set to DROP.

Okay, in that case you don't need the last four DROP rules, the ones after your rules for other targets (ACCEPT, interface, open, REJECT). iptables uses a "use first match" method (I guess that's why the chains are called chains...), so if something matches a rule that has a terminating target (for instance ACCEPT, DROP or REJECT) no rules after the matching rule is evaluated for the packet. If no rules in a chain match a packet, then the policy is carried out. Chains with no policies (user-defined chains for instance) return to the calling chain if no rule in the chain matches. That's what you're using in the open and interfaces chains - your "open" chain is empty, so that will just return and the rule matching will continue in the INPUT chain. Following this, you might want to move your "-f" rule up in the chain, where it actually is of any use

Last edited by Bebo (2008-06-18 10:46:13)

arch0r · 2008-06-18 18:30:29

browsing with opera + good ulfilter.ini list + master password for the magic wand
http://nopaste.info/1643e46164.html

+ connecting through privoxy + blocklist ^^
http://www.neilvandyke.org/privoxy-rule … yke.action

+ iptables firewall
http://wiki.archlinux.de/?title=Firewall

+ all passwords are stored in the KDEwallet
+ encrypted external drive

foxbunny · 2008-06-27 10:29:02

Passwordless SSH login allowed only for an unprivileged user with a _very_ weird username. The RSA public key is used to log in, so brute force is quite impossible.

Also a physical firewall to guard the whole LAN allowing exactly no traffic initiated by remote hosts (except SSH, of course). I'm also planning to replace SSH with a mcabber Jabber client or a jabber bot to use as a remote control (with a dedicated account I'd use to control it, that no one knows of). That's because I'm not using SSH to my LAN form the Internet (because the proxy at work doesn't allow ssh). Very strong passwords everywhere (minimum 40 characters).

Separate rules for gateway -> wan, and lan -> wan, and default REJECT policy, so I know exactly what goes out (hopefully). I use shorewall, which I will 'fix' as soon as I have time to learn iptables.

Arch Linux

#1 2008-06-17 18:47:02

Post Your (linux)Workstation and/or Server Security Practices

#2 2008-06-17 18:50:00

Re: Post Your (linux)Workstation and/or Server Security Practices

#3 2008-06-17 19:48:35

Re: Post Your (linux)Workstation and/or Server Security Practices

#4 2008-06-17 20:30:57

Re: Post Your (linux)Workstation and/or Server Security Practices

#5 2008-06-17 20:35:44

Re: Post Your (linux)Workstation and/or Server Security Practices

#6 2008-06-17 23:47:25

Re: Post Your (linux)Workstation and/or Server Security Practices

#7 2008-06-18 00:02:46

Re: Post Your (linux)Workstation and/or Server Security Practices

#8 2008-06-18 07:43:11

Re: Post Your (linux)Workstation and/or Server Security Practices

#9 2008-06-18 10:45:49

Re: Post Your (linux)Workstation and/or Server Security Practices

#10 2008-06-18 18:30:29

Re: Post Your (linux)Workstation and/or Server Security Practices

#11 2008-06-27 10:29:02

Re: Post Your (linux)Workstation and/or Server Security Practices

Board footer