Securing PostgreSQL
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 37 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/49107 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
PGCon 201827 / 37
1
4
5
7
10
11
12
14
15
16
18
22
23
24
27
30
33
34
36
00:00
Computeranimation
00:46
Computeranimation
02:28
Computeranimation
04:58
Computeranimation
08:53
Computeranimation
09:50
Computeranimation
10:26
Computeranimation
11:21
Computeranimation
12:40
Computeranimation
16:32
Computeranimation
20:16
Computeranimation
24:27
Computeranimation
26:01
Computeranimation
33:20
Computeranimation
33:56
Computeranimation
35:14
Computeranimation
37:45
Computeranimation
40:15
Computeranimation
41:50
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:15
All right, I'm going to get started, it's one o'clock now. I've got 48 slides to go through in 45 minutes.
00:23
So, I'm Joe Conway, I've been with the Postgres community for a lot of years, probably going on 20 years using Postgres and 18 years active member of the community, I'm a committer and a major contributor, I'm also the VP of engineering at CrunchyData, you've seen some other folks from Crunchy, as other people have mentioned,
00:43
we are hiring, so if you're interested, come talk to us. So, this talk is kind of like a high level overview of the security landscape, as well as a little bit of a dive into some frameworks that you can use, make use of to improve your security in general.
01:02
So, specifically, I'm going to go through the, when I say Postgres and ecosystem, I mean, basically, Postgres itself has features that are related to security, but there's also extensions that you can make use of that enhance security in Postgres. I'm going to at least mention and touch on a few of those.
01:20
I'm also going to talk a little bit about something called the CIS Benchmark and the STIG, the Security Technical Implementation Guide. How many people are familiar with either of those things? So, about maybe not quite a third or a quarter. So, I'll give you a little bit more information
01:41
on what those things are and how you might use them. Have a seat, Grant. Yeah. And then, assuming I have enough time, I'll go very quickly through some of the postgresql.conf and pghba.conf settings
02:02
that are specific to the STIG, actually, but they're generally good guidance in terms of security practice. So, I'll kind of rifle through those. Like I said, I don't have a lot of time to go into anything in great depth. There is an appendix that covers, in a little bit more depth, the lightning talk that I gave yesterday, the RLS time travel is in there,
02:22
as well as some more information on two extensions called set user and pg audit. So, just starting with, in terms of security, Postgres actually does have international recognition in terms of its ability to provide security for you.
02:40
And specifically, Crunchy took Postgres, open source Postgres, through something called common criteria certification. So, if you've ever heard people talk about common criteria or EAL level two plus or some words to that effect, Postgres, the open source version of Postgres has gone through that process and been deemed secure,
03:02
at least from that standpoint. So, that's basic functionality enhanced by some of these extensions that I was talking about. We also have a published STIG, again, for open source Postgres. Postgres, STIG, which Crunchy helped get published through a government agency in the US called DISA.
03:23
DISA is responsible for security in the Department of Defense. And so, obviously, they care a great deal about those things. We work with them to publish the STIG, but the STIG is something that you can download and use yourself, and it's the first open source database to have a published STIG.
03:42
Similarly, we're working currently with Center for Internet Security, which is a nonprofit that is more commercially oriented to provide what's called a Postgres CIS benchmark. So, it's roughly equivalent to what the government does with the STIG, it's a series of rules.
04:00
And again, I'll go into more detail about what this means later on. But it's something that you, your enterprise, can use to provide at least one method to lock down your environment for your database and prove to the security auditors that you're compliant with something that is out there
04:20
and not just something that you made up yourself. That's currently in draft form. I was hoping it would be published by now, actually. It's kind of dragged on a bit longer than I was thinking that it would in order to get it. But I'm hoping, again, I've been saying this now for several months, but I'm hoping it will be very soon published, at least in a draft form for comment.
04:42
So, if you do wanna take a look at that when it does get published, you could make comments and actually help improve it. In terms of the security features of Postgres, I kind of lumped them into three categories, perimeter security, internal security, and chronological security. So, in terms of the perimeter security,
05:01
the very first thing you gotta do, if you wanna lock down your database system, is you should care about your operating system that the database is running on. Now, this talk, granted, is kind of oriented around Linux, and specifically, the STIG itself and the CIS benchmark are both written assuming RHEL.
05:21
But most of what I'll talk about is applicable to other Linuxes and other systems in general. In terms of the OS configuration, first thing you should do is perhaps, if you're required to, make sure that the OS is configured for FIPS compliance. Again, this is kind of a US-centric thing,
05:41
but FIPS compliance ensures that you only use certain types of ciphers that are deemed to be safe to use. And then your OS also can be locked down with either a STIG or a CIS benchmark that is applicable to the OS. So you wanna start at the base.
06:00
If your OS is not secure, then your database can hardly be secure. In terms of discretionary access control, actually, Postgres itself does provide at the OS level a certain amount of control using discretionary access control in that it will not run as the root user.
06:21
It won't run as a privileged account, and it does runtime permissions checks already for you on the data directory. So if you try and run with the data directory with incorrect permissions, Postgres will actually not start up. And I think we've done some recent modifications to kind of open that up slightly
06:41
to improve things for things, programs that do backups. I see David shaking his head. I know he's working on that patch. It got committed. So in N11, we will allow group permissions instead of just practicing the Postgres group. So that's actually a good thing.
07:01
So that way, you don't have to do your backups as a more privileged user. Now, the other item here that's not often talked about, but mandatory access control, which is what SELinux, how many people here have heard of SELinux? Probably everyone? Okay, how many people here like and use SELinux?
07:22
All right. All right. Yeah, okay. So one thing to understand here, and I'm gonna digress into this just for a minute because I think it's an important point. If you use RHEL7, you likely are using SELinux already
07:41
because it installs it and enables it by default. However, it enables it in something that's called the targeted policy. The reason that policy is called targeted is because only certain services are targeted to be controlled by SELinux. And if you boil all this, all it down,
08:02
what it really means is that in targeted policy mode, you're not protecting the service from the rest of the system. You're protecting the rest of the system from the service. So in terms of trying to protect your database, actually, targeted SELinux doesn't do that much for you.
08:23
It's really trying to protect someone who manages to break out of the Postgres process from accessing other resources on the system. So there are other policies that ship with RHEL. There are other policies that are available. Debian now has pretty good SELinux support. But what you wanna really use
08:41
is one of the policies that's called fully confined. And in RHEL, the next one up is called the MCS policy, multi-category security. But I also wanna show you just real quick some of the things you can do with SELinux. So for instance, right here, I'm logged in.
09:00
You can see I'm logged into this system. Now, this is actually an MLS policy, which is even one bar above that. But I'm logged in as root, and I'm also sysatomr, which is basically as high as you can get on this system that you're controlling. And when I try and look at the Postgres directory, I can't do it. It's possible to set up SELinux
09:21
so that there's a separate security admin from the sysadmin, and therefore have two-person control over things like accessing directories that root doesn't need to have. The other thing you can do, now here you can see I'm logged in as the Postgres user,
09:41
and dbatomr, which is a role that we defined on this system. So it takes some SELinux knowledge to set up a system like this. But when I look at that directory, you can notice I can see the files. I have to be able to read them as the Postgres user, but I don't get all privileges on all of these files. And if I try and do something like
10:03
modify pghba.conf as the OS user Postgres, I can't do it right now. But I can set things up with a system boolean so that my security user could actually flip this boolean like that, and then suddenly I'm allowed to edit that file.
10:23
And then I could flip it back off, and now I'm not allowed to edit that file. So this allows you to provide two-person control, which one of the things that we're seeing, especially at Crunchy, we deal with a lot, we deal with government agencies, we deal with a lot of very large companies in regulated industries, and this is becoming more and more important to them
10:43
that you be able to provide kind of this level of control over how Postgres is configured and used. Okay, so enough of that. Postgres, you could also provide at the OS level encryption at rest by encrypting the file system. There's a number of options for how you do that.
11:02
There's really no kind of built-in method for encryption at rest other than pgcrypto, and that's kind of completely manual and up to you how you use it. Typically, if you're gonna do something like try and comply with PCI or HIPAA, that's probably the solution that you're gonna go for.
11:22
Oops, sorry. So the next thing on perimeter security is client-server security. There was a whole talk on authentication yesterday. Hopefully, if you're in here and you're interested in security, you saw that. Postgres does host-based authentication. There's kind of internal methods, MD5,
11:42
which these days you probably don't wanna use. It's actually not as terribly insecure as some people wanna make it out to be, but most of these security frameworks will not allow you to use MD5 anymore. So on Postgres 10, you can start using Scram instead.
12:03
Much more secure protocol, up-to-date. The other way you can do it is also with SSL certs, and at the end of the talk, I'll show you a line for how you can do authentication of the client and the server with SSL certs. You can also use external methods, basically the OS, PAM, PIR, and IDENT,
12:22
or things like Kerberos, Active Directory, LDAP. All of those methods are supported. And then, of course, the last aspect of this client-server security is encryption in transit, which is achieved through SSL on your connection.
12:41
Any questions on all that before I move on? So the next area is internal security. DAC stands for Discretionary Access Control. I think I used the term a little bit earlier without explaining it, DAC and MAC. DAC means Discretionary Access Control.
13:01
It means the person that owns the object can basically determine who has access to the object, whereas MAC is Mandatory Access Control, which is where the system has policies that determine who can have access to something. So even though you're the owner of an object, you can't necessarily give access to that.
13:21
In terms of the DAC built into Postgres, it's pretty standard. We have roles, users and groups, which are really both variations and roles. A group in Postgres is really just a role that has no login privilege, and it can be used to kind of accumulate these DAC permissions. They're hierarchical, so you can nest them
13:41
kind of arbitrarily deep. If you do that, you have to be very careful on things like inherited permissions, and you can sometimes get surprised by who can have access to what if you're not careful. Those permissions are all handled through grant and revoke, which I assume everyone at this conference is probably pretty familiar with.
14:01
And again, in terms of Discretionary Access Encryption, you can achieve that through PG Crypto, or actually a good way to do encryption is generally to let your application do it, because then you're not trying to manage the keys on the same machine that has the access to the data.
14:23
Again, this kind of depends on your threat scenario. When you do things like people talk about transparent data encryption, well, if you're doing transparent encryption, that's great if someone walks out of the room with your hard disks, but it doesn't help at all
14:40
if someone manages to hack onto your server or get some kind of a SQL injection and they're able to pull data out because things are being transparently decrypted. In terms of Mac security for internal purposes, there is an extension that comes with Postgres called scpgSQL, it actually provides bindings to SELinux
15:03
to provide access decisions from SELinux. Use of that also requires some SELinux knowledge and probably some custom policy on the system you're using. But you can actually do very robust RBAC-type enforcement on pretty much all the objects in the database,
15:20
including things like locking down the super user in a way that's not otherwise possible. Row-level security, so we talked a little bit about row-level security in the lightning talk yesterday. Do most people here see that? Row-level security is basically the idea
15:40
that you can apply a policy to a table that says for every row in the table, who can see the row, which is kind of transparently done, it's filtered out, they don't even know it exists if they can't see it, or who can modify a row, which in which case is not quite as transparent. If you try and modify something you're not allowed to modify, you'll get an error.
16:03
Now I gotta digress again for a few minutes here to talk about the set user extension. Again, this goes toward the need to provide enhanced level of control, particularly over the super user that we've gotten a lot of demand for. We've created this set user extension, which basically allows you to have finer control
16:23
over escalation to super user and kind of enforced audit logging. There's more detail on this in the appendix, but these are some of the reasons why people want this. If you look at this list of super user capabilities, the super user bypasses discretionary access control,
16:43
bypasses RLS, can load any library they want, which basically means they can do anything they want on the system that Postgres has installed to the extent that the OS user that Postgres is running on can do it. So that goes back to what I was talking about earlier
17:01
about locking down the OS user with SELinux and things like that. Copy program executes an arbitrary shell command. Alter system lets you change settings in your configuration settings. You can create, execute any function, which I'm gonna show you in a minute
17:21
can actually be kind of amusing. Yeah, and pretty much any language, and some things that you might even be surprised by. Set user also lets you multiplex unprivileged users, which is useful if you've got kind of a pool connection and you wanna have the pool connection connected as say some kind of a application client,
17:40
but you'd actually like to be able to multiplex between real database users and use the database permissions to help provide control. So here's an example of bypassing all the DAC. Basically I create, I revoke all on this table that I created from Postgres, and yet when I'm logged in as Postgres, I see the row.
18:02
I don't think that's surprising to anyone in here, probably. This may be a little bit more surprising. So here I've got RLS set up, and when I'm logged in as an unprivileged user, it works. I don't see the row. When I log in as the super user, I still see the row because RLS does not apply to the super user.
18:23
So here's another kind of interesting one. This time system exec is an extension that I wrote a while back to do some benchmark testing. It basically lets you execute anything at the shell, and it times it. But as you can see, what I'm using it for here is to just echo some text into a file on disk
18:43
and then CAD it, and that all works. So as the super user, I can install this function, and I can start reading and writing from the file system. Here's an example of copy program where I'm using echo to create a pghba.conf.
19:05
Now it's in temp right now, but you can see it got written out. And then I can use alter system, and I can actually set that thing as my pghba.conf.
19:20
Now that would require a reload in order to actually take effect, but if you don't have two-person control, your super user might be able to just get away with whatever they want. Here's an example of creating a function
19:41
using the system command, the system C function. And I can use that to, again, create a file on disk. Or even more interestingly, now, these are all functions that are available in libc, malloc, string, dup, open, read.
20:02
Prior to 9.6, I could actually create a function this way and use those to do things like read etc password file. So anyway, that's enough of that. These are kind of some of the things
20:21
that you really need to think about if you're worried about internal attacks. So any questions on that before I move on to what I call chronological security? Yes.
21:06
You can achieve equivalent functionality using SELinux and scpgSQL and custom policy.
21:21
So I mean, you can do it today. It's not simple, and you really need people who know SELinux to do it. Okay, so another aspect of security is, as I said, I'm calling it chronological security, basically logging and auditing.
21:44
Basically, Postgres comes with pretty robust logging support. You can send your logs to syslog, which means you can also send them to rsyslog, which means you can get them shipped off the system so that you don't have the ability for the user who controls Postgres to modify them.
22:01
There's other ways you can do that, of course, with products like Splunk or ELK stacks or EFK stacks, but in any case, there's quite a bit you can do with Postgres logging alone, and in fact, when I talk about these benchmarks later on, you'll see that there's some requirements specific to that built into those.
22:20
But you typically wanna go even beyond that, and that's where this pgAudit extension, David Steel, who's sitting here, was the one who's been maintaining it. I mean, we kind of inherited it from, I guess, Second Quadrant, and David and a few other people have been maintaining it for the last couple of years. We find that we use it in quite a few environments.
22:41
It basically provides a more granular way to do auditing as well as the fact that it resists obfuscation. So the object that you're accessing will actually be in the message even if someone tries to get cute, by dynamically executing a string
23:01
that's concatenated from whatever. And you can use either a session level or coarse-grained or an object level, fine-grained. There's more detail in the appendix. David has, I'm sure, slide decks that you can go find if you go Google for them.
23:21
And also, when I get to the Stig, I'll talk about there's an appendix, and in the appendix to the Stig, there's actually a whole section on how to set up pgAudit. The scpgSQL extension actually does provide some enhanced logging as well because it makes use of the logging that SC Linux makes use of. So SC Linux denials will also go to the audit log.
23:43
Other types of chronological security are the notion of history tables. And so again, I talked about this RLS policy for history tables yesterday in the Lightning Talks. But another way to do that that's actually been around longer and is probably more popular
24:01
is basically using JSON or HSTOR. And there's a whole example. And these blue lines in the slides here are hot links to those examples. So this goes to the appendix of this deck, but this goes out to the example, I believe, on the Postgres Wiki. So if you download these slides later on,
24:23
anything that's in blue will be a link to something. Okay, so now I'm gonna move on to the actual security profiles that I was mentioning before. Any questions about everything else before I do that?
24:42
Okay. So as I mentioned earlier, the CIS is the Center for Internet Security. It's a nonprofit. It strives to produce best practices and is generally used by commercial entities. And at least in the US,
25:01
it's used by government organizations that are kind of non-DOD, non-intelligence community kind of related. We have seen it come up a number of times. It is something that not everyone has heard of, but it's becoming more popular. And a CIS benchmark is basically a set of guidelines
25:23
for a software product. DISA is the Defense Information Systems Agency. As I said before, this is a US Department of Defense agency who's basically tasked with providing information security across the Department of Defense in the US
25:43
and the intelligence communities to some extent. The STIG is the Security Technical Implementation Guide. It's basically configuration standards equivalent to the CIS benchmark to provide guidance to lock down software and systems.
26:04
The CIS benchmark for Postgres, again, it's in draft form right now. It's prescriptive guidance, but it is based on open source Postgres. Right now, I think there is another open source. I think MySQL has a CIS benchmark that's been published.
26:22
That's the only other open source database. There are published CIS benchmarks for things like Oracle and SQL Server, at least. This one has been tested on CentOS 6 and is applicable to Postgres 9 and 5 Plus. All the components that are used in the guidance
26:42
are based on open source, so you can make use of this freely yourself. And it comes with basically the notion of two profiles. And you'll see this term a lot in these kinds of things. Profile is basically a list of things that you're gonna check and fix. So there's profiles that are at level one,
27:02
which are things that have clear security benefit, but you try not to be too intrusive, whereas level two is basically, it might inhibit utility or performance, but if you're in an environment where security is kind of paramount, you're probably gonna want those as well.
27:23
It contains the following kind of broad sections. There's no way to go through at any kind of real level of detail in just a fraction of an hour, but it covers installation and patches and directories, logging, access and authorization,
27:42
settings, basically all of the things that we've been talking about so far are covered in one way, shape, or form in here. A rule starts with a scoring status. I don't honestly know because those are all right now unscored. I think what those are meant to be are kind of like a level of severity,
28:03
and we'll see that in the STIG again later. Which profile, which of those two levels it's a particular rule is applicable to, a description, and again, a lot of this will be repeated in the STIG. You'll see they're fairly similar. There's kind of a general description of a rule, what thing we're gonna check,
28:23
what's the procedure for checking it, and what's the procedure for fixing it if it doesn't pass the check. And then at the end, there are references back to the controls that led us to create this rule and any references.
28:44
The Postgres STIG, again, is a comprehensive set of requirements. It's based on this database SRG, Security Requirements Guide, which is kind of a generic STIG for databases. If you're at all familiar with this area,
29:01
you probably will have noticed over the, particularly over the last three or four years as Postgres popularity has gone up, you kind of get to know the wording of the STIG, and people would show up on the Postgres mailing list about once a month, and they'd ask a question that came right out of the STIG. And so basically people were having to reinvent this stuff
29:24
over and over and over again because there was not a Postgres STIG. Now that there is, you can actually just download the STIG and follow the guidance right in that instead of having to reinvent it yourself if you have these kinds of requirements. It derives its controls from NIST.
29:41
So the CIS controls, they've invented themselves. NIST is a national agency in the US, again, that comes up with these security controls that are being followed. And so these controls are actually reused in other areas as well,
30:01
and other types of security compliance. It's based on RHEL 7 with FIPS crypto enabled. That's fairly straightforward to do with the guidance from RHEL. You can actually FIPS enable on, at least the commercial version of Ubuntu and on the commercial version of SUSE as well.
30:23
They use the same method that Red Hat does. I've seen this one come up a few times on the list as well, and there's some confusion over it. And so I digress for a minute into that. With OpenSSL, normally in order to use FIPS mode, there is actually a FIPS mode call
30:41
that you have to make in C code in order to enable the mode. Postgres does not do that. So people say, well, therefore Postgres cannot be used on a system that has to be FIPS compliant, but that's actually not true because what Red Hat did and what Ubuntu and SUSE both copied directly from Red Hat
31:01
is basically a hack to OpenSSL where you enable FIPS at the operating system level in the kernel. So when you boot up, basically OpenSSL is in FIPS mode automatically and everything that uses it uses FIPS mode. So if you wanna drill into that, find me afterwards
31:22
and I can go into that in a bit of detail. Again, Postgres 9.5 Plus, I think the main reason for 9.5 Plus in both of these is because in order to be compliant with both of them, they depend on PG Audit. PG Audit works for 9.5 Plus. So I think that's primarily why the requirement is 9.5 Plus.
31:42
It has 111 rules and it's all based on open source components. Again, similar things covered, auditing and logging and encryption and decryption, access controls, authentication, some specific rules that are around protecting against SQL injection.
32:02
The STIG comes with some appendices which are very useful actually if you wanna do any of these things that are covered. There's a sample account lockout script, but there's also some detailed instructions on how to install and configure PG Audit, detailed instructions on how to use SSL,
32:22
how to use PG Crypto, some examples on how to do RLS. So that's kind of generally useful in and of itself. When you say SSL, you mean TLS. Right, talking about open SSL. So yeah, it's TLS.
32:45
So the way the anatomy of a rule in the STIG is again, very similar. There's like general information section with identifiers and a severity category and a title. There's a discussion section that sort of talks about, well, why do we care about this thing?
33:01
How do you check it? How do you fix it? And then some references that tie back to the NIST standards. DISA does publish what they call a STIG viewer. The STIG is actually published as a massive XML file, which is very painful to read.
33:21
This STIG viewer is actually, you probably can't see it. There's no way to make the font bigger. It's not the prettiest app in the world, but it's useful in that it provides kind of a way to walk down through each of the controls. Those sections I was talking about are all over here. The other very cool thing you can do is it supports export to RTF.
33:43
So you can basically take the STIG, export the whole thing to one RTF file, and then you can do searches through it easily. It's Java. The other thing I want to mention is,
34:01
again, this is something that Crunchy worked on, but it's open source, is we produced something called the STIG Checker. And it specifically works with Chef InSpec module. So InSpec is designed to automate the compliance checking in general. And so we've created a STIG profile for Chef InSpec
34:26
and published that on GitHub. So there's kind of, if you need to do STIG compliance checking, you can use this as, it's not, it doesn't do everything perfectly. We're continuing to work on it and improve it, but it'll give you a good head start if you need to do compliance checking.
34:42
We're also working on, and it's not, I think it's not been publicly published yet, but we're working on what we call a continuous compliance checker, which is sort of some automation around the STIG checking with kind of a simple web interface to look at the compliance so that you can run this thing.
35:00
Because, you know, basically if you do this, if you're compliant with the STIG today, what does that mean a week from now? Well, ideally you're actually monitoring your compliance on an ongoing basis. The other thing to note is this kind of automation of the STIG checking, there are environments where you could take previously,
35:24
checking compliance to the STIG of a database could take months, if not a year. And with this kind of automation, you can typically get through this process very, very much faster. So now here's an example of an actual CIS benchmark rule.
35:41
I'm not gonna try and go through it in detail, but this is just to give you the flavor. And as I said, most of them right now are not scored. This gives you the profile, level one. For this particular one, ensure excessive administrative privileges are revoked. You know, there's some rationale describing why we should care about this.
36:01
And then there's the audit procedure. How do we check to see that things are done in accordance with this rule? And then a remediation procedure, which is how do you fix it if it doesn't comply? And then finally, the tie back to the actual CIS controls
36:21
that this rule comes from, and then references. And in this case, these are references right into the Postgres documentation for the commands that were used. The STIG is very similar. This is kind of, this is all that stuff that was too small to read in that STIG viewer. Here's a Postgres must be configured
36:41
to prohibit or restrict the use of organization, defined functions, ports, protocols, blah, blah, blah, right? It has a vulnerability ID, it's category two severity. Basically, it goes through all of this, you know, again, description of the rationale and why we care about this.
37:02
And this particular rule, and after discussing it with the people at DISA, boiled down to, in terms of applicability to Postgres, you wanna make sure Postgres is running on the port that your organization has determined it should be running on. So this particular one boils down to checking that you're running on the right port,
37:21
and then fixing it if you're not. So nothing too surprising there. And then again, there's a references section back to NIST, and something called CCIs, which are kind of a way of agglomerating different requirements. Any questions about all that?
37:46
All right, so I know I've been going fast, and it looks like I might actually get through these slides, so that's good. The configs here, now, the CIS benchmark is not complete, so I didn't try and boil those down, but I went through the STIG and found all of the things
38:02
that were in the STIG that were directly prescriptive in terms of what settings you should have in postgres.conf. You know, it basically boils down to, you have to have a PG audit, and it needs to be in shared preload libraries, because that's how it works. You have to have certain logging specific parameters
38:23
for PG audit. Basically, this is saying I'm gonna log all statements except for ones that are deemed to be miscellaneous. You have to have a role defined for it, and so on.
38:40
There's specific requirements for the postgres log itself. You have to log connections and disconnections. You have to have a specific log line prefix to meet all of the rules, so additional information that you wanna have in your log. Log file mode, so that the log file is protected.
39:01
Log destination, really, per the STIG, needs to be some kind of a remote syslog. Again, when you're going through a compliance checking of something like the STIG, though, some of the individual rules become a negotiation between you and whoever's checking compliance. So if you can make an argument for why you don't wanna use our syslog,
39:22
instead you wanna use an ELK stack, that very well may be okay, even though it doesn't strictly comply with the STIG. And going back to the automated STIG checking, when you create those profiles, they have the notion of something called overlays. So if your organization is determined that you can not meet one of the requirements
39:43
in the STIG or meet it in a different way, you can create your own overlay, add that to the STIG checking so that you don't constantly fail that item. And there's some additional requirements in terms of how SSL is set up, and your time zone, password encryption on,
40:05
and some items that are kind of loosely related to kind of denial of service kind of things. So in terms of HPA settings,
40:22
password is explicitly forbidden in the STIG. The method MD5 is not actually addressed, other than the fact that the STIG does require FIPS compliance. FIPS compliance will not allow you to use MD5. So again, depending on your ability to negotiate with whoever's doing the audit of you for compliance,
40:42
probably are not gonna be able to use MD5 method for authentication. The explicitly approved methods are cert and basically Kerberos Active Directory LDAP. Postgres 10, you're probably gonna wanna use SCRAM.
41:01
The STIG has actually not been updated yet for Postgres 10. We are planning to work with DISA to get that done, hopefully sometime in the not too distant future. But so far that has not been done. Based on what I know, again, you probably, if you're running Postgres 10, you discuss it with whoever's auditing your system,
41:21
they probably would accept that. And so with the cert auth method, you need to do kind of verification of both ends of the connection. And so here's an example of a rule that would allow you to do that. You have client cert equals one. And when you connect from psql,
41:42
you can say SSL mode verify full, and now you're verifying the connection on both sides. And I actually made it through all the slides and I have, I think, four minutes left for questions.
42:09
I'm not nearly as familiar with AppArmor as I am with SELinux. From what I know of it, it works a little differently in the way it locks things down.
42:20
So I'm not sure that you can achieve the same thing with that or not, to be honest. I do know that if you go back a few years, SELinux support on a Debian variant system was not very good. But in the last couple of years, there's been great strides made by the SELinux community to bolster their support
42:43
for the Debian derivative systems. So I think it's very feasible to run SELinux on like an Ubuntu system now. I've seen that too with SUSE.
43:16
Any other questions? Yeah, there are some other, I mean,
43:22
this is a big digression, but you know, the Linux kernel supports the notion of security modules, LSM, Linux Security Module. And SELinux is really just one of those, and AppArmor is a different one. And there's some others out there, and there's some commercial ones that are out there.
43:41
And so there are different ways to achieve kind of the same thing. There's a commercial product out by General Dynamics called Pitbull, which also does kind of similar things. So there's, depending on your specific needs, there probably are other options.
44:03
All right, well, that's all I got. Thank you.