On Tue, Sep 20, 2016 at 5:51 AM, newsboost . <newsbo...@gmail.com> wrote:
> 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
>> 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)...
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...
> 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
> 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
> # 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...
> Fwknop-discuss mailing list
Fwknop-discuss mailing list