iptables ssh issue
 

I have a firewall configured like this . I want to be able to ssh the firewall itself from either eth1 (the outside network) or eth0 (the inside network). I have opened up port 22. However, I cannot ssh my firewall. When I reset iptables and ssh'd it:
192.168.1.104 is my firewall's external IP, and .106 is another computer on the same subnet. I also know that the port 37385 that it had established the connection on is dynamic - it's not that same port every time. How do I take this into account in my firewall? It's only letting ports 21, 22, 80, and 139 in right now. What is the range of the 37385 kind of port? Why does ssh establish connections over ports other than 22? What should I do to my firewall?

EDIT: The above netstat connection is actually my firewall trying to open an ssh session to my other computer, which coincidentally won't work either with the firewall up. The netstat for the incoming ssh connection is this:
I am baffled about these arbitrary ports numbers in the 1025-65535 range. Why is it using these?

Ok. That makes alot more sense now. I thought I was losing my sanity looking at that before you edited it.

The high number is the source port on the machine initiating the connection. It's selected from un-privledged ports that are not in use, starting off with 1024 and then simply incrementing for each subsequent connection. Therefore you'll never really be able to guess which source port the remote client will use (as you have no idea of how many sockets the remote host has opened already).

The destination port should always be port 22 unless you specify otherwise. This port is the one you'll be concerned about for allowing incoming ssh connections to pass through the firewall. Using a rule that allows "RELATED,ESTABLISHED"connections will allow the server to communicate back with the client. So usually you can use something like this to allow incoming ssh connections:

iptables -I INPUT -p tcp --dport 22 -j ACCEPT

Then depending on how your firewall is setup you could use this to communicate back with the client:

iptables -I OUTPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT

If you have a default policy of ACCEPT for the OUTPUT chain then you don't even have to worry about the outbound replies.

Thanks Capt_Caveman...

I know for a fact that the output chain's policy is ACCEPT, even though the input and forward chains are DROP. Here is my EXT_FIREWALL chain, where all packets get routed from the INPUT chain on the external network interface:

tcp_ports = "21 22 80 139"
udp_ports = ""
ipt = "/sbin/iptables"

################################################################################
# EXT_FIREWALL
# Packets entering firewall machine
# 1. Allow established and related connections
# 2. Allow new connections on specified ports
# 3. Log and Drop everything else
################################################################################
$ipt -N EXT_FIREWALL
$ipt -A EXT_FIREWALL -m state --state INVALID -j DROP
$ipt -A EXT_FIREWALL -j SPOOF
$ipt -A EXT_FIREWALL -m state --state ESTABLISHED,RELATED -j ACCEPT
$ipt -A EXT_FIREWALL -p icmp -j ACCEPT
#
# Open ports
#
for tcp_p in $tcp_ports
do
$ipt -A EXT_FIREWALL -p tcp --dport $tcp_p -m state --state NEW -j ACCEPT
done
for udp_p in $udp_ports
do
$ipt -A EXT_FIREWALL -p udp --dport $udp_p -m state --state NEW -j ACCEPT
done
$ipt -A EXT_FIREWALL -j LOG --log-prefix "IPT: EXT_FIREWALL: " $logops
$ipt -A EXT_FIREWALL -j DROP

Did you include this line in your scipt as well:

$ipt -A INPUT -i $ext -j EXT_FIREWALL

Because what you posted won't work by itself, as it doesn't have anything linking the INPUT and user-defined EXT_FIREWALL chain together. I tested a modified version of that scipt and included the above line and was able to ssh through the firewall.

Yes - that line was in the firewall script, but I just didn't post it...

Hi CG84.

I can help you with the script.

My first question may seem rather basic but it's a common problem. In the firewall script there are two variables; ext and int. Are they set to your proper cards?

i.e.
default is
int=eth0
ext=ppp0

YOURS should be
int=eth0
ext=eth1

[edit: Corrected grammar.]

yes - eth1 is ext and eth0 is int.

Thanks for the script BTW - it has been very helpful!

You're very welcome.

I'm a little confused now. Here's why: If you haven't modified the script, then it should be accepting all connections on the internal interface by default. It *ONLY* drops invalid packets on the internal interface. hmmm...

What output do you get from this command? (as root)
cat /var/log/messages | grep IPT

Have you made any mods to the script?

Sometimes anti-spoofing rules block all packets coming from unroutable addresses (192.168.x.x) Are you running the internal packets through the no-spoofing rules?

-Dewar

(Dewar, you are going down the same road I am. The script he is using logs all Spoofed addresses to /var/log/messages. If the int/ext variables are reversed, we'll find out there.)

The only other mod I made in the script (except to change the interface variables) was to change the log level to 5 (notice). On 3, it was dumping a bunch of garbage text onto the console, and I didn't know how to edit syslog.conf to get it to stop. But I was actually trying to ssh to the external interface on the box from another computer on that subnet. I also know I couldn't ssh from a computer behind the firewall to a computer outside, and vice versa.

SSH problem solved. The spoof chain was dropping my "fake" subnet of 192.168.1.0/24. I have it working now with that entry commented out.

Even though I've changed the loglevel, I still get garbage text dumped to the console when the f/w is up. Any ideas about how to change syslog.conf for loglevel 5 (notice)?

I'm concerned that your int/ext variables are backwards. I'm assuming that the 192.168.1.0/24 network is your private LAN and that your gateway machine is providing a firewall between 192.168.1.0/24 and a routable network (i.e. Internet)

If you have the above script setup correctly it lets you ssh from any machine on 192.168.1.0/24 to any external or internal machine - including the firewall. It also allows you to ssh to the firewall from any machine.
CAVEAT: Attempting to ssh to the firewall's EXTERNAL ip from an INTERNAL machine will result in failure. There are ways to workaround this problem but do NOT turn off spoofing protection.

I have several potential solutions but they depend on your desired setup.

PS, you shouldn't be able to ssh to a machine inside from outside 'cause that'd defeat the purpose of a firewall. ;-)

Hey JordanH,

I am testing my firewall system here at home on my own network, and I have a subnetwork (192.168.0.0/24) that is on the internal connection on my firewall box. I am getting my computer ready to go back to college, where their dorm networks are full of Windoze boxes pumping out the latest viruses all the time (plus hackers!). So yes, I really don't need the firewall up here at home to begin with (I'm already behind a router/firewall anyways) , but I am just getting it ready for use at college, where I should be able to uncomment that spoof or bad_ip variable again.

So for now, my external network is 192.168.1.0/24 (The gateway to the internet is 192.168.1.1)
My internal network is 192.168.0.0/24

I figured out all the garbage text to the screen was coming from the EXT_FIREWALL chain and they were all broadcast packets from the router - so I added this line right before the log/drop combo at the end of that chain:

iptables -A EXT_FIREWALL -d 192.168.1.255 -j DROP

and that fixed the logging to the console problem - for now.

How can I permanently fix it in syslog.conf - I have also noticed that NOTHING has gotten written to the syslog concerning iptables.

ok. That makes more sense now. Ok... if 192.168.1.0/24 is a valid external network, all you have to do is remove that from the spoofed IP's variable - do not turn off spoofing completely. Also, don't forget to put it back in there once you have gone away to school.

As for logging to the console... I'm not well versed in that area. While I'm slacking off at work ;-) today I'll take a look to see what I can find.

I would avoid dropping packets destined to a certain address. On which port were they being sent? I'm guessing they were from a Win32 machine... anyway, I'd take a look at the destination port and block that instead. Something like
$ipt -A EXT_FIREWALL -p tcp --dport 137 -j DROP
This way, you don't need to change your firewall when moving your PC.

I'll look into the logging to the console thing to see what I find... What exactly was the error message showing up? Was it the iptables messages or was it another error? I suspect it is something being written to stderr rather than something being written to the syslog.