On 09/20/2016 08:56 PM, newsboost wrote:
On 09/20/2016 02:26 PM, Michael Rash wrote:
This cuts out the rate limiting stuff and will help to verify
that SSH is available on eth0. The nmap output you sent had
'filtered' instead of 'closed', so that implies a firewall
policy in the way instead of otherwise having TCP stack
access and SSH not listening on eth0.
You're completely right! First I had my connection "filtered" and
when I tried to ssh to the WAN-side of the router (public IP
address) it was just waiting forever and nothing happens... After
running the command above, when I tried to ssh it immediately
said something about "connection closed" (I'm at work at the
moment, I just didn't have time to reply earlier)...
Ok, so does nmap now report that port 22 is "closed" instead of
"filtered"? If so, then you are either hitting the TCP stack itself
and there is nothing bound to port 22 as Jonathan suspected
(definitely important), or iptables is using the REJECT target
against your connection (as you have below), or both. To be really
sure iptables is not in the way, I would temporarily just flush the
whole policy, test SSH, and then rebuild it. So:
# iptables -F
# iptables -X
... test ssh ...
# iptables-restore ....
You need to make sure SSH is available before fwknopd can have a
chance...
SSH is available from the LAN - that's what's so strange... But now I
tested this. Still the same result: I get that port 22 is "filtered"
from the WAN-side until "opening" with:
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
And then I get that port 22 is "closed"... I verified using "shields
up". It says the same, as I discovered: First, I get a good
"stealth"-rating on "shields up" which is normally good. After running
$IPT -F,.... $IPT -X .... $IPT -I INPUT 1 -p tcp --dport 22 -j
ACCEPT,..... I immediately get that port 22 is closed. BUT I can
connect to port 22 from the LAN-side (192.168.1.XXX)...
UPDATE: I received a little help, from the Asus custom firmware-group: I
discovered that the SSHD-program on my router is called dropbear and I
was looking for SSHD because I'm used to linux... Earlier I discovered,
that the difference between opening up for SSH to only the LAN vs
LAN+WAN is this:
======================================
rt54g@router:/tmp# diff LAN_only.txt LAN+WAN.txt
--- LAN_only.txt
+++ LAN+WAN.txt
*filter
+:SSHBFP - [0:0]
+-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j SSHBFP
+-A SSHBFP -m recent --set --name SSH --rsource
+-A SSHBFP -m recent --update --seconds 60 --hitcount 4 --name SSH
--rsource -j DROP
+-A SSHBFP -j ACCEPT
======================================
From the Asus custom firmware-group, I learned (it's actually obvious
and so simple) that my SSH-WAN-access solution should be to setup
LAN+WAN and then delete the iptables-roule that opened SSH to the
WAN-side (instead of adding the rules that connected the WAN to the LAN,
which is quite simple and obvious but I didn't thought about it before -
something about dropbear was only bound to the LAN-side or
LAN-interfaces and the "LAN+WAN"-setting would bind dropbear-server to
eth0 on the WAN-side). So, I got the following, after using the routers'
web-interface to setup SSH-access to LAN+WAN (these 3 rules are the last
3 rules, output from my "diff"-command above):
wrt54g@router:/tmp/mnt/sda# iptables -t filter -L SSHBFP -v --line-numbers
Chain SSHBFP (1 references)
num pkts bytes target prot opt in out source
destination
1 1 44 all -- any any anywhere
anywhere recent: SET name: SSH side: source
2 0 0 DROP all -- any any anywhere
anywhere recent: UPDATE seconds: 60 hit_count: 4 name: SSH
side: source
3 1 44 ACCEPT all -- any any anywhere
anywhere
I followed the suggestion from the Asus firmware group and deleted the
last ACCEPT-rule in the SSHBFP-chain: wrt54g@router:/tmp/mnt/sda#
iptables -D SSHBFP -j ACCEPT
My findings:
- I tested with "shields up" and "shields up" says now all my ports are
filtered (in "stealth" mode, they call it, so ssh is invisible from
WAN-side)!
- I also tested with nmap from the LAN-side to the external IP (ssh
admin@router-external_IP-address) and this says "22/tcp open ssh". I
believe it's okay, as I'm SSH'ing from the LAN and the router will not
see me coming from the WAN/internet...
- Finally I tested, running a VPN-connection on my main pc and then
connecting (trying to SSH into) to the WAN-side of the router. Again,
now port 22 is filtered - so everything is ok, so far...
Now I need to open up, after sending an SPA-packet. My task is to ensure
I use fwknopd in the correct way, i.e. I believe right after fwknopd
receives the SPA-packet it must use something like the following custom
command to open port 22 and expose it to the WAN-side:
router-shell# iptables -A SSHBFP -j ACCEPT
From earlier I received this information:
[178.161.214.215] (stanza #1) Running CMD_CYCLE_OPEN command:
/opt/sbin/iptables -I INPUT 1 -p 6 -s 178.161.214.215 -d 22 -j ACCEPT
run_extcmd() (with execvpe()): running CMD: /opt/sbin/iptables -I INPUT
1 -p 6 -s 178.161.214.215 -d 22 -j ACCEPT
run_extcmd(): returning 0, pid_status: 0
[178.161.214.215] (stanza #1) Running CMD_CYCLE_CLOSE command in 30
seconds: /opt/sbin/iptables -D INPUT -p 6 -s 178.161.214.215 -d 22 -j ACCEPT
pcap_dispatch() processed: 1 packets
I was thinking, the following:
--------------------------------------
I think when the SPA-packet is received (from e.g. 178.161.214.215 -
this can change!), fwknopd should NOT run this CMD_CYCLE_OPEN command:
/opt/sbin/iptables -I INPUT 1 -p 6 -s 178.161.214.215 -d 22 -j ACCEPT
But instead run something similar to this custom CMD_CYCLE_OPEN command
(IP protocol number 6 = tcp and this is easier to read):
/opt/sbin/iptables -A SSHBFP -p tcp -s 178.161.214.215 -d 22 -j ACCEPT
-------
When fwknopd closes the connection, it should not run this
CMD_CYCLE_CLOSE command:
/opt/sbin/iptables -D INPUT -p 6 -s 178.161.214.215 -d 22 -j ACCEPT
But instead run something similar to this custom CMD_CYCLE_CLOSE command:
/opt/sbin/iptables -D SSHBFP -p tcp -s 178.161.214.215 -d 22 -j ACCEPT
-------
So, what I did (just as I learned from you in here, thanks, I'm very
grateful!) was to change my (non-default location, I know, but here's
the file): /opt/etc/fwknop/access.conf like so (I discovered "-d 22"
gets translated to destination ip 22.0.0.0, so it should be "--dport 22"):
CMD_CYCLE_OPEN /usr/sbin/iptables -I SSHBFP -p $PROTO -s $IP
--dport $PORT -j ACCEPT
CMD_CYCLE_CLOSE /usr/sbin/iptables -D SSHBFP -p $PROTO -s $IP
--dport $PORT -j ACCEPT
CMD_CYCLE_TIMER 15
For the reference: I believe it was important to use the
firmware-version of the iptables instead of the entware. Sometimes I
could not delete or add a rule using the entware-version, so it's really
great fwknopd can run custom commands. Also, in the SSHBFP-chain I hade
some rate-limiting stuff ("recent: SET name: SSH side: source" and
"recent: UPDATE seconds: 60 hit_count: 4 name: SSH side: source") and
therefore I used "iptables -I" to insert my ACCEPT rule above this...
*** VERIFIED AND WORKING!!! ***
Thanks again! I feel it's important to explain how it's working, so
maybe other people who find this through google or whatever, can see the
whole solution... I'm very happy now, thanks - I'll also stay on the
list for a while, to see and maybe learn more possibilities! :-)
------------------------------------------------------------------------------
_______________________________________________
Fwknop-discuss mailing list
Fwknop-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
