>
> From: Michael Rash <michael.rash@gm...> - 2016-09-20 03:01:54
>

Hi Michael, sorry if this message is weird, I received messages as "digest"
but now changed it and did some copy/paste here as I didn't receive this
"digest"-mail yet, but wanted to reply to it anyway...


> On Mon, Sep 19, 2016 at 6:49 PM, newsboost <newsbo...@gmail.com> wrote:
>
>>
>> ======================================
>> 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
>> ======================================
>>
>> I'm definately not an iptables-expert. But what I think I see here, is
>> that when I go from SSH-access, from only LAN to LAN+WAN, then the
>> "only" difference is that the router adds something extra to the
>> IPTABLES-rules. In this case, something extra is added to the
>> "filter"-table, more specifically, the INPUT-chain. My understanding is
>> that "SSHBFP" is a new "target", so when something (a tcp-packet) tries
>> to connect to port 22 from eth0 (the WAN-side of the router = the
>> internet-side) and it is new, the first rule says: Jump to target
>> "SSHBFP". Then there are 3 new commands - I don't know what they do. And
>> finally that packet is ACCEPTED.
>>
>
> That is correct - the additional commands apply the iptables 'recent'
> extension to effectively do rate limiting on incoming SSH connection
> requests. Somewhere else in your INPUT chain there should be a rule to
> accept packets that are part of established connections as well.
>

Thanks! You're right, I'm sure there is a rule for established connections
but that is probably not caught by the diff-tool...


>
>> Without changing these rules in the web-interface, I tried to login to
>> the Asus-router and using SSH (from LAN-side) I wanted to type in
>> something like:
>>
>> # iptables -N SSHBFP
>> # iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state
>> NEW -j SSHBFP
>> iptables: Protocol wrong type for socket.
>> # iptables -A SSHBFP -m recent --set --name SSH --rsource
>> # iptables -A SSHBFP -m recent --update --seconds 60 --hitcount 4 --name
>> SSH --rsource -j DROP
>> # iptables -A SSHBFP -j ACCEPT
>>
>> So, I'm not completely sure what is going on... I don't understand the
>> "Protocol wrong type for socket". These commands don't work. If they
>> did, I think it should be possible to make the fwknopd-server let me
>> in...
>
>
> I think that iptables error is because of a bug in iptables and/or the
> kernel on your system based on some searches I did - those commands should
> work just fine. Your strategy is a good one, and let's try simplifying the
> iptables commands a bit. Just do the following and see if you can SSH to
> the WAN side:
>
> # iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
>

You're right - must be a bug in the entware version of iptables, which I'm
using... Anyway, you're right:


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

Anyway, if it isn't possible for me to login directly to the
>> router using fwknopd, would it be possible for me to maybe first send
>> the SPA-packet and then SSH into one of the machines on the LAN (from
>> the internet/WAN-side), e.g. 192.168.1.150 ? How would I setup this ?
>>
>
> You could use the NAT capabilities in fwknopd to NAT an incoming SSH
> connection from the WAN side straight through to an internal system if you
> prefer that (but it shouldn't be necessary - access to SSH on eth0 should
> be possible directly from the WAN side). There are some details on this
> here:
>
> http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#nat
>

Thanks, I begin to understand it and it makes me feel very happy that by
using your iptables command I now get connection closed instead of
filtered... But why doesn't it yet allow ssh from the outside, just by
running:

# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT

Am I right, somewhere else in the iptables-rules - something must be
REJECTING (isn't that the difference between -j DROP which acts like a
"filter" and -j REJECT which just closes the attempt to SSH in) ?

Or can it be something in the implementation of sshd, on the router? When I
get home from work later today, I'll try to see all the iptables rules and
see if I can understand why it rejects ssh-connections...
Thanks!


Br,
Martin
------------------------------------------------------------------------------
_______________________________________________
Fwknop-discuss mailing list
Fwknop-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fwknop-discuss

Reply via email to