![]() Iptables is a command-line tool for configuring firewall rules, which are actually enforced by the Linux kernel. This can really slow down brute force attacks, notify you when such attacks are occurring, and give you an opportunity to take corrective action if required. fail2ban – a nifty little package that scans log files and implements rules that can do things like dynamically block an IP address for a configurable period of time if there are more than X number of failed login attempts from that address.Also, fail2ban works with iptables (I believe it also works with firewalld). These days it appears to be fashionable to firewall Linux using firewalld instead of iptables, but I’m an old dog and like iptables, so I’ll stick with that. iptables-services – this installs the systemd scripts to allow controlling iptables as a service using systemctl.This installs the following two packages: Yum - y install iptables- services fail2ban I’m going to insert all of my changes into the script just before running the yum update, so just before the following lines: Most of the work will be performed by updating my bootstrap script, with one small change to the CloudFormation template. I didn’t actually find this post until after I’d worked through the things I’m going to implement in this post, but it covered them all and a whole lot more, so you could just go there and skip this post, however, it’s pretty complex and hard to follow in some parts, and I’m going to provide a simple explanation for some simple hardening, so you might want to stick around. The absolute best post I’ve seen on the subject is 40 Linux Server Hardening Security Tips. For instance, I read a bunch of posts that say don’t run services you don’t need, but with no practical advice on how to implement that (like how to figure out what services are running on a typical Linux box, or which specific ones I might want to stop and why). ![]() Really it’s hardening 101 for any Linux host, but this kind of information is surprisingly hard to find on the Internet. Less likely than finding just one vulnerability.Ī previous draft was splitting the internal production network in two part ( or draft #2 at bottom of this article).This post is going to provide a brief description of basic Linux hardening for the Bastion Host I created using CloudFormation in my last post. ![]() With this split, an attacker would need to compromise the Squids first, then the Apaches from the Squids. Perhaps better to have this traffic split and access the Squids directly rather than via the management network? Squid logs and such would have to be transferred via the bastion machine, since this assumes that the Squids are compromised? Or to some other machine with a connection to the Squid-Apache network. Should it be? Presumably same physical network as management? The use of the second network for Squid management effectively makes this impossible because it requires that the Squids be on this internal network. If the Apaches and databases used a different network for their traffic from that used between Squids and Apaches it would be impossible for a compromised Squid to see confidential traffic exchanged between Apache and database. The Squids are the machines which are most exposed to potential attacks. We want to poll snmp for a machine called zwinger : use. We want the apaches to connect to a machine called suda : use. then add manag and prod sub domains and put the ips under. Ī local domain could be used as well to ease things a bit more. ![]() The ip for the internal production interface (10.0.x.x) of the fourth (x.x.x.4) apache (x.x.2.x) is 10.0.2.4. How many server of that kind do we already have ( n) ? To assign an ip to a server interface you just have to ask yourself: Each network is then subnetted according to servers functions : 1 for squids, 2 for apaches, 3 for database and 4 for NFS servers. Hashar's proposition is to use 10.0/16 for internal production and 172.16/16 for management purpose. In order to save some public IPs, we can switch the management and the internal production networks to use rfc 1918 ips.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |