Bekijk de volledige versie : dropbear -s -p 40400 WAN access problem
dyonisos
05-03-2009, 23:31
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
06-03-2009, 12:46
Does it work when you start it on the regular port (22)?
dyonisos
06-03-2009, 18:58
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
06-03-2009, 20:53
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!
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
06-03-2009, 21:33
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
06-03-2009, 21:45
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
06-03-2009, 22:13
Hi Tamadite,
Could you please provide me your iptables config and if possible the brute force prevention iptables.
Thanks dyonisos
dyonisos
06-03-2009, 22:19
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
06-03-2009, 23:06
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
06-03-2009, 23:34
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
06-03-2009, 23:42
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
06-03-2009, 23:45
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
06-03-2009, 23:58
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
07-03-2009, 09:49
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/0.60/htmldoc/Chapter9.html#pageant for more information.
Tamadite
07-03-2009, 21:10
Look at http://wl500g.info/showthread.php?t=10307&page=37 point "15. Automate SSH login"