Using the standard iptables linux template for: Host fw template 1
I am correct in that if not using a workstation for a stand alone or appliance firewall,
I do not need to use the Object Type: Firewall, and can substitute;
Object Type: Firewall - Object Type: Host
The Firewall object refers to the device on which the policy will be installed. This can be a host or network firewall. One side affect of changing the Firewall object with a Host object is for rules that have "Any" in the source or destination. By default Firewall Builder includes the Firewall object in these rules, so for iptables systems that means INPUT/OUTPUT chain entries are added.
There could be other behavior changes as well. Is there a reason you want to replace the Firewall object with the Host object?
The first rule in the Host fw template 1 is anti-spoofing, so if you replace the source from the Firewall object to "Any" you will block all access to the host.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am having difficulties getting iptables in general to recognize broadcast replies from 192.168.55.11 to 192.168.55.255, and 127.0.0.1 to 127.255.255.255 on port 137 (netbios-ns).
I was experimenting and wondered if I 'should' use a firewall object or if the logic of the template is designed for a dedicated firewall on a host as opposed to a workstation. I wasn't using the 'any' scenario and couldn't think of a reason why I couldn't substitute. Probably a last ditch effort to try something out in left field to alleviate my pain from hunting down the blockage of browsing samba shares on the network.
Thank you for your answers to my questions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm guessing your firewall is 192.168.55.11 in this example? Here's what I think you want to do.
* Create an Address object with the address field set to 192.168.55.255
* Add a rule with Source = Firewall, Destination = Address object from above, Service = netbios-ns, Direction = Outbound
You can do the same thing for the 127.255.255.255, but unless the samba share is hosted on the host itself you should not need this since.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Apparently, traffic 'is' getting out to both 127.255.255.255 and 192.168.55.255 but not recognizing a reply.
Yes, the workstation with a firewall is 192.168.55.11 and is a samba server as well.
There is a printer 192.168.55.100 that shows when the 'findsmb' command is issued.
I have the following modules loaded for iptables;
nf_conntrack_netbios_ns nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ipv4 nf_conntrack nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state
If I got what you said correct… this is a compiled rule;
echo '*filter'
echo "-A OUTPUT -p udp -m udp -d 127.255.255.255 -dport 137 -m state -state NEW -j Out_RULE_5 "
echo "-A OUTPUT -p udp -m udp -d 192.168.55.255 -dport 137 -m state -state NEW -j Out_RULE_5 "
echo "-A Out_RULE_5 -j LOG -log-level info -log-prefix \"RULE 5 - ACCEPT \""
echo "-A Out_RULE_5 -j ACCEPT
Sorry, I thought you were trying to block this traffic. If you want to allow broadcast traffic for samba in and out of the host, then set the direction to Both.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
*Scan From client 192.168.55.12 to samba host (firewall builder) 192.168.55.11
nmap -sS -sU 192.168.55.11
PORT STATE SERVICE
22/tcp open ssh
139/tcp open netbios-ssn
445/tcp open microsoft-ds
9100/tcp open jetdirect
137/udp open netbios-ns
*Network Browse discovery using $ findsmb
From Host: $ findsmb = successfully display samba network shares and printer (192.168.55.100)
From Client: $ findsmb = fail on network shares, success on printer.
Client firewall is ufw and is off (sudo ufw disable) to make sure it's not interfering with the ability to (findsmb).
Result from $ conntrack -E during a $ findsmb from the client
Instead of looking at the conntrack log it would be better to turn logging on for your rules and look at the output of /var/log/messages. It will be easier to see what rule in iptables is matching the traffic that is being dropped.
Also, as a basic test you could allow all services from 192.168.55.12 to 192.168.55.11. This would make sure the client is able to browse the share without any firewalling of that traffic. The best way to troubleshoot these kinds of issues is to try and look at one piece at a time. Are other protocols working between these machines?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
/var/log/iptables.log (custom rsyslogd) is showing the same thing conntrack is. I can see it with $ tail -f /var/log/iptables.log
Other protocols… yes but they couldn't interfere because I've already turned off the firewall on the client side with a successful Samba LAN browse so there won't be interference… there is synergy, apt-cacher-ng, ntp, ssh.
Unfortunately I have to abandon this project and leave the client machine with connecting via smb://192.168.55.11 until I sort this out.
I appreciate your time on this, I can imagine how hard it is to troubleshoot with so many variables that could be in the way.
Best regards,
Armz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Problem: Samba broadcast blocked
For those transitioning to Firewall Builder from iptables rules and/or ufw firewall and are having difficulties 'Browsing" the samba shares on the LAN, here is one solution.
Notes:
1. You will want to have module nf_conntrack_netbios_ns module loaded
2. If you are using UFW firewall from the client, it will block broadcasts by default.
You will need to make some adjustments in the default UFW;
a. /etc/ufw/before.rules
# if BROADCAST, RETURN
-A ufw-not-local -p udp -dport 137 -m addrtype -dst-type broadcast -j ACCEPT
-A ufw-not-local -p udp -sport 137 -m addrtype -dst-type broadcast -j ACCEPT
# This was the Original Default Rule moved to below
-A ufw-not-local -m addrtype -dst-type BROADCAST -j RETURN
b. /etc/default/ufw
# extra connection tracking modules to load
# added: nf_conntrack_netbios_ns
IPT_MODULES="nf_conntrack_ftp nf_nat_ftp nf_conntrack_irc nf_nat_irc nf_conntrack_netbios_ns"
3. Restart the UFW firewall;
$ sudo ufw enable
$ sudo ufw reload
4. Make sure module nf_conntrack_netbios_nw is loaded, if not then restart the machine
$ lsmod | grep nf_conntrack_netbios_ns
5. Make sure Samba Server is started, then check visibility from the client machine;
$ findsmb
6. My results;
user1@samba:~$ findsmb
*=DMB
+=LMB
IP ADDR NETBIOS NAME WORKGROUP/OS/VERSION
192.168.55.11 SHARE01 +
Success! (Finally).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi.
Using the standard iptables linux template for: Host fw template 1
I am correct in that if not using a workstation for a stand alone or appliance firewall,
I do not need to use the Object Type: Firewall, and can substitute;
Object Type: Firewall - Object Type: Host
Host object created: 192.168.55.11 / 255.255.255.0
Object Type: Firewall
FW-02 / Policy / rule 1
echo '*filter'
echo "-A INPUT -p all -f -j In_RULE_1 "
echo "-A In_RULE_1 -j LOG -log-level info -log-prefix \"RULE 1 - DENY \""
echo "-A In_RULE_1 -j DROP "
Object Type: Host
FW-02 / Policy / rule 1
echo '*filter'
echo "-A INPUT -p all -d 192.168.49.11 -f -j In_RULE_1 "
echo "-A In_RULE_1 -j LOG -log-level info -log-prefix \"RULE 1 - DENY \""
echo "-A In_RULE_1 -j DROP "
Is there any disadvantage to doing this ?
I'm considering replacing the objects for a comparison test…
Also, the 1st rule in the above default template…
can I substitute the Firewall Object for 'source' with Any ?
Thank you for your ongoing assistance in these matters.
The Firewall object refers to the device on which the policy will be installed. This can be a host or network firewall. One side affect of changing the Firewall object with a Host object is for rules that have "Any" in the source or destination. By default Firewall Builder includes the Firewall object in these rules, so for iptables systems that means INPUT/OUTPUT chain entries are added.
There could be other behavior changes as well. Is there a reason you want to replace the Firewall object with the Host object?
The first rule in the Host fw template 1 is anti-spoofing, so if you replace the source from the Firewall object to "Any" you will block all access to the host.
I am having difficulties getting iptables in general to recognize broadcast replies from 192.168.55.11 to 192.168.55.255, and 127.0.0.1 to 127.255.255.255 on port 137 (netbios-ns).
I was experimenting and wondered if I 'should' use a firewall object or if the logic of the template is designed for a dedicated firewall on a host as opposed to a workstation. I wasn't using the 'any' scenario and couldn't think of a reason why I couldn't substitute. Probably a last ditch effort to try something out in left field to alleviate my pain from hunting down the blockage of browsing samba shares on the network.
Thank you for your answers to my questions.
I'm guessing your firewall is 192.168.55.11 in this example? Here's what I think you want to do.
* Create an Address object with the address field set to 192.168.55.255
* Add a rule with Source = Firewall, Destination = Address object from above, Service = netbios-ns, Direction = Outbound
You can do the same thing for the 127.255.255.255, but unless the samba share is hosted on the host itself you should not need this since.
Thanks for trying to help on this.
Apparently, traffic 'is' getting out to both 127.255.255.255 and 192.168.55.255 but not recognizing a reply.
Yes, the workstation with a firewall is 192.168.55.11 and is a samba server as well.
There is a printer 192.168.55.100 that shows when the 'findsmb' command is issued.
I have the following modules loaded for iptables;
nf_conntrack_netbios_ns nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ipv4 nf_conntrack nf_conntrack_netbios_ns nf_conntrack_ipv4 xt_state
If I got what you said correct… this is a compiled rule;
echo '*filter'
echo "-A OUTPUT -p udp -m udp -d 127.255.255.255 -dport 137 -m state -state NEW -j Out_RULE_5 "
echo "-A OUTPUT -p udp -m udp -d 192.168.55.255 -dport 137 -m state -state NEW -j Out_RULE_5 "
echo "-A Out_RULE_5 -j LOG -log-level info -log-prefix \"RULE 5 - ACCEPT \""
echo "-A Out_RULE_5 -j ACCEPT
Here is an output from $ conntrack -E after a 'findsmb' command is issued;
udp 17 30 src=192.168.55.11 dst=192.168.55.255 sport=43731 dport=137 src=192.168.55.255 dst=192.168.55.11 sport=137 dport=43731
udp 17 30 src=192.168.55.100 dst=192.168.55.11 sport=137 dport=43731 src=192.168.55.11 dst=192.168.55.100 sport=43731 dport=137
udp 17 30 src=192.168.55.11 dst=192.168.55.100 sport=45071 dport=137 src=192.168.55.100 dst=192.168.55.11 sport=137 dport=45071
udp 17 30 src=192.168.55.11 dst=192.168.55.100 sport=45071 dport=137 src=192.168.55.100 dst=192.168.55.11 sport=137 dport=45071
udp 17 30 src=192.168.55.11 dst=192.168.55.255 sport=42793 dport=137 src=192.168.55.255 dst=192.168.55.11 sport=137 dport=42793
udp 17 30 src=192.168.55.100 dst=192.168.55.11 sport=137 dport=42793 src=192.168.55.11 dst=192.168.55.100 sport=42793 dport=137
tcp 6 120 SYN_SENT src=192.168.55.11 dst=192.168.55.100 sport=51986 dport=445 src=192.168.55.100 dst=192.168.55.11 sport=445 dport=51986
tcp 6 src=192.168.55.11 dst=192.168.55.100 sport=51986 dport=445 src=192.168.55.100 dst=192.168.55.11 sport=445 dport=51986
tcp 6 120 SYN_SENT src=192.168.55.11 dst=192.168.55.100 sport=52768 dport=139 src=192.168.55.100 dst=192.168.55.11 sport=139 dport=52768
tcp 6 src=192.168.55.11 dst=192.168.55.100 sport=52768 dport=139 src=192.168.55.100 dst=192.168.55.11 sport=139 dport=52768
udp 17 30 src=192.168.55.11 dst=192.168.55.255 sport=137 dport=137 src=192.168.55.255 dst=192.168.55.11 sport=137 dport=137
udp 17 src=192.168.55.11 dst=192.168.55.255 sport=43731 dport=137 src=192.168.55.255 dst=192.168.55.11 sport=137 dport=43731
udp 17 src=192.168.55.11 dst=192.168.55.255 sport=42793 dport=137 src=192.168.55.255 dst=192.168.55.11 sport=137 dport=42793
Bad news…
No effect. (pulling my hair out)
Sorry, I thought you were trying to block this traffic. If you want to allow broadcast traffic for samba in and out of the host, then set the direction to Both.
No worries,
A Bonkers I will be…
With your correction;
echo '*filter'
echo "-A INPUT -p udp -m udp -s 192.168.55.11 -d 127.255.255.255 -dport 137 -m state -state NEW -j ACCEPT "
echo "-A OUTPUT -p udp -m udp -d 127.255.255.255 -dport 137 -m state -state NEW -j ACCEPT "
echo "-A INPUT -p udp -m udp -s 192.168.55.11 -d 192.168.55.255 -dport 137 -m state -state NEW -j ACCEPT "
echo "-A OUTPUT -p udp -m udp -d 192.168.55.255 -dport 137 -m state -state NEW -j ACCEPT "
Samba existing rule directly below;
echo "-A INPUT -i eth0 -p tcp -m tcp -m multiport -s 192.168.55.0/24 -dports 445,139 -m state -state NEW -j ACCEPT "
echo "-A INPUT -i eth0 -p udp -m udp -m multiport -s 192.168.55.0/24 -dports 138,137 -m state -state NEW -j ACCEPT "
echo "-A OUTPUT -o eth0 -p tcp -m tcp -m multiport -s 192.168.55.0/24 -d 192.168.55.11 -dports 445,139 -m state -state NEW -j ACCEPT "
echo "-A OUTPUT -o eth0 -p udp -m udp -m multiport -s 192.168.55.0/24 -d 192.168.55.11 -dports 138,137 -m state -state NEW -j ACCEPT "
*Scan From client 192.168.55.12 to samba host (firewall builder) 192.168.55.11
nmap -sS -sU 192.168.55.11
PORT STATE SERVICE
22/tcp open ssh
139/tcp open netbios-ssn
445/tcp open microsoft-ds
9100/tcp open jetdirect
137/udp open netbios-ns
*Network Browse discovery using $ findsmb
From Host: $ findsmb = successfully display samba network shares and printer (192.168.55.100)
From Client: $ findsmb = fail on network shares, success on printer.
Client firewall is ufw and is off (sudo ufw disable) to make sure it's not interfering with the ability to (findsmb).
Result from $ conntrack -E during a $ findsmb from the client
udp 17 30 src=192.168.55.11 dst=192.168.55.255 sport=42215 dport=137 src=192.168.55.255 dst=192.168.55.11 sport=137 dport=42215
udp 17 30 src=192.168.55.11 dst=192.168.55.11 sport=137 dport=42215 src=192.168.55.11 dst=192.168.55.11 sport=42215 dport=137
udp 17 30 src=192.168.55.100 dst=192.168.55.11 sport=137 dport=42215 src=192.168.55.11 dst=192.168.55.100 sport=42215 dport=137
udp 17 30 src=192.168.55.11 dst=192.168.55.11 sport=56804 dport=137 src=192.168.55.11 dst=192.168.55.11 sport=137 dport=56804
udp 17 30 src=192.168.55.11 dst=192.168.55.11 sport=56804 dport=137 src=192.168.55.11 dst=192.168.55.11 sport=137 dport=56804
tcp 6 120 SYN_SENT src=192.168.55.11 dst=192.168.55.11 sport=56215 dport=445 src=192.168.55.11 dst=192.168.55.11 sport=445 dport=56215
tcp 6 60 SYN_RECV src=192.168.55.11 dst=192.168.55.11 sport=56215 dport=445 src=192.168.55.11 dst=192.168.55.11 sport=445 dport=56215
tcp 6 432000 ESTABLISHED src=192.168.55.11 dst=192.168.55.11 sport=56215 dport=445 src=192.168.55.11 dst=192.168.55.11 sport=445 dport=56215
tcp 6 120 FIN_WAIT src=192.168.55.11 dst=192.168.55.11 sport=56215 dport=445 src=192.168.55.11 dst=192.168.55.11 sport=445 dport=56215
tcp 6 30 LAST_ACK src=192.168.55.11 dst=192.168.55.11 sport=56215 dport=445 src=192.168.55.11 dst=192.168.55.11 sport=445 dport=56215
tcp 6 120 TIME_WAIT src=192.168.55.11 dst=192.168.55.11 sport=56215 dport=445 src=192.168.55.11 dst=192.168.55.11 sport=445 dport=56215
udp 17 30 src=192.168.55.11 dst=192.168.55.100 sport=60746 dport=137 src=192.168.55.100 dst=192.168.55.11 sport=137 dport=60746
udp 17 30 src=192.168.55.11 dst=192.168.55.100 sport=60746 dport=137 src=192.168.55.100 dst=192.168.55.11 sport=137 dport=60746
udp 17 30 src=192.168.55.11 dst=192.168.55.255 sport=38192 dport=137 src=192.168.55.255 dst=192.168.55.11 sport=137 dport=38192
udp 17 30 src=192.168.55.100 dst=192.168.55.11 sport=137 dport=38192 src=192.168.55.11 dst=192.168.55.100 sport=38192 dport=137
tcp 6 120 SYN_SENT src=192.168.55.11 dst=192.168.55.100 sport=37748 dport=445 src=192.168.55.100 dst=192.168.55.11 sport=445 dport=37748
tcp 6 src=192.168.55.11 dst=192.168.55.100 sport=37748 dport=445 src=192.168.55.100 dst=192.168.55.11 sport=445 dport=37748
tcp 6 120 SYN_SENT src=192.168.55.11 dst=192.168.55.100 sport=51550 dport=139 src=192.168.55.100 dst=192.168.55.11 sport=139 dport=51550
tcp 6 src=192.168.55.11 dst=192.168.55.100 sport=51550 dport=139 src=192.168.55.100 dst=192.168.55.11 sport=139 dport=51550
udp 17 src=192.168.55.11 dst=192.168.55.255 sport=42215 dport=137 src=192.168.55.255 dst=192.168.55.11 sport=137 dport=42215
udp 17 src=192.168.55.11 dst=192.168.55.255 sport=38192 dport=137 src=192.168.55.255 dst=192.168.55.11 sport=137 dport=38192
I'm ready to follow the Yellow Brick Road.
Shouldn't I have a NEW,RELATED associated with these port 137 queries ?
Thanks again.
Armz
Instead of looking at the conntrack log it would be better to turn logging on for your rules and look at the output of /var/log/messages. It will be easier to see what rule in iptables is matching the traffic that is being dropped.
Also, as a basic test you could allow all services from 192.168.55.12 to 192.168.55.11. This would make sure the client is able to browse the share without any firewalling of that traffic. The best way to troubleshoot these kinds of issues is to try and look at one piece at a time. Are other protocols working between these machines?
Thanks Mikehorn…
Understood.
/var/log/iptables.log (custom rsyslogd) is showing the same thing conntrack is. I can see it with $ tail -f /var/log/iptables.log
Other protocols… yes but they couldn't interfere because I've already turned off the firewall on the client side with a successful Samba LAN browse so there won't be interference… there is synergy, apt-cacher-ng, ntp, ssh.
Unfortunately I have to abandon this project and leave the client machine with connecting via smb://192.168.55.11 until I sort this out.
I appreciate your time on this, I can imagine how hard it is to troubleshoot with so many variables that could be in the way.
Best regards,
Armz
Problem: Samba broadcast blocked
For those transitioning to Firewall Builder from iptables rules and/or ufw firewall and are having difficulties 'Browsing" the samba shares on the LAN, here is one solution.
Systems used:
Debian Linux, testing amd 64 - Server, Samba, Firewall Builder firewall
Debian Linux, testing amd 64 - Client, UFW Firewall
Firewall Builder Rules (Server)
Rule |Source |Dest |Service |Iface |Drctn |Action |Time |Opts |Comment
0 |Samba |Samba |Any |eth0 |In |Deny |Any |log |
1 |Any |Samba |ip_fragments |Any |In |Deny |Any |log |
2 |Any |Any |Any |loopback |Both |Accept |Any |Stlss |
3 |Any |Samba |Useful_ICMP |eth0 |Both |Accept |Any | |
|ping_request |
4 |LAN |Samba |ssh |eth0 |Both |Accept |Any | |Open SSH Server
5 |LAN |Samba | |eth0 |Both |Accept |Any | |Samba Server
|Netbios-dgm | |138 udp
|Netbios-ns | |137 udp
|Netbios-ssn | |139 tcp
|SMB | |445 tcp
6 |Samba |LAN |Netbios-ns-reply |eth0 |Out |Accept |Any | |Samba Broadcast
|Netbios-dgm-reply |Replies 137, 138
7 |Any |Samba |Any |Any |Both |Deny |Any |log |
Samba = 192.168.55.11
LAN = 192.168.55.0/24
Netbios-ns-reply = source 137
Netbios-dgm-reply = source 138
Client Machine = 192.168.55.12
Notes:
1. You will want to have module nf_conntrack_netbios_ns module loaded
2. If you are using UFW firewall from the client, it will block broadcasts by default.
You will need to make some adjustments in the default UFW;
a. /etc/ufw/before.rules
# if BROADCAST, RETURN
-A ufw-not-local -p udp -dport 137 -m addrtype -dst-type broadcast -j ACCEPT
-A ufw-not-local -p udp -sport 137 -m addrtype -dst-type broadcast -j ACCEPT
# This was the Original Default Rule moved to below
-A ufw-not-local -m addrtype -dst-type BROADCAST -j RETURN
b. /etc/default/ufw
# extra connection tracking modules to load
# added: nf_conntrack_netbios_ns
IPT_MODULES="nf_conntrack_ftp nf_nat_ftp nf_conntrack_irc nf_nat_irc nf_conntrack_netbios_ns"
3. Restart the UFW firewall;
$ sudo ufw enable
$ sudo ufw reload
4. Make sure module nf_conntrack_netbios_nw is loaded, if not then restart the machine
$ lsmod | grep nf_conntrack_netbios_ns
5. Make sure Samba Server is started, then check visibility from the client machine;
$ findsmb
6. My results;
user1@samba:~$ findsmb
*=DMB
+=LMB
IP ADDR NETBIOS NAME WORKGROUP/OS/VERSION
192.168.55.11 SHARE01 +
Success! (Finally).
I sure wish there was an 'edit' function on this board. I see my table is messy and not aligned.
Also, the Firewall builder example above was created from the default Web Server template.
Thanks for the guidance Mikehorn!
Ciao
Armz