Re: me in ipfw rules - does it include aliases?
Tom Worster wrote: the ipfw man page says: me matches any IP address configured on an interface in the system. which suggests that if i code my rules using me then when i add an alias ip address to an interface with ifconfig, these me rules will immediately work for the newly added address as they do for other addresses. is that correct? Yes, the me keyword is expanded to whatever IP address is assigned on any interface in the system. It's updated whenever an IP address is added to or removed from an interface. Use the simple ruleset bellow to test it yourself: lab# ipfw list 00100 allow ip from me to me 65535 deny ip from any to any add alias ping alias = success remove alias ping alias = failure It's a really useful keyword, yet it's not panacea. When using it, one has to think the possibility of an attacker who uses me addresses. Use some interface checking as well in your ruleset... Nikos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: me in ipfw rules - does it include aliases?
Tom Worster wrote: thanks, nikos. You're welcome. i'm interested in your other comment about the risks of using me. All I am saying is that you have to take care of attacks which use me addresses. Packets with source address a me address coming from a network interface, AKA spoofed packets. Apparently a me source address cannot come from a wire[1], right? It's not a great risk, but you better filter them out. Also, it is very possible that such attacks are not applicable to your network. Or not. I am just pointing the possible false sense of security when using rules which match me addresses. Just be sure that me is really your firewall and not somebody else... for the best possible security, i'll post my ruleset here for y'all to review ... or maybe not :-) You better not:) [1] by the word wire, I mean every non-loopback interface Nikos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: me in ipfw rules - does it include aliases?
On 9/8/09 2:58 AM, Nikos Vassiliadis nvass9...@gmx.com wrote: Tom Worster wrote: the ipfw man page says: me matches any IP address configured on an interface in the system. which suggests that if i code my rules using me then when i add an alias ip address to an interface with ifconfig, these me rules will immediately work for the newly added address as they do for other addresses. is that correct? Yes, the me keyword is expanded to whatever IP address is assigned on any interface in the system. It's updated whenever an IP address is added to or removed from an interface. Use the simple ruleset bellow to test it yourself: lab# ipfw list 00100 allow ip from me to me 65535 deny ip from any to any add alias ping alias = success remove alias ping alias = failure It's a really useful keyword, yet it's not panacea. When using it, one has to think the possibility of an attacker who uses me addresses. Use some interface checking as well in your ruleset... Nikos thanks, nikos. my rules were all written with me and my apache config didn't mention any ip addresses so i went ahead and cut over service from a primary server to its hot standby by removing the external ip address on the primary and adding it as an alias to the standby's external interface. both servers are attached to the same upstream ethernet bridge (not necessarily the most reliable network config, i know) and it worked well. i'm interested in your other comment about the risks of using me. for the best possible security, i'll post my ruleset here for y'all to review ... or maybe not :-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
me in ipfw rules - does it include aliases?
the ipfw man page says: me matches any IP address configured on an interface in the system. which suggests that if i code my rules using me then when i add an alias ip address to an interface with ifconfig, these me rules will immediately work for the newly added address as they do for other addresses. is that correct? - tom ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Need somw further help on ipfw rules
Hello freebsd-questions,
Finally, I ve got to work my ipfw firewall with two NATs (one for local
resources, provided by ISP, one for VPN - which leads me to
Internet= ).
But I need further help on it :-(
Here is my rules:
#!/bin/sh
ipfw='/sbin/ipfw -q'
mynet='192.168.0.0/24'
myprefix='192.168.0.'
adsl_out='xl0'
vpn_out='ng0'
if_loc='rl0'
gw_loc='10.30.100.5'
route1='81.25.32.5/32'
route2='81.25.32.6/32'
route3='81.25.32.13/32'
route4='81.25.32.15/32'
route5='81.25.32.25/32'
route6='81.25.32.34/32'
route7='81.25.32.30/32'
route8='81.25.32.67/32'
route9='81.25.32.48/32'
route10='81.25.32.40/32'
route11='81.25.32.68/32'
route12='81.25.32.69/32'
route13='81.25.32.70/32'
route14='81.25.32.71/32'
route15='81.25.32.81/32'
route16='81.25.32.82/32'
route17='81.25.32.96/32'
route18='72.167.232.126/32'
route19='81.25.32.97/32'
route20='81.25.34.96/28'
${ipfw} -f flush
${ipfw} table 12 flush
${ipfw} -f pipe flush
${ipfw} -f queue flush
${ipfw} pipe 1 config bw 40Kbyte/s queue 50
${ipfw} pipe 2 config bw 15Kbyte/s queue 50
#Filling IPFW free-res table
${ipfw} table 12 add ${route1}
${ipfw} table 12 add ${route2}
${ipfw} table 12 add ${route3}
${ipfw} table 12 add ${route4}
${ipfw} table 12 add ${route5}
${ipfw} table 12 add ${route6}
${ipfw} table 12 add ${route7}
${ipfw} table 12 add ${route8}
${ipfw} table 12 add ${route9}
${ipfw} table 12 add ${route10}
${ipfw} table 12 add ${route11}
${ipfw} table 12 add ${route12}
${ipfw} table 12 add ${route13}
${ipfw} table 12 add ${route14}
${ipfw} table 12 add ${route15}
${ipfw} table 12 add ${route16}
${ipfw} table 12 add ${route17}
${ipfw} table 12 add ${route18}
${ipfw} table 12 add ${route19}
${ipfw} table 12 add ${route20}
# ICMP
${ipfw} add 1 deny icmp from any to any frag
${ipfw} add 2 deny icmp from any to any in via ${adsl_out} icmptype
5,9,= 13,14,15,16,17
${ipfw} add 2 deny icmp from any to any in via ${vpn_out} icmptype
5,9,1= 3,14,15,16,17
${ipfw} add 3 check-state
${ipfw} add 4 allow all from any to any via lo0
${ipfw} add 4 allow all from any to any via ${if_loc}
# Allowing myself everuthin
${ipfw} add 5 allow all from me to any keep-state
#Free res
${ipfw} add 6 divert 8667 ip from table\(12\) to any in via
${adsl_out}= /p
${ipfw} add 7 divert 8667 ip from any to table\(12\) out via
${adsl_out}
${ipfw} add 8 allow all from ${mynet} to table\(12\) out via
${adsl_out}
${ipfw} add 9 allow all from table\(12\) to ${mynet} in via
${adsl_out}= /p
#NAT to Internet
${ipfw} add 10 divert 8668 ip from any to any in via ${vpn_out}
${ipfw} add 11 divert 8668 ip from any to not table\(12\) out via
${vpn_= out}
# Deny access to unrouteable networks
${ipfw} add 12 reject all from any to 10.0.0.0/8 in via ${vpn_out}
${ipfw} add 13 reject all from any to 172.16.0.0/12 in via ${adsl_out}
${ipfw} add 14 reject all from any to 172.16.0.0/12 in via ${vpn_out}
${ipfw} add 15 reject all from any to 0.0.0.0/8 in via ${adsl_out}
${ipfw} add 16 reject all from any to 0.0.0.0/8 in via ${vpn_out}
${ipfw} add 17 reject all from any to 169.254.0.0/16 in via
${adsl_out}= /p
${ipfw} add 18 reject all from any to 169.254.0.0/16 in via ${vpn_out}
# Multicast
${ipfw} add 19 reject all from any to 224.0.0.0/4 in via ${adsl_out}
${ipfw} add 20 reject all from any to 224.0.0.0/4 in via ${vpn_out}
${ipfw} add 21 reject all from any to 240.0.0.0/4 in via ${adsl_out}
${ipfw} add 22 reject all from any to 240.0.0.0/4 in via ${vpn_out}
# Deny access from unrouteable networks
${ipfw} add 23 reject all from 10.0.0.0/8 to any in via ${vpn_out}
${ipfw} add 24 reject all from 172.16.0.0/12 to any in via ${adsl_out}
${ipfw} add 25 reject all from 172.16.0.0/12 to any in via ${vpn_out}
${ipfw} add 26 reject all from 0.0.0.0/8 to any in via ${adsl_out}
${ipfw} add 27 reject all from 0.0.0.0/8 to any in via ${vpn_out}
${ipfw} add 28 reject all from 169.254.0.0/16 to any in via
${adsl_out}= /p
${ipfw} add 29 reject all from 169.254.0.0/16 to any in via ${vpn_out}
# Multicast
${ipfw} add 30 reject all from 224.0.0.0/4 to any in via ${adsl_out}
${ipfw} add 31 reject all from 224.0.0.0/4 to any in via ${vpn_out}
${ipfw} add 32 reject all from 240.0.0.0/4 to any in via ${adsl_out}
${ipfw} add 33 reject all from 240.0.0.0/4 to any in via ${vpn_out}
#SasserNetbios
${ipfw} add 34 reject tcp from any to any 137-139,445,1022,1023
${ipfw} add 35 reject tcp from any 137-139,445,1022,1023 to any
${ipfw} add 36 reject udp from any to any 137-139,445,1022,1023
${ipfw} add 37 reject udp from any 137-139,445,1022,1023 to any
#Other Defence
${ipfw} add 38 reject tcp
Performance loss with dynamic IPFW rules
Здравствуйте, Questions. 1 allow all from any to any via rl0 2 allow all from any to any via rl1 109 skipto 110 tcp from any to any 80 in recv $iface #split only http trafic 109 skipto 200 all from any to any #do not split all other trafic 110 check-state 111 prob 0.5 skipto 131 in recv rl2 121 skipto 122 keep-state in recv rl2 123 setfib 0 proto all in recv rl2 125 skipto 150 proto all in recv rl2 131 skipto 132 keep-state in recv rl2 133 setfib 1 proto all in recv rl2 135 skipto 150 proto all in recv rl2 I am connected on rl1. INET is rl0, rl1 each 4Mbit/s When I open many connections I get performance loss: 1) Web pages are not opened (it seems flow at start goes through rl0 and then goes rl1. EXPECTED: it flows only through one channel until closed) 2) I get about 2Mbit/s while downloading something When I not open many flows I get 8Mbit/s while serfing What is problem? -- С уважением, KES mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Performance loss with dynamic IPFW rules
Здравствуйте, KES. Вы писали 30 декабря 2008 г., 21:47:40: K Здравствуйте, Questions. K 1 allow all from any to any via rl0 K 2 allow all from any to any via rl1 K 109 skipto 110 tcp from any to any 80 in recv $iface #split only http trafic K 109 skipto 200 all from any to any #do not split all other trafic K 110 check-state K 111 prob 0.5 skipto 131 in recv rl2 K 121 skipto 122 keep-state in recv rl2 K 123 setfib 0 proto all in recv rl2 K 125 skipto 150 proto all in recv rl2 K 131 skipto 132 keep-state in recv rl2 K 133 setfib 1 proto all in recv rl2 K 135 skipto 150 proto all in recv rl2 K I am connected on rl1. K INET is rl0, rl1 each 4Mbit/s K When I open many connections I get performance loss: K 1) Web pages are not opened (it seems flow at start goes through rl0 K and then goes rl1. EXPECTED: it flows only through one channel until K closed) K 2) I get about 2Mbit/s while downloading something K When I not open many flows I get 8Mbit/s while serfing K What is problem? Also another interesting behaviour. Packets with FIB 1 are outgoing through rl0 interface, but must out go via rl1. Why? -- С уважением, KES mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re[2]: BUG! Performance loss with dynamic IPFW rules
Здравствуйте, KES. Вы писали 30 декабря 2008 г., 22:29:50: K Здравствуйте, KES. K Вы писали 30 декабря 2008 г., 21:47:40: K Здравствуйте, Questions. K 1 allow all from any to any via rl0 K 2 allow all from any to any via rl1 K 109 skipto 110 tcp from any to any 80 in recv $iface #split only http trafic K 109 skipto 200 all from any to any #do not split all other trafic K 110 check-state K 111 prob 0.5 skipto 131 in recv rl2 K 121 skipto 122 keep-state in recv rl2 K 123 setfib 0 proto all in recv rl2 K 125 skipto 150 proto all in recv rl2 K 131 skipto 132 keep-state in recv rl2 K 133 setfib 1 proto all in recv rl2 K 135 skipto 150 proto all in recv rl2 K I am connected on rl1. K INET is rl0, rl1 each 4Mbit/s K When I open many connections I get performance loss: K 1) Web pages are not opened (it seems flow at start goes through rl0 K and then goes rl1. EXPECTED: it flows only through one channel until K closed) K 2) I get about 2Mbit/s while downloading something K When I not open many flows I get 8Mbit/s while serfing K What is problem? K Also another interesting behaviour. K Packets with FIB 1 are outgoing through rl0 interface, but must out go K via rl1. Why? I resolve problem!!! I have mpd5 on both interfaces rl0 and rl1. It starts PPPoE connection with my ISP. mpd5 has FIB 0. and has option to NAT packets. When I send packet from rl2 to INET it is: tcpdump -n -i rl1 22:51:40.917666 IP 192.168.9.80.3113 205.188.8.85.5190: P 1:27(26) ack 1461 win 65535 I add counters for 192.168.9.80 to ipfw 05500711 54217 count ip from any to any out xmit rl1 05510711 54217 count tag 1 ip from 192.168.9.80 to any out xmit rl1 05515 0 0 deny log ip from any to any out xmit rl1 not tagged 1 05890711 54217 allow untag 1 ip from any to any out xmit rl1 tagged 1 05899 0 0 deny log ip from any to any via rl1 05899 0 0 skipto 65000 ip from any to any Then packet is NATed by mpd (it runned with FIB 0) and out via rl0! instead of rl1 =( I think packet changes its FIB after NATing by process with different FIB than packet itself =( look tcpdump. kes# ifconfig rl0 rl0: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST metric 0 mtu 1492 inet 92.113.11.221 -- 195.5.5.202 netmask 0x kes# ifconfig rl1 rl1: flags=88d1UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST metric 0 mtu 1492 inet 91.124.184.62 -- 195.5.5.209 netmask 0x tcpdump -n -i rl0 23:00:39.013565 IP 91.124.184.62 68.147.56.238: ICMP 91.124.184.62 udp port 59344 unreachable, length 36 23:00:39.043593 IP 91.124.184.62 69.251.246.7: ICMP 91.124.184.62 udp port 59344 unreachable, length 36 23:00:39.675315 IP 91.124.184.62 71.30.187.17: ICMP 91.124.184.62 udp port 10758 unreachable, length 36 23:00:39.818931 IP 91.124.184.62 117.11.167.163: ICMP 91.124.184.62 udp port 10758 unreachable, length 36 23:00:41.865974 IP 91.124.184.62 67.177.215.23: ICMP 91.124.184.62 udp port 10758 unreachable, length 36 23:00:43.289822 IP 91.124.184.62 88.84.178.189: ICMP 91.124.184.62 udp port 10758 unreachable, length 36 tcpdump -n -i rl1 23:00:39.013133 IP 68.147.56.238.23877 91.124.184.62.59344: UDP, length 103 23:00:39.042899 IP 69.251.246.7.46602 91.124.184.62.59344: UDP, length 103 23:00:39.675293 IP 71.30.187.17.61710 91.124.184.62.10758: UDP, length 103 23:00:39.818910 IP 117.11.167.163.12312 91.124.184.62.10758: UDP, length 98 23:00:41.865952 IP 67.177.215.23.24147 91.124.184.62.10758: UDP, length 98 23:00:43.289801 IP 88.84.178.189.60799 91.124.184.62.10758: UDP, length 101 23:00:43.419409 IP 93.80.208.87.61523 91.124.184.62.10758: S 3219801041:3219801041(0) win 8192 mss 1360,nop,nop I think this is wrong behaviour. -- С уважением, KES mailto:kes-...@yandex.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: removing ipfw rules
On Fri, 28 Dec 2007 02:21:54 +0200 Giorgos Keramidas [EMAIL PROTECTED] wrote:
On 2007-12-27 15:47, Noah [EMAIL PROTECTED] wrote:
Hi,
I have two ipfw rules that I want to remove. They are viewable with the
ipfw show command
--- snip ---
06600 0 0 allow ip from any to any proto tcp src-ip
66.66.66.66 dst-port 22
06700 0 0 allow ip from any to any proto tcp src-ip
66.66.66.66 dst-port 22
--- snip
I am typing the command /sbin/ipfw -q delete pass proto tcp src-ip
66.66.66.66 dst-port 22
but both lines remain. What am I doing wrong?
There are differences between the visible rule:
allow ip from any to any proto tcp src-ip 66.66.66.66 dst-port 22
and the one you are trying to delete:
pass proto tcp src-ip 66.66.66.66 dst-port 22
Having said that, can you try something simpler, i.e.
ipfw -q delete 6600
ipfw -q delete 6700
This should work too, if I remember well enough the ipfw syntax.
You do, but deleting by rule number/s is the only way. ipfw(8):
ipfw [-q] {delete | zero | resetlog} [set] [number ...]
Of course Noah could find rule number/s to delete with something like
# ipfw delete `ipfw list | grep $somestring | awk '{print $1}'`
if he was, um, courageous :) Safer tested first with ipfw show ..
cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
removing ipfw rules
Hi, I have two ipfw rules that I want to remove. They are viewable with the ipfw show command --- snip --- 06600 0 0 allow ip from any to any proto tcp src-ip 66.66.66.66 dst-port 22 06700 0 0 allow ip from any to any proto tcp src-ip 66.66.66.66 dst-port 22 --- snip I am typing the command /sbin/ipfw -q delete pass proto tcp src-ip 66.66.66.66 dst-port 22 but both lines remain. What am I doing wrong? Cheers, Noah ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing ipfw rules
On 2007-12-27 15:47, Noah [EMAIL PROTECTED] wrote: Hi, I have two ipfw rules that I want to remove. They are viewable with the ipfw show command --- snip --- 06600 0 0 allow ip from any to any proto tcp src-ip 66.66.66.66 dst-port 22 06700 0 0 allow ip from any to any proto tcp src-ip 66.66.66.66 dst-port 22 --- snip I am typing the command /sbin/ipfw -q delete pass proto tcp src-ip 66.66.66.66 dst-port 22 but both lines remain. What am I doing wrong? There are differences between the visible rule: allow ip from any to any proto tcp src-ip 66.66.66.66 dst-port 22 and the one you are trying to delete: pass proto tcp src-ip 66.66.66.66 dst-port 22 Having said that, can you try something simpler, i.e. ipfw -q delete 6600 ipfw -q delete 6700 This should work too, if I remember well enough the ipfw syntax. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing ipfw rules
thanks for the response.
I was Looking for awk to do some of the parsing like this:
/sbin/ipfw list | grep '%IP%' | awk '{ print ipfw -q delete $1 }' | sh
cheers,
Noah
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules for all interfaces not working ...
On Monday 17 December 2007 19:06:29 Gore Jarold wrote: My main goal is to lock down my ipfw rules so that when I run nmap, all I see is: Interesting ports on 192.168.0.10: Not shown: 1677 closed ports PORTSTATE SERVICE 22/tcp open ssh MAC Address: 00:12:D8:A2:23:C2 Nmap finished: 1 IP address (1 host up) scanned in 9.791 seconds So that means I will need to explicitly block all ports except for the ones I have real servers running on. That's easy. The problem is, this is a laptop and so sometimes iwi0 exists and sometimes it doesn't, and sometimes xl0 exists and sometimes it doesn't ... and that is why my ipfw rules look like this: 00010 00 allow ip from any to any via lo0 00020 00 deny ip from any to 127.0.0.0/8 01000 18134 10505749 allow tcp from any to any established 04000 149884280 allow icmp from any to any 0400127 1728 allow tcp from any to any dst-port 22 setup 04008 00 deny log logamount 100 ip from any to any recv all 65535 15202 2569754 allow ip from any to any See - in rule 04008, I say to deny ip from any to any recv all - so that no matter what interface(s) I have up, and no matter what their addresses are, this one deny rule will apply to them. THe problem is, it doesn't work. As you can see, the counter on that rule is zero, and when I nmap the system I can see things like samba and http, etc., even though the only port I am allowing through is TCP 22. Why is this ? Because there is no all keyword :) ipfw tries to match an interface named all there. Check how these rules match your needs. The first one creates states for connections initiated by your machine to the world allowing related incoming traffic to come back. The second allows all to your TCP port 22. The third denies and logs everything else. ipfw add 1000 allow ip from me to any keep-state ipfw add 2000 allow tcp from any to me dst-port 22 ipfw add 3000 deny log logamount 0 ip from any to any The above ruleset is a minimal example. Modify as needed to limit logamount, allow ICMP etc. HTH, Nikos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw rules for all interfaces not working ...
My main goal is to lock down my ipfw rules so that when I run nmap, all I see is: Interesting ports on 192.168.0.10: Not shown: 1677 closed ports PORTSTATE SERVICE 22/tcp open ssh MAC Address: 00:12:D8:A2:23:C2 Nmap finished: 1 IP address (1 host up) scanned in 9.791 seconds So that means I will need to explicitly block all ports except for the ones I have real servers running on. That's easy. The problem is, this is a laptop and so sometimes iwi0 exists and sometimes it doesn't, and sometimes xl0 exists and sometimes it doesn't ... and that is why my ipfw rules look like this: 00010 00 allow ip from any to any via lo0 00020 00 deny ip from any to 127.0.0.0/8 01000 18134 10505749 allow tcp from any to any established 04000 149884280 allow icmp from any to any 0400127 1728 allow tcp from any to any dst-port 22 setup 04008 00 deny log logamount 100 ip from any to any recv all 65535 15202 2569754 allow ip from any to any See - in rule 04008, I say to deny ip from any to any recv all - so that no matter what interface(s) I have up, and no matter what their addresses are, this one deny rule will apply to them. THe problem is, it doesn't work. As you can see, the counter on that rule is zero, and when I nmap the system I can see things like samba and http, etc., even though the only port I am allowing through is TCP 22. Why is this ? Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW Rules and Games
[EMAIL PROTECTED] wrote: So basically the ruleset should be simple: ipfw -f flush # allow lo0 stuff # block some spoofs/attacks # if you are hosting gameservers from 192.168.17.3 or whatever, # you should (manually) open server ports, in other words, add # routes to 192.168.17.3 to specific server ports ipfw add divert natd all from any to any via $outside_interface allow all from any to any # block some more spoofs/attacks :) # define services (like you did with http) Sorry, this didn't work. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW Rules and Games
Jack Barnett wrote: [EMAIL PROTECTED] wrote: So basically the ruleset should be simple: ipfw -f flush # allow lo0 stuff # block some spoofs/attacks # if you are hosting gameservers from 192.168.17.3 or whatever, # you should (manually) open server ports, in other words, add # routes to 192.168.17.3 to specific server ports ipfw add divert natd all from any to any via $outside_interface allow all from any to any # block some more spoofs/attacks :) # define services (like you did with http) Sorry, this didn't work. just without any security concerns, try this script: #!/bin/sh ipfw -f flush ipfw add divert natd via xl0 ipfw add allow all from any to any But please tell me, what kind of internet connection do you have? You said you have a Dynamic IP. Are you using connecting to the Internet via ppp? If so, replace xl0 up there with tun0 (or whatever tunnel ppp created). Here's my stuff: ::: /etc/natd.conf ::: dynamic yes same_portsyes deny_incoming yes unregistered_only yes redirect address 192.168.123.254 0.0.0.0 ::: part of /etc/rc.conf ::: # [...] ifconfig_rl0=inet 192.168.123.254 netmask 255.255.255.0 ifconfig_ed0=up # -- this is the external one # plus there is a tun0 for PPPoE firewall_enable=YES firewall_script=/etc/ipfw.rules # something like the above script gateway_enable=YES router_enable=NO natd_enable=YES natd_interface=tun0 natd_flags=-f /etc/natd.conf ppp_enable=YES # [...] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
IPFW Rules and Games
Lots of people play games here and basically a pain to keep trying to
get these stupid things to work with individual rules for each.
I'm running FreeBSD 6.x with IPFW/natd
I get a dynamic IP from my ISP and the internal nic is 192.168.17.1
Everything inside the network is 192.168.17.xxx
The setup is this:
192.168.17.x -- 192.168.17.1 [FreeBSD] Dynamic IP -- {Random Game
Server on the Internets}
[Internet Network(GAME)] -- [FreeBSD] -- {Internets}
There are a bunch of games that send out TCP/UDP packets (and who knows
what else) on different ports to different destinations and then
receive data back on random ports. Basically, anything on any
protocol from the internal network should be able to establish and setup
connections out AND be allowed to receive data back from whomever they
connected out to; but random hosts trying to connect in should be blocked.
I added this for a temporary fix:
${fwcmd} add pass all from any to any
I don't think that is the right answer; That allows to much in?
I've tried these per the docs:
${fwcmd} add allow all from any to any out via {$iip} setup
${fwcmd} add allow all from any to any out via {$iip} established
${fwcmd} add allow all from any to any in via {$iip} established
and also a bunch of others; but none of them worked.
Here is my full config:
# simple
[Ss][Ii][Mm][Pp][Ll][Ee])
# This is a prototype setup for a simple firewall. Configure this
# machine as a DNS and NTP server, and point all the machines
# on the inside at this machine for those services.
# set these to your outside interface network and netmask and ip
oif=xl0
onet=`ifconfig xl0 | grep inet | awk '{print $6}'`
omask=0xfe00
oip=`ifconfig xl0 | grep inet | awk '{print $2}'`
# set these to your inside interface network and netmask and ip
iif=dc1
inet=192.168.17.0
imask=0xff00
iip=192.168.17.1
setup_loopback
# Stop spoofing
${fwcmd} add deny all from ${inet}:${imask} to any in via ${oif}
${fwcmd} add deny all from ${onet}:${omask} to any in via ${iif}
# Stop RFC1918 nets on the outside interface
${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif}
${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif}
${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif}
# Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes
RESERVED-1,
# DHCP auto-configuration, NET-TEST, MULTICAST (class D), and
class E)
# on the outside interface
${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif}
${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif}
${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif}
${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif}
${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif}
# Network Address Translation. This rule is placed here
deliberately
# so that it does not interfere with the surrounding
address-checking
# rules. If for example one of your internal LAN machines had
its IP
# address set to 192.0.2.1 then an incoming packet for it after
being
# translated by natd(8) would match the `deny' rule above.
Similarly
# an outgoing packet originated from it before being translated
would
# match the `deny' rule below.
case ${natd_enable} in
[Yy][Ee][Ss])
if [ -n ${natd_interface} ]; then
${fwcmd} add divert natd all from any to any via
${natd_interface}
fi
;;
esac
# Stop RFC1918 nets on the outside interface
${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif}
${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif}
${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif}
# Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes
RESERVED-1,
# DHCP auto-configuration, NET-TEST, MULTICAST (class D), and
class E)
# on the outside interface
${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif}
${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif}
${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif}
${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif}
${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif}
# Allow internal traffic
${fwcmd} add allow all from any to any via ${iif}
# Allow all local traffic
${fwcmd} add allow all from ${inet}:${imask} to ${inet}:${imask}
# Allow TCP through if setup succeeded
${fwcmd} add pass tcp from any to any established
# Allow IP fragments to pass through
${fwcmd} add pass all from any to any frag
# Allow setup of incoming email
#${fwcmd} add pass tcp from any to ${oip} 25 setup
#${fwcmd} add pass
Re: IPFW Rules and Games
Bob Hall wrote:
On Fri, Nov 02, 2007 at 04:59:27AM -0500, Jack Barnett wrote:
I added this for a temporary fix:
${fwcmd} add pass all from any to any
I don't think that is the right answer; That allows to much in?
Yes.
I've tried these per the docs:
${fwcmd} add allow all from any to any out via {$iip} setup
${fwcmd} add allow all from any to any out via {$iip} established
${fwcmd} add allow all from any to any in via {$iip} established
and also a bunch of others; but none of them worked.
Try oip instead of iip. iip is your internal IP address, so anything
going out from iip is going to your lan, and anything coming in to iip
is coming from your lan. You want to control packets communicating with
the outside world, so you want to control them at oip.
Sorry, that didn't work.
I also tried this:
${fwcmd} add allow tcp from any to any via ${oip} setup
${fwcmd} add allow udp from any to any via ${oip} setup
${fwcmd} add allow tcp from any to any via ${oip} established
${fwcmd} add allow udp from any to any via ${oip} established
That also blocks it. :(
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW Rules and Games
Jack Barnett wrote:
Bob Hall wrote:
On Fri, Nov 02, 2007 at 04:59:27AM -0500, Jack Barnett wrote:
I added this for a temporary fix:
${fwcmd} add pass all from any to any
I don't think that is the right answer; That allows to much in?
Yes.
I've tried these per the docs:
${fwcmd} add allow all from any to any out via {$iip} setup
${fwcmd} add allow all from any to any out via {$iip} established
${fwcmd} add allow all from any to any in via {$iip} established
and also a bunch of others; but none of them worked.
Try oip instead of iip. iip is your internal IP address, so anything
going out from iip is going to your lan, and anything coming in to iip
is coming from your lan. You want to control packets communicating with
the outside world, so you want to control them at oip.
Sorry, that didn't work.
I also tried this:
${fwcmd} add allow tcp from any to any via ${oip} setup
${fwcmd} add allow udp from any to any via ${oip} setup
${fwcmd} add allow tcp from any to any via ${oip} established
${fwcmd} add allow udp from any to any via ${oip} established
That also blocks it. :(
Even tried this and still doesn't work.
${fwcmd} add allow tcp from any to any via ${oip}
${fwcmd} add allow udp from any to any via ${oip}
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW Rules and Games
Jack Barnett wrote:
Jack Barnett wrote:
Jack Barnett wrote:
Bob Hall wrote:
On Fri, Nov 02, 2007 at 04:59:27AM -0500, Jack Barnett wrote:
I added this for a temporary fix:
${fwcmd} add pass all from any to any
I don't think that is the right answer; That allows to much in?
Yes.
I've tried these per the docs:
${fwcmd} add allow all from any to any out via {$iip} setup
${fwcmd} add allow all from any to any out via {$iip} established
${fwcmd} add allow all from any to any in via {$iip} established
and also a bunch of others; but none of them worked.
Try oip instead of iip. iip is your internal IP address, so anything
going out from iip is going to your lan, and anything coming in to iip
is coming from your lan. You want to control packets communicating with
the outside world, so you want to control them at oip.
Sorry, that didn't work.
I also tried this:
${fwcmd} add allow tcp from any to any via ${oip} setup
${fwcmd} add allow udp from any to any via ${oip} setup
${fwcmd} add allow tcp from any to any via ${oip} established
${fwcmd} add allow udp from any to any via ${oip} established
That also blocks it. :(
Even tried this and still doesn't work.
${fwcmd} add allow tcp from any to any via ${oip}
${fwcmd} add allow udp from any to any via ${oip}
Grrr, this doesn't work either:
# statefull
${fwcmd} add check-state
${fwcmd} add allow tcp from any to any established
${fwcmd} add allow all from any to any out keep-state
${fwcmd} add allow icmp from any to any
This thread talks about the same problem:
[1]http://lists.freebsd.org/pipermail/freebsd-ipfw/2005-December/00225
8.html
You will most likely find that dynamic rules will allow this
ingress traffic, without the need to explicitly allow it.
But unfortunately there is no follow up reply in that archive.
References
1. http://lists.freebsd.org/pipermail/freebsd-ipfw/2005-December/002258.html
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW Rules and Games
On Fri, 02 Nov 2007 04:59:27 -0500
Jack Barnett [EMAIL PROTECTED] wrote:
Lots of people play games here and basically a pain to keep trying to
get these stupid things to work with individual rules for each.
I'm running FreeBSD 6.x with IPFW/natd
I get a dynamic IP from my ISP and the internal nic is 192.168.17.1
Everything inside the network is 192.168.17.xxx
The setup is this:
192.168.17.x -- 192.168.17.1 [FreeBSD] Dynamic IP -- {Random
Game Server on the Internets}
[Internet Network(GAME)] -- [FreeBSD] -- {Internets}
There are a bunch of games that send out TCP/UDP packets (and who
knows what else) on different ports to different destinations and then
receive data back on random ports. Basically, anything on any
protocol from the internal network should be able to establish and
setup connections out AND be allowed to receive data back from
whomever they connected out to; but random hosts trying to connect
in should be blocked.
You simply need to allow back traffic on the same socket connection
this will happen automatically with TCP if you are passing established
traffic, with UDP you will have to keep-state. You will probably find
that the games also require you to open one or more incoming ports too.
If you are not very confident with ipfw I would suggest you switch to
pf. It's a very good firewall and generally easier to use. Also if you
are playing games, you'll want to do traffic prioritisation, which is a
pain with ipfw.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW Rules and Games
RW wrote:
On Fri, 02 Nov 2007 04:59:27 -0500
Jack Barnett [1][EMAIL PROTECTED] wrote:
Lots of people play games here and basically a pain to keep trying to
get these stupid things to work with individual rules for each.
I'm running FreeBSD 6.x with IPFW/natd
I get a dynamic IP from my ISP and the internal nic is 192.168.17.1
Everything inside the network is 192.168.17.xxx
The setup is this:
192.168.17.x -- 192.168.17.1 [FreeBSD] Dynamic IP -- {Random
Game Server on the Internets}
[Internet Network(GAME)] -- [FreeBSD] -- {Internets}
There are a bunch of games that send out TCP/UDP packets (and who
knows what else) on different ports to different destinations and then
receive data back on random ports. Basically, anything on any
protocol from the internal network should be able to establish and
setup connections out AND be allowed to receive data back from
whomever they connected out to; but random hosts trying to connect
in should be blocked.
You simply need to allow back traffic on the same socket connection
this will happen automatically with TCP if you are passing established
traffic, with UDP you will have to keep-state. You will probably find
that the games also require you to open one or more incoming ports too.
If you are not very confident with ipfw I would suggest you switch to
pf. It's a very good firewall and generally easier to use. Also if you
are playing games, you'll want to do traffic prioritisation, which is a
pain with ipfw.
Thanks. Yes, generally firewalls and networking isn't my strong
point.
I checked out the handbook on it and it looks easy enough.
I found this: [2]http://www.allard.nu/pfw/ - but appears it's not in
the ports and commerical software?
I also have fwbuilder installed; but don't really like that much.
Are there any other GUI like interfaces that could help me in building
rules for pf?
I haven't read though it all yet; but I'll still need natd with pf,
right?
References
1. mailto:[EMAIL PROTECTED]
2. http://www.allard.nu/pfw/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW Rules and Games
On Fri, Nov 02, 2007 at 04:59:27AM -0500, Jack Barnett wrote:
I added this for a temporary fix:
${fwcmd} add pass all from any to any
I don't think that is the right answer; That allows to much in?
Yes.
I've tried these per the docs:
${fwcmd} add allow all from any to any out via {$iip} setup
${fwcmd} add allow all from any to any out via {$iip} established
${fwcmd} add allow all from any to any in via {$iip} established
and also a bunch of others; but none of them worked.
Try oip instead of iip. iip is your internal IP address, so anything
going out from iip is going to your lan, and anything coming in to iip
is coming from your lan. You want to control packets communicating with
the outside world, so you want to control them at oip.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW Rules and Games
Jack Barnett wrote:
Jack Barnett wrote:
Bob Hall wrote:
On Fri, Nov 02, 2007 at 04:59:27AM -0500, Jack Barnett wrote:
I added this for a temporary fix:
${fwcmd} add pass all from any to any
I don't think that is the right answer; That allows to much in?
Yes.
I've tried these per the docs:
${fwcmd} add allow all from any to any out via {$iip} setup
${fwcmd} add allow all from any to any out via {$iip} established
${fwcmd} add allow all from any to any in via {$iip} established
and also a bunch of others; but none of them worked.
Try oip instead of iip. iip is your internal IP address, so anything
going out from iip is going to your lan, and anything coming in to iip
is coming from your lan. You want to control packets communicating with
the outside world, so you want to control them at oip.
Sorry, that didn't work.
I also tried this:
${fwcmd} add allow tcp from any to any via ${oip} setup
${fwcmd} add allow udp from any to any via ${oip} setup
${fwcmd} add allow tcp from any to any via ${oip} established
${fwcmd} add allow udp from any to any via ${oip} established
That also blocks it. :(
Even tried this and still doesn't work.
${fwcmd} add allow tcp from any to any via ${oip}
${fwcmd} add allow udp from any to any via ${oip}
Grrr, this doesn't work either:
# statefull
${fwcmd} add check-state
${fwcmd} add allow tcp from any to any established
${fwcmd} add allow all from any to any out keep-state
${fwcmd} add allow icmp from any to any
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW Rules and Games
Hi, Jack, let's see.
Jack Barnett wrote:
Lots of people play games here and basically a pain to keep trying to
get these stupid things to work with individual rules for each.
I'm running FreeBSD 6.x with IPFW/natd
I get a dynamic IP from my ISP and the internal nic is 192.168.17.1
Everything inside the network is 192.168.17.xxx
The setup is this:
192.168.17.x -- 192.168.17.1 [FreeBSD] Dynamic IP -- {Random Game
Server on the Internets}
[Internet Network(GAME)] -- [FreeBSD] -- {Internets}
There are a bunch of games that send out TCP/UDP packets (and who knows
what else) on different ports to different destinations and then
receive data back on random ports. Basically, anything on any
protocol from the internal network should be able to establish and setup
connections out AND be allowed to receive data back from whomever they
connected out to; but random hosts trying to connect in should be
blocked.
Back on random ports? That's not how it should be. Your client must
send a request (ping or connect) to a server, using the game's client
port as the local port, and the server port as the remote port. The
reply should come back the same way, reversed.
for example, a client sends a connect request:
192.168.17.7:28000 87.15.13.165
natd converts the packet to:
49.74.121.3:28000 87.15.13.165:29000
(49.74.121.3 is your public IP)
and adds a dynamic rule (inside natd, not ipfw), that packet coming from
87.15.13.165, port 29000 to 49.74.121.3 port 28000 should be routed to
192.168.17.7, port 28000. So:
the server replies:
87.15.13.165:29000 49.74.121.3:28000
natd converts the packet to:
87.15.13.165:29000 192.168.17.7:28000
Any unknown packets will be blocked by natd. These are the unauthorized
random hosts.
So basically the ruleset should be simple:
ipfw -f flush
# allow lo0 stuff
# block some spoofs/attacks
# if you are hosting gameservers from 192.168.17.3 or whatever,
# you should (manually) open server ports, in other words, add
# routes to 192.168.17.3 to specific server ports
ipfw add divert natd all from any to any via $outside_interface
allow all from any to any
# block some more spoofs/attacks :)
# define services (like you did with http)
Correct me if I'm wrong.
What games do reply back on random ports?
I added this for a temporary fix:
${fwcmd} add pass all from any to any
I don't think that is the right answer; That allows to much in?
I've tried these per the docs:
${fwcmd} add allow all from any to any out via {$iip} setup
${fwcmd} add allow all from any to any out via {$iip} established
${fwcmd} add allow all from any to any in via {$iip} established
and also a bunch of others; but none of them worked.
Here is my full config:
# simple
[Ss][Ii][Mm][Pp][Ll][Ee])
# This is a prototype setup for a simple firewall. Configure this
# machine as a DNS and NTP server, and point all the machines
# on the inside at this machine for those services.
# set these to your outside interface network and netmask and ip
oif=xl0
onet=`ifconfig xl0 | grep inet | awk '{print $6}'`
I'm not sure about this. Isn't the sixth word the broadcast address
(ending with .255)?
omask=0xfe00
0xfe00 wtf?
oip=`ifconfig xl0 | grep inet | awk '{print $2}'`
# set these to your inside interface network and netmask and ip
iif=dc1
inet=192.168.17.0
imask=0xff00
iip=192.168.17.1
What kind of internet connection do you have?
setup_loopback
# Stop spoofing
${fwcmd} add deny all from ${inet}:${imask} to any in via ${oif}
${fwcmd} add deny all from ${onet}:${omask} to any in via ${iif}
# Stop RFC1918 nets on the outside interface
${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif}
${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif}
${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif}
# Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes
RESERVED-1,
# DHCP auto-configuration, NET-TEST, MULTICAST (class D), and
class E)
# on the outside interface
${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif}
${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif}
${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif}
${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif}
${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif}
# Network Address Translation. This rule is placed here
deliberately
# so that it does not interfere with the surrounding
address-checking
# rules. If for example one of your internal LAN machines had
its IP
# address set to 192.0.2.1 then an incoming packet for it after
being
# translated by natd(8) would match the `deny' rule above.
Similarly
# an outgoing packet
Re: IPFW Rules and Games
On Fri, Nov 02, 2007 at 10:59:04PM +0100, [EMAIL PROTECTED] wrote:
onet=`ifconfig xl0 | grep inet | awk '{print $6}'`
I'm not sure about this. Isn't the sixth word the broadcast address
(ending with .255)?
It's correct. I've been using this in my firewall file since FBSD
4.something. No problems. By default, awk uses spaces as column
delimiters. The line containing inet starts with eight spaces. Try it
and see what happens.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how many IPFW rules?
In the last episode (Oct 30), eBoundHost: Artur said: Hello FreeBSD people! I have a smtp server under attack by what seems like a large botnet. My inetd is choking under the load and not allowing real mail through. I've successfully used tshark to find the offenders and put them into ipfw firewall for port 25. So here is my question, I'm currently blocking 55,529 ip addresses and the server seems pretty snappy, with no noticible load or lag. How many more rulesets will I be able to handle before things start getting fuzzy? If you've created 55K separate rules and you're not seeing any slowdown, then you must have a fast machine :) Using an ipfw table should be even better, though. That lets you load any number of ip/netmask pairs into a tree-based lookup table and match all addresses using one ipfw rule. The ipfw manpage has examples. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how many IPFW rules?
I'm not going to brag but this is one hell of a server :-) hardware prices were not a concern when we built it. Thanks for the pointer I'll definitely manpage it now that I know where to start looking. --Original Message-- From: Dan Nelson Sender: To: eBoundHost: Artur Cc: freebsd-questions@freebsd.org Sent: Oct 30, 2007 23:36 Subject: Re: how many IPFW rules? In the last episode (Oct 30), eBoundHost: Artur said: Hello FreeBSD people! I have a smtp server under attack by what seems like a large botnet. My inetd is choking under the load and not allowing real mail through. I've successfully used tshark to find the offenders and put them into ipfw firewall for port 25. So here is my question, I'm currently blocking 55,529 ip addresses and the server seems pretty snappy, with no noticible load or lag. How many more rulesets will I be able to handle before things start getting fuzzy? If you've created 55K separate rules and you're not seeing any slowdown, then you must have a fast machine :) Using an ipfw table should be even better, though. That lets you load any number of ip/netmask pairs into a tree-based lookup table and match all addresses using one ipfw rule. The ipfw manpage has examples. -- Dan Nelson [EMAIL PROTECTED] Best Regards, Artur eBoundHost http://www.eboundhost.com [EMAIL PROTECTED]___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how many IPFW rules?
On Tuesday 30 October 2007 22:57:31 eBoundHost: Artur wrote: Hello FreeBSD people! I have a smtp server under attack by what seems like a large botnet. My inetd is choking under the load and not allowing real mail through. I've successfully used tshark to find the offenders and put them into ipfw firewall for port 25. So here is my question, I'm currently blocking 55,529 ip addresses and the server seems pretty snappy, with no noticible load or lag. How many more rulesets will I be able to handle before things start getting fuzzy? Do you use 55,529 rules? well, if you do, stop doing it :) There is a solution designed for large sets of addresses, so you better use it. Search the ipfw manual page for lookup table. Apparently, there is no problem doing it the way you do it for your load, but tables are designed for such situations and should be more appopriate and lightweight. Nikos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
how many IPFW rules?
Hello FreeBSD people! I have a smtp server under attack by what seems like a large botnet. My inetd is choking under the load and not allowing real mail through. I've successfully used tshark to find the offenders and put them into ipfw firewall for port 25. So here is my question, I'm currently blocking 55,529 ip addresses and the server seems pretty snappy, with no noticible load or lag. How many more rulesets will I be able to handle before things start getting fuzzy? Best Regards, Artur eBoundHost.com http://www.eboundhost.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Please Help with Confusion about ipfw rules.
I use the sample ipfw rules with keep state as shown in the handbook
firewall section.
People on this list don't have ESP so they can't read your mind about what
rules you have coded.
Posting your ipfw rule set will go a long way to getting a response from
readers of this list.
That being said I recommend you read the ipfw section of the handbook and
use the sample rules listed there.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Martin McCormick
Sent: Thursday, July 26, 2007 10:15 AM
To: freebsd-questions@freebsd.org
Subject: Please Help with Confusion about ipfw rules.
This is a situation where I thought I knew more than I
actually do. I set up a new domain name server with a
client-type firewall after having tested it first, but there is
nothing like hundreds of thousands of packets per hour to show
the weak spots.
I made the mistake of setting up keep-state rules both
coming and going and I now see ipfw complaining frequently about
too many dynamic rules. All I am really trying to do is give
crackers a lot of nothing to look at when scanning the ports on
the system. It isn't doing any NAT or routing, etc. I am not
sure if I really need any keep-state rules. The DNS needs to be
accessible to the world and be able to talk to the world on port
53 and that is all as far as bind is concerned.
What I am confused about is when I actually need
keep-state rules and when a simple rule like:
${fwcmd} add pass all from any to ${ip} 53
and
${fwcmd} add pass all from ${ip} to any 53
That theoretically should leave port 53 wide open to all types
of in-bound and out-bound traffic.
Fortunately, the new system is still working, but I am afraid we
might be dropping some packets so I need to modify the port 53
access.
Thanks for your help.
Martin McCormick WB5AGZ Stillwater, OK
Systems Engineer
OSU Information Technology Department Network Operations Group
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Please Help with Confusion about ipfw rules. Solved.
fbsd2 writes:
I use the sample ipfw rules with keep state as shown in the handbook
they do work fine. They just aren't meant for the kind of load
they were under. I needed to know how to get the same
functionality by other means.
If you use the keep-state directive, high traffic can
basically kill ipfw by running it out of dynamic rule space.
People on this list don't have ESP so they can't read your mind about what
rules you have coded.
But they can read down to where it says:
${fwcmd} add pass all from any to ${ip} 53
and
${fwcmd} add pass all from ${ip} to any 53
It turns out that I didn't catch on to the need for supporting
the reply traffic that each of those two rules generate. This
stateless set of rules solved the problem and does not use up
dynamic rule space.
${fwcmd} add allow ip from any to ${ip} dst-port 53
${fwcmd} add allow ip from ${ip} 53 to any // allow reply traffic
${fwcmd} add allow ip from ${ip} to any dst-port 53
${fwcmd} add allow ip from any 53 to ${ip} // allow reply traffic
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Please Help with Confusion about ipfw rules.
This is a situation where I thought I knew more than I
actually do. I set up a new domain name server with a
client-type firewall after having tested it first, but there is
nothing like hundreds of thousands of packets per hour to show
the weak spots.
I made the mistake of setting up keep-state rules both
coming and going and I now see ipfw complaining frequently about
too many dynamic rules. All I am really trying to do is give
crackers a lot of nothing to look at when scanning the ports on
the system. It isn't doing any NAT or routing, etc. I am not
sure if I really need any keep-state rules. The DNS needs to be
accessible to the world and be able to talk to the world on port
53 and that is all as far as bind is concerned.
What I am confused about is when I actually need
keep-state rules and when a simple rule like:
${fwcmd} add pass all from any to ${ip} 53
and
${fwcmd} add pass all from ${ip} to any 53
That theoretically should leave port 53 wide open to all types
of in-bound and out-bound traffic.
Fortunately, the new system is still working, but I am afraid we
might be dropping some packets so I need to modify the port 53
access.
Thanks for your help.
Martin McCormick WB5AGZ Stillwater, OK
Systems Engineer
OSU Information Technology Department Network Operations Group
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules
Ok, i changed my original rules. I'm going to use both the ruleset you recommended and these ones (not at the same time though :). And see which one gives me the least trouble. greetings, jurjen. #!/bin/sh ipfw -q flush cmd=ipfw -q add ks=keep-state oif=ath0 #sort in en out packets $cmd 1 skipto 15 ip from any to any in recv $oif $cmd 2 skipto 100 ip from any to any out xmit $oif #setup the loopback $cmd 011 allow all from any to any via lo0 $cmd 012 deny all from any to 127.0.0.0/8 $cmd 013 deny ip from 127.0.0.0/8 to any $cmd 014 allow icmp from any to any # Outgoing (15) #check state of incoming packets $cmd 015 check-state #internet sites: $cmd 020 allow tcp from me to any 80 out via $oif setup $ks #allow dns queries $cmd 025 allow udp from me to any 53 out via $oif $ks #to stack $cmd 030 allow all from me to 131.155.0.0/16 via $oif $ks #e-mail pop $cmd 040 allow tcp from me to any 110 out via $oif setup $ks #imap #$cmd 041 allow tcp from me to any 143 out via $oif setup $ks #allow ssh $cmd 050 allow all from me to any 22 out via $oif setup $ks #https $cmd 054 allow tcp from me to any 443 out via $oif setup $ks #gopher $cmd 055 allow tcp from me to any 70 out via $oif setup $ks #root can do anything $cmd 070 allow log all from me to any out via $oif setup $ks uid root # Incoming (100) #log ACK packets that did'nt match the dynamic ruleset $cmd 100 deny log all from any to any established in via $oif #default: deny ip from any to any ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules
Cool! thanks for the reply + suggestions! I haven't had any trouble with my firewall blocking too much yet (also didn't connect to the internet much yet :), but i'll think about just allowing all out... on the other hand i like the idea of just letting through out that i need (which isn't very much) and denying all else. I don't use the file shares on the network, so i figured if i got a packet from one of those addresses it would be a mistake so i let them drop. Anyway, i'll try to build some rules based on the suggestions you made and then i can try them both and then decide which one gives me the least trouble :) greetings, jurjen. On Mon, Dec 18, 2006 at 04:29:06AM +0200, Giorgos Keramidas wrote: On 2006-12-16 18:01, Jurjen Middendorp [EMAIL PROTECTED] wrote: I tried making a firewall for my laptop..but i'm not sure if i forgot anything. And things can always be done better :) #to stack (student computer thing... e-mail, irc, ssh stuff) $cmd 020 allow all from me to 131.155.140.141/16 via $oif $ks #allow ssh $cmd 021 allow all from me to any 22 out via $oif setup $ks #internet sites: $cmd 032 allow tcp from me to any 80 out via $oif setup $ks #https $cmd 033 allow tcp from me to any 443 out via $oif setup $ks #gopher $cmd 034 allow tcp from me to any 70 out via $oif setup $ks #other e-mail #pop $cmd 040 allow tcp from me to any 110 out via $oif setup $ks #imap $cmd 041 allow tcp from me to any 143 out via $oif setup $ks #allow dns queries $cmd 050 allow udp from me to any 53 out via $oif $ks #allow ntp (?) queries $cmd 051 allow udp from me to any 123 out via $oif $ks #i can send icmp myself $cmd 060 allow icmp from me to any out via $oif $ks #but others can't $cmd 061 deny icmp from any to me # #root can do anything $cmd 070 allow tcp from me to any out via $oif setup $ks uid root #log other outgoing packets $cmd 071 deny log all from any to any out via $oif # Incoming #The default is that all other connections will be blocked anyway, but # the more stuff i put in here, the less stuff will get logged #deny incoming to private networks $cmd 100 deny all from 192.168.0.0/16 to any in via $oif#RFC 1918 $cmd 101 deny all from 172.16.0.0/16 to any in via $oif #RFC 1918 $cmd 105 deny all from 169.254.0.0/16 to any in via $oif#DHCP auto $cmd 106 deny all from 192.0.2.0/24 to any in via $oif #reserved $cmd 108 deny all from 192.168.0.0/16 to any in via $oif#D E class # multicast #block smb stuff $cmd 120 deny tcp from any to me 137 in via $oif $cmd 121 deny tcp from any to me 138 in via $oif $cmd 122 deny tcp from any to me 139 in via $oif #log ACK packets that did'nt match the dynamic ruleset $cmd 130 deny log all from any to any established in via $oif #Now log some stuff in case i did something wrong $cmd 999 deny log any to me rule 999 had a syntax error and now it reads ...log all from... that works a bit better :) It's a fairly complex ruleset, but it seems mostly ok. There are a few things I'd change, mostly resulting from my own personal preferences: * I don't like hard-coding rule numbers in IPFW rulesets. * I like using 127.0.0.1/32 instead of any for loopback interfaces. * In general, I prefer much simpler rulesets. * I try to avoid a lot of variables/macros, like your $ks, since they don't really keep things a lot shorter, and when they do they try to abstract away too much of ipfw's syntax. * I don't aggressively filter out ICMP packets. They are useful for a lot of things, they are rate-limited by the kernel, and it is usually silly to block them without a fair amount of knowledge and a very good reason. * I don't deny packets for 'private' networks,like 192.168.0.0/26 because the networks I use with my laptop *ARE* private a lot of the time. Having the firewall block too much and cause me problems is rarely a good way of spending my time. I would probably start with something like: recommendation for ipfw ruleset ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules
On 2006-12-16 18:01, Jurjen Middendorp [EMAIL PROTECTED] wrote: I posted this to the freebsd-security list, but i believe that is not the right list to this question (sorry! this is my first message to the freebsd mailing-lists). I hope this is the right list! :) anyway: I tried making a firewall for my laptop..but i'm not sure if i forgot anything. And things can always be done better :) #to stack (student computer thing... e-mail, irc, ssh stuff) $cmd 020 allow all from me to 131.155.140.141/16 via $oif $ks #allow ssh $cmd 021 allow all from me to any 22 out via $oif setup $ks #internet sites: $cmd 032 allow tcp from me to any 80 out via $oif setup $ks #https $cmd 033 allow tcp from me to any 443 out via $oif setup $ks #gopher $cmd 034 allow tcp from me to any 70 out via $oif setup $ks #other e-mail #pop $cmd 040 allow tcp from me to any 110 out via $oif setup $ks #imap $cmd 041 allow tcp from me to any 143 out via $oif setup $ks #allow dns queries $cmd 050 allow udp from me to any 53 out via $oif $ks #allow ntp (?) queries $cmd 051 allow udp from me to any 123 out via $oif $ks #i can send icmp myself $cmd 060 allow icmp from me to any out via $oif $ks #but others can't $cmd 061 deny icmp from any to me # #root can do anything $cmd 070 allow tcp from me to any out via $oif setup $ks uid root #log other outgoing packets $cmd 071 deny log all from any to any out via $oif # Incoming #The default is that all other connections will be blocked anyway, but # the more stuff i put in here, the less stuff will get logged #deny incoming to private networks $cmd 100 deny all from 192.168.0.0/16 to any in via $oif #RFC 1918 $cmd 101 deny all from 172.16.0.0/16 to any in via $oif #RFC 1918 $cmd 105 deny all from 169.254.0.0/16 to any in via $oif #DHCP auto $cmd 106 deny all from 192.0.2.0/24 to any in via $oif #reserved $cmd 108 deny all from 192.168.0.0/16 to any in via $oif #D E class # multicast #block smb stuff $cmd 120 deny tcp from any to me 137 in via $oif $cmd 121 deny tcp from any to me 138 in via $oif $cmd 122 deny tcp from any to me 139 in via $oif #log ACK packets that did'nt match the dynamic ruleset $cmd 130 deny log all from any to any established in via $oif #Now log some stuff in case i did something wrong $cmd 999 deny log any to me It's a fairly complex ruleset, but it seems mostly ok. There are a few things I'd change, mostly resulting from my own personal preferences: * I don't like hard-coding rule numbers in IPFW rulesets. * I like using 127.0.0.1/32 instead of any for loopback interfaces. * In general, I prefer much simpler rulesets. * I try to avoid a lot of variables/macros, like your $ks, since they don't really keep things a lot shorter, and when they do they try to abstract away too much of ipfw's syntax. * I don't aggressively filter out ICMP packets. They are useful for a lot of things, they are rate-limited by the kernel, and it is usually silly to block them without a fair amount of knowledge and a very good reason. * I don't deny packets for 'private' networks,like 192.168.0.0/26 because the networks I use with my laptop *ARE* private a lot of the time. Having the firewall block too much and cause me problems is rarely a good way of spending my time. I would probably start with something like: : flush=ipfw -q flush : add=ipfw -q add : : oif=ath0 : : $flush : $add allow all from 127.0.0.1/32 to 127.0.0.1/32 via lo0 : $add deny all from 127.0.0.1/32 to any : $add deny all from any to 127.0.0.1/32 : : $add allow icmp from any to any : : $add check-state : : # Allow all outgoing connections. : $add allow all from any to any out via $oif setup keep-state : : # Allow *some* incoming connections (only SSH right now). : $add allow all from any to any 22 in via $oif setup keep-state : : # Block everything else. : $add deny log all from any to any That's pretty minimal, and you can build on top of it :-) If you are using DHCP to get an address for your laptop, you may have to also allow incoming packets from any to 255.255.255.255, destined for UDP port 68, which would make your ruleset: : flush=ipfw -q flush : add=ipfw -q add : : oif=ath0 : : $flush : $add allow all from 127.0.0.1/32 to 127.0.0.1/32 via lo0 : $add deny all from 127.0.0.1/32 to any : $add deny all from any to 127.0.0.1/32 : : $add allow icmp from any to any : : $add check-state : : # Allow all outgoing connections. : $add allow all from any to any out via $oif setup keep-state : : # Allow *some* incoming stuff (only DHCP and SSH right now). : $add allow udp from any to 255.255.255.255 68 in via $oif : $add allow all from any to any 22 in via $oif
ipfw rules
I posted this to the freebsd-security list, but i believe that is not the right list to this question (sorry! this is my first message to the freebsd mailing-lists). I hope this is the right list! :) anyway: I tried making a firewall for my laptop..but i'm not sure if i forgot anything. And things can always be done better :) I'm not sure what i should've put under incoming connections... what i have put there now is pretty useless because the default is to deny, but should i accept any incoming connections that don't match the dynamic rules? I just want to be able to surf the internet without too much trouble and send e-mail and pretty much deny everything else. If someone would have the time to have a quick look at this to see if there's anything wrong with it i would really appreciate it! Bye, jurjen. ps. here is my ruleset: #!/bin/sh ipfw -q flush cmd=ipfw -q add ks=keep-state oif=ath0 #setup the loopback $cmd 001 allow all from any to any via lo0 $cmd 002 deny all from any to 127.0.0.0/8 $cmd 003 deny ip from 127.0.0.0/8 to any #check state of incoming packets $cmd 010 check-state # Outgoing #allow outgoing connections to internetsites, ssh sites # webservers and stack. (keep-state) #to stack (student computer thing... e-mail, irc, ssh stuff) $cmd 020 allow all from me to 131.155.140.141/16 via $oif $ks #allow ssh $cmd 021 allow all from me to any 22 out via $oif setup $ks #internet sites: $cmd 032 allow tcp from me to any 80 out via $oif setup $ks #https $cmd 033 allow tcp from me to any 443 out via $oif setup $ks #gopher $cmd 034 allow tcp from me to any 70 out via $oif setup $ks #other e-mail #pop $cmd 040 allow tcp from me to any 110 out via $oif setup $ks #imap $cmd 041 allow tcp from me to any 143 out via $oif setup $ks #allow dns queries $cmd 050 allow udp from me to any 53 out via $oif $ks #allow ntp (?) queries $cmd 051 allow udp from me to any 123 out via $oif $ks #i can send icmp myself $cmd 060 allow icmp from me to any out via $oif $ks #but others can't $cmd 061 deny icmp from any to me # #root can do anything $cmd 070 allow tcp from me to any out via $oif setup $ks uid root #log other outgoing packets $cmd 071 deny log all from any to any out via $oif # Incoming #The default is that all other connections will be blocked anyway, but # the more stuff i put in here, the less stuff will get logged #deny incoming to private networks $cmd 100 deny all from 192.168.0.0/16 to any in via $oif #RFC 1918 $cmd 101 deny all from 172.16.0.0/16 to any in via $oif #RFC 1918 $cmd 105 deny all from 169.254.0.0/16 to any in via $oif #DHCP auto $cmd 106 deny all from 192.0.2.0/24 to any in via $oif #reserved $cmd 108 deny all from 192.168.0.0/16 to any in via $oif #D E class # multicast #block smb stuff $cmd 120 deny tcp from any to me 137 in via $oif $cmd 121 deny tcp from any to me 138 in via $oif $cmd 122 deny tcp from any to me 139 in via $oif #log ACK packets that did'nt match the dynamic ruleset $cmd 130 deny log all from any to any established in via $oif #Now log some stuff in case i did something wrong $cmd 999 deny log any to me ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Sanity-check for my (working) ipfw rules please...
My individual hosts have a set of firewall rules on each of them that looks like this: /sbin/ipfw add 00010 allow ip from any to any via lo0 /sbin/ipfw add 00020 deny ip from any to 127.0.0.0/8 /sbin/ipfw add 00100 count ip from any to any via em0 in /sbin/ipfw add 00100 count ip from any to any via em0 out /sbin/ipfw add 01000 allow tcp from any to any established /sbin/ipfw add 01010 deny tcp from any to any tcpflags syn tcpoptions !mss /sbin/ipfw add 01011 deny icmp from any to any icmptypes 4,5,9,10,12,13,14,15,16,17,18 /sbin/ipfw add 01012 deny tcp from any to any tcpflags syn,fin /sbin/ipfw add 01013 deny tcp from any to any tcpflags fin,psh,rst,urg /sbin/ipfw add 02001 allow udp from 10.10.10.10 to any 53 /sbin/ipfw add 02002 allow udp from any 53 to 10.10.10.10 /sbin/ipfw add 02003 allow tcp from any to 10.10.10.10 21,22,80,443 setup /sbin/ipfw add 02009 deny ip from any to 10.10.10.10 Easy. Some standard loopback lines, count traffic on the interface, allow established, block out obvious offedners (xmas tree, syn/fin, etc.) and then open up the ports I need and block everything else. Easy. It works great. Two questions: is it appropriate to have line 01000 above all of my bad-behavior lines ? That is, by allowing all established, is it possible that some of those bad tcp packetrs could be let in before they hit my bad-behavior block of ipfw rules ? Or are all of those bad behaviors inconsistent with being an established tcp session ? Second, are there any other bad-behavior blocks I should put into my list? Thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sanity-check for my (working) ipfw rules please...
Ensel Sharon wrote: [ ... ] Two questions: is it appropriate to have line 01000 above all of my bad-behavior lines ? established means ACK and not SYN, basicly. Your bad behavior rules wouldn't really match anything which matches established, but it's probably better to block known-bad stuff earlier on. However, it's not the same thing as stateful tracking, which you might want to consider using depending on what you're doing... -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sanity-check for my (working) ipfw rules please...
On Mon, 10 Jul 2006 18:38:51 -0400 (EDT) Ensel Sharon [EMAIL PROTECTED] wrote: My individual hosts have a set of firewall rules on each of them that looks like this: /sbin/ipfw add 00010 allow ip from any to any via lo0 /sbin/ipfw add 00020 deny ip from any to 127.0.0.0/8 /sbin/ipfw add 00100 count ip from any to any via em0 in /sbin/ipfw add 00100 count ip from any to any via em0 out Note the double-up of rule numbers here... Don't know if you care, but thought I'd point it out. /sbin/ipfw add 01000 allow tcp from any to any established /sbin/ipfw add 01010 deny tcp from any to any tcpflags syn tcpoptions !mss /sbin/ipfw add 01011 deny icmp from any to any icmptypes 4,5,9,10,12,13,14,15,16,17,18 /sbin/ipfw add 01012 deny tcp from any to any tcpflags syn,fin /sbin/ipfw add 01013 deny tcp from any to any tcpflags fin,psh,rst,urg /sbin/ipfw add 02001 allow udp from 10.10.10.10 to any 53 /sbin/ipfw add 02002 allow udp from any 53 to 10.10.10.10 /sbin/ipfw add 02003 allow tcp from any to 10.10.10.10 21,22,80,443 setup /sbin/ipfw add 02009 deny ip from any to 10.10.10.10 Easy. Some standard loopback lines, count traffic on the interface, allow established, block out obvious offedners (xmas tree, syn/fin, etc.) and then open up the ports I need and block everything else. Easy. It works great. Two questions: is it appropriate to have line 01000 above all of my bad-behavior lines ? That is, by allowing all established, is it possible that some of those bad tcp packetrs could be let in before they hit my bad-behavior block of ipfw rules ? Or are all of those bad behaviors inconsistent with being an established tcp session ? As Chuck Swiger pointed out in an earlier reply, you're probably better off moving the rule down below your naughty packet checking. Second, are there any other bad-behavior blocks I should put into my list? How about: deny tcp from any to any tcpflags fin,urg,psh deny tcp from any to any tcpflags syn,fin,rst,ack deny tcp from any to any tcpflags '!syn,!fin,!ack' (rorted from a posting at http://support.daemonnews.org/viewtopic.php?p=846, I have to admit that I havent myself actually checked that these are correct and therefore don't use them myself) and deny all from 10.0.0.0/8 to any in via public interface deny all from 203.219.206.72/30 to any in via internal interface deny all from any to 0.0.0.0/8 via public interface deny all from any to 169.254.0.0/16 via public interface deny all from any to 192.0.2.0/24 via public interface deny all from any to 198.18.0.0/15 via public interface deny all from any to 224.0.0.0/4 via public interface deny all from any to 240.0.0.0/4 via public interface deny all from any to 172.16.0.0 via public interface deny all from any to 192.168.0.0/16 via public interface deny all from 0.0.0.0/8 to any via public interface deny all from 169.254.0.0/16 to any via public interface deny all from 192.0.2.0/24 to any via public interface deny all from 198.18.0.0/15 to any via public interface deny all from 224.0.0.0/4 to any via public interface deny all from 240.0.0.0/4 to any via public interface deny all from 172.16.0.0 to any via public interface deny all from 192.168.0.0/16 to any via public interface Thanks! -- Nick Withers email: [EMAIL PROTECTED] Web: http://www.nickwithers.com Mobile: +61 414 397 446 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sanity-check for my (working) ipfw rules please...
On Tue, 11 Jul 2006 13:16:21 +1000 Nick Withers [EMAIL PROTECTED] wrote: On Mon, 10 Jul 2006 18:38:51 -0400 (EDT) Ensel Sharon [EMAIL PROTECTED] wrote: My individual hosts have a set of firewall rules on each of them that looks like this: (snip) Second, are there any other bad-behavior blocks I should put into my list? How about: deny tcp from any to any tcpflags fin,urg,psh deny tcp from any to any tcpflags syn,fin,rst,ack deny tcp from any to any tcpflags '!syn,!fin,!ack' (rorted from a posting at http://support.daemonnews.org/viewtopic.php?p=846, I have to admit that I havent myself actually checked that these are correct and therefore don't use them myself) and deny all from 10.0.0.0/8 to any in via public interface deny all from 203.219.206.72/30 to any in via internal interface Sorry - 203.219.206.72/30 is the network address for my public interface. deny all from any to 0.0.0.0/8 via public interface deny all from any to 169.254.0.0/16 via public interface deny all from any to 192.0.2.0/24 via public interface deny all from any to 198.18.0.0/15 via public interface deny all from any to 224.0.0.0/4 via public interface deny all from any to 240.0.0.0/4 via public interface deny all from any to 172.16.0.0 via public interface deny all from any to 192.168.0.0/16 via public interface deny all from 0.0.0.0/8 to any via public interface deny all from 169.254.0.0/16 to any via public interface deny all from 192.0.2.0/24 to any via public interface deny all from 198.18.0.0/15 to any via public interface deny all from 224.0.0.0/4 to any via public interface deny all from 240.0.0.0/4 to any via public interface deny all from 172.16.0.0 to any via public interface deny all from 192.168.0.0/16 to any via public interface ...and these actually probably aren't all that appropriate for your situation (i.e., internal client rules, rather than Internet - LAN router) Thanks! Hope this is at least vaguely useful, and sorry for any misleading / inappropriate information! -- Nick Withers email: [EMAIL PROTECTED] Web: http://www.nickwithers.com Mobile: +61 414 397 446 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Dummynet with Dynamic IPFW Rules
I've been looking into using Dummynet for outgoing traffic, and I've found it hard going because the tutorials and how-to's deal with it in isolation, without indicating how it would be used in a real firewall. They generally suggest setting net.inet.ip.fw.one_pass=1, which as I understand it, implies that any packet passed into dummynet is passed statically though the firewall. I want to keep my existing dynamic rules, and it seems that one way would be to keep net.inet.ip.fw.one_pass=0 and follow each dummynet rule with a skipto rule that uses an identical test. So when the packet emerges from dummynet it skips the other pipe and queue rules, and hits the check-state. Something like this: -- ... #prioritize small ack packets 0500 queue 1 tcp from any to any out via vr0 tcpflags ack iplen 0-80 0501 skipto 1000 tcp from any to any out via vr0 tcpflags ack iplen 0-80 #prioritize ntp 0600 queue 1 tcp from any to any out ntp via vr0 0601 skipto 1000 tcp from any to any out ntp via vr0 other queuing rules 1000 check-state 1010 deny tcp from any to any in established 1020 allow tcp from any to any out setup keep-state 1030 allow udp from any to any ntp out keep-state other statefull rules -- Will this work? And is it the best way to handle this problem? It seems a bit clumsy. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: help needed for ipfw rules
On Mon, Sep 26, 2005 at 05:26:12PM +0300, Ertan Kucukoglu wrote: Hi, I have a problem blocking foreign intruders for specific ports in ipfw. One of my friends have 4.X-Stable running in production for proxy, e-mail, virus etc. Server also have natd and ipfw installed on it. We have following rule set. - 00050 2132 1212881 divert 8668 ip from any to any via dc1 00100 1078 4537400 allow ip from any to any via lo0 002000 0 deny ip from any to 127.0.0.0/8 003000 0 deny ip from 127.0.0.0/8 to any 004000 0 allow tcp from 192.168.0.0/24 to me 23 005000 0 deny tcp from 192.168.0.69 to me 1863 005500 0 deny tcp from 192.168.0.63 to me 1863 006000 0 deny tcp from 192.168.0.69 to me 80 006500 0 deny tcp from 192.168.0.63 to me 80 010000 0 allow tcp from 192.168.0.0/16 to me 21 010100 0 deny tcp from any to me 21 011000 0 allow tcp from 212.58.X.X to me 1433 via dc1 (ip intentionally hided) 011100 0 deny tcp from any to me 1433 via dc1 65000 5467 3180867 allow ip from any to any 65535 4654 322885 deny ip from any to any - Natd is diverting port 1433 to an internal machine. When I try with a different ip address on Internet than 212.58.x.x, and I can easily get connect to directed servers' 1433 port. I'm sure that I'm missing something, but I can not recognize what it is at the moment. Any help will be appreciated. Regards, Your forgetting that natd changes the destation ip address so that it is not me. Try putting the block rule before the divert. This is also good for performance. -- Alex Please copy the original recipients, otherwise I may not read your reply. Howto's based on my ppersonal use, including information about setting up a firewall and creating traffic graphs with MRTG http://www.kruijff.org/alex/FreeBSD/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
help needed for ipfw rules
Hi, I have a problem blocking foreign intruders for specific ports in ipfw. One of my friends have 4.X-Stable running in production for proxy, e-mail, virus etc. Server also have natd and ipfw installed on it. We have following rule set. - 00050 2132 1212881 divert 8668 ip from any to any via dc1 00100 1078 4537400 allow ip from any to any via lo0 002000 0 deny ip from any to 127.0.0.0/8 003000 0 deny ip from 127.0.0.0/8 to any 004000 0 allow tcp from 192.168.0.0/24 to me 23 005000 0 deny tcp from 192.168.0.69 to me 1863 005500 0 deny tcp from 192.168.0.63 to me 1863 006000 0 deny tcp from 192.168.0.69 to me 80 006500 0 deny tcp from 192.168.0.63 to me 80 010000 0 allow tcp from 192.168.0.0/16 to me 21 010100 0 deny tcp from any to me 21 011000 0 allow tcp from 212.58.X.X to me 1433 via dc1 (ip intentionally hided) 011100 0 deny tcp from any to me 1433 via dc1 65000 5467 3180867 allow ip from any to any 65535 4654 322885 deny ip from any to any - Natd is diverting port 1433 to an internal machine. When I try with a different ip address on Internet than 212.58.x.x, and I can easily get connect to directed servers' 1433 port. I'm sure that I'm missing something, but I can not recognize what it is at the moment. Any help will be appreciated. Regards, -- Ertan Küçükoğlu [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Effective ipfw rules for blocking MSN Messenger ... ?
I just setup a FreeBSD box for a router, so that I could make use of ipfw to block MSN Messenger traffic ... but I'm having a bugger of a time finding a definitive list of what needs to be blocked :( MSN Messenger appears to be smart enough to go *around* the usual port 1863 and onto port 80 if it needs to ... Can someone that has successfully done this using ipfw send me a list of rules, since obviously I'm not catching it :( Thanks ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Effective ipfw rules for blocking MSN Messenger ... ?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chuck Swiger Sent: Thursday, December 23, 2004 3:33 PM To: Marc G. Fournier Cc: freebsd-questions@freebsd.org Subject: Re: Effective ipfw rules for blocking MSN Messenger ... ? Marc G. Fournier wrote: I just setup a FreeBSD box for a router, so that I could make use of ipfw to block MSN Messenger traffic ... but I'm having a bugger of a time finding a definitive list of what needs to be blocked :( I believe that MSN Messenger dynamically allocates ports. I know this is true for audio and video communications. The standard SIP port is 5060 if that helps. Tom One more thing to clarify. I think by blocking the SIP port you could stop Messenger from receiving contact presence information and hence, block Messenger. Tom ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Are 4 IPFW rules enough?
Kevin Curran wrote: I have a cable modem and I'm using 4.9 as a NAT router for my home network. I have 4 rules in my ipfw config. The first enables NAT and the last is 65000 allow any to any. In between I ha 2 rules to deny access to ports 53 and 110 on the Internet side. That's all. Here's my thinking: I use inetd.conf to enable only the services I want, therefore the ports on which those services are listening I would want open. The two other ports I want to filter on the WAN side are filtered by the rules above. All the other ports are closed, anyway, so why spend time debugging an elaborate rule set? What has to be so elaborate? ipfw add rulenum deny ip from any to me in via oif setup And it's generally a good idea to think about egress as well. It's the strategy you're using for inetd, it should probably be the way you do your firewall. Build the wall with the gates where you want them instead of the other way 'round. My $0.02, Kevin Kinsey ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Are 4 IPFW rules enough?
I have a cable modem and I'm using 4.9 as a NAT router for my home network. I have 4 rules in my ipfw config. The first enables NAT and the last is 65000 allow any to any. In between I ha 2 rules to deny access to ports 53 and 110 on the Internet side. That's all. Here's my thinking: I use inetd.conf to enable only the services I want, therefore the ports on which those services are listening I would want open. The two other ports I want to filter on the WAN side are filtered by the rules above. All the other ports are closed, anyway, so why spend time debugging an elaborate rule set? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Are 4 IPFW rules enough?
Kevin Curran [EMAIL PROTECTED] wrote: I have a cable modem and I'm using 4.9 as a NAT router for my home network. I have 4 rules in my ipfw config. The first enables NAT and the last is 65000 allow any to any. In between I ha 2 rules to deny access to ports 53 and 110 on the Internet side. That's all. Here's my thinking: I use inetd.conf to enable only the services I want, therefore the ports on which those services are listening I would want open. The two other ports I want to filter on the WAN side are filtered by the rules above. All the other ports are closed, anyway, so why spend time debugging an elaborate rule set? Check the output of sockstat -4 to ensure that you don't have anything running that you aren't aware of ... syslogd is a typical culpret. You'll probably have to add syslogd_flags=-ss to /etc/rc.conf Otherwise, you're probably good, execpt that there are some spoofing techniques that may be able to get around such a ruleset. That's beyond my expertise, however. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Are 4 IPFW rules enough?
Boy are you naïve. If firewall protection was that simple every body would be doing it your way. I have just completed my final draft of the complete rewrite of the FBSD handbook firewall section. Here is the URL where you can access it. www.a1poweruser.com/FBSD_firewall/ Give it a read and learn about all your FBSD firewall options -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kevin Curran Sent: Monday, June 14, 2004 9:12 PM To: [EMAIL PROTECTED] Subject: Are 4 IPFW rules enough? I have a cable modem and I'm using 4.9 as a NAT router for my home network. I have 4 rules in my ipfw config. The first enables NAT and the last is 65000 allow any to any. In between I ha 2 rules to deny access to ports 53 and 110 on the Internet side. That's all. Here's my thinking: I use inetd.conf to enable only the services I want, therefore the ports on which those services are listening I would want open. The two other ports I want to filter on the WAN side are filtered by the rules above. All the other ports are closed, anyway, so why spend time debugging an elaborate rule set? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: does NATd _prevent_ use of stateful ipfw rules w/ keep-state?
JJB [EMAIL PROTECTED] schrieb: Thanks for your example. I have finally had time to study it and I see the flaw in it. The example works fine for creating the entry in the dynamic table for setup of keep-state inbound and outbound session start requests. It even handles inbound packets that are part of an established session conversations, But for established outbound session conversations the check-state rule releases the packet before it has been nated. No. 'check-state' does not unconditionally release a packet but performs the 'action'-part of the rule that installed the dynamic rule - in our case 'skipto 1' where it gets nat'ed. There lies in the flaw. Do you have any suggestions on how to correct this? Have you tried the script and it really failed? I just double-checked and it works fine on my system. Thomas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Thomas Wolf Sent: Thursday, June 03, 2004 3:00 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? JJB [EMAIL PROTECTED] schrieb: Where do you get off calling my questioning of Luigi Rizzo's answer as an attack. I have heard that party line statement all to often over that last 4 years, with no backup proof. That party line canned answer may be sufficient for the original thread poster who has not invested the time yet to come to the realization that it doe's not work. My post to the tread was meant to bring this problem out so the experts can look into it and take corrective actions. This should work although some features are missing (loopback, anti-spoofing, identd..): #!/bin/sh log=log cmd=ipfw add allow=skipto 1 oif=rl0 good_tcp=22,25,53,80,443,110 good_udp=53 good_icmp=icmptypes 0,3,8,11,12 ipfw -f flush $cmd 100 divert natd ip from any to any in via $oif $cmd 105 check-state $cmd 110 $allow icmp from any to any $good_icmp $cmd 120 $allow udp from any to any $good_udp out keep-state $cmd 130 $allow tcp from any to any $good_tcp out setup keep-state $cmd 140 deny $log ip from any to any $cmd 1 divert natd ip from any to any out via $oif $cmd 10010 allow ip from any to any $cmd 10020 deny ip from any to any Thomas -- Thomas Wolf Wiener Software Fabrik Dubas u. Wolf GMBH 1050 Wien, Mittersteig 4 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED] -- Thomas Wolf Wiener Software Fabrik Dubas u. Wolf GMBH 1050 Wien, Mittersteig 4 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: does NATd _prevent_ use of stateful ipfw rules w/ keep-state?
Thanks for your example. I have finally had time to study it and I see the flaw in it. The example works fine for creating the entry in the dynamic table for setup of keep-state inbound and outbound session start requests. It even handles inbound packets that are part of an established session conversations, But for established outbound session conversations the check-state rule releases the packet before it has been nated. There lies in the flaw. Do you have any suggestions on how to correct this? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Thomas Wolf Sent: Thursday, June 03, 2004 3:00 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: does NATd _prevent_ use of stateful ipfw rules w/ keep-state? JJB [EMAIL PROTECTED] schrieb: Where do you get off calling my questioning of Luigi Rizzo's answer as an attack. I have heard that party line statement all to often over that last 4 years, with no backup proof. That party line canned answer may be sufficient for the original thread poster who has not invested the time yet to come to the realization that it doe's not work. My post to the tread was meant to bring this problem out so the experts can look into it and take corrective actions. This should work although some features are missing (loopback, anti-spoofing, identd..): #!/bin/sh log=log cmd=ipfw add allow=skipto 1 oif=rl0 good_tcp=22,25,53,80,443,110 good_udp=53 good_icmp=icmptypes 0,3,8,11,12 ipfw -f flush $cmd 100 divert natd ip from any to any in via $oif $cmd 105 check-state $cmd 110 $allow icmp from any to any $good_icmp $cmd 120 $allow udp from any to any $good_udp out keep-state $cmd 130 $allow tcp from any to any $good_tcp out setup keep-state $cmd 140 deny $log ip from any to any $cmd 1 divert natd ip from any to any out via $oif $cmd 10010 allow ip from any to any $cmd 10020 deny ip from any to any Thomas -- Thomas Wolf Wiener Software Fabrik Dubas u. Wolf GMBH 1050 Wien, Mittersteig 4 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules
RYAN vAN GINNEKEN wrote: I know this has probably been posted 1000's of times but i would like to set up a ipfw firewall i run many services on this machine. It acts as a gateway for my network APACHE web server IMAP mail server SMTP mail server BIND name server FTP server also i would like to be able to forward packets to a machine on my network for VNC and also gaming purposes. Just interested in where to find some good rules sets and documentation on the subject Here's a page that contains a long list of links posted by someone on this list: http://freebsd.amazingdev.com/blog/archives/000112.html -- Jonathan Arnold (mailto:[EMAIL PROTECTED]) Daemon Dancing in the Dark, a FreeBSD weblog: http://freebsd.amazingdev.com/blog/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw rules
I know this has probably been posted 1000's of times but i would like to set up a ipfw firewall i run many services on this machine. It acts as a gateway for my network APACHE web server IMAP mail server SMTP mail server BIND name server FTP server also i would like to be able to forward packets to a machine on my network for VNC and also gaming purposes. Just interested in where to find some good rules sets and documentation on the subject THANK YOU. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules
On Thursday 04 March 2004 01:42, RYAN vAN GINNEKEN wrote: I know this has probably been posted 1000's of times but i would like to set up a ipfw firewall i run many services on this machine. It acts as a gateway for my network APACHE web server 80/TCP and perhaps 443/TCP IMAP mail server 143/TCP SMTP mail server 25/TCP BIND name server 53/UDP for xfers 53/TCP FTP server 21/TCP 20/TCP maybe (I use ipf but the principles are the same) - block in/out packages you never want to see at all (e.g. with weird opts or too short to be normal) - block in anything from your own IP - block in anything from private addresses (you can get and update lists of these) - let no broadcasting packets come in or go out even on wrong bcast addresses - block in (and log) everything else except: - your services on their ports keep state and with proxy if needed (ftp?) - let everything outward go and keep state or: - let nothing out except what you may initialize (and keep state) e.g. web traffic, mail retrieval, etc. More cumbersome. - decide on ping etc, what do you want to come in and what ICMP do you want to respond to - send out resets rather than ICMP-no-answer or whatever it's called on blocked ports Keep huge big logs at first, then later strip out what you know means no harm. I don't know about VNC. HTH, Dan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW rules
Articles based on solutions that I use:
http://www.kruijff.org/alex/index.php?dir=docs/FreeBSD/
On Tue, Feb 17, 2004 at 08:46:09PM -0800, Saint Aardvark the Carpeted wrote:
Peter Rosa disturbed my sleep to write:
please what's the difference between this ipfw rules:
${fwcmd} add 63000 deny ip from any to 0.0.0.255:0.0.0.255 in via ${oif}
This denies broadcasts coming in to your machine through the outside
interface. The rule number is specified here, and it's rather high; if
it's not stopping the traffic you think it should, there may be another
rule earlier that's allowing it through.
I'm not certain, but I think the address 0.0.0.255:0.0.0.255 means
anything ending in .255
It just an invalid IP adress. At least the first tree number have to be
zero. The invalid IP adress 0.0.0.0 is usaly used by DHCP server (and
maybe clients). This value can be used to filther that without fithering
anything.
Alex
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
IPFW rules
Hi all,
please what's the difference between this ipfw rules:
${fwcmd} add 63000 deny ip from any to 0.0.0.255:0.0.0.255 in via ${oif}
and
${fwcmd} add deny all from any to 255.255.255.255
It seems similar, but I think it is not. Both should stop broadcasts.
Peter Rosa
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW rules
Peter Rosa disturbed my sleep to write:
please what's the difference between this ipfw rules:
${fwcmd} add 63000 deny ip from any to 0.0.0.255:0.0.0.255 in via ${oif}
This denies broadcasts coming in to your machine through the outside
interface. The rule number is specified here, and it's rather high; if
it's not stopping the traffic you think it should, there may be another
rule earlier that's allowing it through.
I'm not certain, but I think the address 0.0.0.255:0.0.0.255 means
anything ending in .255 -- the part after the colon is a netmask, and
for ipfw it means only the last byte of the address needs to match.
This would catch a broadcast going to your local network if it was a /24.
For example, if your local network was 192.168.100.0/24 (/24 is the
same netmask as 255.255.255.0), then this rule would stop broadcasts on
that network (going to 192.168.100.255). It would *not* stop broadcasts
if you had a smaller or larger netmask, where the broadcast address
didn't end in .255.
${fwcmd} add deny all from any to 255.255.255.255
This denies broadcasts going in any direction (from or to your machine),
no matter what the interface. The address specified is different from
the first -- it's 255.255.255.255, and the whole address needs to match.
Usually you'd see this address when the host is trying to figure out
its IP address -- during DHCP requests, say.
Hope that helps,
Hugh
--
Saint Aardvark the Carpeted
[EMAIL PROTECTED]
Because the plural of Anecdote is Myth.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
slow ipfw rules
Helo everyone I have a nat box with a default to deny ruleset, but whenever i ftp through it i get a transfer rate of + - 3kb/s (over lan) Below are what i have in my firewall script: ipfw disable firewall ipfw -f flush int_if=fxp0 ext_if=rl0 # IPFW Count Rules for MRTG ipfw add 10001 count ip from 10.0.5.100 to any via $int_if ipfw add 10002 count ip from any to 10.0.5.100 via $int_if # NAT ipfw add divert natd ip from any to any via $ext_if # Established Rules ipfw add allow tcp from any to any established # Squid ipfw add allow tcp from someip to me 8080 # DNS ipfw add allow udp from any 53 to any ipfw add allow udp from any to any 53 # NFS Stuff ipfw add allow all from 10.0.5.252 to any ipfw add allow all from any to 10.0.5.252 # SNMP ipfw add allow tcp from someip to me 161 in via $ext_if ipfw add allow udp from someip to me 161 in via $ext_if # FTP ipfw add allow tcp from any to any 21 ipfw add allow tcp from any to any 20 ipfw add allow tcp from any to any 49152-65535 # Internal Lan ipfw add reset tcp from 10.0.5.0/24 to any 80 ipfw add allow all from 10.0.5.0/24 to 10.0.5.0/24 ipfw add allow all from any to 10.0.5.0/24 ipfw add allow all from 10.0.5.0/24 to any # HTTP ipfw add allow tcp from 10.0.5.0/24 to me 80 ipfw add allow tcp from someip to me 80 # ICMP ipfw add allow icmp from any to any # SSH ipfw add allow ip from someip to me # localhost ipfw add allow all from me to any # Finally - Enable the firewall again ipfw enable firewall I have replaced nic's and everythin but to no avail. Please help. Thanks Wayne In a world with no boundaries, Who Needs Gates? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw rules help.
Hello everyone. Im on FreeBSD 4.8R, NATd, ipfw enabled, everything working fine. my box is behind a DSL modem router and clients behind the FreeBSD. My LAN is C class IPs. I compiled ipfw to accept by default. This is my ipfw list: 00050 divert 8668 ip from any to any via rl0 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 65000 allow ip from any to any 65535 allow ip from any to any My Questions: a) lets say I want to deny everything except a range of IPs starting from 192.168.1.1 to 192.168.1.50. what rule set should be? how to set range of IPs? to pass and deny rest of the C class. FreeBSD Doc's doesnot cover this? or i didnot see.! b) If i want to deny everything except ip 192.168.1.5 as follow 00400 allow all from 192.168.1.5 to any 01000 deny all from any to any. when ipfw reads the rules and pass by 00400 then comes to 01000 then it denies even the 192.168.1.5, althou i put this rule before the deny ? what im missing? how should i pass 1 ip and deny all? c) If I want rule 00400 to expire in 9PM and be active in 8AM.(EXAMPLE) how do we do that? is it by set a cron job to delete and add the ipfw rule? or there is something to do from the ipfw it self? D) Last Q: IF I restart the box all the rules will be reset, and comes to default. which is reasonable. How to keep it everytime I restart? do i create a file somewhere, and i tell my rc.conf for it? what the rc.conf line should be? and file format? Question out of subject, How i can do something thro cronjob to make the box Email me the log of firewall everyday on certain time, lets say 9PM ? I hope this questions will help many others, as it will help me. And Thank you very much for this list and help. -- Marwan Sultan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules help.
Marwan Sultan disturbed my sleep to write:
I compiled ipfw to accept by default.
This is my ipfw list:
00050 divert 8668 ip from any to any via rl0
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
65000 allow ip from any to any
65535 allow ip from any to any
Hm...this may not be a big deal, but is there any reason you're putting
the divert rule before the rules dealing with lo0/127.0.0.0/8? The
default FreeBSD open firewall ruleset usually puts the divert rule after
-- this would be rule 400 in your example.
a) lets say I want to deny everything except a range of IPs
starting from 192.168.1.1 to 192.168.1.50.
what rule set should be? how to set range of IPs? to pass
and deny rest of the C class. FreeBSD Doc's doesnot cover this?
or i didnot see.!
man ipfw(8) will help you. Depending on the version of ipfw (I forget
when this syntax was added), you may be able to do this:
ipfw allow all from 192.168.1.{1,50} to any
ipfw deny all from any to any
As for which rule it should be...typically what I do is write down
my firewall rules in a separate file, try to make sure that they make
sense (allow rules before deny rules, for example), then try them
out...always making sure that I have some way into the machine if I'm
working remotely! Usually you can let ipfw take care of assigning rule
numbers, unless you've got something fairly special going on.
b) If i want to deny everything except ip 192.168.1.5 as follow
00400 allow all from 192.168.1.5 to any
01000 deny all from any to any.
when ipfw reads the rules and pass by 00400 then comes to 01000
then it denies even the 192.168.1.5, althou i put this rule before the
deny ? what im missing? how should i pass 1 ip and deny all?
I'm not sure why that would happen, but you can find out. If you change
that deny rule to a deny-and-log rule, like this:
ipfw deny log all from any to any
you can then run tail -f /var/log/security and see what packets are
being caught by the deny rule. You can also run ipfw show, which
will show you how many packets/bytes are being caught by which rules.
Again, read the man page for ipfw.
Off the top of my head, I suspect you're allowing traffic out, but not
back in -- you haven't listed a rule that would allow replies to TCP
traffic back in, or DNS queries. Denying either of these would make it
look like nothing is working. Try this:
allow tcp from 192.168.1.5 to any
allow udp from 192.168.1.5 to any keep-state
check-state
allow tcp from any to any established
deny all from any to any
c) If I want rule 00400 to expire in 9PM and be active in 8AM.(EXAMPLE)
how do we do that? is it by set a cron job to delete and add
the ipfw rule? or there is something to do from the ipfw it self?
As far as I know, you can only do this with a cron job. Test carefully,
though -- it's frighteningly easy to lock yourself out while doing this
sort of thing. I speak from bitter experience. :-)
D) Last Q: IF I restart the box all the rules will be reset,
and comes to default. which is reasonable.
How to keep it everytime I restart?
do i create a file somewhere, and i tell my rc.conf for it?
what the rc.conf line should be? and file format?
man rc.conf(5) will show you firewall options. What I usually do is
write my own and keep it in a separate file -- I find rc.firewall too
confusing when trying to customize it. But have a look at
/etc/rc.firewall and the simple option -- it probably does a lot of
what you want.
Question out of subject,
How i can do something thro cronjob to make the box Email me the
log of firewall everyday on certain time, lets say 9PM ?
Well, you could just have a script that would, say, grep for today's
date in your firewall logs and email that. Another thing you could
consider doing, though, is signing up at dshield.org and using one of
their clients to parse your logs. Dshield collects firewall information
from volunteers around the world, and uses it to alert people to new
or fast-moving threats. It's an excellent idea, and a lot of help to
security people. I use ipfw2dshield to parse and mail my logs, and as a
bonus I get a copy of the email myself to see if there's anything
interesting.
Hope that helps!
Hugh
--
Saint Aardvark the Carpeted
[EMAIL PROTECTED]
Because the plural of Anecdote is Myth.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules help.
Marwan Sultan wrote: a) lets say I want to deny everything except a range of IPs starting from 192.168.1.1 to 192.168.1.50. what rule set should be? how to set range of IPs? to pass and deny rest of the C class. FreeBSD Doc's doesnot cover this? or i didnot see.! I would set a default to deny, then poke holes through it for the stuff you need, such as add allow ip from 192.168.1.1/5 to any add allow ip from any to 192.168.1.1/5 (which sets up to use 1.1 to 1.32). That netmask is your best friend. b) If i want to deny everything except ip 192.168.1.5 as follow 00400 allow all from 192.168.1.5 to any 01000 deny all from any to any. when ipfw reads the rules and pass by 00400 then comes to 01000 then it denies even the 192.168.1.5, althou i put this rule before the deny ? what im missing? how should i pass 1 ip and deny all? It means something didn't even check it with rule 400. This can be due to an IPDIVERT thing changing the address so it doesn't match, or something similar. c) If I want rule 00400 to expire in 9PM and be active in 8AM.(EXAMPLE) how do we do that? is it by set a cron job to delete and add the ipfw rule? or there is something to do from the ipfw it self? cron job. ipfw doesn't have the capability of doing time-based rulesets. Temporary ones are okay, but time based, it can't really handle. D) Last Q: IF I restart the box all the rules will be reset, and comes to default. which is reasonable. How to keep it everytime I restart? do i create a file somewhere, and i tell my rc.conf for it? what the rc.conf line should be? and file format? Create or edit the '/etc/rc.firewall'. I would only make the changes to allow a firewall type of 'file', and then make rc.conf reference a file that contains the rules. Or, you can add a startup script in /usr/local/etc/rc.d/ that adds the rules. Joe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
NAT and IPFW rules
Hallo! Out from reading the manpage for natd, I have a question about how to restrict IPFW access for NAT for the case when I have one computer connected directly to another one (having two NICs installed into it)? That means that I don't have to care about big private network, but rather want to narrow down the access to single private IP address. For NAT to work, two rules need to be added: ipfw add divert natd all from any to any via xl0 Can this rule be restricted (is it possible to divert not every packets)? Right now, every packet that enters/leaves the system is diverted, sometimes natd process eats quite a lot of processor resources. Can this be avoided? How? ipfw add pass all from any to any How can this be restricted? I basically need only outgoing stuff working, that's all, and silently passing any packets from whatever location to any destination is insecure to me. Can someone post a live examples of such setup? Waiting to hear from some gurus ;) -- Eugene - 25 ! - http://ngs.ru/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: NAT and IPFW rules
Hello Friend First I agree with you the FBSD handbook documentation on firewall software sucks big time. It leads the reader into believing that ipfw is the only solution when it is not. FBSD is delivered with ipfw and IPFILTER which are both firewall software applications. The second thing that the sparse ipfw documentation falls to say, is an firewall that does not use stateful rules is not very secure. The real show stopper is ipfw with stateful rules using the 'keep state' option does not work when used with the divert/nated legacy sub-routine. What this means is ipfw with stateful rules can only be used if 'user ppp -nat' is how you connect to the public internet. IPFILTER 's stateful rules work fine, and it has it's own external ipnat function. I strongly recommend you drop ipfw and instead use IPFILTER as it's the superior firewall software solution from the ease of use of stateful rules. If you use 'user ppp to connect to the public internet and want to continue to use ipfw, I have ipfw stateful rule set I can send you. If you want to use IPFILTER, I can sent of an rule set for it also along with links to doc sites. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Eugene Panchenko Sent: Sunday, February 01, 2004 11:15 AM To: [EMAIL PROTECTED] Subject: NAT and IPFW rules Hallo! Out from reading the manpage for natd, I have a question about how to restrict IPFW access for NAT for the case when I have one computer connected directly to another one (having two NICs installed into it)? That means that I don't have to care about big private network, but rather want to narrow down the access to single private IP address. For NAT to work, two rules need to be added: ipfw add divert natd all from any to any via xl0 Can this rule be restricted (is it possible to divert not every packets)? Right now, every packet that enters/leaves the system is diverted, sometimes natd process eats quite a lot of processor resources. Can this be avoided? How? ipfw add pass all from any to any How can this be restricted? I basically need only outgoing stuff working, that's all, and silently passing any packets from whatever location to any destination is insecure to me. Can someone post a live examples of such setup? Waiting to hear from some gurus ;) -- Eugene - 25 ! - http://ngs.ru/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw rules for letting ssh requests in
I can't seem to get the ipfw rules right for letting ssh clients access a ssh
server. I can use ssh on the server to connect to the client; but if I try
to connect from the client to the server, the operation times out.
I have my rules in /etc/ipfw.rules. Executing 'ipfw show' displays all of the
rules as expected. It also shows packets having been allowed at rule 300
after an attempt to connect has been made.
I have copied the top portion of /etc/ipfw.rules:
#!/bin/sh
# Andrew L. Gould's firewall rules.
fwcmd=/sbin/ipfw -q
${fwcmd} -f flush
# Basic rules that should not be changed
${fwcmd} add 00100 pass all from any to any via lo0
${fwcmd} add 00110 deny all from any to 127.0.0.0/8
${fwcmd} add 00120 deny ip from 127.0.0.0/8 to any
# Allow specified service requests in
# ssh
${fwcmd} add 00300 allow tcp from any to me 22
${fwcmd} add 00301 allow udp from any to me 22
##
Does anyone have any idea why the operation is timing out or what I have done
wrong?
Thanks,
Andrew Gould
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules for letting ssh requests in
On Monday 19 January 2004 00:47, Andrew L. Gould wrote:
I can't seem to get the ipfw rules right for letting ssh clients access a
ssh server. I can use ssh on the server to connect to the client; but if I
try to connect from the client to the server, the operation times out.
I have my rules in /etc/ipfw.rules. Executing 'ipfw show' displays all of
the rules as expected. It also shows packets having been allowed at rule
300 after an attempt to connect has been made.
I have copied the top portion of /etc/ipfw.rules:
#!/bin/sh
# Andrew L. Gould's firewall rules.
fwcmd=/sbin/ipfw -q
${fwcmd} -f flush
# Basic rules that should not be changed
${fwcmd} add 00100 pass all from any to any via lo0
${fwcmd} add 00110 deny all from any to 127.0.0.0/8
${fwcmd} add 00120 deny ip from 127.0.0.0/8 to any
# Allow specified service requests in
# ssh
${fwcmd} add 00300 allow tcp from any to me 22
${fwcmd} add 00301 allow udp from any to me 22
Does anyone have any idea why the operation is timing out or what I have
done wrong?
You forgot the packets in the other direction... This should do the trick :
${fwcmd} add 00300 allow tcp from any to me 22
${fwcmd} add 00301 allow tcp from me 22 to any
grtz,
Daan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules for letting ssh requests in
On Sunday 18 January 2004 05:53 pm, Daan Vreeken [PA4DAN] wrote:
On Monday 19 January 2004 00:47, Andrew L. Gould wrote:
I can't seem to get the ipfw rules right for letting ssh clients access a
ssh server. I can use ssh on the server to connect to the client; but if
I try to connect from the client to the server, the operation times out.
I have my rules in /etc/ipfw.rules. Executing 'ipfw show' displays all
of the rules as expected. It also shows packets having been allowed at
rule 300 after an attempt to connect has been made.
I have copied the top portion of /etc/ipfw.rules:
#!/bin/sh
# Andrew L. Gould's firewall rules.
fwcmd=/sbin/ipfw -q
${fwcmd} -f flush
# Basic rules that should not be changed
${fwcmd} add 00100 pass all from any to any via lo0
${fwcmd} add 00110 deny all from any to 127.0.0.0/8
${fwcmd} add 00120 deny ip from 127.0.0.0/8 to any
# Allow specified service requests in
# ssh
${fwcmd} add 00300 allow tcp from any to me 22
${fwcmd} add 00301 allow udp from any to me 22
Does anyone have any idea why the operation is timing out or what I have
done wrong?
You forgot the packets in the other direction... This should do the trick :
${fwcmd} add 00300 allow tcp from any to me 22
${fwcmd} add 00301 allow tcp from me 22 to any
grtz,
Daan
I have the firewall configured to let anything out. As noted above, I was
able to connect from the server to the client using ssh.
Here's the entirety of /etc/ipfw.rules:
#!/bin/sh
# Andrew L. Gould's firewall rules.
fwcmd=/sbin/ipfw -q
${fwcmd} -f flush
${fwcmd} add 00100 pass all from any to any via lo0
${fwcmd} add 00110 deny all from any to 127.0.0.0/8
${fwcmd} add 00120 deny ip from 127.0.0.0/8 to any
# Allow specified service requests in
# ssh
${fwcmd} add 00300 allow tcp from any to me 22
${fwcmd} add 00301 allow udp from any to me 22
# irc
${fwcmd} add 00302 allow tcp from any to me 194
${fwcmd} add 00303 allow udp from any to me 194
# auth (ident)
${fwcmd} add 00304 allow tcp from any to me 113
${fwcmd} add 00305 allow udp from any to me 113
# ircd
${fwcmd} add 00310 allow tcp from any to me 6667
# Allow TCP connections that were initiated locally
${fwcmd} add 00400 check-state
${fwcmd} add 00402 allow tcp from any to any out setup keep-state
# Allow DNS and DHCP activities
${fwcmd} add 00500 allow udp from any 53 to any in recv dc0
${fwcmd} add 00501 allow udp from any 67 to any 68 in recv dc0
${fwcmd} add 00502 allow udp from any to any out
# Allow ICMP activities
${fwcmd} add 00600 allow icmp from any to any icmptype 0
${fwcmd} add 00601 allow icmp from any to any icmptype 3
${fwcmd} add 00602 allow icmp from any to any icmptype 4
${fwcmd} add 00603 allow icmp from any to any icmptype 8
${fwcmd} add 00604 allow icmp from any to any icmptype 11 in
${fwcmd} add 00901 deny tcp from any to any in established
${fwcmd} add 65535 deny all from any to any
#
Thanks,
Andrew Gould
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules for letting ssh requests in
Does portmap have to be enabled to connect to sshd? Thanks, Andrew Gould ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules for letting ssh requests in
Andrew L. Gould wrote: Does portmap have to be enabled to connect to sshd? No ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw rules for letting ssh requests in
On Sunday 18 January 2004 05:53 pm, Daan Vreeken [PA4DAN] wrote:
You forgot the packets in the other direction... This should do the trick :
${fwcmd} add 00300 allow tcp from any to me 22
${fwcmd} add 00301 allow tcp from me 22 to any
grtz,
Daan
It worked.
Thanks,
Andrew Gould
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
input on ipfw rules
Hi, I would like to get some input of these rules I'm currenly using. I come from a linux/cisco background, so I want to know how bad these are :) mostly my questions are the keep-state stuff. I guess 00235 can go, as I think that one allows all trafic from that specific ip if already connected elsewhere? It is compiled with IP_FIREWALL only, so there is also a 65535 deny ip from any to any. # regular stuff ipfw add 00100 allow ip from any to any via lo0 # normal trafic ipfw add 00220 deny log ip from me to any in ipfw add 00225 deny log tcp from any to any in tcpflags fin,syn ipfw add 00230 check-state ipfw add 00235 allow tcp from any to any in established ipfw add 00240 allow tcp from any to any frag ipfw add 00245 allow ip from any to any keep-state out # icmp ipfw add 00300 allow icmp from any to any icmptype 3 ipfw add 00301 allow icmp from any to any icmptype 4 ipfw add 00302 allow icmp from any to any icmptype 11 # ident ipfw add 00600 allow tcp from any to any 113 keep-state setup # ssh ipfw add 00700 allow tcp from any to me 22 keep-state # webhosting services ipfw add 00800 allow tcp from any to me 80 keep-state ipfw add 00810 allow tcp from any to me 21 keep-state ipfw add 00820 allow tcp from any to me 4-45000 keep-state # dns ipfw add 00900 allow udp from me to any 53 keep-state ipfw add 00910 allow udp from any to me 53 # mail services ipfw add 01000 allow tcp from any to me 143 keep-state ipfw add 01010 allow tcp from any to me 110 keep-state ipfw add 01020 allow tcp from any to me 25 keep-state best regards Robin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input on ipfw rules
On 2003-04-05 21:49, Robin Ericsson [EMAIL PROTECTED] wrote: I would like to get some input of these rules I'm currenly using. I come from a linux/cisco background, so I want to know how bad these are :) mostly my questions are the keep-state stuff. I guess 00235 can go, as I think that one allows all trafic from that specific ip if already connected elsewhere? True. ipfw add 00230 check-state ipfw add 00235 allow tcp from any to any in established You don't need both of these... The 'established' one can safely go away if you make it a habbit of writing rules with 'keep-state' as shown below: # ssh ipfw add 00700 allow tcp from any to me 22 keep-state - Giorgos ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
ipfw rules
Greetings, This is what i came up with for my network after reviewing some docs and talking with some people. i want to run it by you all before i impimented because i want it to be secure before i open up my internal network to the outside world. what do you think of my ipfw rules? do they pretty much match up with my situation below? is there anything i could improve on? thanks for any input, brian this is my situation # rl1 is external nic on the router ip comes from the isp # rl0 is internal nic on the router 192.168.1.254 # internal network is 192.168.1.0/24 # 192.168.1.42 is a machine on the local network with sshd # 192.168.1.42 is a machine on the local network with httpd # 192.168.1.40 is a machine on the local network that needs to access a cisco router at work # 192.168.1.0/24 is a trusted network # allow machine on my local network to ping the router setup - kernel config file -- options IPFIREWALL #ipfw compiled into the kernel options IPFIREWALL_VERBOSE #firewall logging capability - optional options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPDIVERT #natd compiled into the kernel rc.conf --- gateway_enable=YES firewall_enable=YES firewall_type=/etc/ipfw.rules natd_enable=YES natd_interface=rl1 # natd -interface rl1, public interface natd_flags=-f /etc/natd.conf /etc/ipfw.rules --- #Deny TCP Fragments add deny log tcp from any to any via any frag #Allow loopback traffic add allow ip from 127.0.0.1 to 127.0.0.1 via lo0 #Allow LAN Traffic add allow ip from 192.168.1.0/24 to 192.168.1.0/24 via rl0 #Allow other traffic add allow tcp from 192.168.1.0/24 to any via rl0 setup keep-state add allow tcp from any to 192.168.1.0/24 via rl0 established keep-state add allow udp from 192.168.1.0/24 to any via rl0 keep-state add allow udp from any to 192.168.1.0/24 via rl0 keep-state add allow icmp from 192.168.1.0/24 to any via rl0 add allow icmp from any to 192.168.1.0/24 via rl0 #Allow internet traffic add allow tcp from any to any out xmit rl1 setup keep-state add allow tcp from any to any in recv rl1 established keep-state #add allow udp from any to any 53.123 out xmit rl1 keep-state #add allow udp from any 53,123 to any in recv rl1 keep-state #add allow udp from any to any 33433-33533 out xmit rl1 keep-state add allow tcp from any to any 22 in recv rl1 setup keep-state add allow tcp from any 22 to any out xmit rl1 established keep-state #Deny everything else and log it add deny log ip from any to any via any /etc/natd.conf -- use_sockets yes same_ports yes dynamic yes unregistered_only yes redirect_port tcp 192.168.1.42:22 22 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
please comment on my nat/ipfw rules (resent)
hi all i have my test machine set up as a gateway box, with ipfw/natd configured on it, set up to filter/redirect packets bound for a client on my internal network. external ip of my internal client is aliased to the outside nic of the gateway box gateway machine's kernel has been recompiled with: options IPFIREWALL options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE gateway's /etc/rc.conf looks like defaultrouter=129.x.x.1 hostname=hostname.com ifconfig_xl0=inet 129.x.x.1 netmask 255.255.255.0 #aliasing internal client's ip to the outside nic of gateway box ifconfig_xl0_alias0=inet 129.x.1.20 netmask 255.0.0.0 #inside nic of gateway box ifconfig_xl1=inet 10.0.0.1 netmask 255.0.0.0 gateway_enable=YES firewall_enable=YES #firewall_script=/etc/rc.firewall firewall_type=/etc/ipfw.rules natd_enable=YES #natd interface is outside nic natd_interface=xl0 #natd flags redirect any traffic bound for ip of www3 to internal ip of www3 natd_flags=-redirect_address 10.0.0.2 129.x.x.20 kern_securelevel_enable=NO . internal client's /etc/rc.conf looks like second machine's /etc/rc.conf: defaultrouter=10.0.0.1 ifconfig_xl0=inet 10.0.0.2 netmask 255.0.0.0 looks like this setup is working. the internal client is a basic webserver/ftp server. i am able to ftp to it, ssh to it, view webpages that it serves up, etc. with it hooked up to the internal nic of the gateway box. i am now trying to come up with a good set of firewall rules on the gateway box to filter out all unnecessary traffic to my internal network. the following is my /etc/ipfw.rules on the gateway box. -snip-- # firewall_type=/etc/ipfw.rules # enquirer ipfw.rules # NAT add 00100 divert 8668 ip from any to any via xl0 # loopback add 00210 allow ip from any to any via lo0 add 00220 deny ip from any to 127.0.0.0/8 add 00230 deny ip from 127.0.0.0/8 to any #allow tcp in for nfs shares #add 00301 allow tcp from 129.x.x.x to any in via xl0 #add 00302 allow tcp from 129.x.x.x to any in via xl0 #allow tcp in for ftp,ssh, smtp, httpd add 00303 allow tcp from any to any in 21,22,25,80,1 via xl0 #deny rest of incoming tcp add 00309 deny log tcp from any to any in established #from man 8 ipfw: allow only outbound tcp connections i've created add 00310 allow tcp from any to any out via xl0 #allow udp in for gateway for DNS add 00300 allow udp from 10.0.0.0/24 to 129.105.49.1 53 via xl0 #allow udp in for nfs shares #add 00401 allow udp from 129.x.x.x to any in recv xl0 #add 00402 allow udp from 129.x.x.x to any in recv xl0 #allow all udp out from machine add 00404 allow udp from any to any out via xl0 #allow some icmp types (codes not supported) ##allow path-mtu in both directions add 00500 allow icmp from any to any icmptypes 3 ##allow source quench in and out add 00501 allow icmp from any to any icmptypes 4 ##allow me to ping out and receive response back add 00502 allow icmp from any to any icmptypes 8 out add 00503 allow icmp from any to any icmptypes 0 in ##allow me to run traceroute add 00504 allow icmp from any to any icmptypes 11 in add 00600 deny log ip from any to any #--- end ipfw.rules ---# -snip-- any comments on how i could improve this set of ipfw rules to better secure my internal client would be appreciated. thanks again redmond msg17337/pgp0.pgp Description: PGP signature
RE: please comment on my nat/ipfw rules (resent)
1. Your firewall rules are not working at all, except for the natd redirect option. This is caused by the kernel compile time option IPFIREWALL_DEFAULT_TO_ACCEPT.This option tell your firewall that any packet that does not match a rule is allowed to pass on through the firewall. Comment out that option in your kernel options source and recompile your kernel to take the default of default-to-deny and your current rules set will stop functioning. 2. You are using the simplest of the rule types 'state-less'. Using this type of rules you have to not only have a rule to allow the packet out you also have to have a rule to allow the packet in. See rules 220 230 of your posted rule set to see how it should be done. 3. There are 3 classes of rules, each class has separate packet interrogation abilities. Each proceeding class has greater packet interrogation abilities than the previous one. These are stateless, simple stateful, and advanced stateful. The advanced stateful rule class is the only class having technically advanced interrogation abilities capable of defending against the flood of different attack methods currently employed by perpetrators. Stateless and Simple Stateful IPFW firewall rules are inadequate to protect the users system in today's internet environment and leaves the user unknowingly believing they are protected when in reality they are not. 4. The advanced stateful rule option keep-state works as documented only when used in a rule set that does not use the divert rule. Simply stated the IPFW advanced stateful rule option keep-state does not function correctly when used in a IPFW firewall that also is using the IPFW built in NATD function. For the most complete keep-state protection the other FIREWALL solution (IPFILTER) that comes with FBSD should be used. Just checkout the IPFW list archives and you will see this subject discussed in detail with out any solution forthcoming. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Redmond Militante Sent: Friday, January 31, 2003 8:18 AM To: [EMAIL PROTECTED] Subject: please comment on my nat/ipfw rules (resent) hi all i have my test machine set up as a gateway box, with ipfw/natd configured on it, set up to filter/redirect packets bound for a client on my internal network. external ip of my internal client is aliased to the outside nic of the gateway box gateway machine's kernel has been recompiled with: options IPFIREWALL options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE gateway's /etc/rc.conf looks like defaultrouter=129.x.x.1 hostname=hostname.com ifconfig_xl0=inet 129.x.x.1 netmask 255.255.255.0 #aliasing internal client's ip to the outside nic of gateway box ifconfig_xl0_alias0=inet 129.x.1.20 netmask 255.0.0.0 #inside nic of gateway box ifconfig_xl1=inet 10.0.0.1 netmask 255.0.0.0 gateway_enable=YES firewall_enable=YES #firewall_script=/etc/rc.firewall firewall_type=/etc/ipfw.rules natd_enable=YES #natd interface is outside nic natd_interface=xl0 #natd flags redirect any traffic bound for ip of www3 to internal ip of www3 natd_flags=-redirect_address 10.0.0.2 129.x.x.20 kern_securelevel_enable=NO . internal client's /etc/rc.conf looks like second machine's /etc/rc.conf: defaultrouter=10.0.0.1 ifconfig_xl0=inet 10.0.0.2 netmask 255.0.0.0 looks like this setup is working. the internal client is a basic webserver/ftp server. i am able to ftp to it, ssh to it, view webpages that it serves up, etc. with it hooked up to the internal nic of the gateway box. i am now trying to come up with a good set of firewall rules on the gateway box to filter out all unnecessary traffic to my internal network. the following is my /etc/ipfw.rules on the gateway box. -snip-- # firewall_type=/etc/ipfw.rules # enquirer ipfw.rules # NAT add 00100 divert 8668 ip from any to any via xl0 # loopback add 00210 allow ip from any to any via lo0 add 00220 deny ip from any to 127.0.0.0/8 add 00230 deny ip from 127.0.0.0/8 to any #allow tcp in for nfs shares #add 00301 allow tcp from 129.x.x.x to any in via xl0 #add 00302 allow tcp from 129.x.x.x to any in via xl0 #allow tcp in for ftp,ssh, smtp, httpd add 00303 allow tcp from any to any in 21,22,25,80,1 via xl0 #deny rest of incoming tcp add 00309 deny log tcp from any to any in established #from man 8 ipfw: allow only outbound tcp connections i've created add 00310 allow tcp from any to any out via xl0 #allow udp in for gateway for DNS add 00300 allow udp from 10.0.0.0/24 to 129.105.49.1 53 via xl0 #allow udp in for nfs shares #add 00401 allow udp from 129.x.x.x to any in recv xl0 #add 00402 allow udp from 129.x.x.x to any in recv xl0 #allow all udp out from machine add 00404 allow udp from any to any out via xl0 #allow some icmp types (codes not supported
Re: please comment on my nat/ipfw rules (resent)
hi you've sold me :) do you have any good online tutorials to recommend for setting up a gateway/firewall/natd machine using ipfilter/ipnat? thanks redmond 1. Your firewall rules are not working at all, except for the natd redirect option. This is caused by the kernel compile time option IPFIREWALL_DEFAULT_TO_ACCEPT.This option tell your firewall that any packet that does not match a rule is allowed to pass on through the firewall. Comment out that option in your kernel options source and recompile your kernel to take the default of default-to-deny and your current rules set will stop functioning. 2. You are using the simplest of the rule types 'state-less'. Using this type of rules you have to not only have a rule to allow the packet out you also have to have a rule to allow the packet in. See rules 220 230 of your posted rule set to see how it should be done. 3. There are 3 classes of rules, each class has separate packet interrogation abilities. Each proceeding class has greater packet interrogation abilities than the previous one. These are stateless, simple stateful, and advanced stateful. The advanced stateful rule class is the only class having technically advanced interrogation abilities capable of defending against the flood of different attack methods currently employed by perpetrators. Stateless and Simple Stateful IPFW firewall rules are inadequate to protect the users system in today's internet environment and leaves the user unknowingly believing they are protected when in reality they are not. 4. The advanced stateful rule option keep-state works as documented only when used in a rule set that does not use the divert rule. Simply stated the IPFW advanced stateful rule option keep-state does not function correctly when used in a IPFW firewall that also is using the IPFW built in NATD function. For the most complete keep-state protection the other FIREWALL solution (IPFILTER) that comes with FBSD should be used. Just checkout the IPFW list archives and you will see this subject discussed in detail with out any solution forthcoming. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Redmond Militante Sent: Friday, January 31, 2003 8:18 AM To: [EMAIL PROTECTED] Subject: please comment on my nat/ipfw rules (resent) hi all i have my test machine set up as a gateway box, with ipfw/natd configured on it, set up to filter/redirect packets bound for a client on my internal network. external ip of my internal client is aliased to the outside nic of the gateway box gateway machine's kernel has been recompiled with: options IPFIREWALL options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE gateway's /etc/rc.conf looks like defaultrouter=129.x.x.1 hostname=hostname.com ifconfig_xl0=inet 129.x.x.1 netmask 255.255.255.0 #aliasing internal client's ip to the outside nic of gateway box ifconfig_xl0_alias0=inet 129.x.1.20 netmask 255.0.0.0 #inside nic of gateway box ifconfig_xl1=inet 10.0.0.1 netmask 255.0.0.0 gateway_enable=YES firewall_enable=YES #firewall_script=/etc/rc.firewall firewall_type=/etc/ipfw.rules natd_enable=YES #natd interface is outside nic natd_interface=xl0 #natd flags redirect any traffic bound for ip of www3 to internal ip of www3 natd_flags=-redirect_address 10.0.0.2 129.x.x.20 kern_securelevel_enable=NO . internal client's /etc/rc.conf looks like second machine's /etc/rc.conf: defaultrouter=10.0.0.1 ifconfig_xl0=inet 10.0.0.2 netmask 255.0.0.0 looks like this setup is working. the internal client is a basic webserver/ftp server. i am able to ftp to it, ssh to it, view webpages that it serves up, etc. with it hooked up to the internal nic of the gateway box. i am now trying to come up with a good set of firewall rules on the gateway box to filter out all unnecessary traffic to my internal network. the following is my /etc/ipfw.rules on the gateway box. -snip-- # firewall_type=/etc/ipfw.rules # enquirer ipfw.rules # NAT add 00100 divert 8668 ip from any to any via xl0 # loopback add 00210 allow ip from any to any via lo0 add 00220 deny ip from any to 127.0.0.0/8 add 00230 deny ip from 127.0.0.0/8 to any #allow tcp in for nfs shares #add 00301 allow tcp from 129.x.x.x to any in via xl0 #add 00302 allow tcp from 129.x.x.x to any in via xl0 #allow tcp in for ftp,ssh, smtp, httpd add 00303 allow tcp from any to any in 21,22,25,80,1 via xl0 #deny rest of incoming tcp add 00309 deny log tcp from any to any in established #from man 8 ipfw: allow only outbound tcp connections i've created add 00310 allow tcp from any to any out via xl0 #allow udp in for gateway for DNS add 00300 allow udp from 10.0.0.0/24
RE: please comment on my nat/ipfw rules (resent)
# suggested is 32768 bytes. Change from 16384. In release 4.5 the defaults # for these values changed upwards to what they are below. net.inet.tcp.sendspace=32768 net.inet.tcp.recvspace=65536 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Redmond Militante Sent: Friday, January 31, 2003 3:37 PM To: JoeB; [EMAIL PROTECTED] Subject: Re: please comment on my nat/ipfw rules (resent) hi you've sold me :) do you have any good online tutorials to recommend for setting up a gateway/firewall/natd machine using ipfilter/ipnat? thanks redmond 1. Your firewall rules are not working at all, except for the natd redirect option. This is caused by the kernel compile time option IPFIREWALL_DEFAULT_TO_ACCEPT.This option tell your firewall that any packet that does not match a rule is allowed to pass on through the firewall. Comment out that option in your kernel options source and recompile your kernel to take the default of default-to-deny and your current rules set will stop functioning. 2. You are using the simplest of the rule types 'state-less'. Using this type of rules you have to not only have a rule to allow the packet out you also have to have a rule to allow the packet in. See rules 220 230 of your posted rule set to see how it should be done. 3. There are 3 classes of rules, each class has separate packet interrogation abilities. Each proceeding class has greater packet interrogation abilities than the previous one. These are stateless, simple stateful, and advanced stateful. The advanced stateful rule class is the only class having technically advanced interrogation abilities capable of defending against the flood of different attack methods currently employed by perpetrators. Stateless and Simple Stateful IPFW firewall rules are inadequate to protect the users system in today's internet environment and leaves the user unknowingly believing they are protected when in reality they are not. 4. The advanced stateful rule option keep-state works as documented only when used in a rule set that does not use the divert rule. Simply stated the IPFW advanced stateful rule option keep-state does not function correctly when used in a IPFW firewall that also is using the IPFW built in NATD function. For the most complete keep-state protection the other FIREWALL solution (IPFILTER) that comes with FBSD should be used. Just checkout the IPFW list archives and you will see this subject discussed in detail with out any solution forthcoming. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Redmond Militante Sent: Friday, January 31, 2003 8:18 AM To: [EMAIL PROTECTED] Subject: please comment on my nat/ipfw rules (resent) hi all i have my test machine set up as a gateway box, with ipfw/natd configured on it, set up to filter/redirect packets bound for a client on my internal network. external ip of my internal client is aliased to the outside nic of the gateway box gateway machine's kernel has been recompiled with: options IPFIREWALL options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE gateway's /etc/rc.conf looks like defaultrouter=129.x.x.1 hostname=hostname.com ifconfig_xl0=inet 129.x.x.1 netmask 255.255.255.0 #aliasing internal client's ip to the outside nic of gateway box ifconfig_xl0_alias0=inet 129.x.1.20 netmask 255.0.0.0 #inside nic of gateway box ifconfig_xl1=inet 10.0.0.1 netmask 255.0.0.0 gateway_enable=YES firewall_enable=YES #firewall_script=/etc/rc.firewall firewall_type=/etc/ipfw.rules natd_enable=YES #natd interface is outside nic natd_interface=xl0 #natd flags redirect any traffic bound for ip of www3 to internal ip of www3 natd_flags=-redirect_address 10.0.0.2 129.x.x.20 kern_securelevel_enable=NO . internal client's /etc/rc.conf looks like second machine's /etc/rc.conf: defaultrouter=10.0.0.1 ifconfig_xl0=inet 10.0.0.2 netmask 255.0.0.0 looks like this setup is working. the internal client is a basic webserver/ftp server. i am able to ftp to it, ssh to it, view webpages that it serves up, etc. with it hooked up to the internal nic of the gateway box. i am now trying to come up with a good set of firewall rules on the gateway box to filter out all unnecessary traffic to my internal network. the following is my /etc/ipfw.rules on the gateway box. -snip-- # firewall_type=/etc/ipfw.rules # enquirer ipfw.rules # NAT add 00100 divert 8668 ip from any to any via xl0 # loopback add 00210 allow ip from any to any via lo0 add 00220 deny ip from any to 127.0.0.0/8 add 00230 deny ip from 127.0.0.0/8 to any #allow tcp in for nfs shares #add 00301 allow tcp from 129.x.x.x to any in via xl0 #add 00302 allow tcp from 129.x.x.x to any in via xl0 #allow tcp
questions about static ipfw rules
running 4.7 with firewall, natd enabled kernel. i wish to create firewall rules outside of the rc.firewall script that remain static across reboots. to that end, i created a set (rc.firewall.rules), pointing rc.conf to that set: firewall_enable=YES firewall_type=/etc/rc.firewall.rules natd_enable=YES.etc /etc/rc.firewall.rules lines are in the format: add 00100 all ip from any to any via lo0 add 00200 deny ip from any to 127.0.0.0/8 ...etc. is this right? when i boot to these conditions, and ipfw show, i get the set that appears when i set firewall_type=OPEN is this the proper format for rules in a static file? regards to all! stephen d. kingrea To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: questions about static ipfw rules
Stephen D. Kingrea [EMAIL PROTECTED] writes: firewall_enable=YES firewall_type=/etc/rc.firewall.rules This should be one of client etc, see rc(8) for more information. norbert. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: questions about static ipfw rules
On Wed, Jan 22, 2003 at 09:45:09AM -0500, Stephen D. Kingrea wrote: running 4.7 with firewall, natd enabled kernel. i wish to create firewall rules outside of the rc.firewall script that remain static across reboots. to that end, i created a set (rc.firewall.rules), pointing rc.conf to that set: firewall_enable=YES firewall_type=/etc/rc.firewall.rules You should change firewall_type to firewall_script. You should then find all works as you want. natd_enable=YES.etc /etc/rc.firewall.rules lines are in the format: add 00100 all ip from any to any via lo0 add 00200 deny ip from any to 127.0.0.0/8 ...etc. is this right? when i boot to these conditions, and ipfw show, i get the set that appears when i set firewall_type=OPEN is this the proper format for rules in a static file? regards to all! stephen d. kingrea To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message -- Daniel Bye PGP Key: ftp://ftp.slightlystrange.org/pgpkey/dan.asc PGP Key fingerprint: 3D73 AF47 D448 C5CA 88B4 0DCF 849C 1C33 3C48 2CDC _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: questions about static ipfw rules
On Wed, Jan 22, 2003 at 03:18:33PM +, Daniel Bye wrote:
On Wed, Jan 22, 2003 at 09:45:09AM -0500, Stephen D. Kingrea wrote:
running 4.7 with firewall, natd enabled kernel. i wish to create firewall
rules outside of the rc.firewall script that remain static across
reboots. to that end, i created a set (rc.firewall.rules), pointing
rc.conf to that set:
firewall_enable=YES
firewall_type=/etc/rc.firewall.rules
You should change firewall_type to firewall_script. You should then
find all works as you want.
Well, almost... If you do it this way, you need to make sure the script
file is executable and makes sense as a shell script. I use something
like
#!/bin/sh
IPFW=/sbin/ipfw
${IPFW} -f flush
${IPFW} add 100 allow ip from any to any via lo0
... etc.
It works well for me.
Dan
--
Daniel Bye
PGP Key: ftp://ftp.slightlystrange.org/pgpkey/dan.asc
PGP Key fingerprint: 3D73 AF47 D448 C5CA 88B4 0DCF 849C 1C33 3C48 2CDC
_
ASCII ribbon campaign ( )
- against HTML, vCards and X
- proprietary attachments in e-mail / \
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
problems with adding ipfw rules via raw sockets
Hi ppl!
I need to use direct access ti ipfw rules via raw sockets instead of
some scripts using ipfw utility.
I looked into ipfw sources and made a simple program to test if I could
add a simple rule this way.
Just rewrote pieces of original code intomy program w/out any serious
change.
But setsockopt() always return EINVAL and string msg Invalid argument.
And no details. Hence I'm in a fix. Icannot get what's wrong indeed.
Here I place my code (short anough).
Any advice would be appritiated.
Maybe some links to some docs - I failed to find anything but a very
short info in manpages.
#includestdlib.h
#includesys/types.h
#includesys/socket.h
#includesys/queue.h
#includenetinet/in.h
#includenetinet/ip_fw.h
#includearpa/inet.h
#includenetdb.h
#includeerrno.h
inttest(void)
{
int sock,res,sz;
struct ip_fw rule;
sock = socket(AF_INET,SOCK_RAW,IPPROTO_RAW);
if (sock==-1) {printf(\n\nsoket() failed with
\%s\\n\n,strerror(errno)); return -1;};
printf(\nsock = %i\n,sock);
memset(rule,0,sizeof(struct ip_fw));
rule.fw_number = 700;
rule.fw_flg = IP_FW_F_DENY;
rule.fw_src.s_addr = inet_addr(195.48.121.34);
rule.fw_smsk.s_addr = inet_addr(255.255.255.255);
rule.fw_dst.s_addr = inet_addr(127.0.0.0);
rule.fw_dmsk.s_addr = inet_addr(255.0.0.0);
rule.fw_prot = IPPROTO_IP;
sz = sizeof(struct ip_fw);
res = setsockopt(sock,IPPROTO_IP,IP_FW_ADD,rule,sz);
if (res==-1) {printf(\n\nsetsockopt() failed with
\%s\\n\n,strerror(errno)); return -1;};
return 0;
};
intmain(void)
{
test();
return 0;
};
Alexander Komratov
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
Re: questions about static ipfw rules
On Wed, 22 Jan 2003, Daniel Bye wrote:
On Wed, Jan 22, 2003 at 03:18:33PM +, Daniel Bye wrote:
On Wed, Jan 22, 2003 at 09:45:09AM -0500, Stephen D. Kingrea wrote:
running 4.7 with firewall, natd enabled kernel. i wish to create firewall
rules outside of the rc.firewall script that remain static across
reboots. to that end, i created a set (rc.firewall.rules), pointing
rc.conf to that set:
firewall_enable=YES
firewall_type=/etc/rc.firewall.rules
You should change firewall_type to firewall_script. You should then
find all works as you want.
Well, almost... If you do it this way, you need to make sure the script
file is executable and makes sense as a shell script. I use something
like
#!/bin/sh
IPFW=/sbin/ipfw
${IPFW} -f flush
${IPFW} add 100 allow ip from any to any via lo0
... etc.
It works well for me.
Dan
yes, that worked quite well. thank you for that nugget!
i should say that joebs' suggestions concerning ipfilter are worthy of
investigation. i really just needed this to be able to ftp files from
inside my lan without having to retype rules at every boot.
thanks!
stephen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
Re: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?]
On Sat, Oct 26, 2002 at 10:47:48PM +0100, Stacey Roberts wrote: Subject: Re: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?] From: Stacey Roberts [EMAIL PROTECTED] To: D. Penev [EMAIL PROTECTED] Cc: FreeBSD Questions [EMAIL PROTECTED] Date: 26 Oct 2002 22:47:48 +0100 Hi, Thanks for the reply. I should mention that I've made some progress with my efforts to set up a samba PDC for my Win2K clients. First of all I am now able to successfully complete all tests in the recommended DIAGNOSTICS.TXT at http://hr.uoregon.edu/davidrl/DIAGNOSIS.txt, except:- test 8: On the PC type the command net view \\BIGSERVER Specifically, I am only able to complete this test by using the IP Addr of the samba server in place of its name. Likewise for test 9 that follows. Recapping, I *am* able to serve share dirs to *NIX clients as well as the Win2K boxes, with the caveat that for the Windows boxes, I have to use the IP Addr of the samba server. This is not an issue for other (*NIX) client hosts. Needless to say, I am not as yet able to have the Win2K boxes join the domain as described in Chapter 9. (How to Configure Samba 2.2 as a Primary Domain Controller - 9.4.3. Joining the Client to the Domain.4.3. Joining the Client to the Domain). I still get the MS error when I click OK after entering the domain as defined in smb.conf. Hope this presents somewhat a clearer description of the current status here. Do get back to if you would require more information in assisting me in resolving this. From you description of the problem it's looks like that win2k box can't make resolving of names to ip address. That's why I accent to firewall because according to you logs ipfw block port 137, which is used to resolve NetBIOS names to IP address. I make a little test and block port 137 on my PDC (Samba 2.2.4 on NetBSD) and results are the same as yours. If that is true (blocking of netbios-ns port) you PDC can't register as domain controler, and workstations when is joined to domain can't find who is PDC for this domain. What are you firewall rules? What's show nbtstat -A YOU_SAMBA_SERVER and nbtstat -c on win2k box? Thanks On Sat, 2002-10-26 at 22:26, D. Penev wrote: On Mon, Oct 21, 2002 at 07:33:58PM +0100, Stacey Roberts wrote: Subject: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?] From: Stacey Roberts [EMAIL PROTECTED] To: Andrew Boothman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], FreeBSD Questions [EMAIL PROTECTED] Date: 21 Oct 2002 19:33:58 +0100 Hello, I'd appreciate some help from anyone who's got samba 2.2.6 running on FreeBSD as a PDC for Win2K client wkstations, please. I'm trying to following the SAMBA How-To at: http://samba.epfl.ch/samba/docs/Samba-HOWTO-Collection.html#AEN60 but fail at the smbclient -L PDC host stage: # smbclient -L -N Demon added interface ip=192.168.1.8 bcast=192.168.1.255 nmask=255.255.255.0 Packet send failed to 192.168.1.255(137) ERRNO=Permission denied Connection to -N failed # I get these entries in /var/log/security: Oct 21 19:31:08 Demon /kernel: ipfw: 910 Deny UDP My IP:2308 net.255:137 out via sis0 You firewall blocks packets to port 137 (netbios-ns). That's why you can access samba server with ip address and not by name. Please help me out here. Stacey On Mon, 2002-10-21 at 02:32, Andrew Boothman wrote: Stacey Roberts wrote: Hello, I've got 2 WIN2K Pro workstations on my home lan that I'd like to enable network logon for. I've been banging my head against a wall for the last four hours trying to get this sorted, but to no avail. I keep getting the same error when trying to enter the Domain name into the WORKGROUP field in Win2K network properties: The following error occured validating the name my_domainname, This condition may be caused by a DNS lookup problem. For more information about troubleshooting common DNS lookup problems see the following Microsoft blah., blah.., blah.., The specified domain either does not exist or could not be contacted. Have you added machine accounts to the FreeBSD box for the client boxes? You need machine accounts that look like clientname$ (dollar sign at end) added both as local accounts and then again with smbpasswd passing whatever the appropriate switch is to create a machine account. I have a FreeBSD box here acting as a PDC so we should be able to find the problem. Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message -- Stacey Roberts B.Sc (HONS) Computer Science Web: www.vickiandstacey.com -- Regards, D. Penev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message -- Stacey Roberts B.Sc (HONS) Computer Science Web: www.vickiandstacey.com -- Regards, D. Penev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?]
Hi, Here's the relevant lines in my firewall: 00620 allow udp from any to any 137 keep-state out xmit sis0 00621 allow tcp from any to any 137 keep-state out xmit sis0 00623 allow log logamount 10 tcp from Win2KBox to me 137,138 keep-state in recv sis0 setup 00624 allow udp from any to any 138 keep-state out xmit sis0 00625 allow tcp from any to any 138 keep-state out xmit sis0 The output from nbtstat -A SAMBA_SERVER_IP: Host not found The output from nbtstat -c: No names in cache After running both commands, no new entries in /var/log/security appear for packets issued from Win2K box. Hope this helps. Stacey On Sun, 2002-10-27 at 07:15, D. Penev wrote: On Sat, Oct 26, 2002 at 10:47:48PM +0100, Stacey Roberts wrote: Subject: Re: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?] From: Stacey Roberts [EMAIL PROTECTED] To: D. Penev [EMAIL PROTECTED] Cc: FreeBSD Questions [EMAIL PROTECTED] Date: 26 Oct 2002 22:47:48 +0100 Hi, Thanks for the reply. I should mention that I've made some progress with my efforts to set up a samba PDC for my Win2K clients. First of all I am now able to successfully complete all tests in the recommended DIAGNOSTICS.TXT at http://hr.uoregon.edu/davidrl/DIAGNOSIS.txt, except:- test 8: On the PC type the command net view \\BIGSERVER Specifically, I am only able to complete this test by using the IP Addr of the samba server in place of its name. Likewise for test 9 that follows. Recapping, I *am* able to serve share dirs to *NIX clients as well as the Win2K boxes, with the caveat that for the Windows boxes, I have to use the IP Addr of the samba server. This is not an issue for other (*NIX) client hosts. Needless to say, I am not as yet able to have the Win2K boxes join the domain as described in Chapter 9. (How to Configure Samba 2.2 as a Primary Domain Controller - 9.4.3. Joining the Client to the Domain.4.3. Joining the Client to the Domain). I still get the MS error when I click OK after entering the domain as defined in smb.conf. Hope this presents somewhat a clearer description of the current status here. Do get back to if you would require more information in assisting me in resolving this. From you description of the problem it's looks like that win2k box can't make resolving of names to ip address. That's why I accent to firewall because according to you logs ipfw block port 137, which is used to resolve NetBIOS names to IP address. I make a little test and block port 137 on my PDC (Samba 2.2.4 on NetBSD) and results are the same as yours. If that is true (blocking of netbios-ns port) you PDC can't register as domain controler, and workstations when is joined to domain can't find who is PDC for this domain. What are you firewall rules? What's show nbtstat -A YOU_SAMBA_SERVER and nbtstat -c on win2k box? Thanks On Sat, 2002-10-26 at 22:26, D. Penev wrote: On Mon, Oct 21, 2002 at 07:33:58PM +0100, Stacey Roberts wrote: Subject: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?] From: Stacey Roberts [EMAIL PROTECTED] To: Andrew Boothman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], FreeBSD Questions [EMAIL PROTECTED] Date: 21 Oct 2002 19:33:58 +0100 Hello, I'd appreciate some help from anyone who's got samba 2.2.6 running on FreeBSD as a PDC for Win2K client wkstations, please. I'm trying to following the SAMBA How-To at: http://samba.epfl.ch/samba/docs/Samba-HOWTO-Collection.html#AEN60 but fail at the smbclient -L PDC host stage: # smbclient -L -N Demon added interface ip=192.168.1.8 bcast=192.168.1.255 nmask=255.255.255.0 Packet send failed to 192.168.1.255(137) ERRNO=Permission denied Connection to -N failed # I get these entries in /var/log/security: Oct 21 19:31:08 Demon /kernel: ipfw: 910 Deny UDP My IP:2308 net.255:137 out via sis0 You firewall blocks packets to port 137 (netbios-ns). That's why you can access samba server with ip address and not by name. Please help me out here. Stacey On Mon, 2002-10-21 at 02:32, Andrew Boothman wrote: Stacey Roberts wrote: Hello, I've got 2 WIN2K Pro workstations on my home lan that I'd like to enable network logon for. I've been banging my head against a wall for the last four hours trying to get this sorted, but to no avail. I keep getting the same error when trying to enter the Domain name into the WORKGROUP field in Win2K network properties: The following error occured validating the name my_domainname, This condition may be caused by a DNS lookup problem. For more information about troubleshooting common DNS lookup problems see the following Microsoft blah., blah.., blah.., The specified domain either does not exist or could not be contacted. Have you added machine accounts to the FreeBSD box for the client boxes? You need machine accounts that look like clientname
Re: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?]
On Sun, Oct 27, 2002 at 10:50:47AM +, Stacey Roberts wrote: Subject: Re: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?] From: Stacey Roberts [EMAIL PROTECTED] To: D. Penev [EMAIL PROTECTED] Cc: FreeBSD Questions [EMAIL PROTECTED] Date: 27 Oct 2002 10:50:47 + Hi, Here's the relevant lines in my firewall: 00620 allow udp from any to any 137 keep-state out xmit sis0 00621 allow tcp from any to any 137 keep-state out xmit sis0 Add: 00622 allow udp from Win2KBox to any 137,138 keep-state in recv sis0 00623 allow log logamount 10 tcp from Win2KBox to me 137,138 ^^ use any because win2k use broadcast if you don't have wins server keep-state in recv sis0 setup 00624 allow udp from any to any 138 keep-state out xmit sis0 00625 allow tcp from any to any 138 keep-state out xmit sis0 The output from nbtstat -A SAMBA_SERVER_IP: Host not found The output from nbtstat -c: No names in cache After running both commands, no new entries in /var/log/security appear for packets issued from Win2K box. Hope this helps. Stacey On Sun, 2002-10-27 at 07:15, D. Penev wrote: On Sat, Oct 26, 2002 at 10:47:48PM +0100, Stacey Roberts wrote: Subject: Re: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?] From: Stacey Roberts [EMAIL PROTECTED] To: D. Penev [EMAIL PROTECTED] Cc: FreeBSD Questions [EMAIL PROTECTED] Date: 26 Oct 2002 22:47:48 +0100 Hi, Thanks for the reply. I should mention that I've made some progress with my efforts to set up a samba PDC for my Win2K clients. First of all I am now able to successfully complete all tests in the recommended DIAGNOSTICS.TXT at http://hr.uoregon.edu/davidrl/DIAGNOSIS.txt, except:- test 8: On the PC type the command net view \\BIGSERVER Specifically, I am only able to complete this test by using the IP Addr of the samba server in place of its name. Likewise for test 9 that follows. Recapping, I *am* able to serve share dirs to *NIX clients as well as the Win2K boxes, with the caveat that for the Windows boxes, I have to use the IP Addr of the samba server. This is not an issue for other (*NIX) client hosts. Needless to say, I am not as yet able to have the Win2K boxes join the domain as described in Chapter 9. (How to Configure Samba 2.2 as a Primary Domain Controller - 9.4.3. Joining the Client to the Domain.4.3. Joining the Client to the Domain). I still get the MS error when I click OK after entering the domain as defined in smb.conf. Hope this presents somewhat a clearer description of the current status here. Do get back to if you would require more information in assisting me in resolving this. From you description of the problem it's looks like that win2k box can't make resolving of names to ip address. That's why I accent to firewall because according to you logs ipfw block port 137, which is used to resolve NetBIOS names to IP address. I make a little test and block port 137 on my PDC (Samba 2.2.4 on NetBSD) and results are the same as yours. If that is true (blocking of netbios-ns port) you PDC can't register as domain controler, and workstations when is joined to domain can't find who is PDC for this domain. What are you firewall rules? What's show nbtstat -A YOU_SAMBA_SERVER and nbtstat -c on win2k box? Thanks On Sat, 2002-10-26 at 22:26, D. Penev wrote: On Mon, Oct 21, 2002 at 07:33:58PM +0100, Stacey Roberts wrote: Subject: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?] From: Stacey Roberts [EMAIL PROTECTED] To: Andrew Boothman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], FreeBSD Questions [EMAIL PROTECTED] Date: 21 Oct 2002 19:33:58 +0100 Hello, I'd appreciate some help from anyone who's got samba 2.2.6 running on FreeBSD as a PDC for Win2K client wkstations, please. I'm trying to following the SAMBA How-To at: http://samba.epfl.ch/samba/docs/Samba-HOWTO-Collection.html#AEN60 but fail at the smbclient -L PDC host stage: # smbclient -L -N Demon added interface ip=192.168.1.8 bcast=192.168.1.255 nmask=255.255.255.0 Packet send failed to 192.168.1.255(137) ERRNO=Permission denied Connection to -N failed # I get these entries in /var/log/security: Oct 21 19:31:08 Demon /kernel: ipfw: 910 Deny UDP My IP:2308 net.255:137 out via sis0 You firewall blocks packets to port 137 (netbios-ns). That's why you can access samba server with ip address and not by name. Please help me out here. Stacey On Mon, 2002-10-21 at 02:32, Andrew Boothman wrote: Stacey Roberts wrote: Hello, I've got 2 WIN2K Pro workstations on my home lan that I'd like to enable network logon for. I've been banging my head against a wall for the last four hours trying to get this sorted, but to no avail. I keep getting the same error when trying to enter
Re: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?]
Hi, I've got a break-through.., I've been testing with new ipfw options and now I'm able to get past entering the Domain and clicking OK. Now I am getting the Password to log into Domain dialogue box appear. This is the amended rule that appears to make this work: $fwcmd add 00622 allow log udp from $oip to me 137-139 in via $oif $fwcmd add 00624 allow udp from any to any 137-139 out via $oif However, for now, I'm getting: The specified user does not exist when I enter [root] and [root's samba passwd] Any thoughts? Don't think I'm not appreciating your patient efforts to assist me. Cheers! Stacey On Sun, 2002-10-27 at 17:56, D. Penev wrote: On Sun, Oct 27, 2002 at 10:50:47AM +, Stacey Roberts wrote: Subject: Re: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?] From: Stacey Roberts [EMAIL PROTECTED] To: D. Penev [EMAIL PROTECTED] Cc: FreeBSD Questions [EMAIL PROTECTED] Date: 27 Oct 2002 10:50:47 + Hi, Here's the relevant lines in my firewall: 00620 allow udp from any to any 137 keep-state out xmit sis0 00621 allow tcp from any to any 137 keep-state out xmit sis0 Add: 00622 allow udp from Win2KBox to any 137,138 keep-state in recv sis0 00623 allow log logamount 10 tcp from Win2KBox to me 137,138 ^^ use any because win2k use broadcast if you don't have wins server keep-state in recv sis0 setup 00624 allow udp from any to any 138 keep-state out xmit sis0 00625 allow tcp from any to any 138 keep-state out xmit sis0 The output from nbtstat -A SAMBA_SERVER_IP: Host not found The output from nbtstat -c: No names in cache After running both commands, no new entries in /var/log/security appear for packets issued from Win2K box. Hope this helps. Stacey On Sun, 2002-10-27 at 07:15, D. Penev wrote: On Sat, Oct 26, 2002 at 10:47:48PM +0100, Stacey Roberts wrote: Subject: Re: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?] From: Stacey Roberts [EMAIL PROTECTED] To: D. Penev [EMAIL PROTECTED] Cc: FreeBSD Questions [EMAIL PROTECTED] Date: 26 Oct 2002 22:47:48 +0100 Hi, Thanks for the reply. I should mention that I've made some progress with my efforts to set up a samba PDC for my Win2K clients. First of all I am now able to successfully complete all tests in the recommended DIAGNOSTICS.TXT at http://hr.uoregon.edu/davidrl/DIAGNOSIS.txt, except:- test 8: On the PC type the command net view \\BIGSERVER Specifically, I am only able to complete this test by using the IP Addr of the samba server in place of its name. Likewise for test 9 that follows. Recapping, I *am* able to serve share dirs to *NIX clients as well as the Win2K boxes, with the caveat that for the Windows boxes, I have to use the IP Addr of the samba server. This is not an issue for other (*NIX) client hosts. Needless to say, I am not as yet able to have the Win2K boxes join the domain as described in Chapter 9. (How to Configure Samba 2.2 as a Primary Domain Controller - 9.4.3. Joining the Client to the Domain.4.3. Joining the Client to the Domain). I still get the MS error when I click OK after entering the domain as defined in smb.conf. Hope this presents somewhat a clearer description of the current status here. Do get back to if you would require more information in assisting me in resolving this. From you description of the problem it's looks like that win2k box can't make resolving of names to ip address. That's why I accent to firewall because according to you logs ipfw block port 137, which is used to resolve NetBIOS names to IP address. I make a little test and block port 137 on my PDC (Samba 2.2.4 on NetBSD) and results are the same as yours. If that is true (blocking of netbios-ns port) you PDC can't register as domain controler, and workstations when is joined to domain can't find who is PDC for this domain. What are you firewall rules? What's show nbtstat -A YOU_SAMBA_SERVER and nbtstat -c on win2k box? Thanks On Sat, 2002-10-26 at 22:26, D. Penev wrote: On Mon, Oct 21, 2002 at 07:33:58PM +0100, Stacey Roberts wrote: Subject: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?] From: Stacey Roberts [EMAIL PROTECTED] To: Andrew Boothman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], FreeBSD Questions [EMAIL PROTECTED] Date: 21 Oct 2002 19:33:58 +0100 Hello, I'd appreciate some help from anyone who's got samba 2.2.6 running on FreeBSD as a PDC for Win2K client wkstations, please. I'm trying to following the SAMBA How-To at: http://samba.epfl.ch/samba/docs/Samba-HOWTO-Collection.html#AEN60 but fail at the smbclient -L PDC host stage: # smbclient -L -N Demon
Re: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?]
On Mon, Oct 21, 2002 at 07:33:58PM +0100, Stacey Roberts wrote: Subject: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?] From: Stacey Roberts [EMAIL PROTECTED] To: Andrew Boothman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], FreeBSD Questions [EMAIL PROTECTED] Date: 21 Oct 2002 19:33:58 +0100 Hello, I'd appreciate some help from anyone who's got samba 2.2.6 running on FreeBSD as a PDC for Win2K client wkstations, please. I'm trying to following the SAMBA How-To at: http://samba.epfl.ch/samba/docs/Samba-HOWTO-Collection.html#AEN60 but fail at the smbclient -L PDC host stage: # smbclient -L -N Demon added interface ip=192.168.1.8 bcast=192.168.1.255 nmask=255.255.255.0 Packet send failed to 192.168.1.255(137) ERRNO=Permission denied Connection to -N failed # I get these entries in /var/log/security: Oct 21 19:31:08 Demon /kernel: ipfw: 910 Deny UDP My IP:2308 net.255:137 out via sis0 You firewall blocks packets to port 137 (netbios-ns). That's why you can access samba server with ip address and not by name. Please help me out here. Stacey On Mon, 2002-10-21 at 02:32, Andrew Boothman wrote: Stacey Roberts wrote: Hello, I've got 2 WIN2K Pro workstations on my home lan that I'd like to enable network logon for. I've been banging my head against a wall for the last four hours trying to get this sorted, but to no avail. I keep getting the same error when trying to enter the Domain name into the WORKGROUP field in Win2K network properties: The following error occured validating the name my_domainname, This condition may be caused by a DNS lookup problem. For more information about troubleshooting common DNS lookup problems see the following Microsoft blah., blah.., blah.., The specified domain either does not exist or could not be contacted. Have you added machine accounts to the FreeBSD box for the client boxes? You need machine accounts that look like clientname$ (dollar sign at end) added both as local accounts and then again with smbpasswd passing whatever the appropriate switch is to create a machine account. I have a FreeBSD box here acting as a PDC so we should be able to find the problem. Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message -- Stacey Roberts B.Sc (HONS) Computer Science Web: www.vickiandstacey.com -- Regards, D. Penev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?]
Hi, Thanks for the reply. I should mention that I've made some progress with my efforts to set up a samba PDC for my Win2K clients. First of all I am now able to successfully complete all tests in the recommended DIAGNOSTICS.TXT at http://hr.uoregon.edu/davidrl/DIAGNOSIS.txt, except:- test 8: On the PC type the command net view \\BIGSERVER Specifically, I am only able to complete this test by using the IP Addr of the samba server in place of its name. Likewise for test 9 that follows. Recapping, I *am* able to serve share dirs to *NIX clients as well as the Win2K boxes, with the caveat that for the Windows boxes, I have to use the IP Addr of the samba server. This is not an issue for other (*NIX) client hosts. Needless to say, I am not as yet able to have the Win2K boxes join the domain as described in Chapter 9. (How to Configure Samba 2.2 as a Primary Domain Controller - 9.4.3. Joining the Client to the Domain.4.3. Joining the Client to the Domain). I still get the MS error when I click OK after entering the domain as defined in smb.conf. Hope this presents somewhat a clearer description of the current status here. Do get back to if you would require more information in assisting me in resolving this. Thanks On Sat, 2002-10-26 at 22:26, D. Penev wrote: On Mon, Oct 21, 2002 at 07:33:58PM +0100, Stacey Roberts wrote: Subject: IPFW Rules for samba PDC? [WAS: samba PDC for WIN2K clients?] From: Stacey Roberts [EMAIL PROTECTED] To: Andrew Boothman [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], FreeBSD Questions [EMAIL PROTECTED] Date: 21 Oct 2002 19:33:58 +0100 Hello, I'd appreciate some help from anyone who's got samba 2.2.6 running on FreeBSD as a PDC for Win2K client wkstations, please. I'm trying to following the SAMBA How-To at: http://samba.epfl.ch/samba/docs/Samba-HOWTO-Collection.html#AEN60 but fail at the smbclient -L PDC host stage: # smbclient -L -N Demon added interface ip=192.168.1.8 bcast=192.168.1.255 nmask=255.255.255.0 Packet send failed to 192.168.1.255(137) ERRNO=Permission denied Connection to -N failed # I get these entries in /var/log/security: Oct 21 19:31:08 Demon /kernel: ipfw: 910 Deny UDP My IP:2308 net.255:137 out via sis0 You firewall blocks packets to port 137 (netbios-ns). That's why you can access samba server with ip address and not by name. Please help me out here. Stacey On Mon, 2002-10-21 at 02:32, Andrew Boothman wrote: Stacey Roberts wrote: Hello, I've got 2 WIN2K Pro workstations on my home lan that I'd like to enable network logon for. I've been banging my head against a wall for the last four hours trying to get this sorted, but to no avail. I keep getting the same error when trying to enter the Domain name into the WORKGROUP field in Win2K network properties: The following error occured validating the name my_domainname, This condition may be caused by a DNS lookup problem. For more information about troubleshooting common DNS lookup problems see the following Microsoft blah., blah.., blah.., The specified domain either does not exist or could not be contacted. Have you added machine accounts to the FreeBSD box for the client boxes? You need machine accounts that look like clientname$ (dollar sign at end) added both as local accounts and then again with smbpasswd passing whatever the appropriate switch is to create a machine account. I have a FreeBSD box here acting as a PDC so we should be able to find the problem. Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message -- Stacey Roberts B.Sc (HONS) Computer Science Web: www.vickiandstacey.com -- Regards, D. Penev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message -- Stacey Roberts B.Sc (HONS) Computer Science Web: www.vickiandstacey.com signature.asc Description: This is a digitally signed message part
need help with ipfw rules
hi all my apologies, this could get long as i'm including the text of various config files: i've been trying to learn ipfw. i've recompiled a kernel with the following options options ICMP_BANDLIM options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPDIVERT options TCP_DROP_SYNFIN options IPFIREWALL_FORWARD options IPSTEALTH options DUMMYNET my rc.conf: # This file now contains just the overrides from /etc/defaults/rc.conf. defaultrouter=1.1.1.1 gateway_enable=YES hostname=hostname.com ifconfig_xl0=inet 1.1.1.1 netmask 255.255.255.0 inetd_enable=YES firewall_enable=YES firewall_script=/etc/ipfw.rules firewall_type=open firewall_quiet=NO tcp_drop_synfin=NO firewall_logging_enable=YES icmp_drop_redirect=YES log_in_vain=YES sendmail_flags=-bd kern_securelevel_enable=NO linux_enable=YES moused_enable=YES moused_port=/dev/psm0 moused_type=auto nfs_reserved_port_only=YES saver=logo sendmail_enable=YES sshd_enable=YES usbd_enable=YES portmap_enable=YES nfs_server_enable=YES mountd_flags=-r i haven't edited rc.firewall this machine is a combinationi desktop/web/ftp/nfs server. my /etc/ipfw.rules looks like ipfw add allow ip from any to any ipfw add allow ip from 127.0.0.1 to 127.0.0.1 vua lo0 ipfw add allow udp from any to any 53 ipfw add check-state ipfw add allow tcp from any to any 80 setup keep-state ipfw add allow tcp from any to any 53 setup keep-state ipfw add allow tcp from any to any 21 setup keep-state ipfw add allow tcp from any to any 22 setup keep-state ipfw add allow tcp from any to any 25 setup keep-state ipfw add allow tcp from any to any 110 setup keep-state ipfw add allow tcp from any to any 587 setup keep-state ipfw add allow tcp from any to any 3306 setup keep-state ipfw add allow tcp from any to any 1 setup keep-state ipfw add reject tcp from any to any ipfw add allow udp from any to any 53 ipfw add allow icmp from any to any icmptype 0,3,4,8,11 ipfw add deny log logamount 5000 ip from any to any (i was following phoenix's and kirk's ipfw advice in another thread) i've also added !ipfw *.* /var/log/firewall.log to /etc/syslog.conf, touch /var/log/firewall.log, and restarted syslogd. upon reboot, the machine hangs in 3 different places during the bootup process. my bootup messages look like: [snip] additional network daemons:mountd oct 21 15:27:47 hostname mountd[96]: get hostname failed for www3 oct 21 15:27:47 hostname mountd[96]: bad host www3, skipping oct 21 15:27:47 hostname mountd[96]: bad exports list line /mnt/drive2/dailybackup www3 nfs on reserved port only=YES nfsd rpc.statd [snip] here it hangs on mountd for a minute or two, then proceeds [snip] starting standard daemons: inetd cron sshd usbd sendmail sendmail-clientmqueue [snip] here it hangs on sendmail and sendmail-clientmqueue, then proceeds it then hangs for hours at 'recovering vi sessions:'. it eventually boots all the way through after a few hours. this is not workable for me. i've switched my /etc/ipfw.rules to ipfw add allow ip from any to any ipfw add allow udp from any to any 53 temporarily, so that i can use the machine, but would like to have a set of basic ipfw rules in place. can anyone tell me where i'm going wrong? i think it's hanging on the bootup process because my ipfw.rules are messed up. thanks redmond Redmond Militante Northwestern University, Evanston, IL. USA [EMAIL PROTECTED] 847-467-7617 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: need help with ipfw rules
Check out this site, once you get a handle on the setup read this HOWTO. I've looked at lot's of resources but this is the best as far as I'm concerned. http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO If someone has one better, I would love to see it. Grant Cooper - Original Message - From: Dan Pelleg [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Redmond Militante [EMAIL PROTECTED] Sent: Monday, October 21, 2002 6:16 PM Subject: RE: need help with ipfw rules hi all my apologies, this could get long as i'm including the text of various config files: i've been trying to learn ipfw. i've recompiled a kernel with the following options ipfw add allow ip from any to any Do you really want to allow everything in, or is this just a typo? If this rule is really in effect, the rest of the rules are not doing anything. ipfw add allow ip from 127.0.0.1 to 127.0.0.1 vua lo0 I'm assuming vua is a typo - should be via. ipfw add allow udp from any to any 53 ipfw add check-state You're not letting DNS replies to come back. You are allowing the queries to go *out*, but when the remote server's reply packets hit the firewall they have port 53 on the *source* address, not on the destination. So they don't match that rule anymore and are discarded. What you probably want instead is: ipfw add allow udp from any to any 53 keep-state Another point: you're not using the divert rule for natd, and I see you have NAT enabled in your rc.conf. This is likely to be a problem later (well, you'll just not have NAT). A very good resource for this is /etc/rc.firewall. Just try to follow what the CLIENT, SIMPLE and OPEN targets do, or even let them run, then output the generated ruleset and use it as the skeleton of your own ruleset. Another useful debugging tool is ipfw show - typed repeatedly to watch which counters increased and so to know which rules were hit. Once you get into stateful filtering, you'll want ipfw -d show. Having said that, good ol' tcpdump is always handy to have around. Just fire up tcpdump -ni XXX with XXX for your external interface and see what's going out and what's coming in. Once you start firewalling for a network, a tcpdump -ni III with III being the internal interface becomes useful as well, either in itself or in addition to the external-watching tcpdump. -- Dan Pelleg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: need help with ipfw rules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi thanks for responding On Mon, Oct 21, 2002 at 09:16:36PM -0400, Dan Pelleg expatiated with great perspicuity: hi all my apologies, this could get long as i'm including the text of various config files: i've been trying to learn ipfw. i've recompiled a kernel with the following options ipfw add allow ip from any to any typo Do you really want to allow everything in, or is this just a typo? If this rule is really in effect, the rest of the rules are not doing anything. ipfw add allow ip from 127.0.0.1 to 127.0.0.1 vua lo0 I'm assuming vua is a typo - should be via. typo again ipfw add allow udp from any to any 53 ipfw add check-state You're not letting DNS replies to come back. You are allowing the queries to go *out*, but when the remote server's reply packets hit the firewall they have port 53 on the *source* address, not on the destination. So they don't match that rule anymore and are discarded. What you probably want instead is: ipfw add allow udp from any to any 53 keep-state i changed this line. boots up fine. webserver, ssh, nfs, mail, etc. work. there's only one problem i noticed right off the bat - it looks like ftp users can authenticate fine, but when their ftp client tries to bring up a list of files in their ftp directories, it hangs at 'getting file list...' any ideas on how to fix? thanks redmond Another point: you're not using the divert rule for natd, and I see you have NAT enabled in your rc.conf. This is likely to be a problem later (well, you'll just not have NAT). A very good resource for this is /etc/rc.firewall. Just try to follow what the CLIENT, SIMPLE and OPEN targets do, or even let them run, then output the generated ruleset and use it as the skeleton of your own ruleset. Another useful debugging tool is ipfw show - typed repeatedly to watch which counters increased and so to know which rules were hit. Once you get into stateful filtering, you'll want ipfw -d show. Having said that, good ol' tcpdump is always handy to have around. Just fire up tcpdump -ni XXX with XXX for your external interface and see what's going out and what's coming in. Once you start firewalling for a network, a tcpdump -ni III with III being the internal interface becomes useful as well, either in itself or in addition to the external-watching tcpdump. -- Dan Pelleg -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9tK3rFNjun16SvHYRAnSNAJ9RPPcFelXQwS3R7ELFN+A8UdEWDwCgsJWS 3TUBFhcGrtRa9eCIrhrnv0w= =07L+ -END PGP SIGNATURE- msg05849/pgp0.pgp Description: PGP signature
Re: ipfw rules
- Original Message - From: Grant Cooper [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, October 11, 2002 5:10 PM Subject: Re: ipfw rules I am having the same problem. I now just allow ftp from certain IP address's. But doesn't the second rule, # /sbin/upfw 10001 allow tco from any 1024-65535 to any 1024-65535 setup keep-state kind of beat's the purpose of a firewall. That's a lot of open ports. I thought IPFW had a way to remember the ports opened by ftp and creates rules dynamically based on the ports opened buy ftp. You're thinking of the punch firewall option in natd. If you're using the ftpd that comes with FBSD, you will see in the man page that the default port range is 49152-65535 so as I understand it, you do not need to open ports 1024-49151 as they will not be used. I am also told one can further limit the port range used by the default ftpd by modifying these sysctl vars: net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.hilast: 65535 However I have not actually tried this. I don't know if there's any significant security advantage in limiting the port range further as I have not seen any discussion on this. But I would suspect that it certainly wouldn't hurt to limit the port range to the number of expected concurrent ftp sessions, thus closing off more ports. Anyone else reading this, please correct me if I am mistaken. Thanks, Drew - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 11, 2002 3:33 PM Subject: re: ipfw rules i was finally able to get ftp (using passive ftp) to work through our firewall. these are the rules I had to add: # /sbin/ipfw 1 allow tcp from any 1024-65535 to any 21 out setup keep-state # /sbin/upfw 10001 allow tco from any 1024-65535 to any 1024-65535 setup keep-state the first rule (1) allows our server to connect via any high port to any server out there on port 21(ftp). this is to initiate the 'control connection'. the second rule (10001) allows anyone to connect via high ports to and from our server. this is for the data transfer part. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
re: ipfw rules
I am able to use cvsup with our firewall. The problem is when actually trying to install the software using the make command since the make command tries to fetch the source tarball from a remote server using ftp. If you have a proxy server running, try putting FETCH_ENV variable into /etc/make.conf (see /etc/defaults/make.conf for example) -- Toomas Aas | [EMAIL PROTECTED] | http://www.raad.tartu.ee/~toomas/ * If it wasn't for C, we'd be using BASI, PASAL and OBOL! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: ipfw rules
At 05:52 PM 10.10.2002 -0400, [EMAIL PROTECTED] wrote: Could anyone please tell me what ipfw rules need to be set in order to allow software installation through the ports collection? I tried adding a rule to allow ftp outbound and although I can ftp out, I still cannot fetch the source tarball when using the make command in /usr/ports. What else needs to be open for the make command to work? Thank you, Michelle I believe it likes to use port 5999 for cvsuping. Best regards, Jack L. Stone, Administrator SageOne Net http://www.sage-one.net [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
re: ipfw rules
On Thursday, October 10, 2002, at 03:06 PM, Jack L. Stone wrote: At 05:52 PM 10.10.2002 -0400, [EMAIL PROTECTED] wrote: Could anyone please tell me what ipfw rules need to be set in order to allow software installation through the ports collection? I tried adding a rule to allow ftp outbound and although I can ftp out, I still cannot fetch the source tarball when using the make command in /usr/ports. What else needs to be open for the make command to work? Thank you, Michelle I believe it likes to use port 5999 for cvsuping. I am able to use cvsup with our firewall. The problem is when actually trying to install the software using the make command since the make command tries to fetch the source tarball from a remote server using ftp. I cannot get ftp to dowload data through our firewall. Is it possible to use the make command without opening up our firewall completely or is it best to put the source tarballs in /usr/ports/distfiles manually? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
