> I think I want to do it at user-space-handler-over-netfilter level. > Reason? Suppose we have a network topology like this: > > A B C D > | | | | > +-------+---+---+-------+ > | > [firewall] > | > +-------+---+---+-------+ > | | | | > W X Y Z > > We'll suppose A, B, C and D are 'our' hosts, and W, X, Y and Z are > 'their' (untrusted) hosts. Furthermore, we know our own network well > enough to know that we can't absolutely guarantee that the user of node > 'C', a laptop plugged in on a hot desk, hasn't loaded some godawful > crap onto his machine while at home, and the user of node 'D', an > accountant who fancies himself as a spreadsheet guru, hasn't played > about with the 'web services' bits of the Excel scripting stuff. > Meantime, host 'A' is our accounts department machine, which is allowed > to send and receive billing enquiries via SOAP, and host 'B' is our > warehouse server, which is allowed to send and receive stlock level > enquiries via SOAP.
So you have already made a fundamental design error. You did not isolate A and B from C and D, network-wise. The not-really-trusted notebook can do IP address takeover games against A and B. You are f**cked. > So some types of SOAP message sent to host 'A' are valid, but all > others should be blocked; and any SOAP messages sent to 'C' and 'D' may > be blocked. So you block anything incoming to C and D, and seperate them from A's network, so they can't do IP takeover of A. This leaves you with protection of the SOAP application on A. Wouldn't that application server be the natural point where you control what type of message to accept? Why should it implement more SOAP functionality than intended? I don't see any requirement for a firewall based SOAP handling, here. (If this thread continues along these lines, it would be better to move it to the normal netfilter mailing list.) best regards Patrick
