LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 01-06-2004, 09:52 PM   #1
computergeek84
Member
 
Registered: Nov 2003
Location: /dev/null
Distribution: Gentoo, Ubuntu
Posts: 61

Rep: Reputation: 15
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:
Code:
# netstat -a | grep ESTABLISHED
tcp              0          0     192.168.1.104:37385          192.168.1.106:ssh             ESTABLISHED
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:
Code:
# netstat -a | grep ESTABLISHED
tcp              0          0     192.168.1.104:ssh          192.168.1.106:33317             ESTABLISHED
I am baffled about these arbitrary ports numbers in the 1025-65535 range. Why is it using these?

Last edited by computergeek84; 01-06-2004 at 10:35 PM.
 
Old 01-06-2004, 11:48 PM   #2
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 57
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.
 
Old 01-07-2004, 09:09 AM   #3
computergeek84
Member
 
Registered: Nov 2003
Location: /dev/null
Distribution: Gentoo, Ubuntu
Posts: 61

Original Poster
Rep: Reputation: 15
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
 
Old 01-07-2004, 11:34 AM   #4
Capt_Caveman
Senior Member
 
Registered: Mar 2003
Distribution: Fedora
Posts: 3,658

Rep: Reputation: 57
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.

Last edited by Capt_Caveman; 01-07-2004 at 11:36 AM.
 
Old 01-07-2004, 12:38 PM   #5
computergeek84
Member
 
Registered: Nov 2003
Location: /dev/null
Distribution: Gentoo, Ubuntu
Posts: 61

Original Poster
Rep: Reputation: 15
Yes - that line was in the firewall script, but I just didn't post it...
 
Old 01-07-2004, 03:12 PM   #6
JordanH
Member
 
Registered: Oct 2003
Location: Toronto, Canada
Distribution: Ubuntu, FC3, RHEL 3-4 AS Retired: SuSE 9.1 Pro, RedHat 6-9, FC1-2
Posts: 360

Rep: Reputation: 30
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.]
 
Old 01-07-2004, 03:27 PM   #7
computergeek84
Member
 
Registered: Nov 2003
Location: /dev/null
Distribution: Gentoo, Ubuntu
Posts: 61

Original Poster
Rep: Reputation: 15
yes - eth1 is ext and eth0 is int.

Thanks for the script BTW - it has been very helpful!
 
Old 01-07-2004, 03:45 PM   #8
JordanH
Member
 
Registered: Oct 2003
Location: Toronto, Canada
Distribution: Ubuntu, FC3, RHEL 3-4 AS Retired: SuSE 9.1 Pro, RedHat 6-9, FC1-2
Posts: 360

Rep: Reputation: 30
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?

Last edited by JordanH; 01-07-2004 at 03:47 PM.
 
Old 01-07-2004, 04:15 PM   #9
Dewar
Member
 
Registered: Sep 2003
Location: Washington State
Distribution: SuSE 8.0, SuSE 9.0, Slack 9.1
Posts: 90

Rep: Reputation: 15
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
 
Old 01-07-2004, 05:57 PM   #10
JordanH
Member
 
Registered: Oct 2003
Location: Toronto, Canada
Distribution: Ubuntu, FC3, RHEL 3-4 AS Retired: SuSE 9.1 Pro, RedHat 6-9, FC1-2
Posts: 360

Rep: Reputation: 30
(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.)
 
Old 01-07-2004, 06:43 PM   #11
computergeek84
Member
 
Registered: Nov 2003
Location: /dev/null
Distribution: Gentoo, Ubuntu
Posts: 61

Original Poster
Rep: Reputation: 15
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.
 
Old 01-07-2004, 07:27 PM   #12
computergeek84
Member
 
Registered: Nov 2003
Location: /dev/null
Distribution: Gentoo, Ubuntu
Posts: 61

Original Poster
Rep: Reputation: 15
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)?
 
Old 01-07-2004, 10:03 PM   #13
JordanH
Member
 
Registered: Oct 2003
Location: Toronto, Canada
Distribution: Ubuntu, FC3, RHEL 3-4 AS Retired: SuSE 9.1 Pro, RedHat 6-9, FC1-2
Posts: 360

Rep: Reputation: 30
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. ;-)

Last edited by JordanH; 01-07-2004 at 10:04 PM.
 
Old 01-07-2004, 10:21 PM   #14
computergeek84
Member
 
Registered: Nov 2003
Location: /dev/null
Distribution: Gentoo, Ubuntu
Posts: 61

Original Poster
Rep: Reputation: 15
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.
 
Old 01-08-2004, 08:15 AM   #15
JordanH
Member
 
Registered: Oct 2003
Location: Toronto, Canada
Distribution: Ubuntu, FC3, RHEL 3-4 AS Retired: SuSE 9.1 Pro, RedHat 6-9, FC1-2
Posts: 360

Rep: Reputation: 30
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SSH] Issue logging in [SSH & Permissions] MD3 Linux - Networking 11 12-10-2006 09:25 AM
SSH issue petachi Linux - Newbie 2 04-06-2004 06:57 PM
iptables issue rkemp Linux - Networking 3 11-29-2003 06:50 PM
iptables issue f1uke Linux - Security 3 08-11-2003 07:58 PM
ssh issue: /usr/bin/ssh -x -oFallBackToRsh no -l WeNdeL Linux - Software 1 03-04-2003 07:17 PM


All times are GMT -5. The time now is 06:09 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration