Re: Updates to several OpenBSD hosts
Hi, On Wed, Jun 24, 2009 at 10:13:21AM +0200, Joachim Schipper wrote: [...] > If you want to go the whole hog, cfengine/puppet may be useful. But > you're likely content to just keep a single configuration up to date, > in > which case simpler measures may suffice. I plan to look into cfengine (didn4t know about puppet, thx) - however, I think configuration files are not a problem. Changes there are always documented and everything is backed up on a central location, so it will be easy to do this manually. > You can use release(8) to construct updated tarballs for the base > system. Create these on a secure system, sftp them to anywhere you > need, > and unpack. Binary patches are possible, but probably more effort than > they're worth for a comparatively small setup like yours. Ok. > I'd be inclined to go with snapshots, but you'll need to follow the > process at least a little and test at least a little. On the other > hand, > if you go with -stable, you should make sure your ports are kept up to > date, which isn't guaranteed. This is the reason why I plan to look into snapshots at all. I got into quite a mess with my mixture between stable OS, and newer versions of programs (like ClamAV, which needs frequent updates). I guess snapshots will keep everything in sync. > Remote upgrades should be possible in either case. > > You can use sysmerge to check for and resolve differences between the > installed files and the etcXY.tgz and xetcXY.tgz files. This is very > useful when upgrading systems. > As for keeping the configuration in sync, you may want to consider > your > favourite version control system. You will, obviously, need some > per-host customizations: these may be best represented as branches. Or > not. > > You should create ports from your personalized postfix and clamav > installations, which will make it a lot easier to install them and > ensure you can easily keep all your hosts on an updated version. This is good advice, didn4t think about creating my own ports for this. > Otherwise, it seems pretty sensible. You might be better off if you > could convince those organizations to trust in a single mailhost run > by > you, though. This is not an option unfortunatly, however, the different mail configurations were never a problem. Thanks for your advice, really appreciated! Urban
Re: Updates to several OpenBSD hosts
Han Boetes wrote: > I'd like to suggest using netboot. So you need only one server to > maintain and for the rest all you have to do is restart services > or reboot the rest. My aploogies for being unclear. Those hosts are all on different locations and nets, even belong to different companies. I don't think netboot is an option here (please correct me if I'm wrong).
Updates to several OpenBSD hosts
Dear list, I am seeking advice on how to keep several almost identical OpenBSD installations up to date over several years / releases if possible. I have 6-10 OpenBSD firewall/gateway/proxy hosts running, all with the following tasks: - pf - squid - postfix / amavisd / clamd - openvpn - ... and a few minor things. All hosts are running on (different) i386 hardware, with a standard kernel. Almost everything is orininally installed using packages/ports, with a few exceptions (postfix, where I always preferred to pick the version myself, or some perl modules for amavisd where I didn4t find a port or package). My goal is to keep those systems up to date. Until now, I only used releases, did source code patches when necessary, and from time to time manual updates to postfix + clamav (I compiled those from source - could4nt use updated ports, as I do not run current - or am I wrong with this assumption?) I really would like to make things easier - by using exactly the same version (which isn4t the case right now unfortunatly) - by using exactly the same set of installed software (with some components disabled if not needed) - by using one "build system" to test the updates, and rolling it out from there to all other hosts - All updates should be done remotely (if something goes terribly wrong I4d still have the option of driving there). My questions are: (1) I should use release(8) for this, shouldn4t I? (2) Would you recommend using the release versions + source code updates, or snapshots together with updated ports? (I am aware that many seem to prefer snapshots here; I was reluctant to use them till now as stability is really important here) (3) Will either of those 2 options make it possible to perform remote upgrades to new OpenBSD releases? (say from 4.5 to 4.6) (4) While the software selection is almost identical on those machines, configuration can be really different. I never tried release(8) - how to keep track of different versions of files in /etc? (5) Do you see a better alternative / what did I get wrong :) ? Thanks for listening Urban
Re: OT: Can an SSH alternative to WebDav be use on OpenBSD
If using sftp with WinSCP is still an option, but you do not want users to have SSH access, this can be achieved easily with sshd_config-settings like: # override default of no subsystems Subsystem sftp/usr/libexec/sftp-server Match Group sftp X11Forwarding no AllowTcpForwarding no ForceCommand /usr/libexec/sftp-server Not sure if this is fits your needs though. -Urban
Re: spamd, CARP and relayd
On Mittwoch 23 Januar 2008 21:05:49 Richard Daemon wrote: [...] > I also recommend Peter N.M Hansteen's book, 'The Book of PF' from nostarch > > (orderable from OpenBSD.org), just the chapter on spamd alone would benefit > you a lot for this! > > If I recall, he even talks about Bob Beck's presentation too. Great book, > well worth it every cent and I would have to say it's a must have for just > about anyone. Ordered it 2 minutes ago, thanks! :) -Urban
Re: spamd, CARP and relayd
On Mittwoch 23 Januar 2008 18:56:52 elpinguim wrote: [...] > Bob Beck's presentation on spamd & pf should provide some useful insight as > to how you could deploy a similar setup. I found the presentation(s) to be > quite helpful a few years ago. > > http://www.ualberta.ca/~beck/nycbug06/ Thanks, but I already stole several ideas from his presentation :) However, it does not answer the 3 questions in my original post. Regarding hardware sizing Bob says he is using a "smallish Dell Server" - I would be interested in more details (how much RAM is needed, how big does the greylist DB get...). I suppose two "standard servers" (single xeon, 2 GB RAM, small internal disk) would be more than sufficient for us, but some real world examples would still be helpful. And the questions about CARP and problematic SMTP servers remain as well. Thanks for your input! -Urban
spamd, CARP and relayd
Hi list, I am thinking about putting thow OpenBSD boxes running spamd, CARP and relayd in front of our primary MXes. I want to use them for greylisting and tarpitting only (RBLs are not an option for us, as we are using a more conservative approach on our postfix servers with policyd-weight - a host has to be on at least 2 blacklists before dropping the connection). (1) We usually have 200.000 - 300.000 SMTP-connections a day, with peaks of ~500.000 during outbreaks. Do you have any suggestions about HW sizing for the OpenBSD box? It would be very helpful if you could share your HW configuration and some numbers about the volume handled. (2) I plan to use CARP for failover, and relayd (hoststated) for spraying SMTP-connections to our postfix servers. Those servers use different interfaces for incoming and outgoing connections. Is it possible to use CARP & relayd to service both "sides" of our SMTP servers (using 2 CARP cluster addresses)? (3) I found several hints in the archives that some people believed to have problems with spamd and SMTP servers using address verification, open relay checkers, and some broken SMTP software. Does any of this still pose a problem for you? Any insights are really appreciated. Thanks in advance -Urban
Re: Problems with pf and rdr
On Sonntag 11 November 2007 06:41:41 Urban Hillebrand <[EMAIL PROTECTED]>
wrote:
> Hi everyone,
>
> I have a problem with pf redirection. I used this simple setup to reproduce
> this issue:
>
> An external host ("HostA") connects to port 55111 on my external interface
> ($IF_EXT) on my openbsd box. This connection is forwarded to the ssh-port
> of an internal Server ("ServerA") using my internal interface ($IF_INT).
>
> To allow this connection through my packet filter, it was my understanding
> that I4d have at least 3 options (I am aware that redirection occurs before
> filtering):
>
> (1) allow the incoming connection on IF_EXT + allow outgoing connection on
> IF_INT:
> This is of course working without problems.
>
> (2) using "rdr pass" instead of "rdr":
> This works for allowing the incoming connection on $IF_EXT, but I still
> seem to need an outgoing rule on $IF_INT.
>
> (3) using "quick" with my rule for $IF_EXT:
> Same thing happens as with (2).
[...]
An off-list reply cleared things up for me. It simply seems that forwarded
packets have to pass the ruleset twice (once for every interface) -
embarrassingly the very first sentence of the "packet filtering" section in
the pf FAQ seems to suggest exactly this behaviour:
"Packet filtering is the selective passing or blocking of data packets as they
pass through a network interface."
It says "through a network interface" here, not "through the network stack"
or "through your packet filter".
I always thought the packet first is rewritten by rdr, and is then evaluated
once against my ruleset. As I never really liked shortcuts in my ruleset
like "quick" or "rdr pass" and always explicitly specified rules for my
connections on all relevant interfaces, this misunderstanding never posed a
problem.
Sorry if this was an obvious question.
Problems with pf and rdr
Hi everyone,
I have a problem with pf redirection. I used this simple setup to reproduce
this issue:
An external host ("HostA") connects to port 55111 on my external interface
($IF_EXT) on my openbsd box. This connection is forwarded to the ssh-port of
an internal Server ("ServerA") using my internal interface ($IF_INT).
To allow this connection through my packet filter, it was my understanding
that I4d have at least 3 options (I am aware that redirection occurs before
filtering):
(1) allow the incoming connection on IF_EXT + allow outgoing connection on
IF_INT:
This is of course working without problems.
(2) using "rdr pass" instead of "rdr":
This works for allowing the incoming connection on $IF_EXT, but I still seem
to need an outgoing rule on $IF_INT.
(3) using "quick" with my rule for $IF_EXT:
Same thing happens as with (2).
Below are the rules I used for (3):
rdr on $IF_EXT inet proto tcp from $HostA to $IF_EXT port 55111 -> 10.2.0.58
port 22
pass in log quick on $IF_EXT inet proto tcp from $HostA to 10.2.0.58
And here is the output from pflog (hostname changed to "HostA"):
Nov 11 05:12:42.874890 rule 12/(match) pass in on xl0: HostA.33844 >
vm-obsd42-1.urban.intra.ssh: [|tcp] (DF)
Nov 11 05:12:42.875015 rule 3/(match) block out on de0: HostA.33844 >
vm-obsd42-1.urban.intra.ssh: [|tcp] (DF)
To verify, here are rules 3 and 12 from pfctl -srvv (external source IP
changed):
@3 block drop out log all
@12 pass in log quick on xl0 inet proto tcp from x.x.x.x to 10.2.0.58 flags
S/SA keep state
I have no problem working around this problem - but I am still curious if I
fundamentally misunderstood something here or if this is not working as
expected. Any ideas?
Thanks
-Urban
Tagging on enc0
Hello list, what4s a good strategy to pass decrypted VPN traffic from roadwarriors on my internal firewall (3.7) interface? The source IP addresses from the roadwarriors are either: (1) a dynamic IP from an arbitrary ISP: Here I could use authpf to dynamically adjust my rules or (2) an internal IP, as several home office users are behind a NAT-T capable router. Here I guess I am out of luck with authpf, as $user_ip would point to the NAT4ed official IP. I could assign the internal IPs and hardcode those into my ruleset as a workaround. While trying to work this out, I came upon a different alternative: Would you consider it reasonably secure to tag VPN traffic on the enc0 interface, and use this tag to pass this traffic on the internal firewall interface? Bad idea? Thanks!
