LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 10-30-2016, 08:12 AM   #1
NotionCommotion
Member
 
Registered: Aug 2012
Posts: 594

Rep: Reputation: Disabled
Restricting external access


I am getting thousands of attempted ssh break-ins. I've already set up the server to prevent ssh logons as root, but would like to do more. I also installed fail2ban.

My iptables configuration is shown below.

A couple of questions.
  1. Is it correct to have ssh go to f2b-SSH? I don't think I ever setup iptables to add it. Would installing fail2ban automatically add this rule?
  2. At the bottom, I have Chain f2b-SSH (1 references). Sometimes iptables shows more banned IPs. Why fail2ban seem to remove suspect IPs from the list of banned IPs?
  3. What changes would you recommend to iptables? The server is for development purposes only, and suppose I could restrict more access to just local access.

Thank you

Code:
[root@devserver log]# cat /var/log/secure | grep 'sshd.*Invalid'
Oct 30 03:31:57 devserver sshd[6837]: Invalid user system from 52.208.228.27
Oct 30 03:47:30 devserver sshd[7981]: Invalid user superadmin from 94.101.186.42
Oct 30 03:51:23 devserver sshd[8296]: Invalid user libsys from 182.180.86.76
Oct 30 04:02:41 devserver sshd[9176]: Invalid user cac_admin from 52.208.228.27
Oct 30 04:14:49 devserver sshd[10125]: Invalid user hscroot from 94.101.186.42
Oct 30 04:26:19 devserver sshd[10953]: Invalid user mlusr from 181.143.230.53
Oct 30 04:26:32 devserver sshd[10983]: Invalid user admin from 68.161.233.215
Oct 30 04:33:41 devserver sshd[11517]: Invalid user adfexc from 52.208.228.27
Oct 30 04:41:35 devserver sshd[12198]: Invalid user USERID from 94.101.186.42
Oct 30 04:50:44 devserver sshd[12922]: Invalid user transfer from 182.180.86.76
Oct 30 04:56:33 devserver sshd[13353]: Invalid user admin from 200.216.31.20
Oct 30 04:58:57 devserver sshd[13549]: Invalid user MGR from 181.143.230.53
Oct 30 05:00:55 devserver sshd[13756]: Invalid user MGR from 68.161.233.215
Oct 30 05:04:04 devserver sshd[14020]: Invalid user MGR from 121.136.90.221
Oct 30 05:08:30 devserver sshd[14398]: Invalid user MGR from 190.14.247.94
Oct 30 05:08:54 devserver sshd[14400]: Invalid user Administrator from 94.101.186.42
Oct 30 05:29:46 devserver sshd[16054]: Invalid user admin from 200.216.31.20
Oct 30 05:35:10 devserver sshd[16450]: Invalid user rwa from 68.161.233.215
Oct 30 05:35:45 devserver sshd[16547]: Invalid user Administrator from 94.101.186.42
Oct 30 05:37:11 devserver sshd[16640]: Invalid user test from 121.136.90.221
Oct 30 05:37:21 devserver sshd[16668]: Invalid user admin from 123.30.37.44
Oct 30 05:42:14 devserver sshd[17039]: Invalid user temp1 from 190.14.247.94
Code:
[root@devserver log]# cat /var/log/secure | grep 'sshd.*failed'
Oct 30 03:54:08 devserver sshd[8574]: reverse mapping checking getaddrinfo for static-181-143-230-53.une.net.co [181.143.230.53] failed - POSSIBLE BREAK-IN ATTEMPT!
Oct 30 04:26:19 devserver sshd[10953]: reverse mapping checking getaddrinfo for static-181-143-230-53.une.net.co [181.143.230.53] failed - POSSIBLE BREAK-IN ATTEMPT!
Oct 30 04:58:57 devserver sshd[13549]: reverse mapping checking getaddrinfo for static-181-143-230-53.une.net.co [181.143.230.53] failed - POSSIBLE BREAK-IN ATTEMPT!
Oct 30 05:08:30 devserver sshd[14398]: reverse mapping checking getaddrinfo for 1901424794.ip32.static.mediacommercecom.co [190.14.247.94] failed - POSSIBLE BREAK-IN ATTEMPT!
Oct 30 05:23:42 devserver sshd[15571]: reverse mapping checking getaddrinfo for iammichael-pc [192.168.1.10] failed - POSSIBLE BREAK-IN ATTEMPT!
Oct 30 05:42:14 devserver sshd[17039]: reverse mapping checking getaddrinfo for 1901424794.ip32.static.mediacommercecom.co [190.14.247.94] failed - POSSIBLE BREAK-IN ATTEMPT!
[root@devserver log]#
Code:
[root@devserver log]# iptables --list --line-number
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    f2b-SSH    tcp  --  anywhere             anywhere            tcp dpt:ssh
2    ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
3    ACCEPT     icmp --  anywhere             anywhere
4    ACCEPT     all  --  anywhere             anywhere
5    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
6    ACCEPT     udp  --  192.168.1.0/24       anywhere            udp dpt:bacnet state NEW
7    ACCEPT     tcp  --  192.168.1.0/24       anywhere            tcp dpt:mysql state NEW
8    ACCEPT     tcp  --  192.168.1.0/24       anywhere            tcp dpt:microsoft-ds state NEW
9    ACCEPT     tcp  --  192.168.1.0/24       anywhere            tcp dpt:netbios-ssn state NEW
10   ACCEPT     udp  --  192.168.1.0/24       anywhere            udp dpt:netbios-dgm state NEW
11   ACCEPT     udp  --  192.168.1.0/24       anywhere            udp dpt:netbios-ns state NEW
12   ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:smtp state NEW
13   ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ndmp state NEW
14   ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https state NEW
15   ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http state NEW
16   LOGGING    all  --  anywhere             anywhere
17   REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain LOGGING (1 references)
num  target     prot opt source               destination
1    LOG        all  --  anywhere             anywhere            limit: avg 10/min burst 5 LOG level debug prefix `DROP: '
2    DROP       all  --  anywhere             anywhere

Chain f2b-SSH (1 references)
num  target     prot opt source               destination
1    REJECT     all  --  221.229.172.71       anywhere            reject-with icmp-port-unreachable
2    RETURN     all  --  anywhere             anywhere
[root@devserver log]#
 
Old 10-30-2016, 10:53 AM   #2
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,538

Rep: Reputation: 1058Reputation: 1058Reputation: 1058Reputation: 1058Reputation: 1058Reputation: 1058Reputation: 1058Reputation: 1058
There is an oldie-but-goodie utility you might want to give a try.

DenyHosts (http://denyhosts.sourceforge.net).

It
Quote:
DenyHosts is a script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks).

If you've ever looked at your ssh log (/var/log/secure on Redhat, /var/log/auth.log on Mandrake, etc...) you may be alarmed to see how many hackers attempted to gain access to your server. Hopefully, none of them were successful (but then again, how would you know?). Wouldn't it be better to automatically prevent that attacker from continuing to gain entry into your system?
What it does is add the address of the attacker to /etc/hosts.deny or creates a IPTABLES entry for you (and a couple of other things). The good thing about /etc/hosts.deny is that it is the first thing "seen" by an attempted connection, part of TCP/IP which, if it exits, is the first in line and immediately denies access (and writes an entry to /etc/hosts.deny -- or IPTABLES).

I've used it for years, it works (there are thousands of entries in hosts.deny), you don't have to fiddle around with configurations and writing entries --- take a look and see what you think.

Hope this helps some.

Last edited by tronayne; 10-30-2016 at 10:58 AM.
 
Old 10-30-2016, 01:30 PM   #3
maples
Member
 
Registered: Oct 2013
Location: IN, USA
Distribution: Arch, Debian Jessie
Posts: 811

Rep: Reputation: 264Reputation: 264Reputation: 264
I'd suggest running SSH on a non-standard port. I've been doing that for years, and as far as I've been able to tell nobody has ever tried to get in.

Of course, using a non-standard port should not be your only method of securing your server: https://en.wikipedia.org/wiki/Securi...ough_obscurity
 
Old 10-30-2016, 06:12 PM   #4
AwesomeMachine
Senior Member
 
Registered: Jan 2005
Location: USA and Italy
Distribution: Debian testing/sid; OpenSuSE; Fedora
Posts: 1,982

Rep: Reputation: 296Reputation: 296Reputation: 296
If you don't need ssh, block port 22. Otherwise, you can use the iptables "recent" module.
Code:
${IPTABLES} -A INPUT -p tcp --dport 3456 -m recent --set --name portknock
${IPTABLES} -A INPUT -p tcp --syn --dport 22 -m recent --rcheck --seconds 60 --name portknock -j ACCEPT
${IPTABLES} -A INPUT -p tcp --syn --dport 22 -j DENY
This requires that ssh users access port 3456 first, and then port 22. If the IP does not knock on port 3456, then the packet drops to the third line, DENY.

It's not a great idea to reassign the ssh port to a non-privileged port (>1024), because non-privileged users can listen and capture user names/passwords. Ports 1024 and below are handled by Linux as privileged, so only root can open them. After a privileged port is opened the process drops back to user level.
 
Old 10-31-2016, 08:00 AM   #5
BW-userx
Senior Member
 
Registered: Sep 2013
Location: MID-SOUTH USA
Distribution: Void Linux / Slackware 14.2
Posts: 3,711

Rep: Reputation: 646Reputation: 646Reputation: 646Reputation: 646Reputation: 646Reputation: 646
Quote:
Originally Posted by AwesomeMachine View Post
If you don't need ssh, block port 22. Otherwise, you can use the iptables "recent" module.
Code:
${IPTABLES} -A INPUT -p tcp --dport 3456 -m recent --set --name portknock
${IPTABLES} -A INPUT -p tcp --syn --dport 22 -m recent --rcheck --seconds 60 --name portknock -j ACCEPT
${IPTABLES} -A INPUT -p tcp --syn --dport 22 -j DENY
This requires that ssh users access port 3456 first, and then port 22. If the IP does not knock on port 3456, then the packet drops to the third line, DENY.

It's not a great idea to reassign the ssh port to a non-privileged port (>1024), because non-privileged users can listen and capture user names/passwords. Ports 1024 and below are handled by Linux as privileged, so only root can open them. After a privileged port is opened the process drops back to user level.
off topic but thanks for the chuckle
" There are two kinds of people: those who put people in two groups, and everyone else. "
 
Old 10-31-2016, 06:50 PM   #6
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 7,893

Rep: Reputation: 2558Reputation: 2558Reputation: 2558Reputation: 2558Reputation: 2558Reputation: 2558Reputation: 2558Reputation: 2558Reputation: 2558Reputation: 2558Reputation: 2558
"The question before the house" should be:

"Why did you allow(?!?!) 'anyone on earth' to see a login: prompt, in the first place?"

No one should be allowed to get that far, unless they have already passed a very-considerable gantlet which has nothing to do with "a password."

As I discuss in my blog post, How To Build A 'Dwarvish Door' with OpenVPN, every one of your systems should present "a smooth, featureless(!) wall" to the outside world. To any and every "port scanner" or "script kiddie," there should be nothing(!) there except (say ...) http and https. (These being the only ports that you intend for outsiders to routinely access.)

It should not even be evident that there exists, in fact, a third alternative: OpenVPN. Thanks to the tls-auth feature, the existence of an OpenVPN server should not even be visible, unless one should possess an initial 1024-bit cryptographic key that will "cause a keyhole to appear." Having "found the keyhole," the only possible way forward should be to possess a 4096-bit one-of-a-kind cryptographic key.

Only then should you first encounter ssh, which then demands, not a password, but yet-another cryptographic key. (The visitor is never once given the opportunity to enter a "login password.")

Yep, if anyone shows up inside the courtyard, having passed through both of these safeguards, you can welcome him or her as "an old friend," because you fairly-well know already who they must be. After all, s/he must have been in possession of three one-of-a-kind, not-revoked digital credentials! Since the credentials are "one of a kind," you already know with very-great certainty exactly who this visitor is.

(And, should the visitor turn out to be an imposter, you can swiftly and decisively react by revoking this visitor's credentials. Instantly, this visitor is shut-out, while no other authorized visitor is even inconvenienced.)

"Thousands of attempts?' Uh uh. How about, "zero?"

Last edited by sundialsvcs; 10-31-2016 at 07:04 PM.
 
1 members found this post helpful.
Old 10-31-2016, 07:43 PM   #7
Sefyir
Member
 
Registered: Mar 2015
Distribution: Linux Mint
Posts: 454

Rep: Reputation: 205Reputation: 205Reputation: 205
Quote:
I don't think I ever setup iptables to add it.
When you install gui firewalls that "make firewalling easy", they tend to fill up iptables with lots of chains and rules that can be hard and confusing to work with directly.

There's two things security related to focus on.
  • Making "it" secure so thousands of attempts aren't a issue
  • Reducing the number of attempts to make it "look" more secure (I will say having a lot fewer attempts will make more malicious ones more evident)

Making ssh secure is pretty easy. Create a keypair, copy it over and enforce key-based access by changing these lines in /etc/ssh/sshd_config

Code:
$ ssh-keygen -t rsa -b 4096 
$ ssh-copy-id your_embedded_device
$ ssh your_embedded_device
Code:
/etc/ssh/sshd_config
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
...
RSAAuthentication yes
PubkeyAuthentication yes
After restarting the ssh service
  • Maintain your existing connection. Do not close it!
  • With a new terminal, connect to the server. If you cannot, revert the changes and restart and make sure you can connect. Don't lock yourself out!

As for reducing the number of attempts, there are a lot of ways to do that (eg fail2ban or other answers here). Personally, I just limit attempts allowed via iptables.
I go over that more here on this thread:

Quote:
... Basically, if you make 15 attempts (or more) within 10 a second period, drop the request. Otherwise accept....
https://www.linuxquestions.org/quest...in-4175588810/
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
restricting access to apps sulekha Ubuntu 3 02-04-2011 08:48 AM
Restricting access using Squid3 Dnyanraj Linux - Server 1 12-13-2008 08:39 AM
Restricting local users from sending external mail (except for one domain) iolames Linux - Newbie 1 03-15-2006 09:57 AM
Restricting access Menestrel Linux - Newbie 1 06-07-2005 08:17 AM
Restricting Developer Access DropHit Linux - General 1 11-12-2003 09:49 PM


All times are GMT -5. The time now is 03:05 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration