You are not logged in.
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
Offline
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)
Offline
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.
[git] | [AURpkgs] | [arch-games]
Offline
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)
Offline
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...
Offline
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)
Offline
@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.
Offline
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)
Offline
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
Offline
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.
Offline