LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Restricting external access (https://www.linuxquestions.org/questions/linux-newbie-8/restricting-external-access-4175592526/)

NotionCommotion 10-30-2016 08:12 AM

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]#


tronayne 10-30-2016 10:53 AM

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.

maples 10-30-2016 01:30 PM

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

AwesomeMachine 10-30-2016 06:12 PM

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.

BW-userx 10-31-2016 08:00 AM

Quote:

Originally Posted by AwesomeMachine (Post 5624959)
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. "

sundialsvcs 10-31-2016 06:50 PM

"The question before the house" should be:

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

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?"

Sefyir 10-31-2016 07:43 PM

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/


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