[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [SPAM] Re: [Xen-users] Re: number of ips
Like I said before, Xen doesn't add DROP rules by default, only ACCEPT (so you need to set policy to DROP. Tho, it does seem like seting antispoof=on should take care of setting policy to DROP on at least Debian. Maybe your firewall script starts after Xen takes care of networking? I have never used Xen on CentOS, so I'm not too sure about it's specific details). Regarding the fact that there is no IP specifed on the ACCEPT rule, what does your iptables commands in the vif script look like? Oh, and I assume you want to remove state match from the first rule (otherwise the virtual servers will not allow any new connections) & remove the second rule (allows all traffic orginating from 192.168.122.0/24. If there is no other match requirements, it will allow DomUs to spoof addresses from 192.168.122.0/24). The third FORWARD rule seems like everything gets ACCEPT'ed there. Also, please use iptables-save, iptables -L doesn't include all of the details (like -i and -o). So, to wrap it up, the iptables-save should look something like: *filter ... :FORWARD DROP [0:0] ...-A FORWARD -d 192.168.122.0/24 -j ACCEPT #Tho, this allows spoofing between two DomUs. You could try adding -m physdev --physdev-in eth0 or whatever your external interface is ... And once you start, there should be one more rule on FORWARD chain-A FORWARD -s 192.168.122.5/32 -m physdev --physdev-in vif6.0 -j ACCEPT #or whatever the IP and vif happend to be -Eljas AlakulppiOn Sat, 11 Apr 2009 14:47:45 +0300, Anand Gupta <xen.mails@xxxxxxxxx> wrote: I tried to use the antispoof feature thinking it should do the trick. Modified /etc/xen/xend-config.sxp and modified it as follows: (network-script 'network-bridge antispoof=yes')Restarted, xen, and then checked the iptables --list. I don't see the DROPrules added. Here is iptables before start of domU **************************************************************************************************************** Chain INPUT (policy ACCEPT) target prot opt source destinationACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT udp -- anywhere anywhere udp dpt:bootps ACCEPT tcp -- anywhere anywhere tcp dpt:bootpsChain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere 192.168.122.0/24 state RELATED,ESTABLISHED ACCEPT all -- 192.168.122.0/24 anywhere ACCEPT all -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-port-unreachable REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain OUTPUT (policy ACCEPT) target prot opt source destination **************************************************************************************************************** Here it is after domU was started **************************************************************************************************************** Chain INPUT (policy ACCEPT) target prot opt source destinationACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT udp -- anywhere anywhere udp dpt:bootps ACCEPT tcp -- anywhere anywhere tcp dpt:bootpsChain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere 192.168.122.0/24 state RELATED,ESTABLISHED ACCEPT all -- 192.168.122.0/24 anywhere ACCEPT all -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-port-unreachable REJECT all -- anywhere anywhere reject-with icmp-port-unreachableACCEPT all -- anywhere anywhere PHYSDEV match--physdev-in vif6.0 Chain OUTPUT (policy ACCEPT) target prot opt source destination **************************************************************************************************************** The only difference between both the outputs isACCEPT all -- anywhere anywhere PHYSDEV match--physdev-in vif6.0 Any ideas why this is happening ?P.S. : If i am wrong in thinking that the above will resolve the problem ofusers binding ips of their domU and using them, please correct me. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |