Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I want to prevent entering suspected IPs to entire server. Certain persons shouldn't be able to access server because I don't want to compromise VPS. VPS is located in Czech Republic data center. Here's informations about IP that definitely shouldn't access server:
Code:
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '46.170.0.0 - 46.171.255.255'
% Abuse contact for '46.170.0.0 - 46.171.255.255' is 'cert.opl@orange.com'
inetnum: 46.170.0.0 - 46.171.255.255
netname: PL-TPSA-20101201
country: PL
org: ORG-PT1-RIPE
admin-c: OPHT
tech-c: OPHT
status: ALLOCATED PA
remarks: In case of abuse contact: cert.opl@orange.com
mnt-by: RIPE-NCC-HM-MNT
mnt-by: TPNET
mnt-lower: AS5617-MNT
mnt-lower: TPNET
mnt-domains: DNS
mnt-routes: AS5617-MNT
created: 2010-12-01T09:07:10Z
last-modified: 2016-09-15T16:06:24Z
source: RIPE # Filtered
organisation: ORG-PT1-RIPE
org-name: Orange Polska Spolka Akcyjna
org-type: LIR
address: Al. Jerozolimskie 160
address: 02-326
address: Warszawa
address: POLAND
phone: +48225230173
fax-no: +48225230178
admin-c: EHD2-RIPE
admin-c: KP21-RIPE
admin-c: AD13130-RIPE
abuse-c: OPHT
mnt-ref: RIPE-NCC-HM-MNT
mnt-ref: TPNET
mnt-by: RIPE-NCC-HM-MNT
mnt-by: TPNET
created: 2004-04-17T11:48:22Z
last-modified: 2017-10-30T14:50:54Z
source: RIPE # Filtered
role: OPL - Hostmaster
address: Orange Polska S.A.
address: Al. Jerozolimskie 160
address: 02-326 Warszawa
address: Poland
phone: +48 800 120810
phone: +48 801 600006
phone: +48 22 5039000
fax-no: +48 22 6225182
org: ORG-PT1-RIPE
admin-c: AD13130-RIPE
admin-c: EHD2-RIPE
tech-c: KP21-RIPE
abuse-mailbox: cert.opl@orange.com
nic-hdl: OPHT
mnt-by: TPNET
created: 2014-03-26T08:23:42Z
last-modified: 2016-10-04T12:22:55Z
source: RIPE # Filtered
% Information related to '46.170.0.0/15AS5617'
route: 46.170.0.0/15
descr: TPNET
descr: for abuse: abuse@tpnet.pl
origin: AS5617
mnt-by: AS5617-MNT
created: 2010-12-01T10:38:55Z
last-modified: 2010-12-01T10:40:56Z
source: RIPE
% This query was served by the RIPE Database Query Service version 1.90 (HEREFORD)
The ISP of IP owner doesn't support IPv6. The 81.219.4.30 traffic comes from city that is located near of city in which I reside. My reason to block IP 46.170.253.113 is because previous instance of my VPS has been compromised and certain persons shouldn't know what is exposed on 80, 443, 8080, future chat application server, staging area etc. Many people from some Poland geographic regions are very much interested in this data. They are counting on the fact that any data that may be associated with me or my network activity will fall into their hands.
I've found also below entries in /var/log/nginx/access.log:
Above IPs were connected to my server today while I had published something post on Facebook.
I really care about securing nginx, databases, future chat server, mail server and administrative services.
I have taken the following steps to secure the server:
Install fresh Debian 8 Jessie from template,
Change root password,
Change administrative user password, modify /etc/sudoers with visudo and add it do group sudo,
Secure SSH by changing port to differ than 22, disabling password authentication, change host key from rsa to ed25519 and enable only ed25519 public key authentication (key is secured by password),
Install needrestart,
Update repositories,
Upgrade Debian 8 Jessie to Debian 9 Stretch,
Configure unattended-upgrades,
Disable IPv6 support in /etc/sysctl.conf (I don't want to make gaps in the system unless I won't learn more about IPv6 protocol),
Configure iptables and fail2ban,
Secure PAM service, edit /etc/sysctl.conf,
Install clamav, chkrootkit, checksecurity, logcheck and add theirs cron jobs,
Add aide intrusion detection system to my server,
Install PostgreSQL and secure postgres user with strong password,
Install and configure mail server (postfix and dovecot) and integrate it with PostgreSQL,
Install and configure nginx, MariaDB, Redis and php-fpm stack for web development,
I rent VPS on Aruba Cloud for 1 EUR per month.
VPS parameters:
OS: Debian 9 Stretch,
Linux kernel: 4.9.0-4-amd64,
Processor: 1 Core Intel Xeon E5-2650L v4,
RAM: 1 GB,
Storage: 20 GB SSD,
Data transfer: 2 TB per month,
Powered by vmware.
My iptables rules:
Code:
# Generated by iptables-save v1.6.0 on Sun Dec 17 13:24:38 2017
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [4297:350729]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 46.170.253.113/32 -j DROP
-A INPUT -s 91.196.50.33/32 -j DROP
-A INPUT -p tcp -m tcp --dport 16960 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 110 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -j LOG
-A INPUT -j DROP
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Sun Dec 17 13:24:38 2017
# Generated by iptables-save v1.6.0 on Sun Dec 17 13:24:38 2017
*nat
:PREROUTING ACCEPT [1284:74814]
:INPUT ACCEPT [321:10920]
:OUTPUT ACCEPT [2779:192465]
:POSTROUTING ACCEPT [2779:192465]
COMMIT
# Completed on Sun Dec 17 13:24:38 2017
/etc/sysctl.conf file:
Code:
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#
#kernel.domainname = example.com
# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3
##############################################################3
# Functions previously found in netbase
#
# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1
# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
net.ipv4.tcp_syncookies=1
# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1
# Uncomment the next line to enable packet forwarding for IPv6
# Enabling this option disables Stateless Address Autoconfiguration
# based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1
# Do not forward IP packets (we are not a router)
# Note: Make sure that /etc/network/options has 'ip_forward=no'
net.ipv4.conf.all.forwarding=0
net.ipv6.conf.all.forwarding=0
# Ignore bogus ICMP errors
net.ipv4.icmp_ignore_bogus_error_responses=1
# Ignore ICMP echo broadcasts
net.ipv4.icmp_echo_ignore_broadcasts = 1
###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
net.ipv4.conf.all.accept_redirects = 1
net.ipv6.conf.all.accept_redirects = 1
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
net.ipv4.conf.all.log_martians = 1
#
# IPv6 configuration
net.ipv6.conf.all.forwarding = 0
net.ipv6.conf.all.autoconf = 1
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
# Disables the magic SysRq key
kernel.sysrq = 0
/etc/ssh/sshd_config file:
Code:
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port xxxx <- differ than 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
#RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
Banner /etc/ssh/ssh-banner
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no
UseDNS no
You say nothing about your system, so I will assume your server is running some version of Linux.
(Sorry, missed part of your message - you are running iptables so use UFW, GUFW or iptables directly as below.)
First, if you have a router between the server and the internet, block the IP in the router's firewall. Log in to the router and find the page or pages for the firewall and follow their instructions.
Second, block the IP on the server's firewall. I know of no version of linux that does not run iptables so even if it is a total pass through (all policies are ACCEPT) it is running. You can install and/or activate a front end or enter the necessary rule(s) in iptables directly. You probably have UFW installed although it may be turned off. You can use the command line to enable it and enter the rules (use the man command for instructions) or it might be easier to install gufw if it is not installed and use it. Gufw is the graphic front end for ufw.
To block it directly by using iptables, on the command line enter:
sudo iptables -I INPUT -s 46.170.0.0/15 -j DROP
sudo iptables -I FORWARD -s 46.170.0.0/15 -j DROP
Those two instructions will block any input from that range of ips. It would not hurt to block the ips in the nat table also, but should not be absolutely necessary. To do that, however, look at the man page and google iptables for general instructions. It is not difficult, but if you are going to do that sort of thing you really should learn a bit about what you are doing.
fail2ban can read logs and issue iptables rules to keep out offenders.
Its not easy, but it is worth it. And is a "hands-on" solution, meaning you will have to adjust and tune it.
Exploits change and so must fail2ban filters must change too.
Much documentation already on the interwebs...
Skype too will "validate" URLs...
Last edited by Habitual; 12-21-2017 at 09:19 AM.
Reason: s/an/and/g
Agreed, it is a 'stopgap' measure. However, a large number of attempts seem to be made by so-called script-kiddies who don''t really know what they are doing or are too lazy to follow up and make a serious attempt. Blocking a range through iptables is so easy that it is worth the effort, in my opinion. It will stop some of the attempts and the remaining ones are more likely to be something serious. For example, I got tired of crap from China so I blocked the entire country. I can do that because I have no interests in China so I lose nothing. Amazing how much that accomplished. Of course I am aware of the many limitations, but it is still worth a couple of minutes effort.
Should I use PSAD? Can you give me some helpful iptables rules to prevent targetted attacks?
My server is attack target for people from some geographic regions of Poland. After recognizing what's the IP 46.170.253.113 I figured that it comes from my school network. It should be taken into account that most attacks comes from different geographic regions of Poland, not only school region. How can I recognize other IPs? Can I use recon-ng?
Quote:
Originally Posted by agillator
To block it directly by using iptables, on the command line enter:
sudo iptables -I INPUT -s 46.170.0.0/15 -j DROP
sudo iptables -I FORWARD -s 46.170.0.0/15 -j DROP
Thanks, but computers from this IP poll still can bypass block by proxy server, VPN or Tor.
This is true. However, by using ips I know of no way to entirely block determined individuals for the reason you mention. As far as the firewall is concerned you can only identify and track the attempts as they happen and block them by similar procedures. Now if the attacks are identified by particular flags or some other sign you have a chance. Firewalls are limited in this regard. Your next step is to identify what the attacker is after and block that by some other means. If they are after particular data files, limiting permissions may help, but again will not be a full or permanent solution. You are now in the part of the 'game' that is a real cat and mouse affair. Whether you are the cat or the mouse . . . . You need to determine for yourself if it is a real attack or just a nuisance, why you are being attacked (what do you have that they want), who they are if you can, and then look for help with specialists who are versed in this sort of thing. Tools like wireshark can help. You might try googling computer security organizations and seeing if any on those lists can help you.
Should I use PSAD? Can you give me some helpful iptables rules to prevent targetted attacks?
My server is attack target for people from some geographic regions of Poland. After recognizing what's the IP 46.170.253.113 I figured that it comes from my school network. It should be taken into account that most attacks comes from different geographic regions of Poland, not only school region. How can I recognize other IPs? Can I use recon-ng?
Thanks, but computers from this IP poll still can bypass block by proxy server, VPN or Tor.
You recognize them by evaluating traffic via nginx access log files (/var/log/nginx/access.log and determine what valid traffic is supposed to be, or look like.
I have to remember to not ban willy-nilly, and I forget the (Filter Rule I use 2)
what's 'normal" traffic?
I can't advise because I don't know what "attack" means in the context you have given. and what ports and/or service are under "attack". And you haven't declared who "certain persons" are, or what is normal for a friendly session.
Is 46.170.0.0/15 (school network?) "good traffic? If true, deny all but 46.170.0.0/15
My fail2ban filter is very extensive, and it's dynamic. once I learn (for example) Internet Explorer 7,8,and 9 are obsolete,I add them to my f2b filter and they're gone.
A solution for me isn't a safety net for you.
What works for you may, in turn not work for me.
No answer or solution will work until you evaluate the logs. Make it a habit.
I spent years pouring over web server logs looking for anything "out of the ordinary".
I'm a fan of
deny all
allow safe_ips
Recently, a server on my network was hit with > 4000 requests to the webserver, in 3 seconds, from just 3 IPs
All but 5 were 200s.
Only 3 POST actions and 2 other non-200 errors. So, they knew what they wanted...I guess.
No one I asked acted like it was a big deal, and HELL YES, it's a big deal because, it's not normal.
I am powerless to stop it.
I spent years pouring over web server logs looking for anything "out of the ordinary".
I'm a fan of
deny all
allow safe_ips
It isn't good solution for me because website on nginx will be limited and propagation of the site will be difficult. I expect a lot of new users on the future site. The site should be available in Poland for a group of readers interested in its subject, although according to some, it should not exist and hence this confusion. Website don't exists and I'm currently creating it.
Quote:
Originally Posted by Habitual
Is 46.170.0.0/15 (school network?) "good traffic? If true, deny all but 46.170.0.0/15
Definitely no! 46.170.0.0/15 should be deny.
Quote:
Originally Posted by Habitual
what's 'normal" traffic?
May I'll reply what isn't normal traffic - ssh knocking, port scanning, spam, trolling, ping flood etc. I always look more closely at traffic through Tor or anonymous proxies. I want to exclude 46.170.0.0/15 because I don't want to be future website and other services accessible by all teachers in my school.
It isn't good solution for me because website on nginx will be limited and propagation of the site will be difficult. I expect a lot of new users on the future site. The site should be available in Poland for a group of readers interested in its subject, although according to some, it should not exist and hence this confusion. Website don't exists and I'm currently creating it.
Then you will have to become adept at watching logs and have definitions for "normal traffic' based on the traffic itself.
Quote:
Originally Posted by cerber
Definitely no! 46.170.0.0/15 should be deny.
Now that's a definitive answer!
I almost believed you
If it weren't for this
Quote:
Originally Posted by cerber
I want to exclude 46.170.0.0/15
Your server, your rules.
Your reasons/arguments/policies are solely yours.
Exclude or deny? You used both, and I'm hard pressed to find a use-case for that.
"I excluded that client session during this examination of the logs" is a statement I'd use.
"17.0.0.0/8 is denied" also a statement I'd use. (Don't ban 17..0.0.0/8 btw.. that all of Apple)
So, you have the two methods I suggested and one is inappropriate for this situation. (deny all... allow safe_ips is a short version of "don't install software that won't be used in the expected manner (opening your server up to yet more abuse via open ports)
Quote:
Originally Posted by cerber
May I'll reply what isn't normal traffic
That's actually a Good Posture by the way,
I definitely can tell or find out what isn't normal by asking myself this question :
What is, or could be an expected clients' browser session, and what does it look like.? Or..I may not know what's Normal either but I have a keen eye for details and Common Sense says (for example) why is that Bolivian IP/32 using 5 Useragents during his 4 minutes in the site?
Quote:
Originally Posted by cerber
ssh knocking, port scanning, spam, trolling, ping flood etc
The "etc" is your continuing vigilance to monitor the server. Those areas of concern for you are addressed one or the other, or both of the two links I offered wrt: "Sticky"
and heres yet another reference if nothing else for comparison of methods used by a lot of people. Securing Debian Manual
P.S. I used to be concerned with anon. and Tor traffic but I began to see bogeys where there weren't any, really. And it's a red herring errand from experiences.
I couldn't reliably deny tor-exit-nodes and after a year trying, I quit doing it.
Merry Christmas and have a More Secure VPS in 2018+
You are gonna be busy!
Then you will have to become adept at watching logs and have definitions for "normal traffic' based on the traffic itself.
logcheck should be fine for automating this task.
Quote:
Originally Posted by Habitual
Exclude or deny? You used both, and I'm hard pressed to find a use-case for that.
"I excluded that client session during this examination of the logs" is a statement I'd use.
"17.0.0.0/8 is denied" also a statement I'd use. (Don't ban 17..0.0.0/8 btw.. that all of Apple)
deny
Quote:
Originally Posted by Habitual
So, you have the two methods I suggested and one is inappropriate for this situation. (deny all... allow safe_ips is a short version of "don't install software that won't be used in the expected manner (opening your server up to yet more abuse via open ports)
What do you think about setup own VPN for administration tasks such as SSH, phpMyAdmin, phpPgAdmin? How can I isolate staging area that should be visible for permitted persons from production area that should be visible for everyone? Is approach deny all... allow safe_ips be good for staging area?
Quote:
Originally Posted by Habitual
P.S. I used to be concerned with anon. and Tor traffic but I began to see bogeys where there weren't any, really. And it's a red herring errand from experiences.
I couldn't reliably deny tor-exit-nodes and after a year trying, I quit doing it.
Tor exits should be more monitored and should have more restrictive rules but shouldn't be denied.
Quote:
Originally Posted by Habitual
The "etc" is your continuing vigilance to monitor the server. Those areas of concern for you are addressed one or the other, or both of the two links I offered wrt: "Sticky"
cron can automate some tasks In my opinion central logging server maybe useful too.
Quote:
Originally Posted by Habitual
and heres yet another reference if nothing else for comparison of methods used by a lot of people.
Securing Debian Manual
This is best manual about securing Linux (except from Gentoo Hardened manuals, but I'm not sure if Gentoo would be suitable for my server). Debian Wiki and Gentoo Wiki are very good written.
Quote:
Originally Posted by Habitual
Merry Christmas and have a More Secure VPS in 2018+
You are gonna be busy!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
In my opinion central logging server maybe useful too.
