On Sat, 19 Mar 2011 06:05:50 -0700 johhny_at_poland77 <johhny_at_poland77@xxxxxxxx> wrote: > Does somebody has an idea, that what kind of iptables/pf rule must i > use to achieve this?: > > i only want to allow these connections [on the output chain]: > > on port 53 output only allow udp - dns > on port 80 output only allow tcp - http > on port 443 output only allow tcp - https > on port 993 output only allow tcp - imaps > on port 465 output only allow tcp - smtps > on port 22 output only allow tcp - ssh > on port 20-21 output only allow cp - ftp > on port 989-990 output only allow tcp - ftps > on port 1194 output only allow udp - OpenVPN > > So that e.g.: OpenVPN on port 443 would be blocked, because only > HTTPS is allowed on port 443 outbound. > > Any ideas? :\ I think you should be able to do what you want using the owner feature of iptables. See man iptables, then search for the owner match module I don't do this, but it looks like you would have to create unique users for the processes you want above. Then add something like the following for each one. # ssh $IPTABLES --append OUTPUT --protocol tcp --dport 22 --syn \ --match owner --uid-owner <your assigned owner name uid here> \ --match conntrack --ctstate NEW --jump ACCEPT The uid will be in the /etc/passwd file for the owner name you created. If the process already runs under its own UID, you would just have to use that one. You could also use gid for the same purpose, and it would be in /etc/group. You would need to default to REJECT or DROP. And the above assumes you have an explicit rule for accepting all ESTABLISHED,RELATED ctstate packets somewhere in the OUTPUT chain, so only has NEW as part of the ctstate in the rule and --syn as flag. That way only ssh can create outbound connections on port 22, but once the link is established, the packet is accepted. I guess it depends on how paranoid you are. Is someone internal capable of and going to hijack the open port once it is established? If you fear that, create another rule without the --syn and NEW, but having ctstate ESTABLISHED,RELATED and no default rule for accepting ESTABLISHED,RELATED packets. A lot of work to set up, and has to be repeated for every user id you want to have outbound connections. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines