Re: macros and anchors
On Sun, 30 Jan 2005 07:40:30 -0300, Fernando Braga [EMAIL PROTECTED] wrote: On Sat, 29 Jan 2005 13:06:00 -0500, solarflux.org/pf [EMAIL PROTECTED] wrote: Peter Huncar wrote: Is there any way to manage macros across rulesets? Sure. Just figure out how to write a little script to find and replace the targeted macro(s) across multiple files. This could be accomplished with a include directive, which is not supported by pfctl nowadays. s/pfctl/authpf/ sorry
Re: macros and anchors
On Saturday 29 January 2005 12:52, Peter Huncar wrote: Hi Is there any way to manage macros across rulesets? Because if you use the same macros in the main ruleset and in some rulesets which will be loaded into anchor points, you have to change multiple files And if you want to change any macro used, you have to change it in every ruleset where the macro is used. $cat /etc/pf.macros rules.conf | pfctl -f- Also pfctl(8)'s -D switch is helpful in some cases. :) I spent an hour searching why my rule isn't working :) . Thank you a lot. Great job you're doing. Hunci -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpcQLWrrHX0x.pgp Description: PGP signature
Re: macros and anchors
On 07:40, Sun 30 Jan 05, Fernando Braga wrote: On Sat, 29 Jan 2005 13:06:00 -0500, solarflux.org/pf [EMAIL PROTECTED] wrote: Peter Huncar wrote: Is there any way to manage macros across rulesets? Sure. Just figure out how to write a little script to find and replace the targeted macro(s) across multiple files. This could be accomplished with a include directive, which is not supported by pfctl nowadays. But I don't know what Daniel and Henning think of it. Like Daniel posted on Friday 28: http://www.benzedrine.cx/pf-include.diff Have fun. -- Michiel van Baak http://lunteren.vanbaak.info [EMAIL PROTECTED] GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x7E0B9A2D Two of the most famous products of Berkeley are LSD and BSD. I don't think that this is a coincidence.
Re: PF Question: auth (port 113) one to many rdr (moved from newbies list)
Kevin wrote: I do not think this is technically possible without extensive effort, nor desirable. The 'ident' (auth, tap, TCP/113) protocol is no longer very useful for the original purpose, but it is still required by IRC servers. Many systems and firewalls, including OpenBSD (via the '-H' flag), offer an identd work-alike which will provide a reasonable answer to any and all ident queries. Why not just go into /etc/inetd.conf and change the arguments on identd from '-el' to '-elH'. This will cause identd to always return an answer for *any* ident query, valid or invalid. Okay. I've enabled this (-elH) and restarted inetd on my firewall and have changed the rule to: pass in log on fxp0 proto tcp from any to any port = auth Now, is there a way I can test it myself to see what's being returned? The IRC server to which I'm trying to connect still says no response.I checked my firewall log and see that it's getting blocked on the way out: Jan 30 15:21:16.438720 rule 0/0(match): block out on fxp0: 24.174.112.98.113 66.198.160.2.1928: S 3654633913:3654633913(0) ack 830143768 win 16384 mss 1460,nop,wscale 0,[|tcp] (DF) === A, while composing this email I figured it out. My rule was: pass out $log_flg on $ext_if proto tcp all modulate state flags S/SA So, it was being blocked on the way out. I changed it to: pass out $log_flg on $ext_if proto tcp all modulate state And now it works. Thanks for helping me realize what was going on. However, I still wish I knew how to see the request from the IRC server and the response from identd. Is there a way? Furthermore, how vulnerable does it make me by not forcing the SYN flag to be set? rvb
Re: PF Question: auth (port 113) one to many rdr (moved from newbies list)
On Sat, 29 Jan 2005 09:56:56 -0600, Rick Barter [EMAIL PROTECTED] wrote: I have been racking my brain and reading, but can't figure out how to setup pf to pass or rdr ident requests to the the proper client (behind the firewall) that is trying to connect to an irc server. I want to rdr the auth (port 113) request coming into my firewall to whichever machine is trying to connect to an irc server. How can I do this? I do not think this is technically possible without extensive effort, nor desirable. The 'ident' (auth, tap, TCP/113) protocol is no longer very useful for the original purpose, but it is still required by IRC servers. Many systems and firewalls, including OpenBSD (via the '-H' flag), offer an identd work-alike which will provide a reasonable answer to any and all ident queries. Currently I have a rdr rule that handles the ident requests by passing them to my windows machine running mIRC. mIRC has built-in ident emulator and works fine. I've tried to setup an ident server on my firewall that will handle all ident requests. I enabled identd in /etc/rc.conf and disabled the one running from /etc/inetd, but with no joy. Why not just go into /etc/inetd.conf and change the arguments on identd from '-el' to '-elH'. This will cause identd to always return an answer for *any* ident query, valid or invalid. What am I missing here? Does anyone have such a setup working? Technically, it should be *possible* to create an identd service running on a NAT gateway which would answer ident queries by looking up the internal originating IP address and returning an ident token corresponding to the actual source IP address, providing better forensics info than just making up a random reply. The primary drawback in implementing the above would be the requirement for the identd server to run as a privileged user in order to have access to the /dev/pf (root only) device to perform DIOCNATLOOK ioctl calls In reality, the ident protocols is no longer used or trusted to provide valid and useful responses, and exists solely as an added check done by IRC servers (of limited value, IMHO) in their fight against compromised bots and open proxies. Kevin Kadow
Re: PF Question: auth (port 113) one to many rdr (moved from newbies list)
On Sun, 30 Jan 2005 15:41:41 -0600, Rick Barter [EMAIL PROTECTED] wrote: Kevin wrote: I do not think this is technically possible without extensive effort, nor desirable. The 'ident' (auth, tap, TCP/113) protocol is no longer very useful for the original purpose, but it is still required by IRC servers. Many systems and firewalls, including OpenBSD (via the '-H' flag), offer an identd work-alike which will provide a reasonable answer to any and all ident queries. Why not just go into /etc/inetd.conf and change the arguments on identd from '-el' to '-elH'. This will cause identd to always return an answer for *any* ident query, valid or invalid. Okay. I've enabled this (-elH) and restarted inetd on my firewall and have changed the rule to: pass in log on fxp0 proto tcp from any to any port = auth Off the cuff, I'd suggest this: pass in on $ext_if proto tcp from any to ($ext_if) port = auth keep state flags S/SA However, I still wish I knew how to see the request from the IRC server and the response from identd. Is there a way? Using the '-l' flag in /etc/inetd.conf, identd logs to syslog. You can watch the actual conversation with the remote IRC server via: tcpdump -i fxp0 -p -n -s 1500 -X port auth There is no need for synproxy or modulate on inbound traffic that terminates on the firewall itself, and with keep state you can lock down the pass out $log_flg on $ext_if proto tcp all modulate state line. Furthermore, how vulnerable does it make me by not forcing the SYN flag to be set? If your policy includes 'keep state' on the incoming request, state table entries are created for incoming sessions permitted by the policy, which avoids extra pass out ... entries, and takes care of the SYN flag question as well. Kevin Kadow
