Quote:
Originally Posted by DBabo
my simple and Q&D script all of the sudden became a big and comprehensive one. ha-ha 
Thank you overy much for detailed explanation and putting the script together.
I have 2 questions :
Code:
$IPT -A OUTPUT -p TCP -o eth0 -m multiport --dports 21,80,443 \
-d ! $LAN -m state --state NEW -j ACCEPT
$IPT -A OUTPUT -p UDP -o eth0 -m multiport --dports 53,123 \
-d ! $LAN -m state --state NEW -j ACCEPT
$IPT -A OUTPUT -m owner --uid-owner dbabo \
-m state --state NEW -j ACCEPT
$IPT -A OUTPUT -m owner --uid-owner root \
-m state --state NEW -j ACCEPT
i read this : "if this is a LAN - don't allow outbound on specified ports. But allow for users dbabo or root even if it's on spec LAN and ports."
Now, should i read it:
"if this is a LAN - don't allow outbound on specified ports. But allow for all other ports/protocols if user is dbabo or root.
Or it is:
"if this is a LAN - don't allow outbound on specified ports. Allow for all other ports/protocols if user is dbabo or root" |
Yeah, sort of. Those four rules say (in the context of the script): "
Allow any outgoing FTP, HTTP, HTTPS, DNS, and NTP connections - as long as their destination is NOT the LAN. Allow absolutely any outgoing connections for users dbabo and root." The LAN limitation is there so that a user with evil intentions won't be able to attack your LAN - it also prevents a worm (Apache-based, for example) from propagating in your LAN, etc.
Quote:
Another question is :
say if the server has many users. Say, it's part in an company. Then what options does sys/security admin have to minimize the amount of work ( let's say we have more than 1 server that has ssh ) keeping security tight?
|
It depends. How many users? Let's say for arguments sake that you have 75 users on the server which need to have SSH access to IP 192.168.1.233 on the LAN. Instead of writing 75 iptables rules each with a different username, you could simply write one and have a substitution occur for the usernames. Like, you could have a text file with a list of the usernames and the iptables script can be told to execute the rule once for each of those usernames. Something like:
Code:
SSH_USERS=`cat /etc/ssh_users.txt`
for i in $SSH_USERS; do
$IPT -A OUTPUT -p TCP -o eth0 -d 192.168.1.233 --dport 22 \
-m owner --uid-owner $i -m state --state NEW -j ACCEPT
done
So if your
/etc/ssh_users.txt file has all the SSH users listed, one per line, like:
Code:
sally
mario
susan
christian
jamie
john
tux
lisa
Etc... then the effect will be that each of them will get their own rule executed. That said, it's a balancing act. Some people would indeed be happy enough with one rule allowing SSH access to the required IPs for anybody, like:
Code:
$IPT -A OUTPUT -p TCP -o eth0 -d 192.168.1.233 --dport 22 \
-m state --state NEW -j ACCEPT
Any rogue users which try to connect would still need to deal with the SSH authentication, so it's not like they are getting a free pass. You could even take an inverse approach by blacklisting certain users, like:
Code:
$IPT -A OUTPUT -p TCP -o eth0 -d 192.168.1.233 --dport 22 \
-m owner --uid-owner apache -m state --state NEW -j REJECT
$IPT -A OUTPUT -p TCP -o eth0 -d 192.168.1.233 --dport 22 \
-m owner --uid-owner susan -m state --state NEW -j REJECT
$IPT -A OUTPUT -p TCP -o eth0 -d 192.168.1.233 --dport 22 \
-m state --state NEW -j ACCEPT
In that example, everyone would be able to SSH to 192.168.1.233 - except apache and susan.
If by "keeping security tight" you meant something more general, then the answer would still be "it depends". There's tons of aspects one needs to cover in order to keep things tight (iptables is just a small part of the picture). I don't know of a tool that will let you take care of every aspect in a super-friendly and centralized way if that's what you mean. Have you checked-out
unSpawn's famous
Security references thread?
EDIT: Added a blacklist example at the end. Fixed $SSH_USERS variable assignment error in the username list example. The file obviously needs to be cat-ed for the contents to be used instead of the file name/path itself - my bad.
