- Details
- Category: Technology
So after doing some readings, I saw that there are several advantages to using TokuDB over InnoDB when we are dealing with huge databases. The thing here is that using that TokuDB requires jemalloc to run. Since CentOS 7 and 8 are systemd enabled using the methods advertised on most websites won't work.
I will write here what I did to enable it.
Read more: Setting Up MariaDB's TokuDB Engine on CentOS/Alma/Rocky
- Details
- Category: Technology
If you have installed FusionPBX from the installation scripts you will notice it has already some fail2ban configurations. If you are using my RPMs, it does not include any kind of this configuration as my philosophy is to specialize in the package to do one thing, not a do-it-all. Anyway, if you are only using FusionPBX with FreeSWITCH as a personal PBX those rules should be more than enough.
I recommend you do a quick reading of my previous fail2ban post where I describe the gap between Layer 7 exposures versus Layer 3 controls. You will understand my thinking.
If you are more serious about your PBX or you are running a business you will find at one point those rules are not enough. I will explain myself a little more. As a commercial service, your exposure to the world is bigger; your domain is advertised, telephones do DNS, HTTP and SIP requests to your servers and sooner than later you will start getting your first kiddy scripts targeting your servers. As you grow, you will find your customers are far from being technical; they do many dumb things (wrong password, because they changed something on the service or inside jobs from tech staff, are some examples) which leads to fail2ban rule executions.
There is nothing more harmful than a bad review from an ignorant customer. They do not know why they are being blocked. So, here is where we need to tun fail2ban and add some important information to pre-block offending IPs.
Read more: Taking the Hardening of FusionPBX / FreeSWITCH further
- Details
- Category: Technology
Don't take it wrong, Fail2ban is an excellent tool to prevent brute-force attacks. However, sometimes there are production scenarios where you need to keep your door slightly open. It is the classic dilemma security vs utilization; in pro of security, you may have a lot of countermeasures that will block many things, depending on your paranoia, you may close as much as you want to a point that you may start to have false positives; in pro of the production, you may need to keep up and running your service no matter what, you even will need to accept some brute-force attacks from "clean" IPs.
Read more: Blocking Offending Traffic to your FreeSWITCH/FusionPBX Server
- Details
- Category: Technology
IT Security is not a simple area. You need more than knowing how to configure a firewall rule. Indeed, in my opinion, you must have an in-depth knowledge of the network stack (TCP and ISO), details about the involved protocols (IP headers, HTTP headers, LDAP authentication just to mention some) and configuration details of the operative system, the involved software (knowing MariaDB options if you are doing database security) and any other theoretical concept about your environment. And this is only for the technical part.
If you want to go further, you should understand security concepts such as risk, vulnerability, exposure, control and others.
At this point, you can have a clear vision of what is best done in your strategy. With all this said, I will talk about a classic error when taking calls about implementing security controls.
Read more: Layer 3 Controls vs Layer 7 Exposures: The fail2ban Case
- Details
- Category: Technology
HTTP/2 (originally named HTTP/2.0) is a major revision of the HTTP network protocol used by the World Wide Web. It was derived from the earlier experimental SPDY protocol, originally developed by Google. HTTP/2 was developed by the Hypertext Transfer Protocol working group httpbis (where bis means "second") of the Internet Engineering Task Force. HTTP/2 is the first new version of HTTP since HTTP 1.1, which was standardized in RFC 2068 in 1997. The Working Group presented HTTP/2 to IESG for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as a Proposed Standard on February 17, 2015. The HTTP/2 specification was published as RFC 7540 in May 2015.
The standardization effort was supported by Chrome, Opera, Firefox, Internet Explorer 11, Safari, Amazon Silk, and Edge browsers. Most major browsers had added HTTP/2 support by the end of 2015.
According to W3Techs, as of November 2018, 31.8% of the top 10 million websites supported HTTP/2.
