equivalent of Linux mount -o bind
So I'm curious if there's something in OpenBSD that's similar to the mount -o bind /dir1 /dir2 to make dir1 appear where dir2 is. I seem to recall a mount_nullfs but don't see it in the latest OpenBSD. Please note that I'm not trying to start a flame war, so there's no need to make Linux comments. BTW, the vnconfig manpage should probably indicate that the image need not be a file, you can use a slice/partition too.
otherOS is to daemontools as openbsd is to ?
Just curious, I recall hearing there was a clone of daemontools for OpenBSD, what was it called? TIA -- Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Re: otherOS is to daemontools as openbsd is to ?
On 2/26/06, vladimir plotnikov [EMAIL PROTECTED] wrote: Take look on FAQ pages: http://www.openbsd.org/faq/faq14.html#MountImage Eh? Disk setup? Anyway, I found 'em, they're called freedt In /usr/ports/sysutils/freedt Thanks anyways -- Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
vpn1401 not probing
Hey, The soekris site says the vpn1401 is fully supported in the latest release of OpenBSD. However, mine isn't autoprobing. What do I need to do to get it working? -- Cryptography is nothing more than a mathematical framework for discussing various paranoid delusions. -- Don Alvarez http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
SCSI HBA support questions
Can anyone confirm that an Adaptec AHA-1542 works with anything since 3.6? I found that support for it was silently broken sometime in 3.x, even though it's listed as supported hardware for x86. Also, I have 3 PCI Bustek adapters (BT-958D, BT-958, BT-946C) in a different machine, but booting up the 3.5 or 3.6 install disks hangs during autoprobe. So does NetBSD 2.x, although strangely NetBSD 1.6.2 is running on it just fine. I only bring this up because this may give some clue as to when the code for these cards stopped working (it is my impression that some code gets shared between the two, although I do not know exactly how or in what direction). Also, there's another compute, a Compaq PPro server, with a dual integrated Adaptec AIC-7xxx controller, but I got various SCSI errors trying to install on it. I have details at home and can post them if necessary. I like BSD, but it's really picky about hardware sometimes, and I've been forced to install Linux instead on more than one occasion because BSDs simply wouldn't boot. -- http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Migration to PF - some questions
In pf nat rules also the first match wins __but__ in pf filter rules the __last__ match wins. In fact that is the one thing I don't like in pf, but to have a first match win you can use the magic word quick in all your pass and block rules. (e.g pass in quick) And thereby end up with yards of quick rules that can catch you later. Ah, but the matching engine doesn't have to traverse the whole rule list that way. Unless pf is doing something really tricky, every packet will have to traverse every firewall rule without use of quicks. On a complicated, busy firewall setup, this might have a noticable performance impact. You should think of it this way: Default security is best with block everything and then pass what selected few things you need. So: block all pass in on $int_if from $safe1 to $ok2 keep state pass in on $ext_if from any to $ext_if port ssh keep state I agree, with the added use of quick on each of the pass rules. In fact, you can probably use quick on virtually every rule other than that default without any loss of expressiveness. Thanks to negations, having two different precedences is largely unnecessary (previously you'd have to pass nonquick for some set of packets, then block again for some subset to get the same effect as a negation). It's probably not necessary, and I may offend purists by my performance optimizations, but I actually have this as my first rule: pass quick on lo0 I also find it useful to use the following rule right after default deny: block return on $lan_if I do have some questions about pf though. How come you can only modify source IP/ports outbound, and destination IP/ports inbound? Why not the other two alternatives? I also don't see why NAT should necessarily occur before the filtering rules. It makes more sense to my intuition to have the order in the pf.conf control the order of operations, but I admit implementation issues may make this less elegant. Also, I find supporting $macros in pf.conf a little crufty. Why not just do something like this: #! /bin/sh lan_if=xl1 wan_if=ex0 pfctl -f /dev/stdin EOM pass quick on lo0 block all pass quick in on $lan_if all keep state pass in quick on $wan_if from any to $wan_if proto tcp port = 22 keep state [...] EOM That way, you have the full expressive power of the shell, including command substitution, arithmetic substitution, variable substitution, trimming suffixes and prefixes, and all kinds of shell magic. It doesn't replace lists or tables of course. But you can easily do conditional inclusion of rules, and that's useful for cases like DHCP. The interface comes up with IP 0.0.0.0/0, which I think means it will accept any packet as destined for this interface, no matter what the destination IP. I only allow in replies from my ISP's DHCP server during this stage, and only those destined to 255.255.255.255 (I don't want rogue servers answering my DHCP requests, which are sent via local broadcast (hence to all my neighbors). It was also pretty useful before things supported the (interface) notation for looking up IP addresses each time. That having been said, pf is way cool. Keep up the good work. -- http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: Migration to PF - some questions
huh? Before any rules are evaluated, the filter checks whether the packet matches any state. If it does, the packet is passed without evaluation of any rules. - pf.conf(5) Yeah, I neglected stateful matching. I should have said that every packet that has to run the gauntlet of rules, has to run all of them. Subsequent reading of the PF FAQ confirms that there's no deep evaluation-reordering magic going on, that quick rules really are faster. -- http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: pf, dfd_keeper, and dynamic firewalls
And we should have to google, why? I can't be bothered if the author can't be bothered to get his own URL correct. I was typing it by hand from a system which had blocked my homepage's IP (don't ask me why, I dunno). Momentary lapse of reason. Nice to see that OpenBSD's culture hasn't changed much. You could also look at my .sig... -- http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Re: pf, dfd_keeper, and dynamic firewalls
So what is the default? It is 022 on all my machines and I have never screwed with it and as a result pkg_add works just fine. I set mine to 077 in .profile. Untidy things like that make me wary of code from the same source... Well, if you think having a paranoid root umask is a bad thing for a security guy, and never having thought about it or messed with it is a good thing, rock on with your bad self. Of course, not thinking about the various contingencies does lead to a much tidier document. And that's what's important, right? Being wary is good. I encourage any potential user to look over the ~1000 lines of python code, as it is quite readable (and browsable online) and it makes for better bug reports. HAND. -- http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
pf, dfd_keeper, and dynamic firewalls
Hey, Just letting people know that a dynamic firewall daemon, (sort of a command shell for the firewall), is available for OpenBSD pf. It's called dfd_keeper, and I'm looking for ideas, suggestions, developers, and testers. You can find it here: http://www.lightconsulting.com/dfd/dfd_keeper/ I'd like to evolve from this into a more complete system. For example: I'd like to integrate it with snort, honeypots, and maybe snortsam. I'd like to have a pcap-based sniffer that invokes commands not related to security incidents... for example active-mode FTP, IRC DCC, talk, p2p applications, etc. I'd like to have a pcap-reading library written in a buffer-safe language that does several things: 1) Decode IPs and TCP/UDP ports, generating top 100 probed ports, top 100 blocking rules, etc. over various time periods. 2) Port scan detector, see: http://www.cipherdyne.com/psad/ 3) Statistics for optimization of rules 4) Port knocking, see: http://www.cipherdyne.org/fwknop/ 5) Abuse of network resources (spam, worms, scanning by internal hosts, arp flooding, bandwidth cap overflow, etc.) I'd like to have a web interface which displays: 1) All of the info from the pcap program above 2) The OS fingerprint history of various IPs 3) ifgraph/smokeping output 4) statistics gathered from arpwatch (MAC history of an IP, IP history of a MAC, c.) 5) Fancy visualizations of the multi-dimensional stastitical information that firewall logs contain: 5a) graphviz 5b) LGL, http://bioinformatics.icmb.utexas.edu/lgl/ 5c) volsuite 5d) OpenQVIS I'd like to have a web interface for toggling/setting firewall rules. Specifically, on/off commands would have a checkbox, multi-mode commands radio buttons, the list-based commands have an add text entry field, etc. I'd like to protect the traffic to dfd_keeper with cryptography. I'd like to implement a coherent system of authorization, so that certain hosts/programs/users could access some commands, but not others. Currently the model is all or nothing. I'd like to add persistence to dfd_keeper so that blocked hosts stay blocked. This will involve some re-structuring due to limitations of python pickling code. I'd like to write an expect script that can shut ports off on managed switches. Combined with the abuse of resources detector above, this means no more manually handling worm invasions! Could also implement this with arp spoofing, if not patented by Mirage Networks. All these cooperating packages might be easiest to configure with some custom afterinstall scripts or maybe even a Live! CD distro for an instant firewall appliance. If you are interested in any of these topics, or have suggestions, please email me and ask to be added to my email list. -- http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
the pf-based dynamic firewall daemon dfd_keeper now available
Hi, I've spent a fair amount of time minimizing open ports and I have a cool new program for other people allergic to unnecessary open ports. The basic idea is called a dynamic firewall daemon, that provides a command-line like interface which can execute carefully controlled modification to your firewall rules on the fly. It has boatloads of applications, like creating firewall rules that expire after a certain period of time, creating fixed-length queues of shunned IP addresses, automatic blocking of IPs that are the source of NIDS alerts, a way to implement port-knocking, temporary enabling of bittorrent ports, extreme islanding in case of a severe intrusion, and lots of other applications. This specific implementation is called dfd_keeper, named after the bridge keeper in The Holy Grail. As the origin of the name might suggest, it is written in python and making use of the twisted asynchronous I/O library. I have put a lot of effort into making it elegant and readable. This is not a one-trick pony. It is a programmatic interface and control of the packet filter from userland. Just for a quick demonstration of how to use dfd_keeper, I have created a script called keeper_example. This sets up a fully functional but somewhat minimal firewall that performs NAT. You will notice that all of the PF-related rules are written in pf.conf syntax - nothing new to learn! I think that anyone of moderate intelligence can use/modify it, even if they are completely ignorant of python. It also defines a few commands, like being able to block a specific IP address. It has an online help command that makes extensive use of python introspection, keeping the documentation with the implementation. You can command dfd_keeper merely using netcat or telnet. There may be cause for a twisted-based web front end as well. Just to anticipate a complaint, there is no authentication in this server beyond what you configure with the pf rules themselves. For me, this is good enough, but I may implement some kind of auth layer above it at a later time. I want to solve the problems correctly. For example, I don't want reusable passwords that will have to be embedded in any other program that wants to make use of dfd commands. For now, if you want authentication, use ssh tunnelling or IPSec. Comments, suggestions, volunteers, code submissions welcome. Justification, explanation, example, browsable code and tarballs here: http://www.lightconsulting.com/~travis/dfd/
