[prev in list] [next in list] [prev in thread] [next in thread]
List: fwknop-discuss
Subject: Re: [Fwknop-discuss] noob - cannot figure out errors (e.g., "Couldn't load target `FWKNOP_INPUT'") w
From: newsboost <newsboost () gmail ! com>
Date: 2016-09-21 20:32:18
Message-ID: 6e7a0785-e76e-0a00-2bb3-2c0b60d891e3 () gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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! :-)
[Attachment #5 (text/html)]
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 09/20/2016 08:56 PM, newsboost wrote:<br>
<blockquote
cite="mid:c54e66b2-e0a0-6ae5-ab53-f063fce0dee3@gmail.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
On 09/20/2016 02:26 PM, Michael Rash wrote:<span class=""></span><br>
<span class=""></span><span class=""></span>
<blockquote
cite="mid:CAA9wn8mj_26FXMsYdmNzFviMQf88L_GqVGWr6QETfGBf1VkQ-Q@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><span class="">
<blockquote style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"
class="gmail_quote">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div>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)...<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div># iptables -F</div>
<div># iptables -X</div>
<div>... test ssh ...</div>
<div># iptables-restore ....</div>
<div><br>
</div>
<div>You need to make sure SSH is available before fwknopd
can have a chance...</div>
</div>
</div>
</blockquote>
<br>
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:<br>
<br>
<span class=""># iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT<br>
<br>
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 .... </span><span class="">$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)...</span><br>
</blockquote>
<br>
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:<br>
<br>
====================================== <br>
rt54g@router:/tmp# diff LAN_only.txt LAN+WAN.txt <br>
--- LAN_only.txt <br>
+++ LAN+WAN.txt <br>
<br>
*filter <br>
+:SSHBFP - [0:0] <br>
+-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -j
SSHBFP <br>
+-A SSHBFP -m recent --set --name SSH --rsource <br>
+-A SSHBFP -m recent --update --seconds 60 --hitcount 4 --name SSH
--rsource -j DROP <br>
+-A SSHBFP -j ACCEPT <br>
====================================== <br>
<br>
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):<br>
<br>
wrt54g@router:/tmp/mnt/sda# iptables -t filter -L SSHBFP -v
--line-numbers<br>
Chain SSHBFP (1 references)<br>
num pkts bytes target prot opt in out
source destination <br>
1 1 44 all -- any any
anywhere anywhere recent: SET name: SSH
side: source<br>
2 0 0 DROP all -- any any
anywhere anywhere recent: UPDATE seconds: 60
hit_count: 4 name: SSH side: source<br>
3 1 44 ACCEPT all -- any any
anywhere anywhere <br>
<br>
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<br>
<br>
<br>
My findings:<br>
- 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)!<br>
- 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...<br>
- 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...<br>
<br>
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:<br>
<br>
router-shell# iptables -A SSHBFP -j ACCEPT<br>
<br>
From earlier I received this information:<br>
[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<br>
run_extcmd() (with execvpe()): running CMD: /opt/sbin/iptables -I
INPUT 1 -p 6 -s 178.161.214.215 -d 22 -j ACCEPT<br>
run_extcmd(): returning 0, pid_status: 0<br>
[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<br>
pcap_dispatch() processed: 1 packets<br>
<br>
<br>
I was thinking, the following:<br>
--------------------------------------<br>
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:<br>
/opt/sbin/iptables -I INPUT 1 -p 6 -s 178.161.214.215 -d 22 -j
ACCEPT<br>
<br>
But instead run something similar to this custom CMD_CYCLE_OPEN
command (IP protocol number 6 = tcp and this is easier to read):<br>
/opt/sbin/iptables -A SSHBFP -p tcp -s 178.161.214.215 -d 22 -j
ACCEPT<br>
-------<br>
When fwknopd closes the connection, it should not run this
CMD_CYCLE_CLOSE command:<br>
/opt/sbin/iptables -D INPUT -p 6 -s 178.161.214.215 -d 22 -j ACCEPT<br>
<br>
But instead run something similar to this custom CMD_CYCLE_CLOSE
command:<br>
/opt/sbin/iptables -D SSHBFP -p tcp -s 178.161.214.215 -d 22 -j
ACCEPT<br>
-------<br>
<br>
<br>
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"):<br>
<br>
CMD_CYCLE_OPEN /usr/sbin/iptables -I SSHBFP -p $PROTO -s $IP
--dport $PORT -j ACCEPT<br>
CMD_CYCLE_CLOSE /usr/sbin/iptables -D SSHBFP -p $PROTO -s $IP
--dport $PORT -j ACCEPT<br>
CMD_CYCLE_TIMER 15<br>
<br>
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...<br>
<br>
*** VERIFIED AND WORKING!!! ***<br>
<br>
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! :-)<br>
<br>
</body>
</html>
------------------------------------------------------------------------------
_______________________________________________
Fwknop-discuss mailing list
Fwknop-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fwknop-discuss
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic