[Vserver] $BL$>5Bz9-9p!v4{$K!"#22/!"#32/!"#52/#9@iK|(B$B1_<}F~Z(B$B5r$r3NG'$7$F2<$5$$!#(B
$B(B $B!!L$>5Bz9-9p!cG[?.l9g$O!"BgJQ62=L$G$9$,!!G[?.Dd;_$r(B
$B!!(B http://bite.to/hosyou
$B!!$K$F$*4j$$?=$7>e$2$^$9!#:FAwCW$7$^$;$s!#!!(B
$B!!(B
$B4{$K!"#22/!"#32/!"#52/[EMAIL PROTECTED]|1_<}F~\$7$/$O!!(Bhttp://bounce.to/hosyou $B$+$i(B
$B(B
$B>Z5r$r3N$+$a$F#52/[EMAIL PROTECTED]|1_:_Bp%S%C%/%S%8%M%9$X0lJb(B
$B"#%$%^!"[EMAIL
PROTECTED]|1_$,$"$C$?$i:G9b$J$N$K!"$NJ}!9!*%$%^$+$i$G$bCY$/$"$j$^$;$s(B!!
$B"##22/!"#32/!"#52/[EMAIL PROTECTED]|1_<}F~Z5r$r3NG'$9$k$^$G$O2?;v$b!V?.MQ$7$J$$!W$G2<$5$$!#(B
$B!!(B $B:[H=$OJ*E*>Z5r$,M#0l$N3N$?$kH=7h(B $B$N7h$aZ5r(,(,8+$;$^$9(,(,2?;[EMAIL PROTECTED]>Z5r(,(,""(B
$B!!El5~9bEy:[H==j$NH=7h=q!/!"#32/!"#52/[EMAIL PROTECTED]|1_<}F~$N(B
$B!!6d9T0uM-?69~$_=q!&J!;c;vL3=j$h$j$NJ]>Z>Z7t;HMQ0MMj=q!&B>(B
$B""(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,""!!(B
[EMAIL PROTECTED]&I{6H:_Bp9b3[%M%C%H<}F~L\E*$K:GE,$G$9!#(B
$B"(;[EMAIL PROTECTED](Bhttp://bounce.to/hosyou
$B$+$i$*4j$$?=$7>e$2$^$9!#(B
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] iptables
On Sat, Apr 03, 2004 at 10:58:01PM -0500, Gregory (Grisha) Trubetskoy wrote: > > Given that vserver won't allow you to use iptables, has anyone tried a > solutions where tha iptables command is replaced by a stub command that > talks to a daemon in context 0 to set up tables? > > It seems that you could create a chain (or two actually - input and > output) for every vserver, and have a rule to jumpt to those chains based > onthe vserver ip. With some clever replacing of INPUT or OUTPUT with name > of the chains for those vservers it seems you could get a 80% functional > iptables, probably enough to fool most firewall config tools (and most > users). Since that chain is only accessed for that particular IP, there > should be no way to cause any damage on the server. while the basic idea sounds very good (it crossed my mind some time ago), the devil is in the detail: - let's assume we have 'rules' to identify the target vserver - let's further assume we know from what server a packet is sent this should allow us to traverse a vINPUT and vOUTPUT table quite well, and it might even allow to do a vPREROUTING or vPOSTROUTING, but it will also open the door for packet mangling and S/DNAT, which is a security issue ... other issues are with identifying the target vserver, because what happens if two vserver share the same IP, but provide different services on different ports ... (but I guess this is a special case, just not handled here) > I was going to try to write something like this, but wanted to check > whether I might be reinventing the wheel here. it might be interesting to join the (hopefully) upcoming discussion about the next generation networking, maybe such issues can be solved by some simple tricks ... best, Herbert > Grisha > ___ > Vserver mailing list > [EMAIL PROTECTED] > http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
