firewall net domain command

jsparksa · 03-30-2007, 12:15 AM

Approaching the FW issue from a different point of view:

I submit this command with FW on:

Code:

    # net lookup dc sparksdomain

and the domain controller was not found, and when I submitted the command with the FW disabled the DC was found.

Log entry:

Code:

Mar 30 01:00:04 jsparksa kernel: SFW2-INint-DROP-DEFLT IN=eth0 OUT= MAC=00:e0:18:38:d4:6a:00:10:4b:0a:76:f5:08:00 SRC=192.168.233.110 DST=192.168.233.101 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=1043 LEN=70 
Mar 30 01:00:04 jsparksa last message repeated 2 times

iptable rules for udp port 137:

Code:

-A input_int -p udp -m udp --dport 137 -j ACCEPT

I have everything else working except the ability to browse the root domain!

Any help provided is greatly appreciated!

Thanks, Jim

blackhole54 · 03-30-2007, 04:24 AM

Your log entry shows the (DROPped?) packet as having source port of 137. Your firewall rule is for a destination port of 137. Is that the problem?

jsparksa · 03-30-2007, 06:37 AM

I really do not know how to fix this problem. I see the destination machine has a rule for udp 137:

Code:

-A INPUT -i eth0 -p udp -m udp --dport 137 -j ACCEPT

I am going to show my ignorance with a guess, adding a rule:

Code:

-A input_int -p udp -m udp --sport 137 -j ACCEPT

The dest machine has a bunch of rules in the form:

Code:

-A INPUT -p tcp -m tcp --sport 1024:65535 --dport 80 -j INPUT_12

Do I need a rule for udp 137 like the one above?

I am really in over my head now and I appreciate any help that may be provided.

Thanks, Jim

blackhole54 · 03-30-2007, 08:29 AM

OK, I am not familiar with SAMBA or the net command. (Although I did just check the net command's man page and found out it is involved with SAMBA

) My assumption on my first post was the firewall in question is on the same machine that the lines from your system log were on. In that case, I am guessing that

Code:

-A input_int -p udp -m udp --sport 137 -j ACCEPT

would be correct. But I am just guessing here since I know nothing about the user defined chain input_int. I would have to see the rest of the firewall rules to say anything definite.

Realize that the rules you are looking at on (what I think is) the other machine are for the packets coming into to it. You are filtering (I presume) on packets coming back the other way. Also, that rule you quoted from the other(?) machine also references a user defined chain (INPUT_12) which I know nothing about.

So the short answer is I would try the rule above. If that doesn't work, you will probably need to post your entire set of firewall rules.

Capt_Caveman · 03-30-2007, 08:49 AM

I think you'd be better off using the iptables statefull packet filtering mechanism rather than trying to match source ports. I'd use something like:

Code:

iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

which will allow all replies to traffic that you initiate.

Doing something like this is dangerous:
-A input_int -p udp -m udp --sport 137 -j ACCEPT

With that rule in place, I could access any port on your entire system simply by setting my scanning source port to 137.

Doing this is only mildly better:
-A INPUT -p tcp -m tcp --sport 1024:65535 --dport 80 -j INPUT_12

That was the whole reason why statefull filtering was added, if you are doing it the other way you might as well be using ipchains.

blackhole54 · 03-31-2007, 12:48 AM

Capt. Caveman's adivce is sound. I've also started wondering what the source of your firewall rules is -- on both boxes. My impression is that you did not write them yourself. Perhaps the whole set of rules on both boxes need to be reviewed?

@Capt. Caveman,
I would disagree with the last rule (--dport 80) you cited, since that is for incoming connections from arbitrary boxes. You could add --state NEW to that rule along with another rule for related/established. But at most (to my understanding) that would only be a mild improvement since it would only exclude "invalid" packets. I do agree with using stateful inspection for returning packets on the client box.

jsparksa · 03-31-2007, 02:15 AM

I now have a working iptables script that allows me to browse the root domain of my internal network. There is a caveat!!

** Note: The script below has all of the suggested rules, and I ran the script three times with different rules commented out. **

(1) win32sux provided the initial script.

(2) Capt_Caveman provided a rule for "iptables statefull packet filtering mechanism" but I was not able to browse the domain.

(3) Blackhole54 provided a rule for UDP Source Port 137, and that rule allowed me to browse the domain.

** The caveat **

Capt_Caveman pointed out a security issue using matching dports and sports.

I do not know if I have put the rules in the proper order and if not maybe that is why Capt_Caveman's suggestion did not work??

Could someone look at the script and suggest a more "correct" fix rather than using matching ports.

Thanks to all who have contributed so far,

Jim

P.S. I did not see post #6 before I submitted this reply. My "original" set of rules was generated using SuSEFireWall2 and the GUI tool. Then I received a script from win32sux as stated above.

Code:

#!/bin/sh

#  (1) inital script: linuxquestions.org -- win32sux

IPT="/usr/sbin/iptables"
LAN_IFACE="eth0"
LAN_NET="192.168.233.0/24"

$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT ACCEPT

$IPT -t mangle -P PREROUTING ACCEPT
$IPT -t mangle -P INPUT ACCEPT
$IPT -t mangle -P FORWARD ACCEPT
$IPT -t mangle -P OUTPUT ACCEPT
$IPT -t mangle -P POSTROUTING ACCEPT

$IPT -t nat -P PREROUTING ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT
$IPT -t nat -P OUTPUT ACCEPT

$IPT -F
$IPT -F -t nat
$IPT -F -t mangle

$IPT -X
$IPT -X -t nat
$IPT -X -t mangle

#  (2) linuxquestions.org -- Capt_Caveman
$IPT -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
$IPT -A INPUT -i lo -j ACCEPT

# SSH TCP Port 22
$IPT -A INPUT -p TCP -i $LAN_IFACE -s $LAN_NET --dport 22 -m state --state NEW -j ACCEPT

# HTTP TCP Port 80
$IPT -A INPUT -p TCP -i $LAN_IFACE -s $LAN_NET --dport 80 -m state --state NEW -j ACCEPT

# NETBIOS Name Service:
$IPT -A INPUT -p UDP -i $LAN_IFACE -s $LAN_NET --dport 137 -m state --state NEW -j ACCEPT

#  (3) linuxquestions.org -- Blackhole54
$IPT -A INPUT -p UDP -i $LAN_IFACE -s $LAN_NET --sport 137 -m state --state NEW -j ACCEPT

# NETBIOS Datagram Service:
$IPT -A INPUT -p UDP -i $LAN_IFACE -s $LAN_NET --dport 138 -m state --state NEW -j ACCEPT

# NETBIOS Session Service:
$IPT -A INPUT -p TCP -i $LAN_IFACE -s $LAN_NET --dport 139 -m state --state NEW -j ACCEPT

# Microsoft Naked CIFS:
$IPT -A INPUT -p TCP -i $LAN_IFACE -s $LAN_NET --dport 445 -m state --state NEW -j ACCEPT

# ICMP Echo:
$IPT -A INPUT -p ICMP -i $LAN_IFACE -s $LAN_NET --icmp-type 8 -m state --state NEW -j ACCEPT

$IPT -A INPUT -j LOG --log-prefix "INPUT DROP: "

and here are log entries for when I was blocked from browsing the domain:

Code:

Mar 31 02:21:59 jsparksa kernel: INPUT DROP: IN=eth0 OUT= MAC=00:e0:18:38:d4:6a:00:10:4b:0a:76:f5:08:00 SRC=192.168.233.110 DST=192.168.233.101 LEN=90 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=137 DPT=1027 LEN=70 
Mar 31 02:22:00 jsparksa last message repeated 2 times
Mar 31 02:23:52 jsparksa last message repeated 3 times

jsparksa · 03-31-2007, 02:18 AM

One more question: Where is the proper place to put the script for system boot purposes. You may assume that I will always want the script to run at boot time.

Thanks, Jim

blackhole54 · 03-31-2007, 07:35 AM

Quote:

Originally Posted by jsparksa

Code:

#  (2) linuxquestions.org -- Capt_Caveman
$IPT -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

jsparksa,

the above two rules in this sequence do the same thing, so you don't need them both. To retain consistency with the rest of your script, I would probably eliminate the first one.

Now as to the question of why the script doesn't work w/o the --sport 137 rule ... I just did a quick internet search and found this. If this is what you are doing, the issue seems to be that your client sends a broadcast message to initiate the request, and the normal iptables/netfilter capability doesn't recognize what comes back as being related to what was sent out. In short, the rule listed above won't let the response back in.

I see three ways you could go from here. You could try to follow the instructions on the link I just provided, or find some other solution from an internet search. Perhaps there is even a standard module already in the kernel source code for handling this.

Or ... You could leave things the way they are. If this is a small LAN that you pretty much trust, there might not really be a security issue.

Or ... If you know that only this one IP address will be responding on port 137, you can change $LAN_NET in that one command only to the particular IP address you know should respond. That will tighten the security down a little from leaving it as it is.

====

As far as where to call this script from, I am not familiar with SuSE either. Some distros have a /etc/rc.d/rc.local or /etc/rc.local file that will always execute on a normal boot. If your distro has one of these you could call your script from there. The first time you boot after making this addition, I recommend making sure it really got executed by, as root giving the command

iptables -nvL

and make sure you see the rules.

jsparksa · 04-01-2007, 10:05 PM

I have a working firewall now and it is included below. It is embarrassing to admit but I had only as far a my laptop to go for a solution. The best part of the solution is that Fw on the laptop was configured with the GUI SuSEfirewall2 tool in YaST.

The laptop was new in December, and a few weeks ago, I installed OpenSuSe 10.2 in a dual-boot environment with Windows Xp Pro. Yesterday it occurred to me to check how samba worked on this machine. And it works just as it should.

I have been using linux at home for almost 3 years now and I have always installed samba when I have installed or upgraded linux. Samba always works as I expect it to work right after the install is finished. Then sometime within 48 hours of the completion the installation, I notice that the machine's ability to browse the internal network stops working.

I almost never have problems with samba shares, and my Windows machines have been able to provide shares and browse the linux machines. My linux machines showed their shares as they should, but they were not able to browse the network when the Fw was enabled.

When I needed to share a file from the the linux machine to another machine, I would put the file onto a shared folder and then I would have to go to the other machine, and pick up the file from the linux share.

That worked fine most of the time because, the primary use of the linux machines is to provide file shares for the purpose of backing up the primary Windows machine.

Now I have bi-directional file sharing!

I am not sure which rule(s) in the working list of iptables shown below actually fixed the samba problem, but I am using the same rules on three suse machines, 9.1 pro, 10.0 pro, and opensuse 10.2. There is some "broadcast configuration" in these rules that I did not use in the original configuration,: (udp 137: netbios-ns, udp 138: netbios-dgm, and udp 177: xdmcp) There is also a flag in the GUI called "Protect internal network" and that seems to translate into rules being created for each port as UDP and TCP.

As stated before, I am nobodies networking/ security expert!

Thank you everybody for all of the help provided. I almost gave up on fixing this problem earlier this week, simply because I did not know how to ask the next question to get further in the problem solving.

Professionally, I have been a programmer for about 26 years, and I know how to debug. My area of expertise is oriented to business, not security, though.

Thanks again,

Jim

How I got this configuration: (SuSE specific)

(1) Stop the firewall on the problem machine.
(2) Copy /etc/sysconfig/SuSEfirewall2 from the working machine to the problemed machine.
(save a backup of the original file)
(3) Restart the FW via YaST. The new configuration will read and iptables rules will be created.

Code:

# Generated by iptables-save v1.3.3 on Sun Apr  1 20:19:06 2007
*mangle
:PREROUTING ACCEPT [1007417:1164254033]
:INPUT ACCEPT [1007388:1164250569]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [682410:91173502]
:POSTROUTING ACCEPT [683530:91294532]
COMMIT
# Completed on Sun Apr  1 20:19:06 2007
# Generated by iptables-save v1.3.3 on Sun Apr  1 20:19:06 2007
*nat
:PREROUTING ACCEPT [3517:518415]
:POSTROUTING ACCEPT [2958:231767]
:OUTPUT ACCEPT [2958:231767]
COMMIT
# Completed on Sun Apr  1 20:19:06 2007
# Generated by iptables-save v1.3.3 on Sun Apr  1 20:19:06 2007
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [9:675]
:forward_ext - [0:0]
:forward_int - [0:0]
:input_ext - [0:0]
:input_int - [0:0]
:reject_func - [0:0]
-A INPUT -i lo -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -i eth0 -j input_int 
-A INPUT -j input_ext 
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-IN-ILL-TARGET " --log-tcp-options --log-ip-options 
-A INPUT -j DROP 
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "SFW2-FWD-ILL-ROUTING " --log-tcp-options --log-ip-options 
-A OUTPUT -o lo -j ACCEPT 
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT 
-A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-OUT-ERROR " --log-tcp-options --log-ip-options 
-A input_ext -p udp -m pkttype --pkt-type broadcast -m udp --dport 137 -j ACCEPT 
-A input_ext -p udp -m pkttype --pkt-type broadcast -m udp --dport 138 -j ACCEPT 
-A input_ext -p udp -m pkttype --pkt-type broadcast -m udp --dport 177 -j ACCEPT 
-A input_ext -m pkttype --pkt-type broadcast -j DROP 
-A input_ext -p icmp -m icmp --icmp-type 4 -j ACCEPT 
-A input_ext -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 0 -j ACCEPT 
-A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 3 -j ACCEPT 
-A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 11 -j ACCEPT 
-A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 12 -j ACCEPT 
-A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 14 -j ACCEPT 
-A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 18 -j ACCEPT 
-A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 3/2 -j ACCEPT 
-A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 5 -j ACCEPT 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 137 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options 
-A input_ext -p tcp -m tcp --dport 137 -j ACCEPT 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 138 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options 
-A input_ext -p tcp -m tcp --dport 138 -j ACCEPT 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 3389 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options 
-A input_ext -p tcp -m tcp --dport 3389 -j ACCEPT 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 443 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options 
-A input_ext -p tcp -m tcp --dport 443 -j ACCEPT 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 5800 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options 
-A input_ext -p tcp -m tcp --dport 5800 -j ACCEPT 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 5801 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options 
-A input_ext -p tcp -m tcp --dport 5801 -j ACCEPT 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 5900 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options 
-A input_ext -p tcp -m tcp --dport 5900 -j ACCEPT 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 5901 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options 
-A input_ext -p tcp -m tcp --dport 5901 -j ACCEPT 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 445 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options 
-A input_ext -p tcp -m tcp --dport 445 -j ACCEPT 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 139 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options 
-A input_ext -p tcp -m tcp --dport 139 -j ACCEPT 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options 
-A input_ext -p tcp -m tcp --dport 22 -j ACCEPT 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 177 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options 
-A input_ext -p tcp -m tcp --dport 177 -j ACCEPT 
-A input_ext -p udp -m udp --dport 139 -j ACCEPT 
-A input_ext -p udp -m udp --dport 3389 -j ACCEPT 
-A input_ext -p udp -m udp --dport 443 -j ACCEPT 
-A input_ext -p udp -m udp --dport 5800 -j ACCEPT 
-A input_ext -p udp -m udp --dport 5900 -j ACCEPT 
-A input_ext -p udp -m udp --dport 138 -j ACCEPT 
-A input_ext -p udp -m udp --dport 137 -j ACCEPT 
-A input_ext -p udp -m udp --dport 177 -j ACCEPT 
-A input_ext -p tcp -m tcp --dport 113 -m state --state NEW -j reject_func 
-A input_ext -p tcp -m limit --limit 3/min -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options 
-A input_ext -p icmp -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options 
-A input_ext -p udp -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options 
-A input_ext -m limit --limit 3/min -m state --state INVALID -j LOG --log-prefix "SFW2-INext-DROP-DEFLT-INV " --log-tcp-options --log-ip-options 
-A input_ext -j DROP 
-A input_int -j ACCEPT 
-A reject_func -p tcp -j REJECT --reject-with tcp-reset 
-A reject_func -p udp -j REJECT --reject-with icmp-port-unreachable 
-A reject_func -j REJECT --reject-with icmp-proto-unreachable 
COMMIT
# Completed on Sun Apr  1 20:19:06 2007

blackhole54 · 04-02-2007, 03:33 AM

Quote:

Originally Posted by jsparksa

I am not sure which rule(s) in the working list of iptables shown below actually fixed the samba problem, ...

Code:

-A INPUT -i lo -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -i eth0 -j input_int 
-A INPUT -j input_ext 

-A input_int -j ACCEPT

Your new firewall accepts all packets coming in through eth0. Only you can judge whether that is acceptable.

jsparksa · 04-02-2007, 11:00 AM

That would be the "Protect the internal network" check box being unchecked. This machine sits behind a router with a FW and I have locked the router down. The outside world can get to the machine via the http and ssh.

Jim

blackhole54 · 04-02-2007, 02:01 PM

Quote:

Originally Posted by jsparksa

That would be the "Protect the internal network" check box being unchecked.

Well, that is why, in this instance, you have no "samba prob lem."