Re: program/binary ip filtering
Hey Bill, Tnx much for the input. I'm the new lead sys admin here. Been away from freebsd for far too long. It's good to be back. ; On Wed, 18 Apr 2007, Bill Moran spaketh thusly: -} -}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 That's what we currently have set up. -}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. Oh? Why is stateful considered more secure? Anybody have links to good reading on this? I've been through the links in the handbook. Tho' I could have missed something, I didn't see anything on why stateful is more secure than in/out. -- Randy([EMAIL PROTECTED]) 725.983.1283 * Rain puts a hole in stone because of its constancy, not its force. - H. Joseph Gerber ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
program/binary ip filtering
Hi All, This may not be the correct list to ask this question, so please point me in the right direction in that case. 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? A quick 5 minute Google didn't provide me with anything noticeable, but that my just be my noobness in the *BSD world. So play nice! ;-) Thanks for any suggestions! Kevin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: program/binary ip filtering
In response to Kevin Hunter [EMAIL PROTECTED]: This may not be the correct list to ask this question, so please point me in the right direction in that case. 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? A quick 5 minute Google didn't provide me with anything noticeable, but that my just be my noobness in the *BSD world. So play nice! ;-) 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? Do you not have control over what is run on this system? 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. -- 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]
Re: program/binary ip filtering
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. How have others handled this type of scenario, where a hardening of a bastion host has been desired/necessary? 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!) Thanks Bill, Kevin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: program/binary ip filtering
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]
Re: program/binary ip filtering
On Apr 18, 2007, at 12:17 PM, Kevin Hunter wrote: 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. You should consider just how difficult it is to rename a malicious program to, say, ssh in order to get around such checking. (Answer: trivial.) If you really want to control traffic in this fashion, you should look towards what the industry calls deep packet inspection or mandatory usage of proxies for all permitted protocols, instead. 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. How have others handled this type of scenario, where a hardening of a bastion host has been desired/necessary? The main approaches are to use a stateful firewall ruleset, to explicitly permit return traffic via additional rules, or to simply permit established connections through. These options are arranged in rough order of how secure they are. I suspect that you are encountering a steep learning curve, and that some additional reading will help you make much better decisions about how to configure a firewall. Consider getting either or both of: Building Internet Firewalls, ISBN-10: 1565928717 http://www.oreilly.com/catalog/fire2/ Firewalls and Internet Security: Repelling the Wily Hacker, ISBN-10: 020163466X http://www.aw-bc.com/catalog/academic/product/0,1144,020163466X,00.html Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: program/binary ip filtering
At 3:46p -0400 18 Apr 2007, Chuck Swiger wrote: On Apr 18, 2007, at 12:17 PM, Kevin Hunter wrote: At 2:42p -0400 18 Apr 2007, Bill Moran wrote: 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. You should consider just how difficult it is to rename a malicious program to, say, ssh in order to get around such checking. (Answer: trivial.) If you really want to control traffic in this fashion, you should look towards what the industry calls deep packet inspection or mandatory usage of proxies for all permitted protocols, instead. Hrm. I was assuming that if I got into the nitty gritty, I could do more than just check the name of the binary, but perhaps not? Thanks for the warning. Do you not have control over what is run on this system? So perhaps our specific example might be prudent: [snip] 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. How have others handled this type of scenario, where a hardening of a bastion host has been desired/necessary? The main approaches are to use a stateful firewall ruleset, to explicitly permit return traffic via additional rules, or to simply permit established connections through. These options are arranged in rough order of how secure they are. I have been given to understand that this approach does not lend itself to fine-tuning down the road, if such -- for /some/ reason -- were needed. . . .? I suspect that you are encountering a steep learning curve, You are /probably/ (read: definitely) correct. I am. :-) and that some additional reading will help you make much better decisions about how to configure a firewall. Consider getting either or both of: Building Internet Firewalls, ISBN-10: 1565928717 http://www.oreilly.com/catalog/fire2/ Firewalls and Internet Security: Repelling the Wily Hacker, ISBN-10: 020163466X http://www.aw-bc.com/catalog/academic/product/0,1144,020163466X, 00.html Will look into those. Thank you again. Kevin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
