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

+: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

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:
[] (stanza #1) Running CMD_CYCLE_OPEN command: /opt/sbin/iptables -I INPUT 1 -p 6 -s -d 22 -j ACCEPT run_extcmd() (with execvpe()): running CMD: /opt/sbin/iptables -I INPUT 1 -p 6 -s -d 22 -j ACCEPT
run_extcmd(): returning 0, pid_status: 0
[] (stanza #1) Running CMD_CYCLE_CLOSE command in 30 seconds: /opt/sbin/iptables -D INPUT -p 6 -s -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. - this can change!), fwknopd should NOT run this CMD_CYCLE_OPEN command:
/opt/sbin/iptables -I INPUT 1 -p 6 -s -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 -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 -d 22 -j ACCEPT

But instead run something similar to this custom CMD_CYCLE_CLOSE command:
/opt/sbin/iptables -D SSHBFP -p tcp -s -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, 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

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...


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

Reply via email to