[SOLVED] Is my firewall preventing me from logging in via ssh?

Pringle · 05-06-2013, 07:10 PM

Hello,

I have created a bash script for my firewall and I thought everything was fine until I logged out and tried to log back in again using ssh.

I only started learning about this a couple of days ago when I noticed many ip addresses in my /var/log/auth.log either attempting to brute force or single attacks.

Here is the script I am using and I thought it would allow all connection attempts apart from the ones I blacklisted.

Code:

#!/bin/bash

IPT=/sbin/iptables

#FLUSH
$IPT -F
$IPT -X

#SET DEFAULTS
$IPT -P OUTPUT ACCEPT
$IPT -P INPUT DROP
$IPT -P FORWARD DROP

#CREATE USER CHAINS
$IPT -N SERVICE

#ALLOWED INPUTS
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A INPUT -j SERVICE

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

#ALLOWED SERVICES
$IPT -A SERVICE -p tcp --dport 22 -j ACCEPT

#SPECIFIC ATTACKS
#prevent local ip spoofing
$IPT -A INPUT -i !lo -s 127.0.0.0/8 -j DROP
#prevent smurf attack
$IPT -I INPUT -p icmp --icmp-type echo-request -m recent --set
$IPT -I INPUT -p icmp --icmp-type echo-request -m recent --update --seconds 2 --hitcount 1 -j DROP
#drop invalid tcp flags
$IPT -A INPUT -m state --state INVALID -j DROP
$IPT -A OUTPUT -m state --state INVALID -j DROP
$IPT -A FORWARD -m state --state INVALID -j DROP
#drop tcp flags that don't make sense
$IPT -t filter -A INPUT -p tcp --tcp-flags FIN,ACK FIN -j DROP
$IPT -t filter -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
$IPT -t filter -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP
$IPT -t filter -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
$IPT -t filter -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
$IPT -t filter -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP

#BLACKLIST
#My attackers
$IPT -A SERVICE -s 94.242.252.0/24 -p tcp -j DROP
$IPT -A SERVICE -s 178.172.235.0/24 -p tcp -j DROP
$IPT -A SERVICE -s 203.255.252.0/24 -p tcp -j DROP
$IPT -A SERVICE -s 221.12.174.0/24 -p tcp -j DROP
$IPT -A SERVICE -s 202.112.112.0/24 -p tcp -j DROP
#Leks' attackers
$IPT -A SERVICE -s 62.217.127.0/24 -p tcp -j DROP
$IPT -A SERVICE -s 106.3.242.0/24 -p tcp -j DROP
$IPT -A SERVICE -s 61.156.238.0/24 -p tcp -j DROP

#Allow Me
$IPT -A SERVICE -s 192.168.1.0/24 -p tcp -j ACCEPT

#SAVE AND DISPLAY
iptables-save > /etc/iptables.rules
$IPT --list

Pringle · 05-06-2013, 08:46 PM

I had been using ssh to access this machine on my local network and I was using the hostname

for example

Code:

ssh user@hostname

and it wasn't working. It was working before I ran my firewall script. I decided to try with ip

for example

Code:

ssh user@192.168.XXX.XXX

and this worked

Can anyone tell me what has caused the difference?

unSpawn · 05-07-2013, 01:37 AM

- either use the firewall tools your system provides or use the default 'iptables-save' and 'iptables-restore' tools for displaying, saving and loading rule sets.
- start with the default rule set and modify that.
- if you're not well-versed in writing rules and like automatic blocking and reporting then best use as much available tools like fail2ban.

Here's what your filter table, simplified and re-ordered, could look like:

Code:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -s 192.168.1.0/24 -m state --state NEW -j ACCEPT
-A INPUT -s 127.0.0.0/8 -j LOG --log-prefix "IN_lo-range "
-A INPUT -s 127.0.0.0/8 -j DROP
-A INPUT -p icmp --icmp-type echo-request -m recent --set
-A INPUT -p icmp --icmp-type echo-request -m recent --update --seconds 2 --hitcount 1 -j LOG --log-prefix "IN_icmp "
-A INPUT -p icmp --icmp-type echo-request -m recent --update --seconds 2 --hitcount 1 -j DROP
-A INPUT -m state --state INVALID -j LOG --log-prefix "IN_inv "
-A INPUT -m state --state INVALID -j DROP
-A INPUT -p tcp --tcp-flags FIN,ACK FIN -j DROP
-A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
-A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP
-A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
-A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
-A OUTPUT -m state --state INVALID -j  --log-prefix "OUT_inv "
-A OUTPUT -m state --state INVALID -j DROP
COMMIT

Ponder why that could be.

*BTW your hostname vs IP address question probably points to faulty or non-existent DNS resolution (if local try /etc/hosts entries or a caching name server like Pdnsd, Dnsmasq or even ISC BINDs caching-nameserver).

Pringle · 05-07-2013, 07:55 PM

Quote:

Originally Posted by unSpawn

*BTW your hostname vs IP address question probably points to faulty or non-existent DNS resolution (if local try /etc/hosts entries or a caching name server like Pdnsd, Dnsmasq or even ISC BINDs caching-nameserver).

Thank you, I added rules to accept packets from my router dns and this solved this problem for me.

I am still finding people trying to access my ssh port from unrecognised ip addresses. I am aware that I could just accept packets from specific ip addresses but I never know where I will log in from next so I don't want to end up blocking myself from getting in for example if I went to France for a few days. I have looked into using a DSA key which I could stick on my mobile phone's SD card and copy it into the authorized_keys file on any machine that I am going to use to connect to my server and then I can delete it once I am done. This seems like the best way forward.

unSpawn · 05-08-2013, 01:26 AM

See http://www.linuxquestions.org/questi...tempts-340366/

Pringle · 05-08-2013, 05:45 PM

I checked out that link you sent me and I feel like this next question is more relevant to that one but that thread was closed. I have created a public key on my server and I can now login using this key. This makes me feel so much more secure now.

However, I have also found that when I tried to log in to another server that I use I couldn't get there. It told me that it too needed a public key even though there is no authorized_key file on there. Does my client machine now have to always use a public key? I also didn't edit the config file on there to disable password access.

The only thing I can think of is that the ssh-keygen tool did something.

Pringle · 05-08-2013, 05:56 PM

Quote:

Originally Posted by pringle

I have looked into using a DSA key which I could stick on my mobile phone's SD card and copy it into the authorized_keys file on any machine that I am going to use to connect to my server and then I can delete it once I am done. This seems like the best way forward.

After some research I realised that actually RSA is a better way forward and you actually copy the contents of the public key into the authorized_keys file on the server and then make sure you have the public key in ~/.ssh on any client you want to log in from.

unSpawn · 05-09-2013, 12:22 AM

Reading SSH documentation or generic instructions about enabling pubkey auth should show copying over the public key to the remote servers ~/.ssh/authorized_keys file is an integral part of getting pubkey auth to work, regardless of the chosen key type. Also see 'man ssh-copy-id'.