Re: pf and DNS
On Fri, 2011-01-07 at 16:26 +0530, Girish Venkatachalam wrote: > On Fri, Jan 7, 2011 at 2:43 PM, Martin Schrvder wrote: > >> > >> And consequently pf which does not know a thing about domains does not help > us. > > > > What exactly is the problem you want to solve? > > > > Sorry for having been abstract. > > Here is the detailed explanation. > > One domain translates to around 100 IP addresses. Yeah, it happens. If you look those IPs up via ARIN's whois[1] server you'll see that they are only a handful of netblocks and you can shove them into a PF table as needed. Have fun maintaining the tables. Because 1) You'll forget to update them periodically 2) You'll be SOL when there is a data center or network issue and suddenly everything is going to another netblock. > > But pf does not agree to using a domain and doing the domain to IP > translation on the fly. If you want to filter based on hostnames instead of IPs, you're going to have to filter based on packet content instead of packet headers. This means either a user space proxy, or have your internal DNS servers claim to be authoritative for those domains[2]. Oh, and if you do go the DNS route, you *WILL* forget to update periodically and you *WILL* be SOL when servers move around. > > Due to this , whatever IP address pf(4) knows at the time of ruleset > loading alone works. > > And I do not want to use a userland proxy. Yeah, and I do not want oodles of hot new blog articles on topics that were interesting and 10-15 years ago... But I know there's no chance of that happening. > > How to do it? In your case I think you should cough up lots money to one of the companies selling a firewall that does deep packet analysis. Perhaps someone here would be kind enough to mention one that's the most expensive appliance that's just an off the shelf PC running *BSD and a transparent squid proxy with pretty GUI front end. Or you could have looked in /usr/ports/www/squid/Makefile and seen that squid in ports is already configured to be usable as a transparent proxy with the aid of pf(4). Grouchy as always, Chris Dukes [1] Around since 1982 although it's changed a bit since then. [2] If you go back to 1995 or so you'll find misguided IT managers using this approach to block big name R rated magazine sites while employees continued to grab increasingly nasty porn with no problems.
Re: OpenBSD with PHP and MySQL
On Thu, 2011-01-06 at 10:43 -0500, Ben Adams wrote: > I know OpenBSD is built for security. > Using OpenBSD with bigmem on Mysql and PHP (No need for apache) machine. > How much of a preformance difference is there from FreeBSD?? > Looking for % or TBS or QBS. > > Machines will be mini 1U. > one Quad core and 8GB of ram. > > Thanks and yes OpenBSD is built for security. Just looking for performance > difference. In all my years of dealing with bad apps I've found that 99 times out of 100 when an application is spinning enough that the hardware isn't mostly idle that the root cause is the crap code in the app and not the OS or the hardware. If in doubt as to how to run the app to get the most bang for the buck, record a representative flow of transactions to the app and play back that recording as an app specific benchmark on your own hardware (Or if your hardware vendor is really nice on some evaluation hardware from them). That you don't realize that you need to develop and run your own benchmarks tells me that putting OpenBSD into the mix won't do a damn thing to address the security and logic issues within your own app, so you may as well go with whatever OS can bring you the cheapest pool of minions. You're welcome. Chris Dukes P.S. I look forward to reading about SpryMed data leaks in a future issue of Risks Digest.
Re: OT: Disadvantages of using virtual firewalls like OpenBSd
On Tue, 2010-11-23 at 15:28 -0500, Brad Tilley wrote: > Nick Holland wrote: > > > what's changed? > > Layering? Nope. > > Crappy programming? Nope. > > Better hardware? not really. > > Features-before-security? Nope. > > Good points. The goals of virtualization are, easy management, power > savings, quick provisioning and deployment, redundancy, etc. When you > talk about security and virtualization at the guest level, the > prevailing attitude is, "If it gets hacked, we'll just restore it from a > known good snapshot... problem solved." With the way most of those app stacks are it's more like "We'll restore it from snapshot when one of our admins or developers fat fingers and blows it all to hell. We honestly can't distinguish malicious behavior from a 3rd party from our existing application bugs." > > I don't hear much talk at all about the host machine and security (the > real server that hosts all the pretend servers is just assumed to be > OK). There just seems to be a lot of trust in the vendors. No more trust than what they are putting into the OS distributions management chooses nor the application stacks management chooses. What's the point of compromising the OS or hypervisors when the memcached servers are open to the entire Internet, and the app stack was designed to make injection attacks easy. Chris Dukes
Re: Architeture Choose
On Fri, 2010-11-05 at 14:30 -0400, Joe McDonagh wrote: > "If your Sun fails" <-- that's a big IF. It's approaching a possibility > of 0 in my experience. > > If performance isn't an issue and stability is your chief goal, none of > this hardware is as stable as a Sun. Not quite my experience. In 2001 I worked at a place with a lot of used Sun hardware courtesy of Fujitsu layoffs (Sparc 20s, Ultra 5s). Entirely too many fried ethernet ports on the sparc 20s. And it took too many iterations to find a sparc 20 that wouldn't crash and burn while building OpenBSD from source. A fidgety developer kicking an ultra 5 from a | orientation to a _ orientation would reliably destroy the power supply and harddrives. On the bright side, I could repair the ultra 5s with power supply and drives scavenged from eMachines with ALI motherboards with the wonderful DMA that shoved garbage into memory for every OS we tried on them. I thought the Micro Channel based RS/6Ks (Before the horrid SMP ones designed by Group Bull) were a bit more bullet proof, with the only dead hardware I'd experience being. 1) Rats pissing on the system boards, because the customer refused to keep the covers on their systems in manufacturing. 2) A ladybird beetle invasion. The RT PC was pretty reliable too. I had one manufactured in 1987 that was still trundling along in 2006 when I gave it away.
Re: nfsv4?
On Wed, 2010-10-27 at 14:26 -0700, James A. Peltier wrote: > - Original Message - > | You mean, NFSv4 seems more "transparent" to you (whatever that means) > | than, say, NFSv2? > > No, in that NFSv4 with Kerberos was an easier move from NFSv3 than to move to > something like AFS, which seem would have required much more work to migrate > the existing systems. What problem were you trying to solve by moving to NFSv4 from NFSv3? AFS was interesting in 1990. It also had some security flaws that led to it being sunset in many environments by about 1998. It also had some damn annoying issues with cache coherency between systems which made it a nightmare for running circuit simulations and synthesis on a cluster. DCE/DFS was interesting 12-15 years ago, but lacked wide platform adoption and was essentially killed off when key people quit working on it in 2000. If you're actually writing oodles and oodles from many servers at once, you're going to want a cluster filesystem suitable for scientific computing. If you're doing manipulation of the files from workstations... you go with whatever is supported on them... but I'm not seeing OpenBSD as a prime candidate for workstations. Thanks, Chris Dukes
Re: nfsv4?
On Wed, 2010-10-27 at 15:28 -0700, James A. Peltier wrote: > I deal with research data. Most of which are tens to hundreds of gigabytes in > size, so it's not a solution for me, but we did evaluate that for some > smaller scale uses. > > Our users are used to typing cd /cs/ and having their files be > available to them. They are used to seeing the same files in the UNIX home > as is in their Windows or Mac shares. This better describes what I mean by > transparent. And OpenBSD probably isn't the tool you want for holding the data, getting the data out to the different platforms used in research or visualizing the data. However, if another goal is to keep hoodlums away from the file servers and the workstations of the researchers, OpenBSD is an excellent platform. Please note OpenBSD doesn't actually have to get to any of the research data to act in this role. Thanks, Chris Dukes
machine-dependent tweaks to /usr/src/etc
On Wed, 2010-10-13 at 19:47 -0600, Theo de Raadt wrote: > There has been talk about going thourgh /usr/src/etc and building > machine-dependent (that means "architecture-dependent" for those of > you who are not on The Team) variations for this. > > People who dug into this got scared and didn't finish. We'd be willing > to look at things other people start for this... and then provide a > long series of comments... if someone has the staying power... Perhaps lower hanging fruit would be for those that regularly tweak /etc to occasionally send in sanitized diffs against the originals with comments as to why the changes were made. Changes that appear for many people probably should eventually go into the FAQ. (Sorry, I don't have any tweaks... 4.7 required no tweaks outside of turning on IP forwarding in /etc/sysctl.conf...) Thanks, Chris Dukes
Does relayd(8) support TLS Server Name Initiation?
And if not is support planned? I'd like to make use of relayd's relays for URL based filtering of https requests. I already know for SSL2 I'm stuck to 1 IP address per cert. A scan of the relayd.conf(5) and ssl(8) and the daily change logs for 4.6 through current all say no, but for all I know someone might be working on something quietly :-). And since the current state of things appears to be "No TLS Server Name Initiation," does anyone have any throughs as to whether or not using relayd redirects and lighttpd or nginx to negotiate TLS SNI would be a bad idea? And if it's a bad idea, what any better ideas are. Thanks, Chris Dukes
