Securing Linux - CentOS7
-
What @scottalanmiller said as a minimum. I like to have fail2ban running everywhere on every service that has it's own login information. I also want chrootkit running via cron anywhere I can.
-
@hobbit666 said:
So keeping the FirewallD service is good enough and just open the ports I need.
But KILL SELINUX!no, I just said that there is no circumstance where you ever remote the firewall.
-
@travisdh1 said:
What @scottalanmiller said as a minimum. I like to have fail2ban running everywhere on every service that has it's own login information. I also want chrootkit running via cron anywhere I can.
What added benefits does fail2ban & chrootkit have?
-
Fail2Ban stops brute force attacks by locking out aggressive IP addresses that make many attempts to log into your system. Without it, an aggressive IP could attack you with one bad password after another, as fast as it could, until it found one that worked (like happened to Alibabab today.) Fail2ban makes brute forces nearly impossible because it would make millions of attempts take a lifetime, rather than a day.
-
@hobbit666 said:
@travisdh1 said:
What @scottalanmiller said as a minimum. I like to have fail2ban running everywhere on every service that has it's own login information. I also want chrootkit running via cron anywhere I can.
What added benefits does fail2ban & chrootkit have?
I left the k out of chkrootkit, doh!
fail2ban - Watches for failed login attempts, if the same account tries to login to many times the account gets locked out of the system for a set period of time. On CentOS 6 the default is 5 failed attempts over 5 minutes gets locked out for 30 minutes. Makes brute forcing any decent password even harder. Once fail2ban is installed and configured for each service to monitor it's good to go.
chkrootkit - Indexes the root file system and latter on checks to see if any files have been changed. So if some hacker got into your web server and replaced the ls command with their own version that does things other than list files in a directory, chrootkit will tell you that ls has changed. After installing you need to manually run it whenever you want to run this check.
-
@scottalanmiller said:
Fail2Ban stops brute force attacks by locking out aggressive IP addresses that make many attempts to log into your system. Without it, an aggressive IP could attack you with one bad password after another, as fast as it could, until it found one that worked (like happened to Alibabab today.) Fail2ban makes brute forces nearly impossible because it would make millions of attempts take a lifetime, rather than a day.
Sounds like it would also mitigate denial of service attacks as well or just logins?
-
@wirestyle22 said:
@scottalanmiller said:
Fail2Ban stops brute force attacks by locking out aggressive IP addresses that make many attempts to log into your system. Without it, an aggressive IP could attack you with one bad password after another, as fast as it could, until it found one that worked (like happened to Alibabab today.) Fail2ban makes brute forces nearly impossible because it would make millions of attempts take a lifetime, rather than a day.
Sounds like it would also mitigate denial of service attacks as well or just logins?
It actually enables DoS attacks, to some degree.
-
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
Fail2Ban stops brute force attacks by locking out aggressive IP addresses that make many attempts to log into your system. Without it, an aggressive IP could attack you with one bad password after another, as fast as it could, until it found one that worked (like happened to Alibabab today.) Fail2ban makes brute forces nearly impossible because it would make millions of attempts take a lifetime, rather than a day.
Sounds like it would also mitigate denial of service attacks as well or just logins?
It actually enables DoS attacks, to some degree.
Can you explain in more detail? Is this because it creates overhead?
-
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
Fail2Ban stops brute force attacks by locking out aggressive IP addresses that make many attempts to log into your system. Without it, an aggressive IP could attack you with one bad password after another, as fast as it could, until it found one that worked (like happened to Alibabab today.) Fail2ban makes brute forces nearly impossible because it would make millions of attempts take a lifetime, rather than a day.
Sounds like it would also mitigate denial of service attacks as well or just logins?
It actually enables DoS attacks, to some degree.
Can you explain in more detail? Is this because it creates overhead?
Creates overhead and causes a system to deny access from an IP address. What to block a system from being able to server requests... just hit it from lots of IP addresses and get it to start blocking them. Instant denial of service.
-
@wirestyle22 said:
@scottalanmiller said:
Fail2Ban stops brute force attacks by locking out aggressive IP addresses that make many attempts to log into your system. Without it, an aggressive IP could attack you with one bad password after another, as fast as it could, until it found one that worked (like happened to Alibabab today.) Fail2ban makes brute forces nearly impossible because it would make millions of attempts take a lifetime, rather than a day.
Sounds like it would also mitigate denial of service attacks as well or just logins?
For DoS attacks it can help, but for most of those it's only going to be a speed bump before figuring out another way to bombard you with traffic.
-
@travisdh1 said:
fail2ban - Watches for failed login attempts, if the same account tries to login to many times the account gets locked out of the system for a set period of time. On CentOS 6 the default is 5 failed attempts over 5 minutes gets locked out for 30 minutes. Makes brute forcing any decent password even harder. Once fail2ban is installed and configured for each service to monitor it's good to go.
This is not correct.
fail2bandoes not lock out anything. By using the term lock out, you are implying it has some access to user account information, which it does not.What it does is add rules to the firewall to cause connections from the source IP to be dropped.
-
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
@wirestyle22 said:
@scottalanmiller said:
Fail2Ban stops brute force attacks by locking out aggressive IP addresses that make many attempts to log into your system. Without it, an aggressive IP could attack you with one bad password after another, as fast as it could, until it found one that worked (like happened to Alibabab today.) Fail2ban makes brute forces nearly impossible because it would make millions of attempts take a lifetime, rather than a day.
Sounds like it would also mitigate denial of service attacks as well or just logins?
It actually enables DoS attacks, to some degree.
Can you explain in more detail? Is this because it creates overhead?
Creates overhead and causes a system to deny access from an IP address. What to block a system from being able to server requests... just hit it from lots of IP addresses and get it to start blocking them. Instant denial of service.
Ah, that makes sense. Thanks.
-
@JaredBusch said:
@travisdh1 said:
fail2ban - Watches for failed login attempts, if the same account tries to login to many times the account gets locked out of the system for a set period of time. On CentOS 6 the default is 5 failed attempts over 5 minutes gets locked out for 30 minutes. Makes brute forcing any decent password even harder. Once fail2ban is installed and configured for each service to monitor it's good to go.
This is not correct.
fail2bandoes not lock out anything. By using the term lock out, you are implying it has some access to user account information, which it does not.What it does is add rules to the firewall to cause connections form the source IP to be dropped.
Ah yes, quite right.
-
When you can, within reason, you want to have SELinux or AppArmor turned on. They are there for a reason, they provide rather a significant amount of additional protection.
-
SELinux writes logs to the /var/log/audit/audit.log file, if auditd isn't running then its the /var/log/messages. If you check the logs, it pretty much tells you what you need to do to allow your service.
-
Do you guys have any great resources for CentOS? If not, do you have any book recommendations? I need a lot of reading material.
-
@wirestyle22 said:
Do you guys have any great resources for CentOS? If not, do you have any book recommendations? I need a lot of reading material.
Have you been following SAM's new Linux guide? That's CentOS.
http://mangolassi.it/topic/7825/sam-learning-linux-system-administration
-
@Reid-Cooper said:
@wirestyle22 said:
Do you guys have any great resources for CentOS? If not, do you have any book recommendations? I need a lot of reading material.
Have you been following SAM's new Linux guide? That's CentOS.
http://mangolassi.it/topic/7825/sam-learning-linux-system-administration
I hear that it comes highly recommended.
-
@scottalanmiller said:
@Reid-Cooper said:
@wirestyle22 said:
Do you guys have any great resources for CentOS? If not, do you have any book recommendations? I need a lot of reading material.
Have you been following SAM's new Linux guide? That's CentOS.
http://mangolassi.it/topic/7825/sam-learning-linux-system-administration
I hear that it comes highly recommended.
There may be a bit of bias there.
-
@scottalanmiller said:
@Reid-Cooper said:
@wirestyle22 said:
Do you guys have any great resources for CentOS? If not, do you have any book recommendations? I need a lot of reading material.
Have you been following SAM's new Linux guide? That's CentOS.
http://mangolassi.it/topic/7825/sam-learning-linux-system-administration
I hear that it comes highly recommended.
I will certainly check it out. I'm building my Linux Test Environment Server. I'm going to use it for a myriad of things.
