?
Solved

Can't SSH after blocking UDP traffic / Firewall Question

Posted on 2007-07-31
16
Medium Priority
?
670 Views
Last Modified: 2013-12-16
I'm configuring my firewall (through iptables).  When I block all UDP traffic (other than DNS), I can no longer open a SSH connection to my server (I'm connecting through PuTTy).  Does anyone know why this is, and what I can keep open to fix this?
0
Comment
Question by:raterus
  • 8
  • 5
  • 3
16 Comments
 
LVL 2

Expert Comment

by:crustymonkey
ID: 19603298
What exactly is the error you receive when trying to ssh to your server?  What are the other rules you have in place in iptables, and specifically, what is the rule you are using to block UDP?
0
 
LVL 33

Author Comment

by:raterus
ID: 19603372
Here is my iptables configuration, I'm using webmin to configure this file.  This problem may also have to do with my fail2ban configuration.  When I first setup the firewall, fail2ban was already in the firewall, I've pretty much taken it out because it didn't look like it was doing much.  

I'm getting "Connection Refused", when I put these changes in place.


# Generated by iptables-save v1.2.11 on Mon Jul 16 20:28:19 2007
*mangle
:PREROUTING ACCEPT [2696780:446829969]
:INPUT ACCEPT [2696776:446829809]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2808381:854054509]
:POSTROUTING ACCEPT [2808381:854054509]
COMMIT
# Completed on Mon Jul 16 20:28:19 2007
# Generated by iptables-save v1.2.11 on Mon Jul 16 20:28:19 2007
*nat
:PREROUTING ACCEPT [2316660:117119074]
:POSTROUTING ACCEPT [164312:11907459]
:OUTPUT ACCEPT [164312:11907459]
COMMIT
# Completed on Mon Jul 16 20:28:19 2007
# Generated by iptables-save v1.2.11 on Mon Jul 16 20:28:19 2007
*filter
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:fail2ban-SSH - [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -p tcp -m tcp -m multiport -j ACCEPT --dports 21,22,25,53,80,110,143,443,993,995,10000,20000
-A fail2ban-SSH -j RETURN
-A INPUT -p udp -m udp -m multiport -j ACCEPT --dports 22,53
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -m tcp -j DROP
-A INPUT -p udp -m udp -j DROP
COMMIT
# Completed on Mon Jul 16 20:28:19 2007
0
 
LVL 2

Expert Comment

by:crustymonkey
ID: 19605332
Is this the machine that you are trying to SSH *to* or *from*?
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 33

Author Comment

by:raterus
ID: 19605374
Firewall is running on the machine I'm trying to SSH to
0
 
LVL 2

Expert Comment

by:crustymonkey
ID: 19605897
Ok, there seems to be nothing really wrong with the setup you have posted.  Do you have physical access to the server that you are trying to configure or is it remote?  If you have physical access, it would probably be worth your time to sit at the console after you make your change which locks out ssh and run the following as root:

iptables --line-numbers -L -v -n

This will dump your current, in memory, config to the terminal.  You may want to pipe this to less as it will probably go over 24 lines.  Make sure that the config that gets dumped to the screen looks like what is in the file.  I'm noticing that the file was last saved on the 16th and that you might be ending up with something different after your webmin configuration.  You have to remember that what is in the save file does not reflect what the current running config is.  The file is only changes when you run iptables-save /path/to/file.  What you have posted should allow you to ssh to the machine so you probably want to take it to one more step of troubleshooting.
0
 
LVL 16

Expert Comment

by:xDamox
ID: 19607572
Hi,

You can fix this by issuing:

iptables -I INPUT 1 -m state --state NEW,ESTABLISHED,RELATED -p tcp --dport 22 -j ACCEPT
iptables -I INPUT 1 -m state --state NEW,ESTABLISHED,RELATED -p udp --dport 22 -j ACCEPT
0
 
LVL 33

Author Comment

by:raterus
ID: 19608358
Here is the output of,
iptables --line-numbers -L -v -n
(below)

The interesting thing is I can apply the iptables, but if I have an open SSH connection, it'll still work fine.  This problem is ONLY when I try to open a SSH connection after I apply the configuration, existing sessions won't be dropped.

xDamox, As you can see from the below configuration, I'm already accepting port 22 for both TCP and UDP

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     all  --  *      *       127.0.0.1            0.0.0.0/0
2        3   224 fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
3       26  2191 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp multiport dports 21,22,25,53,80,110,143,443,993,995,10000,20000
4        0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp multiport dports 22,53
5        0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
6        0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp
7        0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 39 packets, 31874 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-SSH (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        3   224 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0
0
 
LVL 16

Expert Comment

by:xDamox
ID: 19608464
Yea,

Try placing the SSH rule at the very beginning of the INPUT table.
0
 
LVL 33

Author Comment

by:raterus
ID: 19608527
I'm not dropping packets until the very end, so I'm not sure how that will help here.
0
 
LVL 16

Expert Comment

by:xDamox
ID: 19608555
Hi,

Its just to help with debugging and eliminate any other possible errors.
0
 
LVL 33

Author Comment

by:raterus
ID: 19608728
Right, and on my above configuration, everything works as expected until I add a rule to drop all UDP packets at the very end.  So something with UDP, not having to do with port 22 (which is already allowed above), is blocking PuTTY from connecting to my linux server.  By the way, I'm using public key authentication when I try to log on.

I'm going to try specifying a port range, and see if I can't figure out exactly what port I'm blocking is causing the problem.
0
 
LVL 33

Author Comment

by:raterus
ID: 19609061
This problem is getting much more weirder.

I started opening and closing ranges of ports on my firewall, hoping to track down exactly what port I am blocking is causing the problem.  

The port ranges I came up with were somewhere between 42000 - 42200.  I was trying to track it down further, but whatever this is, it's changing ports on me every couple of minutes.

Why in the world would OpenSSH need an open UDP port in this range to be able to be successfully connected to?  And why would it need to change?
0
 
LVL 2

Accepted Solution

by:
crustymonkey earned 2000 total points
ID: 19609809
The only thing that I can think of here is that you have some restriction configured in terms of DNS resolution.  When you do a DNS lookup, the response is returned via UDP on a random unprivileged port (>1023).  If you don't have those open for external udp connections, you won't receive the DNS response.  If I remember correctly, the only time TCP is used for DNS is in zone transfers.  The default sshd_config has the following set:

UseDNS=yes

If sshd cannot perform a reverse lookup on the connecting IP, it will refuse the connection.  Either open your UDP ports > 1023 or set UseDNS=no in your sshd_config.  I'm not positive on this, but you may be able to continue to deny udp connections by adding the following:

iptables -I INPUT 1 -p udp --dport 1024:65535 -m state --state RELATED -j ACCEPT

I seem to remember reading somewhere that the kernel will set the DNS response port to a related state in the stack.  Therefore, using the above rule, you should be able to receive DNS responses, but not anything else on your unprivileged ports.
0
 
LVL 33

Author Comment

by:raterus
ID: 19610357
I think I've learned a bit about firewalls today, and it makes a lot of sense now.

crustymonkey, you were right about the DNS issue.  My ssh server was sending a DNS query, and blocking the response.  In fact, my firewall was setup in such a way it would block ANY response from an outside server that it initiated, so even something as simple as the web wasn't working from my server.

So what I've ended up doing is adding a rule to allow any packets, for Established or Related connections.  And everything appears to be working now!

Let me know if I've done something wrong.
0
 
LVL 2

Expert Comment

by:crustymonkey
ID: 19610421
That sounds correct.  I haven't worked with iptables in a while so I'm a little rusty (I use pf on FreeBSD nowadays).  I probably should have noticed that though ;-)  Anyhow, hope everything works right for you.
0
 
LVL 33

Author Comment

by:raterus
ID: 19610442
Thanks again for your help!
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Note: for this to work properly you need to use a Cross-Over network cable. 1. Connect both servers S1 and S2 on the second network slots respectively. Note that you can use the 1st slots but usually these would be occupied by the Service Provide…
It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:
Suggested Courses
Course of the Month13 days, 22 hours left to enroll

809 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question