R: smtpd: access.db?
Il giorno lunedì 12 giugno 2023 22:41 Steve Fairhead ha scritto: > I'm in newbie mode again. I'm working on replacing an old OpenBSD server > running Sendmail with a new one running smtpd. With Sendmail, I rely > heavily on the access.db feature to block TLDs, usernames, email > addresses, and domains. Is there an equivalent feature with smtpd? You can filter on many things by leveraging smtpd.conf(5) rules and tables(5). For more complex filtering scenarios you might investigate smtpd-filters(7). See the relevant manpages and examples. > Also I can't see any reason why spamd shouldn't play well with smtpd, I'm not sure I understand your question: spamd is MTA agnostic and interacts with pf and pf tables. See spamd(8) and the other manpages linked there. f
Re: Overwriting softraid keys
On Thu, May 25, 2023 at 09:35AM Stefan Sperling wrote: > On Wed, May 24, 2023 at 04:37:00PM +0000, Francesco Toscan wrote: > Hi misc@, > >> I'm going to migrate a FreeBSD ZFS-based fileserver to a OpenBSD 7.3 >> UFS-based one. >> In order to comply with regulations, part of data must be encrypted; >> regulations also dictate that I have to be able to destroy the encryption >> keys. [...] >> To "destroy" the keys I think it could be sufficient to use dd and overwrite >> the first megabyte of the softraid chunk with random data. > Yes, indeed. There is only one section of meta-data at the beginning of the > chunk and if this meta-data is lost then the decryption key is gone as well. [...] Thank you for the detailed explaination, much appreciated. For the record, bioctl and the stack do comply. > It is not yet possible to encrypt a key disk with a passphrase, which would > provide two-factor authentication. There is no technical reason which would > prevent this from being implemented, it just hasn't been done. >From a user perspective, a user who is not able to help coding, I can just say that encrypting a key disk with a passphrase would be great. Thanks for your time, f
Overwriting softraid keys
Hi misc@, I'm going to migrate a FreeBSD ZFS-based fileserver to a OpenBSD 7.3 UFS-based one. In order to comply with regulations, part of data must be encrypted; regulations also dictate that I have to be able to destroy the encryption keys. So, I want to split data into multiple partitions, mounted read-only (it's "cold" data, there's no point in mounting rw); one of them, of about 50GB, will be a chunk dedicated to softraid. The volume will be assembled by hand and the on-disk encryption key will be encrypted with a user supplied password (right, regulations). If I understand correctly the 2010 paper by Marco Peereboom, he designed the crypto softraid discipline so the encrypted keys would be saved in a variable part of softraid medatata, stored at the beginning of the chosen chunk, after an offset of 512 bytes. To "destroy" the keys I think it could be sufficient to use dd and overwrite the first megabyte of the softraid chunk with random data. Am I missing something? Thanks, f
Re: bwi(4) issues
On Sun, May 18, 2014 at 02:33:15PM +0200, Francesco Toscan wrote: > > The CAVEATS section of the man page seems to describe your issue. > > Perhaps it's a hardware problem? Does it work again if you downgrade > > to 5.5-release? > > I'll boot 5.5-release and report what's happening. Here's the followup. With 5.5-release network with bwi is stuck...very very very low transfer rates (about 80 KB/sec average speed, 110 KB/sec peak). bce is broken, kernel logs tons of bce0: descriptor error. Running -current from May 12th snapshot bwi runs slow but better, bce sometimes runs good, sometimes prints descriptor error message (kernel or configuration untouched). -- f.
Re: bwi(4) issues
On Sun, May 18, 2014 at 01:08:00PM +0200, Stefan Sperling wrote: > On Sun, May 18, 2014 at 12:52:53PM +0200, Francesco Toscan wrote: > > Hi misc@, > > > > Network with bwi has become *slow*, slow as unusable. Every kind of > > traffic is somehow slowed. Transmissions work but they take forever to > > complete. > > The CAVEATS section of the man page seems to describe your issue. > Perhaps it's a hardware problem? Does it work again if you downgrade > to 5.5-release? Stefan, thanks for your reply. I thought my device was one among those fortunate working chips :)) I'm looking at bwi.c 's CVS record: last commit was 8 weeks ago, I'm sure performances were suboptimal before that. Preceeding commit was 5 months ago and I'm sure in February 26th the driver performed better. This snapshot from May 12th performs better than three/four weeks ago, but the driver was not modified: can't give numbers but three/four weeks ago network was stuck, now it's just very slow. Unfortunately between last February and April I was forced to use this laptop as a rescue FreeBSD 9 system (btw, bwi worked fine there) so I have an usage blackout of two months. I'll boot 5.5-release and report what's happening. -- f.
bwi(4) issues
Hi misc@, I'm running 5.5-current from May 12 build (dmesg attached). I noticed a regression in bwi(4) network device driver. I knew it worked fine somewhere between 5.4-current built on January and 5.5-release, unfortunately I haven't enough informations to narrow the timeframe. BTW, here are the issues. Network with bwi has become *slow*, slow as unusable. Every kind of traffic is somehow slowed. Transmissions work but they take forever to complete. WIFI network is wpa encrypted; when using dhclient things seem to get worse. I enabled debugging on bwi0 and console got flooded with: bwi0: received probe_resp from my:ap:lladdress rssi 54 mode 11g bwi0: received probe_resp from my:ap:lladdress rssi 54 mode 11g bwi0: received probe_resp from my:ap:lladdress rssi 55 mode 11g bwi0: received probe_resp from not:my:ap:lladdress rssi 36 mode 11g bwi0: received probe_resp from another:ap:but:not:mine rssi 34 mode 11g bwi0: received probe_resp from yet:another:ap rssi 35 mode 11g bwi0: received probe_resp from another:ap:but:not:mine rssi 35 mode 11g bwi0: received probe_resp from another:ap:but:not:mine rssi 36 mode 11g bwi0: received probe_resp from yet:another:ap rssi 37 mode 11g bwi0: received probe_resp from yet:another:ap rssi 37 mode 11g bwi0: received probe_resp from another:ap:but:not:mine rssi 36 mode 11g bwi0: received probe_resp from yet:another:ap rssi 36 mode 11g bwi0: received probe_resp from another:ap:but:not:mine rssi 35 mode 11g bwi0: received action from my:ap:lladdress rssi 54 mode 11g bwi0: received probe_resp from my:ap:lladdress rssi 54 mode 11g bwi0: received probe_resp from my:ap:lladdress rssi 54 mode 11g bwi0: received probe_resp from yet:another:ap rssi 35 mode 11g [...] My network card seems too busy managing beacons to actually route IP packets. After some minutes of "activity" (as trying to browse www.openbsd.org) netsta -W bwi0 outputs the following: ieee80211 on bwi0: 0 input packets with bad version 0 input packets too short 0 input packets from wrong bssid 1154 input packet duplicates discarded 0 input packets with wrong direction 10 input multicast echo packets discarded 0 input packets from unassociated station discarded 1 input encrypted packet without wep/wpa config discarded 0 input unencrypted packets with wep/wpa config discarded 39 input wep/wpa packets processing failed 0 input packet decapsulations failed 0 input management packets discarded 0 input control packets discarded 0 input packets with truncated rate set 0 input packets with missing elements 0 input packets with elements too big 0 input packets with elements too small 0 input packets with invalid channel 66 input packets with mismatched channel 0 node allocations failed 0 input packets with mismatched ssid 0 input packets with unsupported auth algorithm 0 input authentications failed 0 input associations from wrong bssid 0 input associations without authentication 0 input associations with mismatched capabilities 0 input associations without matching rates 0 input associations with bad rsn ie 1 input deauthentication packet 0 input disassociation packets 0 input packets with unknown subtype 0 input packets failed for lack of mbufs 0 input decryptions failed on crc 0 input ahdemo management packets discarded 0 input packets with bad auth request 17 input eapol-key packets 0 input eapol-key packets with bad mic 0 input eapol-key packets replayed 0 input packets with bad tkip mic 0 input tkip mic failure notifications 0 input packets on unauthenticated port 0 output packets failed for lack of mbufs 0 output packets failed for no nodes 0 output packets of unknown management type 1 output packet on unauthenticated port 2 active scans started 0 passive scans started 0 nodes timed out 0 failures with no memory for crypto ctx 0 ccmp decryption errors 0 ccmp replayed frames 0 cmac icv errors 0 cmac replayed frames 10 tkip icv errors 10 tkip replays So I plugged in a spare ral-based USB dongle, enabled debug and looked at console output: it performed the active scan, then it associated to my ap... ...and nothing more than group rekeying. Action beacons sometimes. netstat -W looks normal. Suggestions to further debug this? bwi used to work well, unfortunately I can't really say when this problem arose. Thanks, f. >> hostname.bwi0 << nwid mynet wpakey mykey dhcp >> dmesg and pcidump follow << OpenBSD 5.5-current (GENERIC.MP) #126: Mon May 12 22:40:04 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1994850304 (1902MB) avail mem = 1
Re: Content filtering in smtpd(8)
Hi Gilles, On Wed, Feb 26, 2014 at 11:37:47AM +0100, Gilles Chehade wrote: > On Wed, Feb 26, 2014 at 11:16:40AM +0100, Francesco Toscan wrote: > > Is this content filtering api documented anywhere? I found no mention in > > smtpd.conf(5) or smtpd(8) man pages. > > > > nope because we're still stabilizing the API, there are still a few > shortcomings but we should be done by 5.6 Ah ok, can't wait for 5.6 :-) > the API is supposed to be usable by a larger audience very soon (we're > talking in matter of weeks), the python/perl bindings are just regular > filters, they are not part of smtpd itself, they rely on the C API so > they are as usable as the API itself ;-) > > If you are interested in filters development, ping me off-list and I > can tell you where to get started. Thank you very much Gilles, continuing off-list. -- f. Non sono pigro...ma non ne ho voglia :D :D
Content filtering in smtpd(8)
Hi, looking at GSOC2014 OpenBSD Foundation's idea list, I found a reference to some "Perl and Python bindings" to smtpd's own content filtering framework. Is this content filtering api documented anywhere? I found no mention in smtpd.conf(5) or smtpd(8) man pages. I'd like to know whether this api or these perl bindings are intended to be usable by larger audience, because I have to rewrite outdated and horrible code written for sendmail (it uses sendmail's milter interface): it would be nice to start over with smtpd. I really appreciate any help you can provide. -- f. Non sono pigro...ma non ne ho voglia :D :D
Re: ntp and pppoe
Il giorno 17/nov/07, alle 20:02, Henning Brauer ha scritto: * Francesco Toscan <[EMAIL PROTECTED]> [2007-11-17 19:22]: I use ifstated to detect link changes and restart ntpd. bad idea. loses all state. just give it a little slack, it copes. Have still to try on 4.2, but on 4.0 I ended up with ifstated because sometimes ntpd kept sending packets with old IP for weeks (I am fortunate enough to keep the same IP assigned for 30-40 days). I've never sent a bug report because I was unable to reproduce the problem in a consistent way. I'll try with 4.2 as soon as I'll have time to update. f.
Re: ntp and pppoe
Il giorno 17/nov/07, alle 16:59, Christoph Leser ha scritto: I use the pppoe0 device to connect to my isp. And I use ntpd. ntpd seems not to be aware of the changing ip address of the interface. It keeps sending messages with the source address it saw on startup, as can be seen for netstat -an or pflog. I use ifstated to detect link changes and restart ntpd. It just works, plain and simple. f.
Re: RAIDFrame inconsistancy and server will not boot!
On 10/26/07, Jake Conk <[EMAIL PROTECTED]> wrote: If the filesystem is screwed up then shouldn't the raid just ignore it and run on 1 disk until I fix the problem? That seems like the logical thing it should do unless all my mirrors of /var are messed up. No, raid doesn't do that. Let's assume we have a raid1 setup with two twin disks, no spares. Imagine it as a floor (your filesystem) substained by two columns (your disks): if a column collapses the other one keeps the floor up, but if the floor has holes your forniture will fall down, regardless columns' health. RAID just cares about disks' health, not filesystem's health. And lastly, is it possible in the worst case scenario if one of my disks is completely fsck'ed up is it possible to run the system on 1 of the raid 1 disks until a second comes? If the *disk* fails raid takes care of it automagically. If for some reasons the filesystem fails then you might have to fix it by hand. f.
Re: RAIDFrame inconsistancy and server will not boot!
2007/10/26, Jake Conk <[EMAIL PROTECTED]>: > Hello, > > I was trying to restart my server and noticed it wasn't coming back > online so when I went down to go take a look at it I was having a RAID > problem. This is what was showing on the screen: > > ... > PARTIALLY TRUNCATED INODE I=720 > THE FOLLOWING SYSTEM HAD AN UNEXPECTED INCONSISTENCY: > [...] > My question is what causes this? How can I be warned before a problem > like this happens and what's the best way to prevent this from coming > up? And lastly, is it possible in the worst case scenario if one of my > disks is completely fsck'ed up is it possible to run the system on 1 > of the raid 1 disks until a second comes? Your problem is related to filesystem, not disks. For some reasons your filesystem (on top of raid) was not properly unmounted: assuming you didn't hard-reboot your server, this happened to me whith some IDE devices which lied about commit of write operations. Even if my server was rebooted normally, filesystem and disks were left in an inconsistent state. Better SCSI disks solved the problem. Hardware has become more crappy day by day. RAID in general keeps your system up if a disk fails, not if filesystem on top of it screws up. f.
Re: Can't read authpf rules with pfctl
2007/10/22, Jeff Simmons <[EMAIL PROTECTED]>: > [...] > > firewall:~#pfctl -a '*' -sr > anchor "*" all { > pfctl: DIOCGETRULES: Invalid argument > } > > Am I misreading the man page in assuming that both of these commands should > return the block line that the authme login set up, or is something else > going on? Use pftcl -vsA, it will return you the anchors nested in authpf/* like: authpf authpf/user(pid) authpf/anotheruser(pid) The use pfctl -a 'authpf/user(pid)' -sr to display user's rules. f.
Re: Squid/authpf with lookups on Active Directory
Il giorno 19/ott/07, alle 17:03, Ari Constancio ha scritto: How can I authenticate users from AD to get through pf? I'm unsure I've correclty understood your request. If you mean "How can I make my authpf users authenticate against AD" then use login_ldap from ports (you probably have to do some modifications on AD schema, don't remember), make a login class in login.conf for your authpf users and allow them to use login_ldap only as authentication method. f.
Re: hardening BSD (was systrace/stsh policies)
2007/10/14, Aaron <[EMAIL PROTECTED]>: > I guess with all the hoopla about 'hardening'/trusted this and > that/fuzzy knobs(i.e. SE Linux) i got a little overzealous looking for As others have already pointed out these knobs might not be useful to your setup and your needs. Think also that more complexity you add then more likely you'll find out bugs lurking in the dark, waiting for the right moment to bite your ass. I have a box running FreeBSD with MAC policies configured in production for a year now; I must be honest, the only thing I'm really sure about is it's a royal pain to update and manage. Not a great deal, I'm planning a switch to 4.2. f.
Re: Debugging ral
A few lines above I wrote supported channel: i meant supported by your clients. Yes, this should be corrected, thank you. I don't know if some device supports those "high" channels: another ral adapter I tested does, my laptop doesn't. For example my iBook supports channels from 1 to 11 (don't know if it is an hardware limitation or it's just Apple) while another Toshiba laptop equipped with XP associates on chan 13 without any problem, not channel 112 however. After some playing with my clients I found the most powerful supported channel for me is chan 6. f. Non sono pigro...ma non ne ho voglia :D :D Il giorno 25/set/07, alle 16:15, Matthew Szudzik ha scritto: Why did you choose channel 6 instead of channel 112 (or channels 161 or 165, which have "power=16")? Channels 1 through 6 all have "power=14".
Debugging ral
I'd like to thank in public Damien Bergamini, he helped me a lot in debugging my ral setup: it was very very slow and unreliable. With Damien's tips now I have a better understanding of my ral device and, above all, it works flawlessy. I wrote a small doc reporting this experience and Damien's tips: I hope it could be useful. http://sekureshell.altervista.org/docs/trouble_ral.html f. Soekris docs & resources - http://sekureshell.altervista.org
Re: pfctl explaination
2007/6/21, Peter N. M. Hansteen <[EMAIL PROTECTED]>: You may be hitting one or more of the several relevant limits, but have you tried something like 'pfctl -T flush -t tablename' before reloading the table data? Yes, if I first flush the table it works flawlessy. The 'problem' occurs only reloading the ruleset directly with pfctl -f, without flushing / cleaning anything, when pfctl has two full copies of this large_table. f.
Re: pfctl explaination
2007/6/20, Ted Unangst <[EMAIL PROTECTED]>: yes, reloading the rules makes another copy then switches over. if you have a really large table, this means having two copies of the table during the transition. Thank you for your answer. I've just tried to set table-entries to 550K, more than double the content of (210144 entries) but reload always gives: /etc/pf.conf.queue:17: cannot define table large_table: Cannot allocate memory I guess pfctl needs even more entries or I hit another kind of limit, I'll look into it. f.
pfctl explaination
Hi misc@, I'm trying to understand how pfctl re-loads rules and tables. On my soekris board, 64MB RAM, I have a large table with more than 200K entries. It's used to perform some egress filtering (yes maybe it's too large but it's really effective). I raised up table-entries limit to 250K and I get the following scenario: when I first load the rules everything works fine; when I reload the rules with pfctl -f pf.conf, pfctl segfaults or exits returning "Cannot allocate memory" as if table-entries limit were not high enough. If I first flush the large table and then reload the rules everything works fine again. I once read on misc@ Henning Brauer saying pfctl -f performs operations "atomically": should I assume pfctl creates another copy of in this process? How does it work? It's really just a curiosity about pfctl internals. Thanks, f.