Re: pf in 4.0 not honoring nat rule with table for vlan tagged interface
On Wed, Jun 20, 2007 at 01:27:22AM -0400, Brian A. Seklecki wrote:
Very bizarre. The only advice I can offer is that maybe it's getting
confused on - $nat_if instead of the more-pragmatic - ($nat-if).
The above worked!
Doesn't make sense though. According to pf.conf(5):
nat-rule = [ no ] nat [ pass [ log [ ( logopts ) ] ] ]
[ on ifspec ] [ af ]
[ protospec ] hosts [ tag string ] [ tagged string ]
[ - ( redirhost | { redirhost-list } )
[ portspec ] [ pooltype ] [ static-port ] ]
redirhost = address [ / mask-bits ]
address= ( interface-name | ( interface-name ) | hostname |
ipv4-dotted-quad | ipv6-coloned-hex )
So, - $nat_if and - ($nat_if) seem equally-valid.
Perhaps the parse code is trying too hard to resolve $nat_if in the
former, and thus finding the underlying interface instead of the logical
upper layer vlan interface?
Give it a shot. If not, we'll turn up debugging and log
~BAS
On Tue, 19 Jun 2007, Albert Chin wrote:
I have a perfectly-working 4.0 firewall and decided to move one of the
physical interfaces to a new vlan tagged interface. I changed the
interface name in pf.conf and noticed that NAT wasn't working. The NAT
rule is:
nat_if = vlan109
table tww_nets const { 192.168.1.0/24, 192.168.4.0/24, 10.191.57.0/24 }
nat pass log on $nat_if from tww_nets to any - $nat_if
If nat_if is a physical interface, like fxp0, the above nat rule
works. I can get the nat rule to work if I omit the use of the table:
nat pass log on $nat_if from { 192.168.1.0/24, \
192.168.4.0/24, \
10.191.57.0/24 } to any - $nat_if
So:
1. If the only change I make to pf.conf is a global search/replace
from fxp0 to vlan109, why doesn't pf behave as if using
a physical interface?
2. Why the workaround above to get pf working with the vlan tagged
interface? Bug in pf?
--
albert chin ([EMAIL PROTECTED])
l8*
-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
http://www.spiritual-machines.org/
Guilty? Yeah. But he knows it. I mean, you're guilty.
You just don't know it. So who's really in jail?
~Maynard James Keenan
--
albert chin ([EMAIL PROTECTED])
CARP interface state change logging patch
The OpenBSD PF-MIB stuff is incredibly useful -- especially the
PF-MIB:CarpIFTable objects. Thanks to all involved with that. I've also
had success with Net-SNMP 5.4 (opti@'s version) with those patches; will
try to port them to other PF-enabled OSs soon.
In the mean time, I want to keep going with additional debugging and
monitoring functionality in CARP. Here is a small patch that is
incredibly useful for troubleshooting and debugging cumbersome issues.
Silence is killer, especially when you turn on logging and receive
nothing:
This adds functionality similar to debug standby in Cisco-land:
*Mar 1 02:56:13: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet3/0, changed state to up
*Mar 1 02:56:14: SB0: FastEthernet3/0 state Listen - Init
*Mar 1 02:56:20: SB0: FastEthernet3/0 state Init - Listen
*Mar 1 02:56:30: SB0: FastEthernet3/0 state Listen - Speak
*Mar 1 02:56:40: SB0: FastEthernet3/0 state Speak - Standby
*Mar 1 02:56:41: SB0: FastEthernet3/0 state Standby - Active
With this patch:
# ifconfig carp40 vhid 40 carpdev pcn0 pass foo up
Jun 20 03:05:46 vmware-openbsd-lab /bsd: carp40: state transition from: MASTER
- to: INIT
Jun 20 03:05:46 vmware-openbsd-lab /bsd: carp40: state transition from: INIT -
to: BACKUP
Jun 20 03:05:46 vmware-openbsd-lab /bsd: carp40: state transition from: BACKUP
- to: INIT
Jun 20 03:05:46 vmware-openbsd-lab /bsd: carp40: state transition from: INIT -
to: BACKUP
Jun 20 03:05:46 vmware-openbsd-lab /bsd: carp40: state transition from: BACKUP
- to: INIT
Jun 20 03:05:46 vmware-openbsd-lab /bsd: carp40: state transition from: INIT -
to: BACKUP
Jun 20 03:05:49 vmware-openbsd-lab /bsd: carp40: state transition from: BACKUP
- to: MASTER
I think there are probably ~20 other CARP_LOG() calls that could improve
the experience, but this is a good place to start and we'll move on from
there.
Against the OPENBSD_4_1 tree (rev 1.132.2.1):
# cvs diff -u ip_carp.c
Index: ip_carp.c
===
RCS file: /cvs/src/sys/netinet/ip_carp.c,v
retrieving revision 1.132.2.1
diff -u -r1.132.2.1 ip_carp.c
--- ip_carp.c 2007/04/30 20:39:44 1.132.2.1
+++ ip_carp.c 2007/06/20 07:03:15
@@ -2111,6 +2111,8 @@
void
carp_set_state(struct carp_softc *sc, int state)
{
+ static const char *carp_states[] = { CARP_STATES };
+ CARP_LOG(sc, (state transition from: %s - to: %s,
carp_states[sc-sc_state], carp_states[state]));
if (sc-sc_state == state)
return;
l8*
-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
http://www.spiritual-machines.org/
Guilty? Yeah. But he knows it. I mean, you're guilty.
You just don't know it. So who's really in jail?
~Maynard James Keenan
Re: Random crash
Luca Losio [EMAIL PROTECTED] writes: Hi all, I'm having a lot of crashes with my 4.1 since I updated from 4.0 ...the console output is: page fault trap code=0 stopped at enqueue_randomness+0xc5addb%al,0(%eax) ddb RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION! Funny how that message magically disappears from bug reports that don't bother to provide the information that is being asked in ALL CAPS. //art
Re: linker scripts
Constantine Kousoulos wrote: Having a linux background (and a limited NetBSD experience), i expected to find linker scripts in the kernel source code. However, this is simply not true for most architectures. What is the logic behind the lack of linker scripts? Do you have an actual problem or are you trying to invent one?
Re: linker scripts
Constantine Kousoulos [EMAIL PROTECTED] writes: Having a linux background (and a limited NetBSD experience), i expected to find linker scripts in the kernel source code. However, this is simply not true for most architectures. What is the logic behind the lack of linker scripts? The same logic as the lack of awk scripts that pre-process the assembler files before feeding them to the assembler. //art
Help with pf address translation
We have ipsec running on an internal firewall, with packets being
routed to the internal firewall via an external firewall. We wish to
move off of the internal 192.168.11.0/24 network and onto a net-10
network. What pf rules do we need to automatically translate between a
net-10 block and the internal 192.168.11.0/24 block?
--
| internet |
--
|
| [ext_if] external ip
---
| external firewall |
---
| 192.168.23.2 (default route for internal firewall)
|
| [vpn_if] 192.168.23.1
---
| internal firewall |
---
| [int_if] 192.168.11.254 (default route for 192.168.1.0/24)
The following rule redirects VPN traffic from the external firewall to
the internal firewall:
rdr pass on $ext_if proto udp from any to $ext_if:0 \
port { 500, 4500 } - 192.168.23.1
Our goal is to map 10.20.30.13 to 192.168.11.13, 10.20.30.14 to
192.168.11.14, etc. for VPN clients.
We initially added a rule on the internal firewall config with:
table tww_nets const { 192.168.11.0/24, 10.20.30.0/24 }
nat pass log on $int_if from !tww_nets to tww_nets - ($int_if:0)
++ rdr pass log on enc0 proto tcp from any to 10.20.30.13 \
++ - 192.168.11.13
This works in redirecting inbound VPN traffic to 192.168.11.13:
Jun 20 07:15:42.947878 rule 3/(match) rdr in on enc0: 192.168.10.100.42888
192.168.11.13.80: [|tcp] (DF) [tos 0x10]
Jun 20 07:15:42.947902 rule 1/(match) nat out on fxp4: 192.168.11.254.5
192.168.11.13.80: [|tcp] (DF) [tos 0x10]
However, once the packet arrives at 192.168.11.13, it must make it's
way back to the VPN client at 192.168.10.100. That's where we're
having the trouble. The inbound packet comes in through
192.168.11.254 and goes out through 192.168.23.1 (tcp dump traffic on
vpn_if):
07:31:02.534408 10.20.30.13.80 192.168.10.100.54486: R [tcp sum ok] 0:0(0)
ack 771645959 win 0 (ttl 63, id 13259, len 40)
Jun 20 07:53:03.872494 rule 0/(match) block in on fxp0: 10.20.30.13.80
192.168.10.100.54486: [|tcp]
Thinking about this some more, the rdr on enc0 doesn't make much
sense. I'm thinking we need some kind of binat rule but I'm unable to
come up with one that works. Any ideas?
--
albert chin ([EMAIL PROTECTED])
Re: pf in 4.0 not honoring nat rule with table for vlan tagged interface
* Brian A. Seklecki [EMAIL PROTECTED] [2007-06-20 07:39]: Very bizarre. The only advice I can offer is that maybe it's getting confused on - $nat_if instead of the more-pragmatic - ($nat-if). Perhaps the parse code is trying too hard to resolve $nat_if in the former, and thus finding the underlying interface instead of the logical upper layer vlan interface? no way. to teh original poster, please show: 1) ifconfig -A 2) pf.conf 3) pfctl -nvf /etc/pf.conf specically, compare the nat rule(s) in 2) and 3). you should see $nat_if replaced by an IP address. of course do NOT use ($nat_if) for that -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: Security of the keyboard
On Tue, Jun 19, 2007 at 07:05:38PM -0700, Don Scott wrote: I think Artur Grabowski too easily dismisses the question. I'd be interested to know if you get any informative responses that are not also posted to [EMAIL PROTECTED] Mikulas (the friend) told me the algorithm to hack the root password. First you need to know the addresses of the individual keys in the translation tables - that's probably doable from the operating system kernel memory map. Then you need to know how many way associative your cache is and how the addresses are shared. If it's say 4-way you use 4 addresses in your userspace that share the cache entry. Then you read all of them 4. Now comes the monitoring phase. You cyclically time how long it takes to read each of these 4 addresses using rdtsc. When you get anomalously high reading on any of them, you know the given address in the key translation table has been accessed. This will probably suffer from some noise (made up keystrokes - other process flushing the cache entry for you). But I guess if you run this long enough and the admin comes to the console and types the root password and you see root in the keystroke stream and you have luck that no other activity created too much fake keystrokes, then you can know or at least well guess for the password. Of course this will be a local exploit only. This stuf is generally called side channels (don't confuse with covert channels). The idea is that a secret information leaks out and can be read in supposedly irrelevant signs of the CPU operation. It's the CPU equivalent of trashdiving - picking up those yellow post-it notes from the dustbin and searching for the root passwords. Like if you ask someone and he needs a time to think even for a trivial question, then he's probably lying - he needs brain CPU time to carefully make things up in a way it doesn't create apparent discrepancies. But if you ask him are you lying, he tells you no. You are getting an access to a secret through the timing. Mikulas said he even knew some link to where they cracked OpenSSL this way - Mikulas can you post it? CL On 6/19/07, Karel Kulhavy [EMAIL PROTECTED] wrote: A friend who is happening to write his own operating system just pointed out to me that a keyboard driver cannot use - lookup tables, because timing accessing these lookup tables would yield information what key was pressed when entering a root password - tests and jumps, because the same would be possible with the BTB (branch target buffer). He said he had to write the whole driver using logical operation masking. Does OpenBSD also have this trick? How is the keyboard security designed in OpenBSD to prevent these covert channels leaking the information to an unprivileged process? CL
Re: Security of the keyboard
Yay ! Let's map everything uncached from now on! For great justice! [I was tempted to write some stuff about how keyboard keycode translation works in wscons, but it's not worth my time] Miod
OpenSSL key theft through cache timing
http://www.daemonology.net/papers/htt.pdf This is the missing link to my post about keyboard security. CL
Re: pf in 4.0 not honoring nat rule with table for vlan tagged interface
On Wed, Jun 20, 2007 at 10:47:43AM +0200, Henning Brauer wrote: * Brian A. Seklecki [EMAIL PROTECTED] [2007-06-20 07:39]: Very bizarre. The only advice I can offer is that maybe it's getting confused on - $nat_if instead of the more-pragmatic - ($nat-if). Perhaps the parse code is trying too hard to resolve $nat_if in the former, and thus finding the underlying interface instead of the logical upper layer vlan interface? no way. to teh original poster, please show: 1) ifconfig -A vlan109: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0e:0c:b2:e3:e3 vlan: 109 priority: 0 parent interface: fxp1 groups: vlan egress inet6 fe80::20e:cff:feb2:e3e3%vlan109 prefixlen 64 scopeid 0x10 inet 192.168.13.1 netmask 0xfff8 broadcast 192.168.13.7 2) pf.conf 3) pfctl -nvf /etc/pf.conf specically, compare the nat rule(s) in 2) and 3). you should see $nat_if replaced by an IP address. of course do NOT use ($nat_if) for that Ahh. #3 shows the following: nat pass log on vlan109 inet6 from tww_nets to any - fe80::20e:cff:feb2:e3e3 when #2 looks like: nat pass log on $nat_if from tww_nets to any - $nat_if And, #3 shows the following: nat pass log on vlan109 from tww_nets to any - (vlan109) round-robin when #2 looks like: nat pass log on $nat_if from tww_nets to any - ($nat_if) I guess pf picks the first address for the interface. -- albert chin ([EMAIL PROTECTED])
Re: pf in 4.0 not honoring nat rule with table for vlan tagged interface
* Albert Chin [EMAIL PROTECTED] [2007-06-20 11:24]: On Wed, Jun 20, 2007 at 10:47:43AM +0200, Henning Brauer wrote: * Brian A. Seklecki [EMAIL PROTECTED] [2007-06-20 07:39]: Very bizarre. The only advice I can offer is that maybe it's getting confused on - $nat_if instead of the more-pragmatic - ($nat-if). Perhaps the parse code is trying too hard to resolve $nat_if in the former, and thus finding the underlying interface instead of the logical upper layer vlan interface? no way. to teh original poster, please show: 1) ifconfig -A vlan109: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0e:0c:b2:e3:e3 vlan: 109 priority: 0 parent interface: fxp1 groups: vlan egress inet6 fe80::20e:cff:feb2:e3e3%vlan109 prefixlen 64 scopeid 0x10 inet 192.168.13.1 netmask 0xfff8 broadcast 192.168.13.7 strange, on all my boxes there is al least lo0 and enc0, something in your kernel is broken. and fxp* disappeared too. 2) pf.conf 3) pfctl -nvf /etc/pf.conf specically, compare the nat rule(s) in 2) and 3). you should see $nat_if replaced by an IP address. of course do NOT use ($nat_if) for that Ahh. #3 shows the following: nat pass log on vlan109 inet6 from tww_nets to any - fe80::20e:cff:feb2:e3e3 when #2 looks like: nat pass log on $nat_if from tww_nets to any - $nat_if sp pf cannot figure out the address family for this rule, and picks v6 while you want v4. so just specify v4 explicitely: nat pass log on $nat_if inet from tww_nets to any - $nat_if -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: OpenSSL key theft through cache timing
On Wed, 20 Jun 2007, Karel Kulhavy wrote: http://www.daemonology.net/papers/htt.pdf This is the missing link to my post about keyboard security. No, it isn't. You can't really compare a public key crypto operation to someone bashing at a keyboard. -d
Re: Random crash
On 6/19/07, Brian A. Seklecki [EMAIL PROTECTED] wrote: Are you doing something strong with Cryptography? No, just ssh and apache Funny, my GENERIC kernel gives me: OpenBSD 4.1 (GENERIC) #1435: Sat Mar 10 19:07:45 MST 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC Try downloading bsd from ftp.openbsd.org/pub/OpenBSD/4.1/i386 and replace the one you have and see what happens I just applied the official patch, no custom Sorry for the missing ifo, today I tried to reboot and now hangs at boot...
rdr outgoing traffic
Hello. I have machine with one interface pcn0 and ip 192.168.1.7 and I was trying to redirect outgoing traffic from it with no success. My pf rule: rdr on pcn0 inet proto tcp from pcn0 to 192.168.1.1 port 80 - 192.168.1.10 When I do telnet 192.168.1.1 80 it doesn't redirect traffic. What am I doing wrong? Thanks in advance. -- RafaE Brodewicz
Re: rdr outgoing traffic
what is 192.168.1.10 then? Hello. I have machine with one interface pcn0 and ip 192.168.1.7 and I was trying to redirect outgoing traffic from it with no success. My pf rule: rdr on pcn0 inet proto tcp from pcn0 to 192.168.1.1 port 80 - 192.168.1.10 When I do telnet 192.168.1.1 80 it doesn't redirect traffic. What am I doing wrong? Thanks in advance. -- RafaE Brodewicz
Re: pf in 4.0 not honoring nat rule with table for vlan tagged interface
On Wed, Jun 20, 2007 at 11:40:36AM +0200, Henning Brauer wrote: * Albert Chin [EMAIL PROTECTED] [2007-06-20 11:24]: On Wed, Jun 20, 2007 at 10:47:43AM +0200, Henning Brauer wrote: * Brian A. Seklecki [EMAIL PROTECTED] [2007-06-20 07:39]: Very bizarre. The only advice I can offer is that maybe it's getting confused on - $nat_if instead of the more-pragmatic - ($nat-if). Perhaps the parse code is trying too hard to resolve $nat_if in the former, and thus finding the underlying interface instead of the logical upper layer vlan interface? no way. to teh original poster, please show: 1) ifconfig -A vlan109: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 lladdr 00:0e:0c:b2:e3:e3 vlan: 109 priority: 0 parent interface: fxp1 groups: vlan egress inet6 fe80::20e:cff:feb2:e3e3%vlan109 prefixlen 64 scopeid 0x10 inet 192.168.13.1 netmask 0xfff8 broadcast 192.168.13.7 strange, on all my boxes there is al least lo0 and enc0, something in your kernel is broken. and fxp* disappeared too. Sorry, I only posted the ifconfig of the vlan interface, not the full ifconfig output. 2) pf.conf 3) pfctl -nvf /etc/pf.conf specically, compare the nat rule(s) in 2) and 3). you should see $nat_if replaced by an IP address. of course do NOT use ($nat_if) for that Ahh. #3 shows the following: nat pass log on vlan109 inet6 from tww_nets to any - fe80::20e:cff:feb2:e3e3 when #2 looks like: nat pass log on $nat_if from tww_nets to any - $nat_if sp pf cannot figure out the address family for this rule, and picks v6 while you want v4. so just specify v4 explicitely: nat pass log on $nat_if inet from tww_nets to any - $nat_if Indeed, thanks. -- albert chin ([EMAIL PROTECTED])
Re: rdr outgoing traffic
On Wed, 20 Jun 2007 12:00:18 +0200, RafaE Brodewicz [EMAIL PROTECTED] wrote: Hello. I have machine with one interface pcn0 and ip 192.168.1.7 and I was trying to redirect outgoing traffic from it with no success. My pf rule: rdr on pcn0 inet proto tcp from pcn0 to 192.168.1.1 port 80 - 192.168.1.10 When I do telnet 192.168.1.1 80 it doesn't redirect traffic. What am I doing wrong? http://www.openbsd.org/faq/pf/rdr.html#reflect -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: cannot enable executable stack...
It appears that a similar bug was encountered by Debian in 2005. See http://lists.debian.org/debian-glibc/2005/08/msg00289.html http://lists.debian.org/debian-glibc/2005/08/msg00311.html http://lists.debian.org/debian-glibc/2005/08/msg00483.html This would suggest that it might be a problem with OpenBSD's compat_linux.
Re: linker scripts
O/H Chris Kuethe ]cqaxe: Let me spin that around and ask you, what is the logic behind having linker scripts? If our bootloader can load a simple elf binary (or maybe one built with a slightly different text address) then why use linker scripts? CK A simple answer to a simple question. Thank you Chris. Constantine PS Next time cc your answer to the list so that others can benefit from it. On 6/19/07, Constantine Kousoulos [EMAIL PROTECTED] wrote: Having a linux background (and a limited NetBSD experience), i expected to find linker scripts in the kernel source code. However, this is simply not true for most architectures. What is the logic behind the lack of linker scripts? Thanks, Constantine
Icecast on OpenBSD
Hi, I have been experimenting with having a stream from my desktop computer, so that I can tune in on my PDA while I am cooking in the kitchen for example. I have mpd installed nicely. The icecast output module for mpd has proven too resource intensive for my 1.6gHz (which shocked me), so I am going to try using ices2 to directly grab what the sound card is playing. Here is the input module section of my ices2.xml: input modulesun/module param name=device/dev/audio/param param name=rate44100/param param name=channels2/param param name=metadata0/param !--param name=metadatafilename/home/ices/metadata/param-- /input So, mpd is playing through the soundcard, the icecast server is up and waiting for sources. # ices2 /etc/ices2.xml [2007-06-20 14:07:46] INFO ices-core/main IceS 2.0.1 started... [2007-06-20 14:07:46] EROR input-sun/sun_open_module Failed to open audio device /dev/audio: Device busy [2007-06-20 14:07:46] EROR input/input_loop Couldn't initialise input module sun [2007-06-20 14:07:46] INFO ices-core/main Shutdown complete And ktrace reveals this snippet: 23249 ices2CALL open(0x885cc770,0,0) 23249 ices2NAMI /dev/audio 23249 ices2RET open -1 errno 16 Device busy Surely the device should be busy if I am to take data from it? Or have I misunderstood? I have also tried /dev/audio0,sound,sound0 all with no success. Has anyone else had this working? -- Best Regards Edd --- http://students.dec.bournemouth.ac.uk/ebarrett
Re: [Nagiosplug-devel] nagios check_carp for OpenBSD carp(4)
Just to follow-up: I have written a plugin that uses the somewhat complete PHP Net-SNMP bindings (no getsnmptable() ?!) and the new PF-MIB::CARP Agent Extensions to Net-SNMP snmpd(8). I'll post it on NagiosExchange for review if/when I can deploy a production 4.1-stable system. ~BAS On Fri, 2006-12-15 at 19:15 -0500, Brian A. Seklecki wrote: Thoughts? Strategies? Ideas? --- IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
Re: Security of the keyboard
Miod Vallat [EMAIL PROTECTED] writes: Yay ! Let's map everything uncached from now on! For great justice! Yay! Then we can start inlining code again for greater performance! //art
Re: Security of the keyboard
Karel Kulhavy [EMAIL PROTECTED] writes: On Tue, Jun 19, 2007 at 07:05:38PM -0700, Don Scott wrote: I think Artur Grabowski too easily dismisses the question. I'd be interested to know if you get any informative responses that are not also posted to [EMAIL PROTECTED] Mikulas (the friend) told me the algorithm to hack the root password. First you need to know the addresses of the individual keys in the translation tables - that's probably doable from the operating system kernel memory map. Then you need to know how many way associative your cache is and how the addresses are shared. If it's say 4-way you use 4 addresses in your userspace that share the cache entry. Then you read all of them 4. Now comes the monitoring phase. You cyclically time how long it takes to read each of these 4 addresses using rdtsc. When you get anomalously high reading on any of them, you know the given address in the key translation table has been accessed. This will probably suffer from some noise (made up keystrokes - other process flushing the cache entry for you). probably? some noise? In pure theory, when the keyboard input is the only thing going on in the machine, when the machine is disconnected from the network, has no disk I/O when the password is typed and no other processes running, you still get a few timer interrupts for every character being typed (you do not type faster than 100 characters per second). Not only that, but the whole path between the actual keyboard interrupt and whereever you could find a table lookup (guess what? many table entires share the same cache lines) stomps on so much cache that you'd be completly lost in the noise. This is assuming a hyperthreaded cpu where the monitoring thread can run uninterrupted all the time. Without that, you're even more screwed because the context switches will add even more noise to the side channel. These kinds of attacks are barely theoretically possible when the attacker completly controls the operation that he's snooping on (which happens with crypto operations). To use this for passive monitoring of events as rare as keyboard input sounds like sensationalism. Sure, in a very distant theory it might actually be doable, but rubber hose cryptoanalysis is much more realistic in almost all scenarios I can imagine. And guess what. Keyboards use a serial protocol. Which means that there will be slightly different voltage drops in the system varying with the keys you press. ZOMG! OpenBSD provides a side channel for attackers through the sensors framework! And you can also use the information about keyboard interrupts that you can get through sysctls to get more or less exact timing of when keys are pressed, which will give you much more accurate information about what's being typed since the timing between key strokes is much easier to analyze than the noise you'd get from cache timing. //art
Re: Security of the keyboard
Artur Grabowski [EMAIL PROTECTED] writes: And guess what. Keyboards use a serial protocol. Which means that there will be slightly different voltage drops in the system varying with the keys you press. ZOMG! OpenBSD provides a side channel for attackers through the sensors framework! And don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). //art
Re: Security of the keyboard
Artur Grabowski [EMAIL PROTECTED] writes: And don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). Now that last bit is almost certainly pure speculation, since, as the aps man page says, IBM has not provided any useful documentation. Who knows what a suitably knowledgeable attacker who sits patiently waiting for your keystrokes to be caught by the sensors could do with the data? Don't ask me, ask USENET. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ First, we kill all the spammers The Usenet Bard, Twice-forwarded tales delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Icecast on OpenBSD
On 2007/06/20 14:11, Edd Barrett wrote: So, mpd is playing through the soundcard, the icecast server is up and waiting for sources. There's no mixer/splitter on /dev/audio; unless it's set to non-blocking it can't be shared. (When it is non-blocking, you can still expect some fun...see ports@ about audiotest, for example).
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 large_table in this process? How does it work? It's really just a curiosity about pfctl internals. Thanks, f.
Re: Security of the keyboard
Yay ! Let's map everything uncached from now on! For great justice! [I was tempted to write some stuff about how keyboard keycode translation works in wscons, but it's not worth my time] Miod You don't have to map keyboard map uncached, just change the way code is written --- instead of x = a[i] you write something like x = 0; for (j = 0; j sizeof a/sizeof *a; j++) x |= a[j] (-(i ^ j) 31) - 1; Keyboard reading code is in sys/dev/wscons/wskbdutil.c, function wskbd_get_mapentry. It scans the keymap linearly until it finds the key pressed. So, by amount of L2 cache lines eaten, an attacker could tell which class of keys was pressed. Mikulas
Re: Security of the keyboard
On Wed, Jun 20, 2007 at 04:00:01PM +0200, Artur Grabowski wrote: Karel Kulhavy [EMAIL PROTECTED] writes: On Tue, Jun 19, 2007 at 07:05:38PM -0700, Don Scott wrote: I think Artur Grabowski too easily dismisses the question. I'd be interested to know if you get any informative responses that are not also posted to [EMAIL PROTECTED] Mikulas (the friend) told me the algorithm to hack the root password. First you need to know the addresses of the individual keys in the translation tables - that's probably doable from the operating system kernel memory map. Then you need to know how many way associative your cache is and how the addresses are shared. If it's say 4-way you use 4 addresses in your userspace that share the cache entry. Then you read all of them 4. Now comes the monitoring phase. You cyclically time how long it takes to read each of these 4 addresses using rdtsc. When you get anomalously high reading on any of them, you know the given address in the key translation table has been accessed. This will probably suffer from some noise (made up keystrokes - other process flushing the cache entry for you). probably? some noise? In pure theory, when the keyboard input is the only thing going on in the machine, when the machine is disconnected from the network, has no disk I/O when the password is typed and no other processes running, you still get a few timer interrupts for every character being typed (you do not type faster than 100 characters per second). Not only that, but the whole path between the actual keyboard interrupt and whereever you could find a table lookup (guess what? many table entires share the same cache lines) stomps on so much cache that you'd be completly lost in the noise. This is assuming a hyperthreaded cpu where the monitoring thread can run uninterrupted all the time. Without that, you're even more screwed because the context switches will add even more noise to the side channel. These kinds of attacks are barely theoretically possible when the attacker completly controls the operation that he's snooping on (which happens with crypto operations). To use this for passive monitoring of events as rare as keyboard input sounds like sensationalism. Sure, in a very distant theory it might actually be doable, but rubber hose cryptoanalysis is much more realistic in almost all scenarios I can imagine. This kind of security design is assuming favourable constellation of uncontrollable environmental noises to scramble the information we are knowingly leaking. It's basically a snake oil. We have no proof that under every conceivable circumstances the noises will be present in a way that completely masks the information leak. Why not write the keyboard driver the same way how the friend did it in his OS - using bitmasking and avoiding conditional jumps and lookup tables? Then the security would be guaranteed and not just hoped for. And guess what. Keyboards use a serial protocol. Which means that there will be slightly different voltage drops in the system varying The capacitors and regulator which are made to keep the voltage almost constant with a swing of tens of amperes (60W/1.5V=40A) will not permit a measurable swing when you change the current draw by a milliamp or so. The precision of voltage measurement is too low for this and the noise from other permanently running sources too high. CL
Re: Security of the keyboard
On Wed, Jun 20, 2007 at 06:14:07PM +0200, Karel Kulhavy wrote: And guess what. Keyboards use a serial protocol. Which means that there will be slightly different voltage drops in the system varying The capacitors and regulator which are made to keep the voltage almost constant with a swing of tens of amperes (60W/1.5V=40A) will not permit a measurable swing when you change the current draw by a milliamp or so. The precision of voltage measurement is too low for this and the noise from other permanently running sources too high. This kind of security design is assuming favourable constellation of uncontrollable environmental noises to scramble the information we are knowingly leaking. It's basically a snake oil. We have no proof that under every conceivable circumstances the noises will be present in a way that completely masks the information leak. -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: Security of the keyboard
Karel Kulhavy wrote: This kind of security design is assuming favourable constellation of uncontrollable environmental noises to scramble the information we are knowingly leaking. It's basically a snake oil. We have no proof that under every conceivable circumstances the noises will be present in a way that completely masks the information leak. Or, on exit to user mode, flush the caches, TLB, and branch target cache. This would kill any such leaks. Or, compile to PIC, and use a random number generator to reassign load addresses every time the kernel is loaded, and break up the kernel into chunks so the addresses used by the keyboard code are unknown. Or, for any process which is CPU bound, sample its instruction stream and if it is using instructions which probe CPU resources, kill the process. Or, who knows... there are probably dozens of ways to prevent leakage of this kind. It's still amazingly improbable that any information could usefully get through this way. Banging on the walls deliberately trying to transfer information from process to process can only send a few bits a second in most cases, which is why getting information about computationally intensive things like cryptography might work.
Re: Locations of stable ports vs current ports
On Wed, Jun 20, 2007 at 10:05:25AM -0700, Joe S wrote:
This site has a nice interface to ports: http://ports.openbsd.nu/
But they ports it says are in OpenBSD are not in my tree. Is this
site showing current only?
That site isn't run by the project; I assume it follows -current,
but you could check their FAQ (or compare file revisions).
The cvs website on openbsd.org
(http://www.openbsd.org/cgi-bin/cvsweb/ports/) also has the www/rt
port. Is the cvs website showing current too?
cvsweb will show you whatever you want it to. Look for the 'Show
only files with tag' button at the bottom, and select the version
you're interested in.
--
o--{ Will Maier }--o
| web:...http://www.lfod.us/ | [EMAIL PROTECTED] |
*--[ BSD Unix: Live Free or Die ]--*
Re: Security of the keyboard
On 6/20/07, Karel Kulhavy [EMAIL PROTECTED] wrote: This kind of security design is assuming favourable constellation of uncontrollable environmental noises to scramble the information we are knowingly leaking. It's basically a snake oil. We have no proof that under every conceivable circumstances the noises will be present in a way that completely masks the information leak. Why not write the keyboard driver the same way how the friend did it in his OS - using bitmasking and avoiding conditional jumps and lookup tables? Then the security would be guaranteed and not just hoped for. so why don't you provide us with a program that recovers the root password? that will make it much easier to assess whether the attack is real or not.
SNMP monitoring script
I recently started messing with SNMP, and I found that attempting to
get it to do active monitoring via snmpd results in a segfault. could
be my box, could be that it's a new implementation, could be bad mojo.
in any event, I decided I'd reached the point of diminishing returns
via troubleshooting, so I went ahead and wrote up a script to do what
I wanted snmpd to do. Namely, monitor the processes in the snmpd.conf
file, and email me trap notifications if there are any issues.
pre
#!/usr/local/bin/bash
# procmon - given an snmpd.conf file, this script monitors
# given proc directives for process status since
# snmpd segfaults like a whiny bitch when you ask it
# to do active process monitoring. Iggdawg dislikes
# whiny bitches. Notifies via snmptrap.
COUNT=1
CONFIG=/etc/snmp/snmpd.conf
for name in $(cat $CONFIG | grep proc | awk '{print $2}')
do
if [ -e /tmp/proc.$COUNT ] ; then
if [ $(/usr/local/bin/snmpwalk -v 1 -c localpass localhost
1.3.6.1.4.1.2021.2.1.100.$COUNT | awk '{ print $4 }') = 0 ] ; then
/usr/local/bin/snmptrap -v 2c -c localpass localhost ''
1.3.6.1.4.1.2021.2.1.101.$COUNT UCD-SNMP-MIB::prErrMessage.$COUNT s
$(echo Trouble with $name has cleared)
rm /tmp/proc.$COUNT
else
COUNT=$(( $COUNT + 1 ))
fi
else
if [ $(/usr/local/bin/snmpwalk -v 1 -c localpass localhost
1.3.6.1.4.1.2021.2.1.100.$COUNT | awk '{ print $4 }') != 0 ] ; then
touch /tmp/proc.$COUNT
echo $name has issues. Here's the skinny:
$(/usr/local/bin/snmpwalk -v 1 -c localpass localhost
1.3.6.1.4.1.2021.2.1.101.$COUNT) /tmp/proc.$COUNT
/usr/local/bin/snmptrap -v 2c -c localpass localhost ''
1.3.6.1.4.1.2021.2.1.101.$COUNT UCD-SNMP-MIB::prErrMessage.$COUNT s
$(cat /tmp/proc.$COUNT)
COUNT=$(( $COUNT + 1 ))
else
COUNT=$(( $COUNT + 1 ))
fi
fi
done
/pre
Change to the shell of your choice. I chose bash, that's how I roll.
I'll explain a little for those less experienced with scripts. It
reads off your existing snmpd.conf file and reports when a process
goes down. It makes a lockfile so it won't report more than once.
Every time the script is run, it checks to see if any previously
reported problems have been resolved. it notifies and kills the
lockfile if this is the case. I run this script as */5 * * * * in
cron.
So far as I know, this supports MIN/MAX flags on the proc directive in
the config file. I tested it by killing my internal ftp-proxy process
bound to localhost:8021 triggering the proc ftp-proxy 2 2 line. the
trap showed up in my email, and reported to snmptrapd via its existing
config file. Basically you can drop this in and have it just work
if you have snmpd and snmptrapd set up and running as proper (emailing
restart events at least, for instance), respecting only path changes
depending on your setup. Presumably this would script would expand
well to cover any of the other types of monitor OIDs with little
hassle.
PS - writing an email in a normal editor after a couple hours in vi
produces more xs than las vegas.
Re: incoming load balancing
I moved this to the appropriate list. Please read this page, http://www.openbsd.org/mail.html to see why it was moved. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luciano M. Mercucci Sent: Wednesday, June 20, 2007 11:34 AM To: [EMAIL PROTECTED] Subject: incoming load balancing Gentlemen, I am new in the list. I am with problem of incoming load balancing for links. Example I have 2 ext_if and 1 int_if and my server web behind openBSD 4,1 with mpath. The problem is that the times function the times not, it is lost. Vi in incoming forums that of the one not to balance links, a unica solution would be, to activate the roteamento in the modems ADSL and Wire Modem. It is this same, does not have as? To balance the entrance of trustworthy form? The Exit is functioning. Thanks, Luciano
Re: Locations of stable ports vs current ports
On Wed, Jun 20, 2007 at 10:05:25AM -0700, Joe S wrote: I'm running openbsd 4.1-stable. I'm also using cvsup to get/update ports-stable [snip] This site has a nice interface to ports: http://ports.openbsd.nu/ But they ports it says are in OpenBSD are not in my tree. Is this site showing current only? Yes. The cvs website on openbsd.org (http://www.openbsd.org/cgi-bin/cvsweb/ports/) also has the www/rt port. Is the cvs website showing current too? The cvs website contains the entire repository, so it shows -current and can also show every revision. The web access tool is very useful, as it can show you logs of every change made to every collection since incept. e.g.: http://www.openbsd.org/cgi-bin/cvsweb/ports/www/Makefile?annotate=1.279 shows that www/rt was added to ports/www/Makefile in revision 1.265, and http://www.openbsd.org/cgi-bin/cvsweb/ports/www/Makefile/ shows that was done on March 19. When you checkout a tree from a repository with an OPENBSD_X_Y tag, you are checking out the -stable tree. You can also checkout other trees, such as -release (OPENBSD_X_Y_BASE), or -current at a particular date and time (e.g.: -D 2007-06-01 16:00). You will probably find cvs(1) very helpful in understanding what you have, though cvsup in checkout mode does not produce the CVS structures you would have in a true cvs working directory.
Re: Security of the keyboard
On Wednesday 20 June 2007 12:28:28 Darrin Chandler wrote: On Wed, Jun 20, 2007 at 06:14:07PM +0200, Karel Kulhavy wrote: And guess what. Keyboards use a serial protocol. Which means that there will be slightly different voltage drops in the system varying The capacitors and regulator which are made to keep the voltage almost constant with a swing of tens of amperes (60W/1.5V=40A) will not permit a measurable swing when you change the current draw by a milliamp or so. The precision of voltage measurement is too low for this and the noise from other permanently running sources too high. This kind of security design is assuming favourable constellation of uncontrollable environmental noises to scramble the information we are knowingly leaking. It's basically a snake oil. We have no proof that under every conceivable circumstances the noises will be present in a way that completely masks the information leak. Karel, If you want to control the keyboard, look for the TEMPEST standard for emi/rf reduction. I'm sure the standard has been leaked by now. That will solve your fears of folks getting data from it. --STeve Andre'
Re: cannot enable executable stack...
On 6/20/07, Matthew Szudzik [EMAIL PROTECTED] wrote: It appears that a similar bug was encountered by Debian in 2005. See http://lists.debian.org/debian-glibc/2005/08/msg00289.html http://lists.debian.org/debian-glibc/2005/08/msg00311.html http://lists.debian.org/debian-glibc/2005/08/msg00483.html This would suggest that it might be a problem with OpenBSD's compat_linux. right. i'm not even sure what the growsdown flag does. linux compat is really only maintained to the extent that people find issues and fix them. you could try having the mprotect mask out the bad bits and cross your fingers.
max number of connections through the firewall
I am trying to approximate the maximum number of open TCP connections that an OpenBSD firewall can support at any given time. The scenario here is a firewall with 2 interfaces, a bunch of Web servers behind it on private IP addresses, a fairly simple set of rules (NAT each server on a public IP address on the external interface, allow HTTP in, deny the rest). How much memory is used by every new TCP connection that the firewall needs to keep track of? Will the firewall run into other problems before it runs out of memory? Will NAT use memory in the scenario described above? -- Florin Andrei http://florin.myip.org/
Re: Security of the keyboard
And guess what. Keyboards use a serial protocol. Which means that there will be slightly different voltage drops in the system varying with the keys you press. ZOMG! OpenBSD provides a side channel for attackers through the sensors framework! And don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). well, and dont' forget the physical attack angle. Between the screen leakage perhaps being used to detect a large number of pink pixels and the aps(4) sensor leakage could probably detect the rythmic thumping when the laptop owner is doing some one handed laptop driving when the other hand is occupied. An attacker could use this information to then physically take control of the machine while the operator has both hands busy and is vulnerable! -Bob
Re: max number of connections through the firewall
From previous discussions (search the archives) this has nothing to do with userland memory available but to kernel data structures. Also read pf.conf(5) man page: OPTIONS pf(4) may be tuned for various situations using the set command. interval Interval between purging expired states and [...snip...] set limit states 1 ~BAS On Wed, 20 Jun 2007, Florin Andrei wrote: I am trying to approximate the maximum number of open TCP connections that an OpenBSD firewall can support at any given time. The scenario here is a firewall with 2 interfaces, a bunch of Web servers behind it on private IP addresses, a fairly simple set of rules (NAT each server on a public IP address on the external interface, allow HTTP in, deny the rest). How much memory is used by every new TCP connection that the firewall needs to keep track of? Will the firewall run into other problems before it runs out of memory? Will NAT use memory in the scenario described above? -- Florin Andrei http://florin.myip.org/ l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ Guilty? Yeah. But he knows it. I mean, you're guilty. You just don't know it. So who's really in jail? ~Maynard James Keenan
Re: Security of the keyboard
* Bob Beck wrote: And guess what. Keyboards use a serial protocol. Which means that there will be slightly different voltage drops in the system varying with the keys you press. ZOMG! OpenBSD provides a side channel for attackers through the sensors framework! And don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). well, and dont' forget the physical attack angle. Between the screen leakage perhaps being used to detect a large number of pink pixels and the aps(4) sensor leakage could probably detect the rythmic thumping when the laptop owner is doing some one handed laptop driving when the other hand is occupied. An attacker could use this information to then physically take control of the machine while the operator has both hands busy and is vulnerable! I just unplugged all my keyboards.
Re: Security of the keyboard
someone already hacked you and sent that message -- be afraid On 6/20/07, Marc Balmer [EMAIL PROTECTED] wrote: * Bob Beck wrote: And guess what. Keyboards use a serial protocol. Which means that there will be slightly different voltage drops in the system varying with the keys you press. ZOMG! OpenBSD provides a side channel for attackers through the sensors framework! And don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). well, and dont' forget the physical attack angle. Between the screen leakage perhaps being used to detect a large number of pink pixels and the aps(4) sensor leakage could probably detect the rythmic thumping when the laptop owner is doing some one handed laptop driving when the other hand is occupied. An attacker could use this information to then physically take control of the machine while the operator has both hands busy and is vulnerable! I just unplugged all my keyboards.
Re: Security of the keyboard
That's ok, you can use my wep enabled wireless keyboard!! On 6/20/07, Marc Balmer [EMAIL PROTECTED] wrote: * Bob Beck wrote: And guess what. Keyboards use a serial protocol. Which means that there will be slightly different voltage drops in the system varying with the keys you press. ZOMG! OpenBSD provides a side channel for attackers through the sensors framework! And don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). well, and dont' forget the physical attack angle. Between the screen leakage perhaps being used to detect a large number of pink pixels and the aps(4) sensor leakage could probably detect the rythmic thumping when the laptop owner is doing some one handed laptop driving when the other hand is occupied. An attacker could use this information to then physically take control of the machine while the operator has both hands busy and is vulnerable! I just unplugged all my keyboards. -- This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation.
Re: pfctl explaination
On 6/20/07, Francesco Toscan [EMAIL PROTECTED] wrote: 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 large_table in this process? How does it work? It's really just a curiosity about pfctl internals. 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.
Re: cannot enable executable stack...
right. i'm not even sure what the growsdown flag does. Indeed, Linux doesn't have the same standard of documentation as OpenBSD. The PROT_GROWSDOWN flag for mprotect is not even mentioned in mprotect's man page on linux http://linux.about.com/library/cmd/blcmdl2_mprotect.htm
Re: X.org: i810 - intel update
On 6/18/07, Alexey Suslikov [EMAIL PROTECTED] wrote: Hello [EMAIL PROTECTED] As seen in http://wiki.x.org/wiki/IntelGraphicsDriver, xf86-video-i810 is no more and there is xf86-video-intel driver instead. New driver supports more chipsets including i965 and i945 (aka GMA 950 which is frequently used in laptops). Is such i810 - intel update for Xenocara planned or not (since we already have xorg-server 1.2.0 with -current Xenocara)? Unfortunatly more recent intel drivers have lots of regression on very popular existing hardware. We have xf86-video-intel 1.7.4 (the last release before the merge of the modesetting branch) in the xenocara tree, but it's not built by default, as it still installs (and advertises itsel to the X server) as 'i810'. You can build it manually (make -f Makefile.bsd-wrapper obj ; make -f Makefile.bsd-wrapper) to try it on your hardware. xf86-video-intel 2.0.0 is a whole different story. It requires xserver 1.3 and xrandr 1.2 and it's not ready for general use yet.
Re: Security of the keyboard
On Wed, 20 Jun 2007, Mikulas Patocka wrote: Yay ! Let's map everything uncached from now on! For great justice! [I was tempted to write some stuff about how keyboard keycode translation works in wscons, but it's not worth my time] Miod You don't have to map keyboard map uncached, just change the way code is written --- instead of x = a[i] you write something like x = 0; for (j = 0; j sizeof a/sizeof *a; j++) x |= a[j] (-(i ^ j) 31) - 1; What an improvement - that is so much more maintainable.
Re: Security of the keyboard
And guess what. Keyboards use a serial protocol. Which means that there will be slightly different voltage drops in the system varying with the keys you press. ZOMG! OpenBSD provides a side channel for attackers through the sensors framework! And don't forget the aps(4) sensor on Thinkpads! The accelerometer can probably measure the acceleration caused by various key strokes and that acceleration will be different depending on where on the keyboard you hit (different angles) and with which finger (different strength). well, and dont' forget the physical attack angle. Between the screen leakage perhaps being used to detect a large number of pink pixels and the aps(4) sensor leakage could probably detect the rythmic thumping when the laptop owner is doing some one handed laptop driving when the other hand is occupied. An attacker could use this information to then physically take control of the machine while the operator has both hands busy and is vulnerable! Physically AND emotionally vulnerable. That's the worst possible scenario. It's bad enough to be pwn3d, nevermind when your blood pressure is up!
cgi best practices (was: Re: http://openbsd.rt.fm/faq/faq10.html#httpdchroot)
David Newman [EMAIL PROTECTED] wrote: Anything else? perldoc perlsec has a lot of good advice. -- Stephen Takacs [EMAIL PROTECTED] http://perlguru.net/ 4149 FD56 D078 C988 9027 1EB4 04CC F80F 72CB 09DA
Interface traffic counters
I have a problem where I need to know how much traffic has passed on a
given interface. I don't need it broken down by IPs, protocols or
whatever of the sort.
After a bit of research I discovered the SIOCGIFDATA ioctl that seems
to do what I want.
I built myself a little test application to try it out (see at the end
of the mail for the code). The number it reports for my egress
interface are weird though:
$ ./ifbw pppoe0
bandwidth: 802865637b up 1907983523b down
reduced: 765.67MiB up 1.78GiB down
I am certain I downloaded at least 2.6GB in the last few days and
uploaded at least 3.2GB. Also, for the outbound traffic shaping queue
I have over this interface pftop reports 33Gb of traffic.
So I have questions for the network gurus. Am I doing something
incorrectly with my code below?
If not, are the counters just out of whack and it's normal?
Also, if anybody knows a better way to do this, please tell me.
Arnaud
The test code:
#include sys/types.h
#include sys/ioctl.h
#include sys/socket.h
#include net/if.h
#include err.h
#include stdio.h
#include stdlib.h
static struct if_data data;
int sd;
#define MAX_UNIT 9
static const char *sizes[MAX_UNIT] =
{ B, KiB, MiB, GiB, TiB, PiB, EiB, ZiB, YiB };
void reduce_size(double size, float *res, const char **unit) {
unsigned short unit_idx = 0;
while (size = 1024 unit_idx MAX_UNIT) {
size /= 1024.0;
unit_idx++;
}
*res = size;
*unit = sizes[unit_idx];
}
static struct if_data *get_if_data(char *name) {
struct ifreq ifr;
strlcpy(ifr.ifr_name, name, sizeof(ifr.ifr_name));
ifr.ifr_data = (caddr_t) data;
if (ioctl(sd, SIOCGIFDATA, (char *) ifr) 0) return NULL;
return data;
}
int main(int argc, char **argv) {
float val;
const char *unit;
if (argc != 2) {
fprintf(stderr, usage:\n);
fprintf(stderr, \tifbw ifname\n);
exit(2);
}
sd = socket(AF_INET, SOCK_DGRAM, 0);
if (sd == -1) err(1, socket);
if (get_if_data(argv[1]) == NULL) err(1, ioctl);
printf(bandwidth: %lub up %lub down\n, data.ifi_obytes, data.ifi_ibytes);
reduce_size(data.ifi_obytes, val, unit);
printf(reduced: %.2f%s up, val, unit);
reduce_size(data.ifi_ibytes, val, unit);
printf( %.2f%s down\n, val, unit);
return 0;
}
--
No, we're keeping them for 4.2 Ultimate Edition which will be
available for the low low price of $595.00. -- dlg@, talking about the
hackaton network changes.
Re: rdr outgoing traffic
On Wed, 20 Jun 2007, Jason Dixon wrote: On Wed, 20 Jun 2007 12:00:18 +0200, RafaE Brodewicz [EMAIL PROTECTED] wrote: Hello. I have machine with one interface pcn0 and ip 192.168.1.7 and I was trying to redirect outgoing traffic from it with no success. My pf rule: rdr on pcn0 inet proto tcp from pcn0 to 192.168.1.1 port 80 - 192.168.1.10 When I do telnet 192.168.1.1 80 it doesn't redirect traffic. What am I doing wrong? http://www.openbsd.org/faq/pf/rdr.html#reflect Certainly interesting reading, but I don't think it addresses OP's question. As I understand it, the refers to an ethernet, no routing through a firewall being involved. 192.168.1.7 192.168.1.1 192.168.1.10 | | | ...-+---+---+- Host7 connects through its sole interface pcn0 to an ethernet. The OP has a rule which he believes will cause tcp packets for Host1:80 to be redirected to Host10:80. OP implies (and I infer) that the rdr rule given is his only pf rule. Clearly packets going from Host7 to anywhere else pass through interface pcn0. There is no interface to reflect from in the sense of the faq entry cited. I can duplicate OP's problem. This rule is slightly different. (his Host10 is my Host2, obviously) I have added pass log. This is the ~entire~ contents of /etc/pf.conf rdr pass log on fxp0 inet proto tcp from fxp0 to 192.168.1.1 port 80 \ - 192.168.1.2 port 8080 My OS is 4.1 STABLE, i386. Note that in my kernel, net.inet.ip.forwarding=0. Also note that this kernel was booted with pf=NO in /etc/rc.conf, so the extra stuff related to that switch in /etc/rc was not performed. Trial: [EMAIL PROTECTED] root 0:167]# telnet 192.168.1.1 80 Trying 192.168.1.1... telnet: connect to address 192.168.1.1: Connection refused This does not appear to be redirected. I would have expected to see this: [EMAIL PROTECTED] root 0:167]# telnet 192.168.1.1 80 Trying 192.168.1.2... telnet: connect to address 192.168.1.2: Connection refused (No daemons are listening on port 1:80 or 2:8080). Enabling forwarding changes nothing. (I didn't expect it to.) I have time and resources (throw-away boxes on the LAN) to experiment, but request guidance and clues. I have repeated the experiment with this pf.conf and forwarding enabled: (129... is www.openbsd.org) It also failed to redirect. ## rdr pass log inet proto tcp from any to 192.168.1.1 port 80 - 129.128.5.191 port 80 pass log all ## A few years ago, I would have said to enable packet filtering in /etc/sysctl.conf, but that appears to be no longer switchable. A few trials with block filter rules shows pf to be on. Dave
OpenBSD port update
I've successfully installed OpenBSD 4.1. I'm new for OpenBSD therefore still studying how to update OpenBSD ports tree. How can i do this? Please someone tell me quick tips. If give me more detailed information i'll be very happy. -- Best regards, Erdenebat Guntomor No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail
OpenBSD port update
I've successfully installed OpenBSD 4.1. I'm new for OpenBSD therefore still studying how to update OpenBSD ports tree. How can i do this? Please someone tell me quick tips. If give me more detailed information i'll be very happy. -- Best regards, Erdenebat Guntomor mailto:[EMAIL PROTECTED]
Re: OpenBSD port update
On 6/20/07, Erka Gun [EMAIL PROTECTED] wrote: I've successfully installed OpenBSD 4.1. I'm new for OpenBSD therefore still studying how to update OpenBSD ports tree. How can i do this? Please someone tell me quick tips. If give me more detailed information i'll be very happy. Read all of this: http://www.openbsd.org/faq/faq15.html Then come and ask an informed question. Good luck! -Nick
Re: Locations of stable ports vs current ports
Ok. So it appears the port I want is in CURRENT ports. Since we're not supposed to mix CURRENT ports with a STABLE system (or vice-versa), I have to wait for this port to get included in STABLE, which I'm guessing would be in 4.2 or build it from scratch. On 6/20/07, Josh Grosse [EMAIL PROTECTED] wrote: On Wed, Jun 20, 2007 at 10:05:25AM -0700, Joe S wrote: I'm running openbsd 4.1-stable. I'm also using cvsup to get/update ports-stable [snip] This site has a nice interface to ports: http://ports.openbsd.nu/ But they ports it says are in OpenBSD are not in my tree. Is this site showing current only? Yes. The cvs website on openbsd.org ( http://www.openbsd.org/cgi-bin/cvsweb/ports/) also has the www/rt port. Is the cvs website showing current too? The cvs website contains the entire repository, so it shows -current and can also show every revision. The web access tool is very useful, as it can show you logs of every change made to every collection since incept. e.g.: http://www.openbsd.org/cgi-bin/cvsweb/ports/www/Makefile?annotate=1.279 shows that www/rt was added to ports/www/Makefile in revision 1.265, and http://www.openbsd.org/cgi-bin/cvsweb/ports/www/Makefile/ shows that was done on March 19. When you checkout a tree from a repository with an OPENBSD_X_Y tag, you are checking out the -stable tree. You can also checkout other trees, such as -release (OPENBSD_X_Y_BASE), or -current at a particular date and time (e.g.: -D 2007-06-01 16:00). You will probably find cvs(1) very helpful in understanding what you have, though cvsup in checkout mode does not produce the CVS structures you would have in a true cvs working directory.
Re: OBSD 4.1 drops to ddb with cdd0: error 22 on component 0 (and 1 (mirror))
On 6/16/07, Marius Hooge [EMAIL PROTECTED] wrote: Can at least someone tell me, why I get no replies? probably because nobody can help. sometimes things don't work out.
