This course has been updated! We now recommend you take the Full Stack for Front-End Engineers, v3 course.
Transcript from the "Fail2ban: Exercise" Lesson
[00:00:00]
>> Jem Young: Let's install Fail2Ban, I mentioned that at the end of class last time. Fail2Ban, what it does is it scans your offlog files, so everybody try to login. It scans those with rules and says, if you match this rule, as in you failed to login within x number of times in x seconds or minutes or something like that, we're just gonna ban you.
[00:00:21] We're not gonna fail you, we're not gonna let you log in. We're not even gonna read anything, we're just gonna ban you, like ban your IP. Fail2ban is very useful software, but it's very tricky, as you see with this warning right here. [LAUGH] Big warning. I have almost locked myself out of the server before.
[00:00:37] So, let's install Fail2ban. apt install Fail2ban, the two, the number two. So, sudo apt install. Fail2ban. Yes?
>> Speaker 2: Question in chat was why commenting the first line?
>> Jem Young: Great question. We're commenting out the first line because we don't necessarily want all the updates that they're gonna push with unattended upgrades.
[00:01:07] We only want security patches. So let's say nginx makes a change, and let's say it even runs a little bit faster. We don't necessarily want that because it could break our existing integration. That's unlikely, but it could happen. We only want security patches, so if there is a vulnerability that exists within, say, your SH protocol, or something like that, we want those patches, but not necessarily all of the latest and greatest versions.
[00:01:31] Great question, though. All right, Fail2ban. So now we're going to copy with the cp command, copy. We're going to copy the jail comp file. Jail is just all of the offenders. It's all the people that tried to log in when they shouldn't have. We're going to make a copy of that file through our jailed.local because we don't want to change jail.conf, if it has good defaults in it.
[00:01:59] But if we wanna change something, we do it in our local file, and those will override our defaults.
>> Jem Young: So I will go ahead and do that too.
>> Jem Young: sudo cp/etc/fail2ban/jail.conf. And we're gonna say, copy it to, etc, fail2ban, we'll call it jail.local.
>> Jem Young: Excellent. And now, let's just VI that file, take a look at it.
[00:02:55]
>> Jem Young: Right, everybody with me so far? We're in our jail.local file for Fail2Ban. Excellent. And again, heavily commented, as a lot of these files are, it's very useful. Things we're gonna care about in here. We're gonna care about ban time. So 600 seconds is ten minutes. Yes. So we're saying, if someone is banned, they are banned for ten minutes, where I've gotten myself into trouble before is I've set the ban time too long, so some people started to say, a year.
[00:03:30] Like you're just permanently banned, essentially. Yes, some people just permanently ban people. That's dangerous, because let's say you're trying to log in with your ssh key, but it turns out you change that at some point, and you just totally forgot. If you set, say your max retry to one, so, you only have one chance to login correctly and you set your ban time to a year.
[00:03:48] Well, you just locked yourself out of your server for a year. You'd have to use a VPN or switch your IP, somehow and try to login again. But, if you have the same problem, you're just going to keep banning, banning, you're going to run out of IPs. So.
[00:03:59] That's the reason for the big giant warning here. If you try to go overboard, you try to be overzealous with your security, you can lock yourself out. Remember, people make mistakes. You'll make mistakes. Try to account for that. So ban time 10 minutes is pretty fine, is fine.
[00:04:17] Max retry is the same. If you retry within this amount of time, so, ten minutes, again. You're going to be banned, it counts towards your max retries. And five is fine. A lot of people said that three, three is usually pretty good, but we can leave this alone for now.
[00:04:31] If you want to play with it in the future, feel free, but again don't be overzealous with your security, you're gonna have a bad time. And we're good. And if we want, for fun, let's go ahead and tail that Fail2Ban log and see what's happening. See if anybody is trying to get in.
[00:04:47] Yes. So tail, Fail2Ban. Oops. I forgot.
>> Jem Young: And there's nothing really happening. So later, for fun, if you wanna check your Fail2Ban, you'll see how many people got banned, cuz there's bots just running through, trying to log into your server. Now we just ban them.
>> Speaker 3: What was that command again?
[00:05:13]
>> Jem Young: That was tail.
>> Speaker 3: There it is.
>> Jem Young: dash f. And fail2ban.log. Let me [INAUDIBLE].
>> Jem Young: As we learned in the last course, tailing your logs is one of the more useful commands you'll ever know, because it's a realtime stream of what's happening.
>> Jem Young: Yes, heed my warnings, they're there because I've made the mistake before.
[00:05:45]
>> Speaker 2: We did have a question in chat about why we need to copy a specific sudo.
>> Jem Young: Yeah. Great question, let me jump back a few slides. So the question is, why do we have to copy, back on fail2ban, why do we have to copy our jail.conf to our jail.local.
[00:06:02] Jail.conf is the default, they're kinda the default set Fail2ban is gonna use, we copy them to a local file so we can modify them. So, if you start messing with defaults, things might break. So, the best bet is always to make a local copy of the file and then change just the things we want.
[00:06:20] And that keeps everything else the same. That way, we don't override any useful settings that we don't necessarily know about.