dropbear -s -p 40400 WAN access problem

[dyonisos]

I am starting dropbear with port 40400 and opened firewall on same port.
WAN access through bridged modem (no port forward needed) gives putty Disconnect error: "no supported authentication methods available"

Any idea how to solve this? Seems like putty or dropbear does not support this?
Thanks for your help!

[Tamadite]

Does it work when you start it on the regular port (22)?

[dyonisos]

on port 22 it is working perfect.

WAN access with dropbear -s -p 40400 even shows login request and thereafter disconnects with the above stated error message.

any idea how to solve this?

[dyonisos]

as dropbear -s -p 40400 is not working, I am experiencing heavy attacks on port 22. Also I am using a fixed WAN-IP.

please help!

[al37919]

a simple defense against brute force attacks would be based on ipt_recent module of iptables. It is included by default in the latest release of testing post-10 firmware ( http://wl500g.info/showthread.php?t=18004 http://code.google.com/p/wl500g )

[Tamadite]

That's very strange!

I have created the scenario with public/private keys using parameters "-s -p 40400" as you do. By using putty, I can open a ssh session from both LAN and WAN without problems.

[Tamadite]

a simple defense against brute force attacks would be based on ipt_recent module of iptables. It is included by default in the latest release of testing post-10 firmware ( http://wl500g.info/showthread.php?t=18004 http://code.google.com/p/wl500g )

I have brute force attack prevention for SSH by using iptables. I can give you the configuration for it if you want.

On the other hand, I would run two SSH deamons on two different ports: one deamon on the ordinary port 22 with "disable password logins" (parameter -s) and the other one on any other port e.g. 40400 where I can login by using user/password in case I do not have the private-key with me. On both cases/ports, brute force attack prevention is desirable.

[dyonisos]

Hi Tamadite,

Could you please provide me your iptables config and if possible the brute force prevention iptables.

Thanks dyonisos

[dyonisos]

syslog.log fills up quickly; this is what I receive in thousands:

Mar 6 23:13:44 dropbear[11840]: login attempt for nonexistent user from ::ffff:66.246.72.93:51983

[Tamadite]

Since the policy of my INPUT chain is DROP, what I added to the firewall when recreating your case was:

iptables -I INPUT -p tcp --dport 40400 -j ACCEPT

I got your error message a couple of times while recreating your environment until I got it fixed. My experience is that the source of your problem might not be on the firewall but on the configuration of SSH and/or Putty and maybe the keys. What I can not get is why you do not get that error message on port 22 (dropbear -s) but on port 40400 (dropbear -s -p 40400). Does it work for you with "-s -p 40400" when opening a session from the LAN?

The brute force attack prevention code is:

#!/bin/sh

# This we know...
WANIF=vlan1
LANIP=192.168.1.1

# insert necessary modules
insmod ipt_recent
insmod ipt_psd
insmod ipt_TARPIT

# deleting last firewal rules (policy)
iptables -D INPUT -j DROP
iptables -D INPUT -j logdrop

# Drop previous offenders - you dont want them in your net at all!
iptables -N BANDITDROP
iptables -A INPUT   -m recent --rcheck --name BANDIT -j BANDITDROP
iptables -A FORWARD -m recent --rcheck --name BANDIT -j BANDITDROP
iptables -A BANDITDROP -m recent --update --seconds 3600 --rttl --name BANDIT \
  -j LOG --log-prefix "Bandit DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -A BANDITDROP -j REJECT --reject-with  icmp-net-unreachable

# SSH server with brute force prevention
iptables -N SSHFORCEDROP
iptables -N SSHACCEPT
iptables -A INPUT -m tcp -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 2 -j SSHACCEPT
# iptables -A INPUT -p tcp --dport 22 -j SSHACCEPT
iptables -A INPUT -m tcp -p tcp --dport 22 -j SSHFORCEDROP
iptables -A SSHFORCEDROP -m recent --set --name BANDIT
iptables -A SSHFORCEDROP -m recent --update --seconds 3600 --rttl --name BANDIT \
  -j LOG --log-prefix "SSH_Brute_Force DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -A SSHFORCEDROP -p tcp -j TARPIT
iptables -A SSHFORCEDROP -j  REJECT --reject-with  icmp-proto-unreachable
iptables -A SSHACCEPT -j LOG --log-prefix "SSH ACCEPT " --log-tcp-sequence \
  --log-tcp-options --log-ip-options
iptables -A SSHACCEPT -j ACCEPT
iptables -t nat -A PREROUTING -i ${WANIF} -p tcp --dport 22 -j DNAT --to-destination ${LANIP}:22
# iptables -t nat -A PREROUTING -i ${WANIF} -p tcp --dport 22 -j DNAT --to-destination 192.168.1.1:22

# Restablishing INPUT chain policy
iptables -A INPUT -p tcp -m tcp -j LOG --log-prefix "TARPIT " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -A INPUT -p tcp -m tcp -j TARPIT
iptables -A INPUT -j logdrop
iptables -A INPUT -j DROP

I added the code above to a separate file that is called by post-firewall.

NOTES:
delete entry from BANDIT file: echo "-[keyword]" > [path/BANDIT]
clear BANDIT file: echo "clear" > [path/BANDIT]

[dyonisos]

Thanks for your fast response!

actually I used dropbear in post-boot without any parameter (as default port is 22).
this is working perfect LAN and WAN.

I had to switch my DSL-modem into bridged mode and for this reason I wanted to use a different ssh port e.g. 40400 by using dropbear -s -p

and dropbear -s -p 40400 does neither work on LAN nor WAN displaying the authentication methods error after typing login name.

I thinks you are right, that dropbear or putty are doing something wrong here.

What is the meaning of the -s parameter of dropbear? Maybe I need to configure dropbear?

[Tamadite]

dropbear --help

will show, among other informaiton:

-s              Disable password logins

Since it seems you are not using private/public key on port 22, try:

dropbear -p 40400

It should work from LAN. To get it to work from WAN you should open port 40400 on the firewall as mentioned on previous posts.

[dyonisos]

is my post-firewall file maybe lousy? I don't know about iptables.

#!/bin/sh
# set default policy
iptables -P INPUT DROP
#
# remove last default route
iptables -D INPUT -j DROP
#
# deny ftp access from WAN?
# iptables -D INPUT -p tcp -m tcp -d "$2" --dport 21 -j ACCEPT
#
# allow WAN ssh access
iptables -A INPUT -p tcp --syn --dport 22 -j ACCEPT

[dyonisos]

Thanks again!

the problem is the -s switch.

Is it difficult to arrange for public/private key (any port?) authentication?
How could I do that or is there a how to?
Is it correct I would not need typing password anymore in my ssh-tunnel setups?

[Tamadite]

I will try to make a HowTo on this matter.

The point with "-s" is that there will not be need to send the password to the server but the client sends signature generated with the private-key instead.

When the signature is generated on the client you have to introduce a passphrase instead which has local signficance only, in other words the passphrase is used by the local siganture generator to be able to use the private-key therefore the passphrase has no signifcance for the server hence it is never sent out.

A way to avoid the typing of passphrase is to use pageant. See http://the.earth.li/~sgtatham/putty/...9.html#pageant for more information.