>But it is the client that goes to the server to renew. If you have a >wide-open outgoing policy, this is not an issue. If not, you need to >let the client(s) get to the server. That is, you may need,
well I don't have a wide open outgoing policy as you can see. Pass in quick on sis0 proto udp from 0.0.0.0 to 255.255.255.255 port = 67 keep state The rule above, on the bridge, allows only udp broadcast with port 67 to pass. This sis0 interface is connected via cross over cable to the interface on the nat/rtr requesting the dhcp lease, so only the router is allowed to do this as the rest of the lan is on the other side of the router and I have very strict rules. I don't allow the rtr to pass everything out as that is such a huge.... and getting more common mistake. It makes a Trojans job so much easier when the policy allows all out, the only thing it has to do is find the route...then it is phone home time. As for the client requesting a renew...i really don't know but I can say that when the lease is up I can see the server sending data to my machine and if the rule: pass in quick on xl1 proto udp from 12.242.18.34/32 port = 67 to any port = 68 keep state is not present, my connection to the isp gets dropped. If the latter happens, and I have watched this, the client will then talk to 12.242.18.34, without broadcast, and get a new ip. If the rule above is present the ip renews and stays the same. I have had the same ip for days now with the rule. >But does that really make a difference in your security? If >12.242.18.34 stopped working, would you just take the first DHCP >server on the network that responded? Have you called up AT&T or >otherwise verified that 12.242.18.34 is actually their blessed DHCP >server and it isn't another user's rouge server? ;) I felt pretty comfortable with using the above server since I have seen the same server handing out ip address for several mo. now, but you are defiantly right about checking...so I did and according to the tech I conversed with the server is indeed an AT&T dhcp server. Actually the address 12.242.18.34 is a vip for a cluster of servers. If it ever stopped working I would only have to change my outbound rule "which is really inbound from the inet side" but my client should pick up the first one that answers. I really would not see a problem with this as I am only obtaining an ip..nothing else is allowed in, and if it's another user's rouge server well that's at&t's problem. >Not sure what you mean here. Yes, you won't see a difference between a >"drop" or half-open scan versus a regular "connect" scan, but in >either case, you will see the scan (that initial SYN). I was told that if ,for example, I had "block in quick on sis1 proto tcp port = 21" ....and someone tried to telnet to my ip snort would not pick this up because the filter dropped it. Your saying this is not the case, so if I have "block in on sis1 all" I can still see all the attempts, scans etc.. that is thrown at me? Thanks crist for all you help, have a great day bro. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Crist J. Clark Sent: Thursday, August 15, 2002 3:10 PM To: taproot420 Cc: 'James A. Robbins'; [EMAIL PROTECTED] Subject: Re: cant get dhcp to pass through bridge. ! please help On Thu, Aug 15, 2002 at 02:08:37PM -0500, taproot420 wrote: > I don't know about it being the only one, but it's the only one I have > seen showing up in the lease on any machine I have used dhcp on for > about 3 mo. > > " Actually, if these are the only rules you have, you will end up with a > situation exactly like this where the DHCP client cannot reach the > server to renew." > > Remember, pass "OUT" on the sis0 interface, on this bridge, is from the > internet so the rule- pass out quick on sis0 proto udp from > 12.242.18.34/32 port = 67 to any port = 68 ...lets the dhcp server with > ip address 12.242.18.34 communicate with the box and renew its lease. > Before I had this rule, the internet connection would go down after 12 > or so hrs. The box has been up now for about 3 days, with the same ip, > and is still kicking. But it is the client that goes to the server to renew. If you have a wide-open outgoing policy, this is not an issue. If not, you need to let the client(s) get to the server. That is, you may need, > pass in quick on sis0 proto udp from 0.0.0.0 to 255.255.255.255 port = 67 keep state pass in quick on sis0 proto udp from 12.0.0.0/8 port = 68 to 12.242.18.34/32 port = 67 keep state > All I can say is the rules are working fine here. Now if my isp dhcp > server mentioned above goes down or they change ip's or something I will > have a problem. I would rather spend 10-15 mins. If this ever happened > and figure out the new ip or what ever had to be done then allow any ip > to broadcast dhcp upd packets. But does that really make a difference in your security? If 12.242.18.34 stopped working, would you just take the first DHCP server on the network that responded? Have you called up AT&T or otherwise verified that 12.242.18.34 is actually their blessed DHCP server and it isn't another user's rouge server? ;) > Anyway thanks for the advice on snort. I though if you filtered the > interface for ex. Drop scans, telnet etc... and someone tried snort > would not see it. thanks for the advice. Not sure what you mean here. Yes, you won't see a difference between a "drop" or half-open scan versus a regular "connect" scan, but in either case, you will see the scan (that initial SYN). -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/ | [EMAIL PROTECTED]
