Re: Compromising a host with pf enabled?
On Nov 19, 2007 10:53 PM, Clint Pachl [EMAIL PROTECTED] wrote: In my DMZ research, some sources state that all services need to be replicated in each DMZ. Following that advice, I would have to setup Kerberos, ntp, backup, and DNS in each DMZ and the LAN; that sounds like a lot of work. What do you guys think? A company I know just moved to this architecture. They have something on the scope of 5 DMZs consisting of about 10 different segments/tiers. This was the result of security architecture design for the most secure setup to provide segmentation. I think it sucks. While the amount of segmentation they have is probably A Good Thing, the way it is implemented imposes this necessary duplication of infrastructure services in each of the segments. So instead of a pair of DNS servers, they've got a pair of DNS servers *per segment.* Ditto for LDAP, DHCP, monitoring, backup and administration jump servers. Maybe more. It significantly increased the amount of systems that need to be maintained in the organization. Introducing jump servers increased the number of administrative accounts that were needed by everyone. It increased the complexity of the design and processes for administration. It increased the amount of replication of services and data transfer on the networks for that. It significantly increased the cost to implement. We have suspicions that it's now too difficult for administrators to effectively maintain the hosts in these segments and some may be slipping on patches, backups, or other necessary administration tasks. Moral: only do this crap if you can balance it out with the ability to reasonably manage the outcome and not incur disproportionate cost to the benefit it provides. DS
Re: Compromising a host with pf enabled?
Darren Spruell wrote:
On Nov 19, 2007 10:53 PM, Clint Pachl [EMAIL PROTECTED] wrote:
In my DMZ research, some sources state that all services need to be
replicated in each DMZ. Following that advice, I would have to setup
Kerberos, ntp, backup, and DNS in each DMZ and the LAN; that sounds like
a lot of work. What do you guys think?
A company I know just moved to this architecture. They have something
on the scope of 5 DMZs consisting of about 10 different
segments/tiers. This was the result of security architecture design
for the most secure setup to provide segmentation.
I think it sucks. While the amount of segmentation they have is
probably A Good Thing, the way it is implemented imposes this
necessary duplication of infrastructure services in each of the
segments. So instead of a pair of DNS servers, they've got a pair of
DNS servers *per segment.* Ditto for LDAP, DHCP, monitoring, backup
and administration jump servers. Maybe more. It significantly
increased the amount of systems that need to be maintained in the
organization. Introducing jump servers increased the number of
administrative accounts that were needed by everyone. It increased the
complexity of the design and processes for administration. It
increased the amount of replication of services and data transfer on
the networks for that. It significantly increased the cost to
implement. We have suspicions that it's now too difficult for
administrators to effectively maintain the hosts in these segments and
some may be slipping on patches, backups, or other necessary
administration tasks.
Moral: only do this crap if you can balance it out with the ability to
reasonably manage the outcome and not incur disproportionate cost to
the benefit it provides.
Thanks for that feedback. That example you gave sounds like an admin
nightmare.
I've decided to go with a fairly flat topology. I will have a single
DMZ, a LAN segment, and a segment for WLAN and use a single firewall to
route between the segments. Anything that will be directly accessible
from the Internet will go in the DMZ, otherwise everything else goes in
the LAN. I will poke holes in the firewall from the DMZ to the LAN as
necessary (i.e. webservers - {database,kerberos,etc}). Every host on
the network will have pf enabled, only allowing services to specified
hosts. I will also be setting up nagios and snort to keep the network in
check and watch for illegal communications between servers.
I've done a lot of network and DMZ design research over the last 3 days.
I've looked at hundreds of websites and newsgroup postings and read the
following titles:
Building DMZs for Enterprise Networks
http://www.amazon.com/Building-Enterprise-Networks-Robert-Shimonski/dp/1931836884/ref=sr_1_6?ie=UTF8s=booksqid=1195677170sr=1-6
Designing and Building Enterprise DMZs
http://www.amazon.com/Designing-Building-Enterprise-DMZs-Flynn/dp/1597491004/ref=sr_1_8?ie=UTF8s=booksqid=1195677170sr=1-8
Designing Large Scale LANs
http://www.amazon.com/Designing-Large-Scale-Kevin-Dooley/dp/0596001509/ref=sr_1_11?ie=UTF8s=booksqid=1195677281sr=1-11
I've also built highly segmented networks and find them difficult to
manage and they have highly complex traffic flows and firewall rule
sets. And I don't believe they offer much more security because many
attacks are taking place at the application level and on the inside
carried out by compromised hosts. I think every server should be
hardened and monitored and trust no one.
In all my research, I like best this article about MIT's security
architecture:
http://www.computerworld.com/securitytopics/security/story/0,10801,100021,00.html
Re: Compromising a host with pf enabled?
Clint Pachl wrote: I've done a lot of network and DMZ design research over the last 3 days. I've looked at hundreds of websites and newsgroup postings and read the following titles: The best security setup are the simplest one that you can look at your pf configuration and understand very well each lines as well as any other admin that may need to play with it. That's how you avoid mistakes. I am not a fan of multiple DMZ by any mean, specially when traffic needs to go across these different DMZ, every time someone does that, over time, you end up having holes in it as it's getting complicated and sometime an admin will take a shortcut because of an issue that crap up one day, fix dirty and quickly and never go back to look at it and then your DMZ end up in swiss cheese before you know it. My own preferred setup is your firewall at the edge of your network facing the Internet obviously, one DMZ and the LAN. Then each servers that run services in the DMZ, in my case anyway there is only one service per servers and that server run OpenBSD and PF on each one. Couldn't be simpler and when it is time to upgrade to the next release, that's pretty quick as well as there isn't any excuse of, (well guys, you don't understand, I can't upgrade, I need to still run 3.5 because of this or that reason and my setup is to complicated, etc). Then you are always at the latest release, you follow the release and keep all your servers up to date and because it's one service per server, it's pretty quick and painless to upgrades, etc. Then each server as I said run PF, but also in every setup, don't only block incoming traffic, do it right and block the outgoing one as well. Again, many will say, it's to complicated to do, so they don't do it, but I would say that if that's to complicated to understand, then you have no clue what you are doing and sure don't understand your traffic and have no security policy either in that case. Just a simple example to illustrate this. You wrote that you have web server. I don't know, may be you also run php on it. Let said you have an intern that is in charge for the summer of the web server php upgrades. Let say that he doesn't really write good code, but it does work, so everyone is happy, but there is plenty of holes created by not checking the value pass to the various scripts. Then you have a bad guys going and trying to compromise your network via php simple injection of codes, via one not check variable on your php code and that obviously run the scripts and what that does called a URL on an other server on the net, the inject that on your box and then you end up compromise. So, what all your setup was used for. Nothing and didn't protect you much. But if your PF configuration on your web server only allow traffic coming from port 80 and going to others 1023 as an example and actually block any traffic coming from you to any other device on port 80, then you have block that compromise and you can see it in your logs. You know your server only allow incoming on 80 and reply to these ( dns as well, etc, put you use your own server as well, so you secure that already the same way), then you make your setup secure and with proper setup and very simple to maintain as well. The best security setup is to know what is suppose to come in and also what is suppose to go out and you allow only these. Now if you do simple setup with one service per box and on top of your mail firewall, you have PF on that box and every other DMZ servers, your are going to have very peaceful nights and plenty of sleep! Hope this help, but if you sit back and just think about it, you will see that you don't need to read for days on to find the best setup, or what works for you. Instead of studying all the documents on the Internet about security setup, study your network about what it does needs and what traffic is suppose to be on it and make it so. You will learn a lots doing so and even that as a side effect, if you also block outgoing traffic and you log all connections trying to go to port 25 that is not your own servers, you will find all your Windows compromise workstations as well in the process, very quickly, etc. Or all the visitor to your network with their laptops that bring with them virus, etc and don't even know it. Checking incoming traffic logs is important yes, but other then blocking access to these bad guys, there isn't much you can do. However, blocking outgoing traffic and also checking these logs are way more important and then you are pro active in your security and will fix issues way before they create damage on your LAN. My setup send emails to the support team when these happen, so I tell you that is doesn't take long before a visitor plug his/here laptop on the LAN with virus before it gets detected and then get his/here head beat up for not be responsible and the issue is taken care of very
Re: Compromising a host with pf enabled?
On Mon, 2007-11-19 at 22:53 -0700, Clint Pachl wrote: In my DMZ research, some sources state that all services need to be replicated in each DMZ. Following that advice, I would have to setup Kerberos, ntp, backup, and DNS in each DMZ and the LAN; that sounds like a lot of work. What do you guys think? That you are basically bypassing your own firewall. Just create a third subnet for your management services and allow only the lan and dmzs to access it through the firewall. Not perfect but IMHO better than establishing a direct path between a dmz and a lan and adding complexity to monitor traffic on that path. ciao Luca
Compromising a host with pf enabled?
Is it possible for a cracker to compromise or root a machine on a network that has pf enabled with the single rule block all in?
Re: Compromising a host with pf enabled?
Clint Pachl wrote: Is it possible for a cracker to compromise or root a machine on a network that has pf enabled with the single rule block all in? I suspect you're just fishing, but in the interests of spirited debate - Is block in all the first rule, the last rule, or somewhere in between? (Yes, it DOES matter) - Does the cracker have alternate methods of entry (tty, ssh, console, etc)?
Re: Compromising a host with pf enabled?
On Nov 19, 2007 6:37 PM, Chris Zakelj [EMAIL PROTECTED] wrote: Clint Pachl wrote: Is it possible for a cracker to compromise or root a machine on a network that has pf enabled with the single rule block all in? I suspect you're just fishing, but in the interests of spirited debate - Is block in all the first rule, the last rule, or somewhere in between? (Yes, it DOES matter) It does say single rule. - Does the cracker have alternate methods of entry (tty, ssh, console, etc)? Social engineering? Usually the weakest point. Greg -- Ticketmaster and Ticketweb suck, but everyone knows that: http://ticketmastersucks.org Obsession in the low desert: http://lodesertprotosites.org Dethink to survive - Mclusky
Re: Compromising a host with pf enabled?
Greg Thomas wrote: It does say single rule. Yes, but at that point it becomes a rather useless system. It's likely to break in curious ways, since anything using the 127.0.0.1 loopback will, I think, either become unresponsive or start throwing errors. Social engineering? Usually the weakest point. Agreed.
Re: Compromising a host with pf enabled?
Chris Zakelj wrote: Clint Pachl wrote: Is it possible for a cracker to compromise or root a machine on a network that has pf enabled with the single rule block all in? I suspect you're just fishing, but in the interests of spirited debate - Is block in all the first rule, the last rule, or somewhere in between? (Yes, it DOES matter) - Does the cracker have alternate methods of entry (tty, ssh, console, etc)? Not fishing, just thinking. I didn't want to get into too many non-OpenBSD details on MISC, but I will expound a little. I'm trying to design a simple, but secure network with a couple of DMZs and a minimum of firewalls. Here is my initial thought. [Internet] | | [DMZ_2]---[FW]---[DMZ_1] | | [LAN] DMZ_1 = web servers DMZ_2 = database servers LAN = servers like Kerberos, ntp, DNS, backup (dump via ssh), engineering workstations Traffic Flow Internet - DMZ_1 (people need web pages) DMZ_1- DMZ_2 (get data to populate the web pages) DMZ_2- LAN (for Kerberos, ntp, DNS, backup) DMZ_1- LAN (for Kerberos, ntp, DNS, backup) Ok, so you're never supposed to let a server on a public DMZ access a server on your LAN. So I was thinking of creating a management subnet that would allow out-of-band services, such as backup, Kerberos, ntp, etc. To implement the out-of-band channel, each of the hosts on the DMZs would get an additional NIC for communicating on the management subnet. None of these hosts would allow packet forwarding and all would use the block in rule for that interface. There is no need to login to the hosts via ssh because they are automatically configured, pulling updates from a golden server. If a login is needed, it would be from the serial console. Below is my topology re-design that implements the management subnet. The DMZs access the LAN directly via the management subnet for Kerberos, ntp, backup, and DNS service. I would probably put a network monitor on the management subnet to detect suspicious traffic. Is this topology insecure? Suggestions and criticisms are very welcome. [Internet] | | [DMZ_2]---[FW]---[DMZ_1] || | || | --[LAN]- In my DMZ research, some sources state that all services need to be replicated in each DMZ. Following that advice, I would have to setup Kerberos, ntp, backup, and DNS in each DMZ and the LAN; that sounds like a lot of work. What do you guys think? -pachl
Re: Compromising a host with pf enabled?
Chris Zakelj wrote: Greg Thomas wrote: It does say single rule. Yes, but at that point it becomes a rather useless system. It's likely to break in curious ways, since anything using the 127.0.0.1 loopback will, I think, either become unresponsive or start throwing errors. Ok, I'm in brainstorm/big-picture mode and wasn't concerning myself with the technical details, but I will clarify. pf will block all incoming external connections. All traffic will pass on the loopback.
