power failure resistance
Hi, I need to deploy a number of openbsd firewalls based on alix2d13 hardware. The goal is to separate industrial network from LAN, in order to protect unpatched systems on industrial network from potential malware on LAN, while providing some level of access (mostly low-traffic VNC from LAN to industrial and sql in the opposite direction). The problem is that we have very unstable power grid, resulting in unclean shutdnowns of devices. I cannot UPS them all. How can I configure firewalls so they are resistant to those power failures (ie do not need fsck)? How should I partition? Which partitions should be mount read-only? Which should be mount as memory disks? Which size shoud I allocate for memory disks (RAM is a constraint here as I have only 256Mb)? Any other advices? Thank you in advance, -- Marko Cupać
Re: power failure resistance
On Wed, Feb 19, 2014 at 12:38:53PM +0100, Marko Cupa�? wrote: Hi, I need to deploy a number of openbsd firewalls based on alix2d13 hardware. The goal is to separate industrial network from LAN, in order to protect unpatched systems on industrial network from potential malware on LAN, while providing some level of access (mostly low-traffic VNC from LAN to industrial and sql in the opposite direction). The problem is that we have very unstable power grid, resulting in unclean shutdnowns of devices. I cannot UPS them all. How can I configure firewalls so they are resistant to those power failures (ie do not need fsck)? How should I partition? Which partitions should be mount read-only? Which should be mount as memory disks? Which size shoud I allocate for memory disks (RAM is a constraint here as I have only 256Mb)? Any other advices? 5 minutes work in google... It is not so complicated as it looks like. Or use flashboot which is *unsupported* by OpenBSD project. jirib
Re: power failure resistance
marko.cu...@mimar.rs (Marko Cupa??), 2014.02.19 (Wed) 12:38 (CET): I need to deploy a number of openbsd firewalls based on alix2d13 hardware. The goal is to separate industrial network from LAN, in order to protect unpatched systems on industrial network from potential malware on LAN, while providing some level of access (mostly low-traffic VNC from LAN to industrial and sql in the opposite direction). The problem is that we have very unstable power grid, resulting in unclean shutdnowns of devices. I cannot UPS them all. How can I configure firewalls so they are resistant to those power failures (ie do not need fsck)? How should I partition? Which partitions should be mount read-only? Which should be mount as memory disks? Which size shoud I allocate for memory disks (RAM is a constraint here as I have only 256Mb)? Any other advices? I'm not recommending, just telling what I do. I'm having two alixes with smallish SSDs and found that with ``fsck -p -y'' instead of ``fsck -p'' in rc(8) it is fast enough on unclean reboots. It's incredibly fast. As fsck -y implies I do not have valuable read/write mounted data on these machines. Just checked and your 2d13 got the ``44 pin IDE header''. Layout of one of these: wd0 at pciide0 channel 0 drive 0: TS64GSSD25-M wd0: 1-sector PIO, LBA48, 61136MB, 125206528 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4 a: 206.7M 63 4.2BSD 2048 163841 # / b: 502.0M 423360swap c: 61136.0M 0 unused d: 302.7M 1451520 4.2BSD 2048 163841 # /tmp e: 3506.8M 2071440 4.2BSD 2048 163841 # /usr f: 2000.7M 9253440 4.2BSD 2048 163841 # /var g: 2000.7M13350960 4.2BSD 2048 163841 # /var/log h: 25005.6M 17448480 4.2BSD 2048 163841 # /home i: 27610.6M 68659920 4.2BSD 2048 163841 # /home/foo /dev/wd0a on / type ffs (local, noatime, softdep) /dev/wd0d on /tmp type ffs (local, noatime, nodev, nosuid, softdep) /dev/wd0e on /usr type ffs (local, noatime, nodev, softdep) /dev/wd0f on /var type ffs (local, noatime, nodev, nosuid, softdep) /dev/wd0g on /var/log type ffs (local, noatime, nodev, nosuid, softdep) /dev/sd0i on /vol/bigdata type msdos (local, nodev, nosuid, read-only, uid=1001, gid=0, mask=0775) So, I see... I didn't even bother to mount /home and /home/foo or make /usr read-only. This thingy is my home file/minidlna server and get's it's unclean shutdown almost every day. Consider logging to memory buffer to keep the HDD/SSD as idle as possible. Bye, Marcus
Re: power failure resistance
On 2014-02-19, Marko Cupać marko.cu...@mimar.rs wrote: Hi, I need to deploy a number of openbsd firewalls based on alix2d13 hardware. The goal is to separate industrial network from LAN, in order to protect unpatched systems on industrial network from potential malware on LAN, while providing some level of access (mostly low-traffic VNC from LAN to industrial and sql in the opposite direction). The problem is that we have very unstable power grid, resulting in unclean shutdnowns of devices. I cannot UPS them all. Remember you don't need a traditional UPS with an inverter for such a system, just a simple battery-backup unit. Have you considered something like these? http://www.mini-box.com/picoUPS-100-12V-DC-micro-UPS-system-battery-backup-system http://www.mini-box.com/picoUPS-120-12V-DC-micro-UPS-battery-backup How can I configure firewalls so they are resistant to those power failures (ie do not need fsck)? How should I partition? Which partitions should be mount read-only? Which should be mount as memory disks? Which size shoud I allocate for memory disks (RAM is a constraint here as I have only 256Mb)? Any other advices? Thank you in advance, For this type of system, I do one of two things: 1. Run a flashboot- or flashrd-based system running everything from ramdisk. Note that these are not straight OpenBSD, if you have problems with them which look like they may be OS-related, you will be expected to re-test under a standard OpenBSD system to make sure the problem isn't specific to the non-standard installation. 2. Mount filesystems read-only. As well as needing ro flags in fstab, you'll also need to be aware of the mount -uw line in /etc/rc, and will need to provide memory-based filesystems for /dev and (at least parts of) /var. I use -P to populate from a template directory, swap /dev mfs rw,nosuid,-s=4096,-i=1024,-P=/dev_src 0 0 swap /var mfs rw,async,nodev,nosuid,-s=32000,-P=/var_src 0 0 I typically use memory buffers for syslog on these systems and disable file logging, see syslogc(8), syslogd(8) -s option, syslog.conf(5).
Re: OpenBSD rootkits
Em 18-02-2014 23:00, Theo de Raadt escreveu: This is total balony. The way you are using the word rootkit, it could now refer to anything from a gardening shovel or anything else. Very very sloppy. In the Unix context, the word rootkit has a very specific meaning. You're using the word wrong. LD_PRELOAD provides NO BENEFIT here, because a person who has already gained the privs will use another method to retain them, because LD_PRELOAD is a visible and useless deadend! Theo, I'm using the word rootkit in the sense I've always knew it, a malicious program installed *after *you had gained root access on a machine, which it's sole purpose is to maintain the access while ate the same time, hiding the fact that it's being done so: http://en.wikipedia.org/wiki/Rootkit Also, I mentioned in one of the first e-mails that are much better ways to hide a rootkit. There is not a doubt about that. We were only discussing if it is indeed *possible* to have a rootkit using LD_PRELOAD on OpenBSD. Just that and nothing else. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: OpenBSD rootkits
Giancarlo Razzolini said: Theo, I'm using the word rootkit in the sense I've always knew it, a malicious program installed *after *you had gained root access on a machine, which it's sole purpose is to maintain the access while ate the same time, hiding the fact that it's being done so: http://en.wikipedia.org/wiki/Rootkit Also, I mentioned in one of the first e-mails that are much better ways to hide a rootkit. There is not a doubt about that. We were only discussing if it is indeed *possible* to have a rootkit using LD_PRELOAD on OpenBSD. Just that and nothing else. Putting something into LD_PRELOAD is nowhere near hiding it, if not completely opposite. 1. Any competent system administrator will be watching out his environment. 2. The actual assignment should happen somewhere in a fairly limited set of files (~/.profile, ~/.kshrc or several locations in /etc). Basic mtree check defeats such hiding. In fact for files in /etc root will even receive a pretty mail message the night addition happens. 3. echo $LD_PRELOAD That's not to mention that unless someone logs in as root (which is discouraged in favor of sudo), he isn't affected by root's LD_PRELOAD. So again: there's not much useful things you can do with this trick. You can do some nasty things, but whoever has access to root will be aware of your actions very soon. Given that you already assume that you raised your privilege to root, basicly with your LD_PRELOAD trick you are limited to the subset of things you can already do for the similar period of time, which means that if you actually spend some time on tempering with LD_PRELOAD, you just wasted this time. -- Dmitrij D. Czarkoff
Re: OpenBSD rootkits
Em 19-02-2014 11:19, Dmitrij D. Czarkoff escreveu: Putting something into LD_PRELOAD is nowhere near hiding it, if not completely opposite. 1. Any competent system administrator will be watching out his environment. 2. The actual assignment should happen somewhere in a fairly limited set of files (~/.profile, ~/.kshrc or several locations in /etc). Basic mtree check defeats such hiding. In fact for files in /etc root will even receive a pretty mail message the night addition happens. 3. echo $LD_PRELOAD That's not to mention that unless someone logs in as root (which is discouraged in favor of sudo), he isn't affected by root's LD_PRELOAD. So again: there's not much useful things you can do with this trick. You can do some nasty things, but whoever has access to root will be aware of your actions very soon. Given that you already assume that you raised your privilege to root, basicly with your LD_PRELOAD trick you are limited to the subset of things you can already do for the similar period of time, which means that if you actually spend some time on tempering with LD_PRELOAD, you just wasted this time. Oh my, it appears you did not read what I wrote, again. I'll not keep feeding this, but I'll just say that these modern rootkits, even the one mentioned by the OP, do some pretty nasty things to avoid detection. They hook open() so if you try to read some of the files you mentioned, it won't appear on them. It would be as the file was not tampered with. They can work for the entire system, not just for the root user. I personally think that a rootkit using LD_PRELOAD is just lazy. But this is my opinion, which do not mean that I can't discuss the possibility of a rootkit using it, which is exactly what we were doing. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
AR9462 WLAN support
Hello, are there any plans to support the Atheros AR9462 WLAN IC (aka AR5B22, aka WB222)? In my case I'd like to use it in a Acer AO725 laptop. If not, might it be possible to port code from the ath9k driver (Linux) or would that not be a feasible way? Regards, Carsten
Re: AR9462 WLAN support
On Wed, Feb 19, 2014 at 04:34:27PM +0100, carsten.ku...@arcor.de wrote: Hello, are there any plans to support the Atheros AR9462 WLAN IC (aka AR5B22, aka WB222)? In my case I'd like to use it in a Acer AO725 laptop. If not, might it be possible to port code from the ath9k driver (Linux) or would that not be a feasible way? It's technically possible since the ath9k driver is dual BSD/GPL. There is also FreeBSD's ath driver, and there is the Atheros HAL which was recently open sourced: https://github.com/qca/qcamain_open_hal_public Contrary to the others OpenBSD currently has a split between ath and athn drivers. I think it makes sense to maintain that. It has also been suggested to port FreeBSD's ath driver to OpenBSD. I don't believe that is less work than extending the existing athn driver, though. So far I've found extending athn quite hard, and I don't think having to deal with possible regressions for already supported hardware would make this any easier. And it's possible that FreeBSD's driver relies on features specific to FreeBSD's net80211 stack. I don't know how much of a hurdle that would be but I wouldn't expect it to be trivial. There is already existing code for some newer atheros chips in ar9003.c. However it is currently unused and doesn't work with an ar9485 I have lying around. I have some work in progress patches for that if you're interested but they don't make anything work yet. Are you asking because you're interested in hacking on this yourself? Because we really need people who would want to do that.
Re: AR9462 WLAN support
Are you asking because you're interested in hacking on this yourself? If there would already be some work in progress I'd like to use this one day instead of hacking myself. If not I'd intend to work on it. Not really short term though. It has also been suggested to port FreeBSD's ath driver to OpenBSD. I don't believe that is less work than extending the existing athn driver, though. I'd prefer to extend the athn driver, I'd investigate at first in that. Thank you for your extensive information.
Re: power failure resistance
On Wed, Feb 19, 2014 at 12:38:53PM +0100, Marko Cupa?? wrote How can I configure firewalls so they are resistant to those power failures (ie do not need fsck)? How should I partition? Which partitions should be mount read-only? Which should be mount as memory disks? Which size shoud I allocate for memory disks (RAM is a constraint here as I have only 256Mb)? Any other advices? The heavy-handed approach... the firewall boots from either CD ROM https://cocoavillagepublishing.com/development/tools/openbsd/tips/cdrom or USB stick http://www.volkerroth.com/tecn-obsd-diskless.html and send log data to a remote machine that is on a UPS. Since nothing gets written to the boot media during operation, fsck is not required. -- Walter Dnes waltd...@waltdnes.org
Printing problem
I don't print from my laptop often, but all was fine until recently. I am at latest snapshot: OpenBSD 5.5-beta (GENERIC) #247: Fri Feb 7 12:04:52 MST 2014 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz (GenuineIntel 686-class) 2 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,CNXT-ID,xTPR,PERF real mem = 536252416 (511MB) avail mem = 515588096 (491MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 01/12/04, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf76a0 (61 entries) bios0: vendor Dell Computer Corporation version A10 date 01/12/2004 bios0: Dell Computer Corporation Latitude C640 When trying to print either through USB or network connection, I get this error: Your printer job (estimate_details_for_customer) had the following errors and may not have printed: No printer definition (option -P name) specified! I did not have any problems previously. I haven't made any changes either. I am using commands of lpr -Plp estimate_details_for_customer or lpr -Paps1 estimate_details_for_customer Any advice? Chris Bennett
Re: Printing problem
On Wed, Feb 19, 2014 at 11:20 AM, Chris Bennett chrisbenn...@bennettconstruction.us wrote: I don't print from my laptop often, but all was fine until recently. I am at latest snapshot: OpenBSD 5.5-beta (GENERIC) #247: Fri Feb 7 12:04:52 MST 2014 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz (GenuineIntel 686-class) 2 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,CNXT-ID,xTPR,PERF real mem = 536252416 (511MB) avail mem = 515588096 (491MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 01/12/04, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf76a0 (61 entries) bios0: vendor Dell Computer Corporation version A10 date 01/12/2004 bios0: Dell Computer Corporation Latitude C640 When trying to print either through USB or network connection, I get this error: Your printer job (estimate_details_for_customer) had the following errors and may not have printed: No printer definition (option -P name) specified! I did not have any problems previously. I haven't made any changes either. I am using commands of lpr -Plp estimate_details_for_customer or lpr -Paps1 estimate_details_for_customer Any advice? Known issue with that snapshot. Already fixed in -current.
Re: Printing problem
On Wed, Feb 19, 2014 at 12:32:36PM -0800, Jeremy Evans wrote: On Wed, Feb 19, 2014 at 11:20 AM, Chris Bennett chrisbenn...@bennettconstruction.us wrote: I don't print from my laptop often, but all was fine until recently. I am at latest snapshot: OpenBSD 5.5-beta (GENERIC) #247: Fri Feb 7 12:04:52 MST 2014 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz (GenuineIntel 686-class) 2 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,CNXT-ID,xTPR,PERF real mem = 536252416 (511MB) avail mem = 515588096 (491MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 01/12/04, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @ 0xf76a0 (61 entries) bios0: vendor Dell Computer Corporation version A10 date 01/12/2004 bios0: Dell Computer Corporation Latitude C640 When trying to print either through USB or network connection, I get this error: Your printer job (estimate_details_for_customer) had the following errors and may not have printed: No printer definition (option -P name) specified! I did not have any problems previously. I haven't made any changes either. I am using commands of lpr -Plp estimate_details_for_customer or lpr -Paps1 estimate_details_for_customer Any advice? Known issue with that snapshot. Already fixed in -current. I rather think this is the foomatic-filters - cups-filters update that breaks existing filter scripts for lpd setups, because cups-filters removes lpd compat. There was no current.html warning for this update, unfortunately. But the fix is simple. A wrapper script is now needed to use foomatic with lpd. Check the cups-filters README file in /usr/local/share/doc/pkg-readmes.
Multiple rdomains PF one to one NAT not working
I am trying to configure one to one nat for some duplicate subnets. I have tried very hard to figure how how this can be done with OpenBSD, but I haven't gotten it completely working yet. First, I want to explain what I am trying to accomplish. I have a single public interface in rdomain 0 and then I will have many private interfaces each in seperate rdomains. Each of these private interfaces will have a high probability of having the same subnet 192.168.64.0/24 and there will be multiple systems in each of the private rdomains. ie 192.168.64.2-5. I want to be able to address each system with a public a unique public IP and I want each system to use the same public IP to get to external systems beyond their one private rdomain. publicIP replace with real public IP What is currently working: I can successfully do a redirect from the public interface to the private host in a specific rdomain like this. client to server: match in log(all) on em0 to publicIP rdr-to 192.168.64.2 rtable 3020 match out log(all) on em1 nat-to em1 server to client or external system is broken match in log(all) on em1 from 192.168.64.2 to !em1:network nat-to publicIP rtable 0 match out log(all) on em0 received-on em1 Remember I want to nat each system to a specific public IP in rdomain 0, so I have base that decision on which rdomain its coming from and what's private IP is because their will be multiple systems in each rdomain. The syntax above was the only way I have found to make that nat statement match those conditions the limitations of multiple conditions once the packet was back in rdomain0. If you wait until its back in rdomain zero. Then you have to be able to say something like received-on em1 from 192.168.64.2 nat-to publicIP... I wasn't able to do a double condition like that in the pf.conf This is what you see in tcpdump of pflog0 so it does in fact get nated and the request is routed to the destination IP and it responds with a response packet. The response packet never makes it back to the internal server though because it doesn't use the rules that I would expect it to. ...rule 1/(match) [uid 0, pid 16504] pass in on em0: external client publicIP: icmp: echo reply (id:fdbe seq:225) (ttl 64, id 29430, len 84) ...rule 3/(match) [uid 0, pid 16504] match in on em0: external client publicIP: icmp: echo reply (id:fdbe seq:225) (ttl 64, id 29430, len 84) ...rule 1/(match) [uid 0, pid 16504] pass out on em0: publicIP external client: icmp: time exceeded in-transit (ttl 255, id 10940, len 56, bad ck That is not what I expect or what I need to happen. I need the response packet to pass using rule 2 so that it get's redirected back to the server where it came from. If its a new request started from a client or external system then it does hit rule 2 and it does get redirected to the server. I realize this might be acomplicated configuration, but I really need a true one to one nat both directions with multiple rdomains. I would love to use OpenBSD to solve this use case. @0 block drop in on ! lo0 proto tcp from any to any port 6000:6010 [ Skip steps: f=2 sa=5 da=2 sp=end ] [ queue: qname= qid=0 pqname= pqid=0 ] @1 pass log (all) all flags S/SA [ Skip steps: r=end p=end sa=5 sp=end dp=end ] [ queue: qname= qid=0 pqname= pqid=0 ] @2 match in log (all) on em0 inet from any to publicIP rtable 3020 rdr-to 192.168.64.2 [ Skip steps: i=4 r=end p=end sa=5 sp=end dp=end ] [ queue: qname= qid=0 pqname= pqid=0 ] @3 match out log (all) on em0 all received-on em1 [ Skip steps: d=5 r=end p=end sa=5 da=5 sp=end dp=end ] [ queue: qname= qid=0 pqname= pqid=0 ] @4 match out log (all) on em1 inet all nat-to 192.168.64.1 [ Skip steps: i=end r=end f=end p=end sp=end dp=end ] [ queue: qname= qid=0 pqname= pqid=0 ] @5 match in log (all) on em1 inet from 192.168.64.2 to ! 192.168.64.0/24 rtable 0 nat-to publicIP [ Skip steps: i=end d=end r=end f=end p=end sa=end da=end sp=end dp=end ] [ queue: qname= qid=0 pqname= pqid=0 ] pass log(all) match in log(all) on em0 to publicIP rdr-to 10.2.0.2 rtable 3020 match out log(all) on em0 received-on em1 match out log(all) on em1 nat-to em1 match in log(all) on em1 from 192.168.64.2 to !em1:network nat-to publicIP rtable 0 Thank You for any Advice or if this is a bug then hopefully it can get resolved. I think this mightbe a bug, but I didn't want to call it a bug before I had other people look at this. James Hunter
Re: DVD ISO and mount_udf: FSD does not lie within the partition!
On 2014 Feb 18 (Tue) at 02:57:50 -0500 (-0500), Philippe Meunier wrote: :# cat /mnt/README.TXT :This disc contains a UDF file system and requires an operating system :that supports the ISO-13346 UDF file system specification. OpenBSD does not support disks that have both UDF and MS-DOS filesystems. -- The older I grow the more I distrust the familiar doctrine that age brings wisdom. -- H. L. Mencken
