In response to Kevin Hunter <[EMAIL PROTECTED]>: > At 2:42p -0400 18 Apr 2007, Bill Moran wrote: > >> We are in the process of setting up a bastion host. One of the > >> things we'd like to do is to filter packets not only at the ip > >> layer, but by what program is listening on a particular port. Is > >> this a possibility? > > > > Are you saying that you want to have the packet filter check to see > > what application is listening on a particular port, then allow/deny > > access based on the name of the application? > > Exactly. > > > Do you not have control over what is run on this system? > > So perhaps our specific example might be prudent: > > kevin $: ssh bastion > bastion $: ssh internalserver > <hang> > > Relevant part of log: > > Apr 18 09:35:23 kappia ipmon[405]: 09:35:22.695348 fxp0 \ > @0:4 b internalserver,22 -> bastion,53136 PR tcp \ > len 20 52 -AS IN > > It's blocking because we are dropping all packets not destined for > port 22. Since ssh /from/ the bastion picks a random high port, it's > dropping all the return packets to that random high port.
Your packet filter rules are wrong. Without knowing what product you're using, I can't say the exact way to fix it, but the generally rule is that you either need to write stateful rules (so that the initial connection creates a state that is then used to allow traffic in both directions) or you need to create two rules -- one to allow traffic out, the other to allow traffic in. Stateful filtering is generally considered to be more secure, but you then have concerns about properly maintaining state tables, which can be a problem on very busy servers. However, the problem you're describing now seems to be a completely different problem from the one described in the previous email. It's possible that I've misunderstood both of them. > How have others handled this type of scenario, where a hardening of a > bastion host has been desired/necessary? Again (unless I'm misunderstanding) through properly written filter rules. The current trend seems to be toward using stateful filtering. > > However, you might be able to accomplish this by using a pf table, > > then having a secondary script update the table based on the output > > of sockstat or some other similar hack. > > We did not know about this utility. We'll check out your idea. > Thank you for the pointer. We'll let the list know how it > goes. :-) (Of course, if there's a standard, cut and dry solution, > that'd be ideal!) -- Bill Moran http://www.potentialtech.com _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
