Re: Privilege bracketing in Solaris 10
> http://www.sun.com/blueprints/0406/819-6320.pdf > > I'm not a C developer so it is mostly Greek to me, but others may find > some concepts therein useful. 30 years after VMS and 40 years after EMAS. Ivan Sutherland sure had it right with his observatiion of the "great wheel of reincarnation" as it applies to computing... G
Re: slow realloc: alternate method?
> Yup, > I used this in (function splitfields) where the delimiter was chosen > with getopt: > > http://etudiant.epitech.net/~veins/sort/sort.c Oh yes, sort... that reminds me... http://www.gtoal.com/wordgames/sort/sort.[ch] - see the above for the epitome of managing store yourself... It's not pretty and I'm not proud of the actual code but I was very pleased with the way I did the memory management. It allocates a single block of RAM at startup and partitions it rather sneakily for all objects ever needed by the program, I believe as efficiently as is possible. I wrote this because we were sorting text files of 100's of Mb on a machine that had 4Mb of physical ram; gnusort had a serious bug in that you told it how much ram you wanted to use but it then went over your request quite significantly. This was semi-OK on Unix where the use of VM would at least let the program run (albeit thrashing VM a lot) but on our hardware with physical memory only, it *always* failed a malloc at some point. As has been noted in this thread, realloc is evil! The code is well commented. Some might say to excess :-) It's probably one of the most complex pieces of memory management I've had to do in an application, and I didn't want to take the risk that I'd have to do maintenance on it 20 years later, and take one look at it and say "WTF???!" (So I guess that means it'll be due for maintenance in 2008 ;-) ) G
Re: slow realloc: alternate method?
> Growing your array by only a constant amount each iteration takes > quadratic time. By instead doubling the array size each time as > necessary, you can reduce this to (amortized) linear time. (I believe > the man page's intention was to show how to avoid leaking memory, not > how to write an efficient program.) See 'makespace' in http://www.gtoal.com/compilers101/tinc/02_Graham_Toal/teeny.c for an example of a generic way to do this. You call makespace each time you access your flex array with an index, and it will make sure the array is large enough such that the element with that index is present. (You don't need to call it if you know that the index is smaller than the largest index you've already accessed, but for safety it might be good practice to call it before every array access - the overhead isn't too high) You could probably use the preprocessor to hide it entirely, and just access your array with a macro, eg i = tickdata(n); rather than i = tickdata[n]; and have the macro first call makespace... G
Re: Recommendations for an OpenBSD-based Backup Solution
> Some friends of mine need a backup solution that can
> easily handle regular, automated backups from some M$
> Win 2k and Linux workstations as well as an OpenBSD
> 3.8 based Samba file server that I had set up for them
> a while ago.
I'm a little late to this party, and I apologise if
what I say here has been said already, or ruled out
already.
One of the biggest nuisances with backing up Windows
is that if you just naively walk the file structure
tree, you'll hit files that cause errors that are
very hard to trap. Some programs such as Karen's
Replicator actually manage to do this but they're in
the minority.
What I discovered earlier this year is that Windows
does in fact have a way of referring to the raw disk
by name (similar to "/dev/hdc1" on unix for example),
which makes it much easier to do a full-disk backup
while a system is running. Raw C parition would
be \\.\C: for example, and I think the entire drive,
partions, boot blocks and all (eg like /dev/hdc)
is something like \\.\PhysicalDrive0: (however
I haven't tried that one, only the \\.\C: variant
- see here:
http://www.utexas.edu/its/unix/reference/oracledocs/v92/B10501_01/win.920/a95491/ap_raw.htm
for confirmation)
These names are not usable by all utilities, but
anything in C that does fopen ought to be able
to access them.
Here's a simple program you can use to backup an
entire partition assuming no bad blocks. It exits
on the first data error which if your disk is good
denotes the end of the partition. Better handling
of bad blocks is possible, but I didn't need it.
(If I get any, then its time to restore from backup
to a new drive, not time to backup more disk errors!)
Hope this helps. You might be able to build on
this technique to do something like an scp directly
to a unix (though be careful with the scp protocol
that you handle >2Gb files properly)
Obviously when you restore the partition, you'll
need to do a windows-style fsck when you reboot as
it will be the equivalent of a crashed machine,
possibly quite an inconsistent one depending on
what was writing to disk during the backup. This
is why people pay big bucks for professional
backup software.
regards
Graham
#include
#include
#include
#include
int main(int argc, char **argv) {
FILE *input, *output;
long long bytes = 0LL;
int c;
if (argc != 3) {
fprintf(stderr, "syntax: cp64 .\\C: D:\\backup.img\n");
exit(1);
}
input = fopen(argv[1], "rb");
if (input == NULL) {
fprintf(stderr, "cp64: cannot open input file %s - %s\n", argv[1],
strerror(errno));
exit(2);
}
output = fopen(argv[2], "wb");
if (output == NULL) {
fprintf(stderr, "cp64: cannot open output file %s - %s\n", argv[2],
strerror(errno));
exit(3);
}
for (;;) {
c = fgetc(input);
if (c == EOF) break;
if (ferror(input)) {
fprintf(stderr, "Could not read from input (at %lld bytes) - %s\n",
bytes, strerror(errno));
exit(4);
}
fputc(c, output);
if (ferror(output)) {
fprintf(stderr, "Could not write to output (at %lld bytes) - %s\n",
bytes, strerror(errno));
exit(5);
}
bytes += 1LL;
#ifdef TEST
if (bytes == 256LL) {
fprintf(stderr, "Not implemented - only first 256 bytes saved.\n");
exit(6);
}
#endif
}
fprintf(stderr, "%lld bytes transferred\n", bytes);
exit(0);
}
Re: Compilers make a system less secure?
> > But what if your system has no compiler? When attacker should compile his > > sploit anywhere, and transfer binary evil code onto your box. E.g. he has > to > > have access to the similar machine, maybe with similas OS version and arch. > > I know not having a compiler has been considered "secure systems > best practice" for a long, long time - but it comes from a distant > past when compilers for networked systems were expensive tools, I can keep quiet no longer :-) Here is the definitive answer to the question. This does indeed come from long ago, but not from any of the reasons yet stated. Back in the old days when the only access to a system was by a modem to a login prompt, and there was no networking available to make things easy, the only way to get a binary on to a machine was to somehow enter it from the keyboard (or equivalent, eg pulling it in via tip's ~ escapes) The thought was that if there was no way to compile a source file, and no way to say turn a hex file into binary (i.e. programs like uudecode were also removed) then it was impossible to create a working binary because you could not simply cat > file with binary characters. This sort of worked for a little while, until people worked out how to write executable programs consisting solely of printable ascii text :-) Although to be honest it was never much protection anyway, as there were several other workarounds you could easily find. It was also only useful in some very restricted environments where you were allowing people a shell but restricting them to specific turnkey commands. Some people also used it as a backup safety mechanism for completely captured environments, so that if they broke out and got a shell, they couldn't do anything with it. As you all know there are *far* better ways of doing this now, and indeed there probably were even at the time. But as someone who was there at the time, I can assure you that this is where the myth of not installing a compiler for security reasons came from. Graham
HOWTO on spamd+transparent bridge under OpenBSD
For anyone who is interested, I've written up a document on how to install OpenBSD, configure it as a transparent bridge, then install spamd on it. It was written primarily for our campus computer center who want to know how to do it if something happens to me (like I get a better job elsewhere for example ;-) ) but I think I've written it generally enough that it will be of use to anyone. The page is here: http://wiki.utpa.edu/InfoSec/GreyListingInstall?action=print regards Graham
Re: HOWTO on spamd+transparent bridge under OpenBSD
> You've got a couple of weird things and errors on your page: > - You say OpenBSD doesn't support multiple consoles: ctrl+alt+f2 Yup! Thanks. Linux uses ALT-Fkey which I tried. Didn't try adding CTRL. :-/ Assumed it didn't have it, and too busy getting everything else working to go look for it. I've now documented it. > - Using the 3.7 ports tree on 3.6 is not recommended. The only install disk I have is 3.6. I assume that by doing an install over the net, I get the 3.7 system - but some trace of 3.6 seems to have remained because some funny things happened later... > - tarring and untarring fake-i386 to install a port is just weird. > make install should already do that It didn't, it gave an error and did a fake install. It appears to be related to the 3.6/2.7 problem. Other packages installed cleanly. > - Why not install screen from a package like jove? I'd rather forget about packages and use ports for everything, but I thought it was worth mentioning for newbies like myself who spent hours looking for apt-get and yum and emerge etc etc - i.e coming from a linux environment... > - sh /etc/netstart bridge0 will fire up your new bridge without rebooting. Thanks, didn't know that. Actually I just found out that "ifconfig bridge0 create" was the crucial missing step I didn't know. > That's all I can think of at the moment. Apreciate it, thanks. G PS I'm marking all these comments up in he wiki as I reply. Two more emails pending from folks who sent similar corrections...
Re: HOWTO on spamd+transparent bridge under OpenBSD
steven mestdagh <[EMAIL PROTECTED]> wrote: > On Fri, Oct 14, 2005 at 03:11:59PM -0500, Graham Toal wrote: > > For anyone who is interested, I've written up a document on > > how to install OpenBSD, configure it as a transparent bridge, > > then install spamd on it. It was written primarily for our > > campus computer center who want to know how to do it if something > > happens to me (like I get a better job elsewhere for example ;-) ) > > but I think I've written it generally enough that it will be > > of use to anyone. > > > > The page is here: > > http://wiki.utpa.edu/InfoSec/GreyListingInstall?action=print > > Some quick feedback... > You write (allow me to turn off caps): > > > The disk formatting is a major pain. > > Why? I don't know why, I just know that both myself (experienced in BSD and BSDI from days gone by, and linux in recent years, but not OpenBSD at all) plus a colleague at work who has a fair bit of OpenBSD experience both have wasted literally days with formatting problems. So having found a working recipe that seems easy, I thought it was worth pointing out to folks that if you do something else, you might hit the hassles we did. I had tried to reuse an old partition table and failed even though it sure looked OK to me - the install program wouldn't progress past the formatting section; my friend had problems when he formatted the swap partition before the data partition. > > password for root acct? write it down, you'll need it later > > Writing down passwords, are you serious? To each his own :-) I generally find that if you create a 'strong' password, you pretty much have to write it down until you remember it. Then dispose of the note properly. But that's an argument for another forum. By the way I'm not alone in this heresy. At least one person whose opinions I respect agrees with me: http://www.schneier.com/blog/archives/2005/06/write_down_your.html > > OpenBSD doesn't appear to support multiple consoles using the F keys the > > way linux does. > > Try CTRL+ALT+F2/F3... it's in the FAQ. So I've been told :-/ Unless you know something is there to go look for it, you don't come across it (especially when all the searching you are doing is on pf and rdr etc :-) ) I've fixed the doc. > Also, I don't see the need for a ports tree on this type of system, > and your installation of the "screen" application looks horrible. Problem with 3.6 boot CD and 3.7 installation I think. The Jove ports install was smooth, but for some reason screen screamed. > Wouldn't it be better to skip the installation part, and point people to > the OpenBSD FAQ (especially faq4.html), and to the afterboot(8) manual page? No, but I'll certainly add those pointers. And it *is* a wiki page. If you feel that what I've said is just plain wrong or misleading, please feel free to go in there yourself and correct it. Just bear in mind it was written by someone who needed to use OpenBSD to support a specific tool and who before this had no OpenBSD experience, for an audience who are in the same boat. It's definitely not a proper guide, it's a "How I managed to make it work after two weeks of struggling, so that hopefully you can make it work in two hours of slavishly typing exactly what I say" :-) > When you copy over pf.conf, do you set its owner/permissions correctly? > Anyway, /etc/security will let you know if you didn't. :) Good point. I guess I was lucky that the defaults worked OK. G
Re: Limiting Shell Access Damage (was Guruness)
> Turning this into a learning experience: Does anyone have any hints or > advice about hardening OpenBSD for shell accounts. Do people tweak > things other than the login.conf settings? I have to deal with student > shell accounts where students are learning to program and often create > problems by accident. (Firsly, not mentioning restricted shells at all, because we all hate them, right? rksh? ) Back in the old days before umls or half a dozen other equally appropriate technologies which I would use in preference if I were doing it again today, I used to build a chroot environment with a minimal subset of commands and relevant data files for just this sort of thing. If y'all promise not to laugh, I found this code in my archives that I wrote in 1993. http://www.gtoal.com/historical/tcsh.c Obviously the layout of the filesystem will have changed over the years, but maybe there's something in there that's still salvagable. No, it's not hackproof, and I certainly would not write something like this nowadays, but the main reason I used this a dozen years ago was not to stop advanced hackers but to stop careless naive users (our customers, actually) doing something dangerous by accident, and to stop casual guest account visitors from browsing around the filesystem gratuitously. If you go the chroot route: this is from the linux world but probably adaptable: http://fakechroot.alioth.debian.org/ Also equally amusing in a historical sense is lsh.c in the same directory. Again, better ways exist to do that now (watch/ttysnoop). As well as full virtualization, you might look at copy-on-write filing systems to allow users to unwind mistakes. Nowadays I would use user mode linux or colinux to create a lightweight virtual machine and let them manage it completely, using c-o-ws as a quick way to revert if they screw it up. I don't what what the BSD equivalent of uml might be. A quick google search for 'virtual server bsd' shows that they do exist (http://www.esosoft.com/virtualserver/), at least for FreeBSD. If there's no specific OpenBSD lightweight virtualization then maybe you could use a more heavyweight emulation such as qemu (http://www.erikveen.dds.nl/qemupuppy/index.html) or plex86 (http://sourceforge.net/projects/plex86) or xen (http://www.xensource.com/, http://www.cl.cam.ac.uk/Research/SRG/netos/xen/) or vserver (http://www.solucorp.qc.ca/miscprj/s_context.hc) or many commercial products: virtualpc/vmware/openvz/serenity(svista)/ virtuozzo/parallels (microsoft, serenity and parallels have all had beta programs that allowed you to use their latest development products for an extended period, as opposed to the few weeks you usually get from a mere eval download. Of those I think parallels.com is the only one currently available) There's a pile of links on various subjects related to virtualization in my online bookmarks: http://www.gtoal.com/bookmarks/Computer_stuff/Virtual_PC/index.php (+ some misfiled under http://www.gtoal.com/bookmarks/Virtual_PC/index.php) and a lesser amount of relevant links in http://www.gtoal.com/bookmarks/Computer_stuff/Unix/index.php and http://www.gtoal.com/bookmarks/Computer_stuff/Security_backup_and_admin/index.php Another option is a live cd: http://www.freesbie.org/ or http://www.livebsd.com/ ... Maybe you'll find something of interest in there. If not, reading other people's bookmarks is almost as much fun as looking at their bookshelves :-) regards Graham
Re: spamd extension
> My experience is that greylisting requires at least 2 failed attempts. > Maybe my pf.conf isn't setup properly. But, there's always 1 'extra' failure > that seems to me should pass through. James is right, it's a design flaw of spamd that two failed attempts are required. This is what happens: 1) first attempt, goes to spamd, is logged. 2) second attempt, goes to spamd, is marked as good ... *BUT* it still went to spamd. spamd is not an application relay, so it has no way of passing that currently-active second attempt through to the true MTA, so ... 3) third attempt, redirected to true MTA The only fix for this is a *major* redesign of spamd (or equivalently incorporating spamd's greylisting code into a spamfilter which *does* relay connections at the IP level to an MTA - which is actually what I'm working on at the moment) One of the pre-requisites (in my opinion) for a filter which relays connections (rather than routing them through) is full transparency, i.e. the MTA sees the IP of the original caller, not the IP of the relay. This is so that the MTA continues to do third-party relay rejection and does not require you to duplicate that logic in your relay host. Fortunately for us, OpenBSD+pf have exactly the facilities needed to transparently forward at the TCP/IP session level, albeit not a common or easy thing to do. Graham
know any neat tricks for 2 * dhclient?
I wanted to set up a system which has two ether cards (it's part of a transparent bridge so it'll be inline with someone's connection) such that it'll pick up a DHCP address on *both* cards ... the trick comes from not knowing in advance whether the DHCP server will be on the inside connection or the net-facing one. (i.e. if the bridge is deployed near the network edge, the DHCP server is inside; but if it is deployed immediately in front of a single server, then it will see DHCP facing outwards). It *ought* to be possible to configure both hostname.xl0 and hostname.fxp1 as dhcp, and whichever one comes up first, will then bridge through the DHCP server for the other. Unfortunately it just happens by luck of alphabetical order, that the one which comes up first is *not* looking at a DHCP server. So after a relatively short period of retries it goes to sleep. Then the other interface asks for its dhcp address and gets it quickly. What I expected was that the first would sleep for a short time then ask again, and get it OK. I haven't seen that happen - about 30 minutes later and the interface still has no IP. What's the best way to ensure that they both get IPs as quickly as possible? I can think of some dirty hacks, but I don't like the solutions I've come up with. (For example, if I kick off the dhcp client requests in the background, that interferes with the rest of the boot sequence). Has anyone had this configuration before and come up with an elegant solution? thanks Graham
Re: know any neat tricks for 2 * dhclient?
> I use a bridge and assign the IP to one NIC, albeit statically assigned, > on several "production" OpenBSD 3.5 systems. If I ever switched the IP to > the Other NIC, I would lose connectivity until the ARP tables on the > various LAN hosts updated with the new MAC address. Maybe about 10 minutes > if I recall. I don't recall what the times are for ARP table refreshes > average. I'm not talking about switching the IPs, I want a different one on each interface, both assigned from the local DHCP space. > Agreeing with what another individual said regarding this post, it's a > transparent bridge, so that IP living on multiple NICs is a really moot > point. I would venture to guess that the kernel gets really annoyed having > to track an address on two different NICs with or without a bridge in > place. As I said, not the same IP on multiple NICs, different IPs on each NIC. G
Re: know any neat tricks for 2 * dhclient?
> Maybe I'm not understanding the problem, but for a tranparent bridge, you > wouldn't want it to be assigned an IP address on either network card. hence > the "transparent" part. You would think so, but you would be wrong. As I was when I started this project. In OpenBSD a bridge must either have no interfaces with IPs or both interfaces with IPs. You need to put an IP on it when you are generating traffic from the bridge, specifically if you are filtering traffic going through it at the tcp session level. So you're right that you don't need or want IPs if you are just bridging and not touching the traffic (except maybe to block something with a pf firewall rule) but wrong if what you are building is a transparent filter (or cache, such as squid) like a spam filter or a virus filter that intercepts web pages. Here's the definitive word on it: http://marc.theaimsgroup.com/?l=openbsd-misc&m=101814255119388 By the way, by 'transparent filtering' I specifically mean that the server sees the IP of the client in incoming requests, and the client sees the IP of the server on replies. There is a half-assed version of this that is sometimes implemented where the client does see the server IP, but the server sees the call as coming from the man in the middle. For my purposes I need both sides of the conversation to be equally transparent. (That part I've more or less worked out how to do, and am in the process of cleaning up the proof of concept code right now) Now that we've cleared that up, got any ideas on how to use dhclient to pick up IP addresses for both interfaces, when only one of them faces the dhcp server and the other one happens to execute first? The solution should work in any installation and not require local knowlege (because the whole point of doing this as a transparent filter is to turn the spam filter into an appliance that can be plugged in and just work, no config necessary. Like a commercial spam appliance, except free ;-) ) Graham
Re: spamd extension
> >The only fix for this is a *major* redesign of spamd (or equivalently > >incorporating spamd's greylisting code into a spamfilter which *does* > >relay connections at the IP level to an MTA - which is actually what I'm > >working on at the moment) > Why start from scratch ? There are enough seasoned, full featured MTA's > around that will allow you to incorparate greylisting. And you get all > the other stuff like STARTTLS, AUTH etc gratis. > > I'd either accept spamd's few limitiations or incorparate greylisting > into a MTA. > > Just my thoughts. There *are* several greylisting implementations using MTAs if that is what you want. The attractive feature of spamd+openbsd/pf is that it is MTA-agnostic. After it does its thing it simply routes your connection through to the real MTA at the IP level. Anyway, it's not starting from scratch for me - I have a mature pseudo-transparent SMTP filter that works well and has been in service for over a year - it's just that I have not publicised it much because in its current form it requires configuration, such as telling it what domains you accept mail for, which IPs are local, etc. I needed to learn about transparent bridging first and recode the I/O so that the filtering is not visible at the IP level. Which I now have, mostly. My filter uses spamassassin plus spamprobe plus uvscan plus clamav, with some automatic detection of spamtrap addresses thrown in. I haven't yet added greylisting to it, and indeed our deployment at the University where I work has an openbsd running spamd sitting in front of my filter sitting in front of the real MTA! By incorporating the logic from spamd into my code, I can remove one piece of hardware. And improve spamd while I'm at it, because with thi sarchitecture I can forward that second connection attempt to the MTA, and avoid having two delays rather than one. Graham
Re: spamd extension
> On 10/26/05, James Harless <[EMAIL PROTECTED]> wrote: > > Chad, > > > > I appreciate the insight. I do realize it's a difficult problem but, > > I think that there's a solution (albeit possibly from someone smarter > > than I). > > Nope there's just not. There is, but not with spamd as currently implemented. The fix would involve this: 1) accept the connection, remember the target IP 2) go through the rcpt from/mail to protocol, and when you have the information, check it in your whitelist. If it is present, open a connection with the original target, repeat the rcpt/mail exchange (not forgetting the HELO) and then sit back and transparently proxy the rest of the connection. It's doable, it's just not easy. That plus a lot more is what the filter I was talking about in the other thread does; maybe if it's not too difficult, I'll do a shorter version which doesn't have the majority of my code, but just adds the logic above to spamd, if there's any interest? It does require spamd to be running in a transparent bridge. *NOT* a NAT gateway, which is the most common configuration. By the way, the other improvement I'd make in spamd if I had my druthers, is that it would have the option of accepting the initial email and returning the tempfail code at the end of the data exchange rather than before it as it currently does. This would allow proper QA on the rejected mails. You'ld need to create a signature of an email and when the mail went through successfully on the second attempt, locate the original copy using the signature and remove it from the cache; mails which never retried would remain in the cache, and would be swept after an appropriate time out, giving you a good record of rejected mails. You could either use this info to generate stats, or you could run the mails through a traditional spam filter as a consistency check, to try to detect genuine connections that had been inadvertently blocked. Or if you're sure all the rejects were genuinely spam, you could feed the saved copies into spam filter training, or to a cooperative net project like Vipul. Lots of scope there for new features. Graham
Re: know any neat tricks for 2 * dhclient?
> It *ought* to be possible to configure both hostname.xl0 and hostname.fxp1 > as dhcp, and whichever one comes up first, will then bridge through the > DHCP server for the other. Unfortunately it just happens by luck of > alphabetical order, that the one which comes up first is *not* looking > at a DHCP server. So after a relatively short period of retries it > goes to sleep. Then the other interface asks for its dhcp address and > gets it quickly. What I expected was that the first would sleep for a > short time then ask again, and get it OK. I haven't seen that happen - > about 30 minutes later and the interface still has no IP. I was thinking when I posted this that the problem was that the interfaces picked up IP addresses in the wrong order. That would be true if we were routing from one to the other, but in fact I've just realised that the real problem is that the interfaces are brought up *before the bridging is turned on*. So naturally only one of them will be facing a DHCP server. The other one should only get its IP address *after* the bridging is enabled. It never does. I think the problem may be a misunderstanding of dhclient. Why is it not retrying? The man page doesn't give any clues. It *is* still running, as can be seen from ps. I'm not accidentally blocking it with pf as my pf.conf allows everything from anywhere to anywhere! Do I have to do something special to make dhclient wake up? (Yes, I know I can manually kill it and re-issue the command, and I can even automate it by writing a script to grep ifconfig -A, find the interface that has no IP, look for the dhclient for that interface, kill it and restart it - but as I said I'm looking for a guru-level elegant solution, not a crude hack...) Or might this be one of these bridging problems where the packets are going out on the wrong interface...? (thinking aloud as I type here...) OK, I'll go do some tcpdumping. Assuming that the problem turns out to be that the dhcp request for fxp1 is always routed out of fxp1 (makes sense, right?) what can I do to have it routed out the other interface via bridging? (Remembering that the solution has to work symmetrically, if in some other deployment it is the other of the two interfaces which can't see the DHCP server...) thanks Graham
Re: know any neat tricks for 2 * dhclient?
> Assuming that the problem turns out to be that the dhcp request for > fxp1 is always routed out of fxp1 (makes sense, right?) what can I do > to have it routed out the other interface via bridging? (Remembering > that the solution has to work symmetrically, if in some other deployment > it is the other of the two interfaces which can't see the DHCP server...) Confirmed that this is the problem. Two ways: 1) I changed /etc/netstart to bring up the bridge before it configures the interfaces. Dirty, but it works - and the internal interface still didn't manage to talk to the dhcp server; and 2) I manually killed the dhclient process for fxp1 once everything was running smoothly from a clean boot, and manually started "dhclient -d fxp1" - and again, it did not talk to the dhcp server even though the bridge was already running by that point for sure.. I could force the traffic from one interface to the other with pf and a route-to option, but only if I know which interface the dhcp server is connected to. Since I cannot make that assumption (it depends on where in the network the bridge is inserted) I can't see a solution. Well, short of some really hacky code to scan the output of ifconfig -A, and rewrite a new version of pf.conf on the fly. Can anyone think of some ingenious rule for pf that will get me what I need? This is the last significant stumbling block in a long project to build a completely idiot-proof spam filter that works just like a commercial appliance - plug it in and use it, no config necessary. (Actually the *last* stumbling block will be a completely idiot-proof installer - or a live CD - but I'll cross that bridge when I come to it. No pun intended.) Graham
Re: know any neat tricks for 2 * dhclient?
> From: Kevin Frand <[EMAIL PROTECTED]> > > Why not start the system with one interface down (so you know which way > to route to) then "up" it at the end of the boot sequence and start the > dhclient? Because DHCP isn't a routable protocol, so knowing that information doesn't help. (Although you've given me a thought - maybe I could run dhcprelay between each interface...) G
Re: know any neat tricks for 2 * dhclient?
> > What I expected was that the first would sleep for a > > short time then ask again, and get it OK. I haven't seen that happen - > > about 30 minutes later and the interface still has no IP. > > [This goes vastly OT, I know:] > > I am blank astonished that it seems to be impossible to get two > independent NICs picking up their IPs from different networks; or even the > same network, that is. > What is wrong in my understanding, that if I plug 7 NICs and connect them > (or do not connect them) to a DHCP server, that all of them independently > try to get an IP ? They're not both connected to a DHCP server. The DHCP server is only connected to one of the NICs. Nevertheless I want both NICs to get an IP from that DHCP server. I thought I could do it because they were bridged NICs. I was wrong. Graham
Re: know any neat tricks for 2 * dhclient?
(description of why it can't work deleted for brevity) > Now, your "bridge" should bridge this dhcp-packet from one interface to the > other? That doesn't work: its sending this packet out through that > interface, it can't send it out on all other interfaces. So there's no solution? I see now that the packet flow doesn't support it, but logically it does make sense to want an IP from that DHCP server to be given to the other interface, after all any systems hanging off that interface *will* get an address from the DHCP server on the other side of the bridge, so why shouldn't I? There has to be some way around it? Some pf re-routing trick? Is dhrelay/dhcprelay my only option? Graham
Re: know any neat tricks for 2 * dhclient?
> I'm still confused. > > Why do you need to succed in getting a DHCP address for _both_ interfaces? > Wouldn't it be OK if jsut the one that hapened to face the DHCP server came > up? This would still give you remote access. I can get away with DHCP on one side only, but having actually tried this (at length) it looks like the 'real' address has to be on the same side as the target server in order to make the NAT work when faking the source address of the client. I.e. it is determined by the client/server relationship and which interfaces the client and the server talk to me via. Unfortunately the interface which gets the address from DHCP can be on *either* the client *or* the server side. This is because a filtering appliance like this can either be placed at the edge of your network (in which case the DHCP server is on the inside, same interface as your target server, in my case a mail server) - or it can be placed immediately in front of that server only, in which case the DHCP server will be on the *outside*, same interface as the clients. Therefore to allow for either of these deployments, its safer if I just get a DHCP address for both sides, from whichever side the DHCP server happens to be on. So... if the specific deployment happens to have the DHCP server on the same interface as the target server whose traffic is being filtered, then what you suggest above will work OK. But if they're on different interfaces, it won't. I've tried it. One administrative solution would be to tell people to only place the filter on the edge, with the DHCP always inside. However my own experience here with our own computer center is that they're pretty reluctant to run all the campus traffic through one device just to add some mail functionality. Whereas placing it in front of the mailer is not such a big deal. (Also cheaper in terms of supporting the bandwidth - campus edge: 45Mbit - mailer: 1 Mbit) I really wonder how these transparent commercial anti-spam appliances do it. If you think it is tough under OpenBSD/pf, it's next to impossible under Linux. What trick have they worked out thay I'm missing? Or are they just not as transparent/config free as I am assuming they need to be? Graham
Re: know any neat tricks for 2 * dhclient?
> i am confused as to why anyone would want to make a setup like > this, unless they were being shady. if you are going to be Yeah, it does make a perfect man-in-the-middle attack kit I must admit, but no, that's not what I'm working on :-) > installing a transparent filter/proxy/etc., shouldn't you have > enough control over the networking environment to work around > the DHCP problems? Nope. This is to be used in a spamfilter, which can be pre-configured and given to someone to install at their site, with the only requirement being that they get the ethernet wires in the right sockets. (And even that I can probably work around with a bit of hackery) > it seems to me that working on the setup as it is currently > posited is a poor time investment. i would think harder about > how to change other things to work around this issue. unless, > of course, you were being shady ;). I've already thought hard about it. I got the spam filter part working over a year ago, but for the target users (high-schools, colleges, and universities plus any other govt-funded organisations in Texas - and anyone else that wants it) anything that is as complex to configure as the system currently is, is a non-starter. It has to be idiot proof and basically just an appliance like a commercial one. When you buy a linksys router for your home cable, you don't have to edit header files and recompile (or even just tweak params in a GUI) - you just plug it in and use it. That's what I need to make in order to get wide distribution of this thing. Hence the requirement for true transparency. If you don't have that (i.e. your MTA sees connections as coming from your spam filter appliance) then it will treat *all* incoming mail as either internal or external depending on where your appliance sits - rather than being able to determine internal addresses from external ones by looking at the incoming IP. For something like an FTP proxy or a transparent squid cache, this is not so much of an issue, but for email where you have to reject third-party spams while allowing local users to mail successfully, it's a requirement. (The other requirements are that it is MTA-agnostic, as the users could have any mailer and it will undoubtedly be one that they can't tweak because they have no source code; and that it does *not* store-and-forward, because that brings in a whole new set of data management issues that I'm not willing to handle. It has to pass connections through to the target MTA in real time.) Graham
Re: spamd extension
> From: Hannah Schroeter <[EMAIL PROTECTED]> > And there's no mailout pool with shared queue involved, and if the > envelope sender address is always the same (i.e. no VERP, no SES, > no self-signed SRS, no SRS-enabled forwards, etc.). Surprisingly few. > >problem? During the initial weeks of using spamd on my server, half of the > >complaints about undelivered email were not the fault of spamd. > > So the other half *was* the fault of spamd? Oh, you floccinaucinihilipilificatrix, you! The very paranoid among us will read the disclaimers involved in greylisting and never get round to implementing it. The braver souls will just do it and see what happens. It turns out that it is an *extremely* valuable tool - far more so than simple content filters, no matter how good they are - and it is well worth having. And I say that as someone who started off at the paranoid end of the spectrum and who implemented greylisting a lot sooner than planned solely because a new CIO had used it at his previous site and insisted we put it up. Yes, there are a few teething troubles, but they mostly get taken care of in the first month where you're monitoring everything closely anyway. There were only two systematic problems we had: 1) some sites issue an RSET, before the RSET code was in spamd. 2) People using older installations of Cisco PIX firewalls had SMTP masking enabled (visible by connecting to their server and seeing stars (***) where text should be.) Asking them to turn off this useless and broken misfeature fixed the problem, or if they weren't willing to do that, have them mask only incoming connections, not outgoing ones. At our University we have some very demanding faculty with a low tolerance for email glitches. Despite this the greylisting not only went without complaints, it has generated more praise for the IT dept than any other measure in the last year (which is probably a bit galling to the guys working on the hard stuff ;-) ) My advice, just do it. Graham
Re: OpenBSD is popular as a VM image
> Just an update on the popularity of the OpenBSD 3.8 VM image: > Since it was posted on Dec 19 (4 days ago), apache logs have shown 2826 > hits on the file with just over 277 gigs of traffic created by those > downloads. > Not bad for only a few days. I hope this isn't too OT for this list, but... do you know if it is possible under VMWare to have the virtual system be the only one which talks to the real ether card, while having the hosted PC only communicate to the net by routing via the VM'd system? What I'm thinking is that we could set up an OpenBSD as a personal firewall to a (cough, spit) Windows machine, and channel all the IP for the Windows machine through that VM'd OpenBSD system. Currently I'm using an extra box under my desk for a BSD firewall but since my main PC is already running 3 emulated systems as my development environment (one 'clean' PC for programming, one Linux for a dev web server, and believe it or not one emulated Vax/VMS for legacy work) it would be really nice to throw the OBSD firewall under VMware as well and have everything in one box! (incidentally this is one of the nicest development environments I've had for some time. VMware is cool, but having a PC with 3 flat panel displays is pretty nice too!) Graham
Re: OpenBSD VMWare image too popular
If it's that popular it's worth setting up a torrent! G
Re: uuencode
uuencode test.txt < test.txt The parameter is not the file name, it's what is written after the begin (ie the ouyput file name) G
Re: Backup MX server
Although I know where David is coming from with this slightly contentious comment, he's wrong. The argument is that most senders will do their own back-off, and the hassle of setting up a *good* backup MX server is so high that the benefit scarcely justifies it. However where he is wrong is not in the senders who don't resend (they're just broken anyway) or in the local clients who are sending outgoing mail via your server (bad idea anyway), but in clients who back off *for a long time* when they think you're down. In other words a backup MX lets you recover more quickly and more gracefully than not having one. Also critical is backup DNS. Let's assume we're looking at a disaster here, a long-term (5 day?) outage rather than a failed UPS. If your DNS is on the same net as the mailer, its down too. Senders soon get no result at all when they look you up, with the result that mail *bounces* (unknown address) rather than requeues. So set up a backup DNS even if you don't have a backup MX. Also for a major disaster, you probably don't want to continue secondarying your main (locally hosted) zone file. You may even want to replace the zone file on the backup MX host with a different one pointing to different servers, so you can have a web presence and maybe even some way of accessing your mail. In this case make sure you have a pre-prepared primary zone file that you can run on your backup DNS host, and have a protocol (i.e. a human protocol, phone no's and a password) so you can tell the remote person that it is time to switch from being a secondary DNS server to being a primary. You might even have your disaster site always running in preparation, just with no DNS normally pointing to it. (I do, and I'm not telling you the address ;-) ) In the event of a truly major disaster, with no telephones even, leave explicit instructions with this remote person on what circmstances they can kick in your backup DNS automatically, eg there is a national emergency reported on TV and your site has not been reachable for days. Personally I do believe in Backup MX, as long as it does proper relay checking. It's nice if it also does spam checking, but not critical because your primary MX will still do that. However if you do spam checking *and rejection* on your backup MX, you'll significantly lower the load on the primary when it returns. Note that 5 days of pent-up mail arriving at once can kill a machine even if it is normally up to the peak loads you get, so you want a throttling control both on what the backup MX forwards to you when you return, and what you accept from other sources when you return. Graham
Re: Backup MX server
> NO - it does not! Well, not unless the sending MTA is broken. To quote > from Postfix documentation referring to not getting an MX record from > DNS: > " By default, the Postfix SMTP client defers delivery and tries again > after some delay. This behavior is required by the SMTP standard." Yes it does. I've run an ISP with about 3000 accounts and currently manage the spam filter and virus filter for the campus here with about 20,000 accounts, so I have had plenty of opportunity to see this happen. There are many broken clients and MTAs out there. G
Re: Backup MX server
> $ host -t mx stonehenge.com > stonehenge.com mail is handled by 666 spamtrap.stonehenge.com. > stonehenge.com mail is handled by 5 blue.stonehenge.com. > > Any mail delivered to spamtrap gets the following response: > > 450 Violation of RFC2821 Section 5 Paragraph 8 correlates highly with > spamming and is therefore rejected. > > And yes, that's the paragraph that says "deliver to lowest MX first". > > I'm skipping about *half* of the incoming spam just with this one trick. For > more details, find the PDF I wrote titled "you had me at HELO" via google. Ouch! You're a brave one. That's fine until your first big network outage :-) Oh wait - I bet they're both on the same net segment, right? You wouldn't dare do that with a machine elsewhere on the net! I might use the fact that mail had been delivered to a backup MX as *one* factor in a spam evaluation function but rejecting it all entirely is pretty risky. I think you've just been lucky so far. Doesn't your main machine ever reject calls because the load average is too high, for example? I bet you're not running greylisting either. If you were, legitimate mail would frequently try your backup MX. It's a neat observation that several of us have made, and it is tempting to find a way to take advantage of it, but I think that rejecting *everything* that arrives on your lowest-valued MX is just going too far! Graham
