Re: Why packets are not blocked
Jim [EMAIL PROTECTED] writes: [...] You are getting good commentary already so I'm asking a lamer noob q about how you got the output below. tcpdump? Here is the tail of the pflog file while she is on Mar 07 20:30:43.516434 rule 14/0(match): pass out on dc0: 67.174.79.141.60805 64.12.174.121.80: S 3652110150:3652110150(0) win 65535 mss 1460,nop,nop,sackOK (DF) Whatever it is, its much clearer than what I'm getting. Can you comment on how it done?
Re: Why packets are not blocked
man tcpdump tcpdump -tttner /var/log/pflog Harry Putnam wrote on Thu, Mar 09, 2006 at 12:39:02PM -0600: Jim [EMAIL PROTECTED] writes: [...] You are getting good commentary already so I'm asking a lamer noob about how you got the output below. tcpdump? [...] Mar 07 20:30:43.516434 rule 14/0(match): pass out on dc0: 67.174.79.141.60805 64.12.174.121.80: S 3652110150:3652110150(0) win 65535 mss 1460,nop,nop,sackOK (DF) [...]
Re: Why packets are not blocked
Ingo Schwarze [EMAIL PROTECTED] writes: man tcpdump tcpdump -tttner /var/log/pflog hehe ... well put and thanks... nice.
Re: Why packets are not blocked
On 2006/03/07 23:08, Chris Zakelj wrote: Aye. You're flushing rules and NAT, but not your state table. Since the state is already established, rules aren't re-evaluated. Adding a state flush ought to get AOL wiped out. Just be mindful that if you have something going on (like an SSH session), those states will also get nailed. Removing 'flags S/SA' from the pass rules should help there.
Re: Why packets are not blocked
Try flushing the state table too.
-Andy
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Jim
Sent: 08 March 2006 03:00
To: misc@openbsd.org
Subject: Why packets are not blocked
When my kid gets grounded I block the gameroom computer from getting to the
internet. The script that runs is
#!/bin/sh -
cp /home/jmays/pf.conf.noGameroom /etc/pf.conf
pfctl -F rules -f /etc/pf.conf
pfctl -F nat -f /etc/pf.conf
The file that becomes the pf.conf file is
# pf.conf.noGameroom file
#
# Define useful variables
#
ExtIF =dc0 # External Interface
IntIF =hme0 # Internal Interface
loopbackIF=lo0 # Loopback Interface
#
IntNet =192.168.100.0/24 # Our internal network
Austin =192.168.100.129
Gameroom=192.168.100.130
NoRouteIPs={ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }
#Services={ ssh, ftp }
Services={ ssh }
# Clean up fragmented and abnormal packets
scrub in all
# nat on dc1 from 192.168.100.0/24 to any - dc1
nat on $ExtIF from $Gameroom to any tag GAME - ($ExtIF)
nat on $ExtIF from $IntNet to any - ($ExtIF)
block out log quick on $ExtIF tagged GAME
#pass anything on loopback
pass out quick on $loopbackIF
# don't allow anyone to spoof non-routeable addresses
block in quick on $ExtIF from $NoRouteIPs to any
block out quick on $ExtIF from any to $NoRouteIPs
# by default, block all incoming packets, except those explicitly
# allowed by further rules
block in on $ExtIF all
# allow others to use allowed services
pass in on $ExtIF inet proto tcp from any to any port $Services \
flags S/SA keep state
# and let out-going traffic out and maintain state on established
connections
# pass out all protocols, including TCP, UDP and ICMP, and create state,
# so that external DNS servers can reply to our own DNS requests (UDP).
block out log on $ExtIF all
pass out log on $ExtIF inet proto tcp all flags S/SA keep state
pass out log on $ExtIF inet proto udp allkeep state
pass out log on $ExtIF inet proto icmp allkeep state
#
The problem is that if the kid is already logged into AOL Instant messenger,
the connection is not broken. So even though she is grounded, she can still
chat all day on AIM. Why isn't this pf.conf file blocking everything on
that computer?
Here is the tail of the pflog file while she is on
Mar 07 20:30:43.516434 rule 14/0(match): pass out on dc0:
67.174.79.141.60805 64.12.174.121.80: S 3652110150:3652110150(0) win 65535
mss 1460,nop,nop,sackOK (DF)
Mar 07 20:30:43.739711 rule 14/0(match): pass out on dc0:
67.174.79.141.52657 209.62.180.190.80: S 4073040009:4073040009(0) win
65535 mss 1460,nop,nop,sackOK (DF)
Mar 07 20:30:43.960820 rule 14/0(match): pass out on dc0:
67.174.79.141.63494 216.39.69.77.80: S 3255465945:3255465945(0) win 65535
mss 1460,nop,nop,sackOK (DF)
Mar 07 20:30:44.014579 rule 15/0(match): pass out on dc0:
67.174.79.141.60482 204.127.202.4.53: 46801+ A? spe.atdmt.com. (31)
Mar 07 20:30:44.063887 rule 14/0(match): pass out on dc0:
67.174.79.141.60937 80.67.84.16.80: S 1960373362:1960373362(0) win 65535
mss 1460,nop,nop,sackOK (DF)
Mar 07 20:31:02.940879 rule 14/0(match): pass out on dc0:
67.174.79.141.51753 204.127.198.10.110: S 2067644325:2067644325(0) win
65535 mss 1460,nop,nop,sackOK (DF)
I don't even have 14 rules. Why is this passing on rule 14?
Thanks
Jim
Re: Why packets are not blocked
On Tue, Mar 07, 2006 at 11:08:51PM -0500, Chris Zakelj wrote: Steven wrote: * Jim [EMAIL PROTECTED] [060307 20:36]: The problem is that if the kid is already logged into AOL Instant messenger, the connection is not broken. So even though she is grounded, she can still chat all day on AIM. Why isn't this pf.conf file blocking everything on that computer? I'm not anything of a pf expert, but shouldn't this be expected if you have keep state rules in your pf.conf? I mean, you've changed the rule-set, but the connection was set up before the change, and pf will want to keep allowing the packets from the connection to pass as a result. Just my $0.02 CDN, even with the current exchange rates, still not worth a lot. I'll let the real experts handle it from here. :-) Aye. You're flushing rules and NAT, but not your state table. Since the state is already established, rules aren't re-evaluated. Adding a state flush ought to get AOL wiped out. Just be mindful that if you have something going on (like an SSH session), those states will also get nailed. There are other ways to go about this: tcpdrop(8) is probably the proper technical solution. Also, http://www.bofh.org.pl/man contains some useful additional commands, which are, sadly, not part of the base system - SNIP would be a rather useful thingy, here. Joachim
Re: Why packets are not blocked
On 3/7/06, Jim [EMAIL PROTECTED] wrote: When my kid gets grounded I block the gameroom computer from getting to the internet. The script that runs is #!/bin/sh - cp /home/jmays/pf.conf.noGameroom /etc/pf.conf pfctl -F rules -f /etc/pf.conf pfctl -F nat -f /etc/pf.conf The script should probably read #!/bin/sh - cp /home/jmays/pf.conf.noGameroom /etc/pf.conf pfctl -F rules -f /etc/pf.conf pfctl -F nat -f /etc/pf. pfctl -k 192.168.100.130 --Bryan
Re: Why packets are not blocked
* Jim [EMAIL PROTECTED] [060307 20:36]: The problem is that if the kid is already logged into AOL Instant messenger, the connection is not broken. So even though she is grounded, she can still chat all day on AIM. Why isn't this pf.conf file blocking everything on that computer? I'm not anything of a pf expert, but shouldn't this be expected if you have keep state rules in your pf.conf? I mean, you've changed the rule-set, but the connection was set up before the change, and pf will want to keep allowing the packets from the connection to pass as a result. Just my $0.02 CDN, even with the current exchange rates, still not worth a lot. I'll let the real experts handle it from here. :-) -- W. Steven Schneider [EMAIL PROTECTED]
Re: Why packets are not blocked
Steven wrote: * Jim [EMAIL PROTECTED] [060307 20:36]: The problem is that if the kid is already logged into AOL Instant messenger, the connection is not broken. So even though she is grounded, she can still chat all day on AIM. Why isn't this pf.conf file blocking everything on that computer? I'm not anything of a pf expert, but shouldn't this be expected if you have keep state rules in your pf.conf? I mean, you've changed the rule-set, but the connection was set up before the change, and pf will want to keep allowing the packets from the connection to pass as a result. Just my $0.02 CDN, even with the current exchange rates, still not worth a lot. I'll let the real experts handle it from here. :-) Aye. You're flushing rules and NAT, but not your state table. Since the state is already established, rules aren't re-evaluated. Adding a state flush ought to get AOL wiped out. Just be mindful that if you have something going on (like an SSH session), those states will also get nailed.
Re: Why packets are not blocked
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 7, 2006, at 11:20 PM, Jim wrote: Has pfctl -k always been in pf or is this something that was new? It appears to have been introduced in 3.1. http://www.openbsd.org/cgi-bin/man.cgi? query=pfctlapropos=0sektion=8manpath=OpenBSD +3.1arch=i386format=html - -- Bryan Allen [EMAIL PROTECTED] http://bda.mirrorshades.net Cyberpunk is dead. Long live cyberpunk. iD8DBQFEDmAh8DRlpnH/NmoRAqubAJ4uDOfVaI0JO22VOE3xwAilVrImSQCcDcRl 9icuLF8Y9p4KencHuhWsg44= =TTYE -END PGP SIGNATURE-
