I am constantly getting SSH login attempts that are based on a dictionary attack. My log shows stuff like:
2013-04-28T05:22:26.711755-05:00 xxxxxxxxx sshd[23428]: Invalid user ryley from 78.31.75.140
2013-04-28T05:47:58.312178-05:00 xxxxxxxxx sshd[23992]: Invalid user sabrina from 78.31.75.140
2013-04-28T06:13:40.433017-05:00 xxxxxxxxx sshd[24523]: Invalid user sal from 78.31.75.140
2013-04-28T06:39:06.286358-05:00 xxxxxxxxx sshd[25078]: Invalid user sally from 78.31.75.140
2013-04-28T07:04:35.286350-05:00 xxxxxxxxx sshd[25639]: Invalid user sales from 78.31.75.140
2013-04-28T07:30:01.827528-05:00 xxxxxxxxx sshd[26177]: Invalid user sam from 78.31.75.140
2013-04-28T07:55:40.004215-05:00 xxxxxxxxx sshd[26729]: Invalid user samantha from 78.31.75.140
2013-04-28T08:21:15.498609-05:00 xxxxxxxxx sshd[27320]: Invalid user sammy from 78.31.75.140
I am currently blocking the offending ip address by issuing the command:
iptables -I INPUT 1 -s 78.31.75.140 -j DROP
This is very effective until I reboot the computer. The rule is lost after I reboot the computer. I want to learn how to configure SuSEfirewall2 to block the request for two reasons. 1. if I configure the firewall the rule will stick through a reboot and 2. it is the correct way to do the block.
I have been searching for a way to do this but have been unable to find a way to do it in the SUSE fireewall configuration. I see the /etc/sysconfig/scripts/SuSEfirewall2-custom file but I do not know what section I should put my rules in.
> This is very effective until I reboot the computer. The rule is lost
> after I reboot the computer. I want to learn how to configure
> SuSEfirewall2 to block the request for two reasons. 1. if I configure
> the firewall the rule will stick through a reboot and 2. it is the
> correct way to do the block.
>
> ## Type: string
> ## Default:
> #
> # Services to allow. This is a more generic form of FW_SERVICES_XXX_{IP,UDP,TCP}
> # and more specific than FW_TRUSTED_NETS
> #
> # Format: space separated list of net,protocol,dport,sport,flags]]]
> # Example: "0/0,tcp,22"
> #
> # Supported flags are
> # hitcount=NUMBER : ipt_recent --hitcount parameter
> # blockseconds=NUMBER : ipt_recent --seconds parameter
> # recentname=NAME : ipt_recent --name parameter
> # Example:
> # Allow max three ssh connects per minute from the same IP address:
> # "0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
> #
> # The special value _rpc_ is recognized as protocol and means that dport is
> # interpreted as rpc service name. See FW_SERVICES_EXT_RPC for
> # details.
> #
> # Note1: keep in mind that FW_SERVICES_EXT_TCP, FW_SERVICES_EXT_UDP
> # take precedence over FW_SERVICES_ACCEPT_EXT so don't open the same
> # port with both options.
> #
> # Note2: the iptables recent module may not be available for ipv6. To
> # avoid an error message use 0.0.0.0/0 instead of 0/0. This will
> # install the rule for ipv4 only.
> #
> #FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"
Another way is using “/etc/hosts.deny”.
Then there are scripts that scan the log and automatically add rules.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
Everything I have read says that hosts.allow and hosts.deny are deprecated. They are used by TCP Wrappers, host-based access control which means only services that have been compiled with TCP Wrappers will adhere to the rules in those files. I could very well be wrong but I think the correct way is to create a rule in the SuSEfirewall2. Any idea on how to do that?
I am not sure what exactly you are trying to achieve.
If you do not want ssh connections to your machine, just disable sshd, and close port 22 (ssh) in your firewall using YaST.
If you want to enable ssh connections, but avoid those attacks in general, you can use fail2ban (from the standard repositories) and/or change the sshd port from 22 to a higher value (e.g. 60022) in/etc/ssh/sshd_config.
On 2013-04-28 18:36, JimOpensuse wrote:
>
> Hi thanks for your response.
>
> Everything I have read says that hosts.allow and hosts.deny are
> deprecated. They are used by TCP Wrappers, host-based access control
> which means only services that have been compiled with TCP Wrappers will
> adhere to the rules in those files.
Just try it and find out
> I could very well be wrong but I
> think the correct way is to create a rule in the SuSEfirewall2. Any
> idea on how to do that?
I told you already the correct rule in SuSEfirewall2
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
On Sun, 28 Apr 2013 15:06:03 +0000, JimOpensuse wrote:
> I have been searching for a way to do this but have been unable to find
> a way to do it in the SUSE fireewall configuration.
Rather than look for a solution with a particular tool, I’d look for a
solution that accomplishes the goal.
I had a similar issue, and I use blockhosts - fail2ban also would work
for this.
I don’t know what you’ve read that says that using hosts.allow/hosts.deny
is deprecated, been using it here for a while and it works fine. Got a
citation?
SSH uses tcp wrappers, so it’ll work just fine for your purposes. If it
were apache that was under attack, then that wouldn’t work (since Apache
doesn’t use tcp wrappers). But for services that do, it’s a very good
solution.
If you want a more flexible scheme than hosts.deny, you could also do the following (I found this on the 'Net myself, but since I don’t know where, I unfortunately cannot properly give credit for it - although I wish I could):
Just open (as root) the file /etc/sysconfig/scripts/SuSEfirewall2-custom and insert the following lines into the function fw_custom_after_chain_creation():
iptables -N SSH
iptables -N SSH_ABL
iptables -A SSH -m recent --name SSH_ABL --update --seconds 7200 -j DROP
iptables -A SSH -m recent --name SSH --rcheck --seconds 600 --hitcount 3 -j SSH_ABL
iptables -A SSH_ABL -m recent --name SSH_ABL --set -j LOG --log-level warn --log-prefix "ABL: +SSH: "
iptables -A SSH_ABL -j DROP
iptables -A SSH -m recent --name SSH --rcheck --seconds 10 -j LOG --log-level warn --log-prefix "RATE: "
iptables -A SSH -m recent --name SSH --update --seconds 10 -j REJECT
iptables -A SSH -m recent --name SSH_ABL --remove -j LOG --log-level warn --log-prefix "ABL: -SSH: "
iptables -A SSH -m recent --name SSH --set -j ACCEPT
iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j SSH
(credit to an unknown user who invented this method)
This sets up a scheme that checks for the number of connections within a certain period of time.
First of all, two additional chains are established (one for the checks on the SSH port, one for the actual blacklisting) and several rules added that handle the timing, blocking and unblocking of incoming connections.
Incoming requests are first redirected to the SSH chain. There is a timing window of ten minutes in which a maximum of three connections can come in, with an additional rule that rejects further connections that are attempted within ten seconds from the previous one, thereby updating the timeout counter (i. e. the next request would have to wait for another ten seconds before the firewall lets it pass). Furthermore, if more than three connection attempts are made before the ten-minute timeout expires, the SSH_ABL chain comes into effect, adding the IP address in question to the actual blacklist.
Any IP address redirected to the SSH_ABL chain gets blacklisted for two hours, thereby causing the firewall to drop any further connection attempts from that particular address. Also, any connection attempt within this two-hour period is going to reset the timeout for that particular IP address, and anyone attempting a connection would have to wait for the entire two-hour period before he can successfully establish a connection again.
If necessary, you can alter the timings set herein to suit your needs.
Also, I’m currently working on an active blacklister that adds IP-specific rules to two other chains (which I haven’t mentioned herein) or removes them from these to allow for even longer timeouts (blocked IP addresses will be saved upon machine shutdown and reestablished upon restart), however, that’s still WIP…
Last but not least you should consider switching SSH to RSA keys for authentication (in case yoh haven’t already done so) and disable password authentication…
On 2013-04-28 22:36, Robidu wrote:
> (credit to an unknown user who invented this method)
>
> This sets up a scheme that checks for the number of connections within
> a certain period of time.
This, or something similar, is already implemented in SuSEfirewall2, you
just have to adjust the variable “FW_SERVICES_ACCEPT_EXT” as posted before.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
Well, then, feel free to set these timings to your liking - and maybe adjust the number of allowed attempts per time frame as well.
Besides, the way this mechanism is constructed, only SSH is affected and so leaves rsync completely unharmed.
I know. I used that one before, but this variant is a lot stricter since it tends to lock out potential attackers for an extended period of time, but at the same time allowing for some margin of error.
the simple thing that can be done in order to avoid these ssh scans is to allocate a non standard port number for example from private range 49152–65535. In my case it solved the problem completely.
