Re: route -mpath and ping -I issue (with no pf)
On 2012-11-24, Gilles LAMIRAL wrote: > When I do two tcpdump on each interface I see that > when it fails the ping -I are just going on the wrong interface > even if the routing table indicates the contrary. Routes depend on the *destination* address only. Source address has no effect on which routing table entry is used for a certain packet. If you require traffic with a certain source address to be sent via a certain interface, that is not a job for the classic routing table, you will need to use another method involving PF for route selection (either route-to / reply-to, or you may be able to do this with multiple route tables). > Do you have any explanation for this routing inversion > or a workaround/good practice to have a ping -I always working as intended? This is working as intended..
Re: openbsd 5.2 i38 migrate to amd64
On 2012-11-24, bofh wrote: > On Thu, Nov 22, 2012 at 10:08 AM, Nick Holland > wrote: >> On 11/22/12 09:58, bofh wrote: >>> Can I just run install -> upgrade and install everything but etc.tgz >>> and xetc.tgz? Any post installation stuff I have to worry about? >> >> No. Reinstall completely. Do not try to "migrate" without a complete >> wipe/reload. > > Thanks! Out of curiousity, are there executables that are in i386 but > not amd64 or vice versa? I can see issues with libraries. Am just > curious. > > Better to clean out all the directories that may contain binaries (/*bin, /usr/*bin, /usr/X11R6, /usr/lib*, /usr/mdec) as well as packages (after keeping a copy of pkg_info output to feed to pkg_add -zl). It can be done (even on a running system if you're careful) but definitely not recommended. It's one of those things where if you have to ask how to do it, you probably shouldn't.
Re: upstream vendors and why they can be really harmful
(cc'ing misc instead of tech) On Sat, Nov 24, 2012 at 7:21 PM, William Ahern wrote: > On Thu, Nov 22, 2012 at 01:27:46PM -0430, Andres Perera wrote: >> On Thu, Nov 22, 2012 at 11:58 AM, Kevin Chadwick >> wrote: >> > On Thu, 22 Nov 2012 09:30:41 -0430 >> > Andres Perera wrote: >> > >> >> i'm not sure how using js for configuration files, as opposed to using >> >> a language commonly deployed for the same purpose, such as lua, >> >> presents an innate constraint on security. >> > >> > Firstly the article mentioned JIT preventing true randomisation. >> > >> > Secondly pulling in JS as a dependency even on servers is rediculous and >> > is a language very familiar to attackers and unfamiliar to many users. >> > It would be especially, shall we say kind to attackers utilising rop >> > attacks. >> >> but jit isn't irreparably interleaved with js >> >> am i compromising by running luajit in interpreter mode instead of the >> reference implementation > > Almost certainly, yes. And that's not a slight against Mike Pall's skills. > Complexity is the enemy of security, every time. Merely disabling a feature > doesn't remove its footprint from the code base. lets make something clear: using luajit as an example does not impose a strict meaning on "disable". consider it an absolute requirement that "disables" entails: not using mmap or mprotect directly, and more importantly, impose memory layout constrictions outside of what system malloc would > > And have you read any of those codebases? The reference Lua implementation > is a model of clear programming, IMO. > >>, moreover, would that imply that lua the language is insecure or is the >> specific implementation at fault? > > Lua-the-language is designed with implementation details in mind. When an > implementation details become intolerably complex, they consider removing > the feature (e.g. the new generational collector in 5.2). i'm not interested in defending the position that having the ability of choosing between two allocators, or even that the allocator is exposed to the user at all, is part of the language. i consider it a stupid argument to participate in. if the intention was to evoke the idea that, in the real world, implementation and design are not conveniently independent, then i would ask for an example that correspondingly uses an implementation detail that is relevant to the light use expected out of a configuration language by a project like polkit >> >> why would the runtime be attractive for rop? what configuration vm >> needs syscalls that would be attractive to an attacker that can change >> the address of a jump? does the runtime really need to open sockets, >> or spawn processes? (i'm not even talking about languages) > > Those syscalls are accessible in the run time environment, whether or not > they're intentionally bound. And that's all that matters, at the end of the > day. If intentions drove run time safety, there would never be attacks > against real-world code. i'm also not interested in perpetually repeating myself, specially when opposing opinions differ on what's lacking in the imaginary, js-driven sudo program. in the same message you quoted i used systrace (no deferred arg-check) as a deterrent. there's no need for overly simplistic quips like "If intentions drove run time safety, there would never be attacks against real-world code"; i don't see how those promote discussion at all
Re: relayd and header directives
Hi,
Spoke with Sebastian and Reyk an they helped me to solve the issue.
You have to apply the following patch Sebastian provided.
This is the message from Sebastian with the fix:
Hi,
the problem is that strtonum() can only handle a maximum of LLONG_MAX in
maxval.
(file: 4GB-fix-llu.patch)
diff --git a/usr.sbin/relayd/relay_http.c b/usr.sbin/relayd/relay_http.c
index 4b67295..b39c210 100644
--- a/usr.sbin/relayd/relay_http.c
+++ b/usr.sbin/relayd/relay_http.c
@@ -81,7 +81,7 @@ relay_read_http(struct bufferevent *bev, void *arg)
if (gettimeofday(&con->se_tv_last, NULL) == -1)
goto fail;
size = EVBUFFER_LENGTH(src);
- DPRINTF("%s: size %lu, to read %llu", __func__, size, cre->toread);
+ DPRINTF("%s: size %lu, to read %ll", __func__, size, cre->toread);
if (!size) {
if (cre->dir == RELAY_DIR_RESPONSE)
return;
@@ -227,7 +227,7 @@ relay_read_http(struct bufferevent *bev, void *arg)
* the carriage return? And some browsers seem to
* include the line length in the content-length.
*/
- cre->toread = strtonum(pk.value, 0, ULLONG_MAX,
+ cre->toread = strtonum(pk.value, 0, LLONG_MAX,
&errstr);
if (errstr) {
relay_abort_http(con, 500, errstr, 0);
@@ -390,7 +390,7 @@ relay_read_httpcontent(struct bufferevent *bev, void *arg)
if (gettimeofday(&con->se_tv_last, NULL) == -1)
goto fail;
size = EVBUFFER_LENGTH(src);
- DPRINTF("%s: size %lu, to read %llu", __func__,
+ DPRINTF("%s: size %lu, to read %ll", __func__,
size, cre->toread);
if (!size)
return;
@@ -399,7 +399,7 @@ relay_read_httpcontent(struct bufferevent *bev, void *arg)
if ((off_t)size >= cre->toread)
bev->readcb = relay_read_http;
cre->toread -= size;
- DPRINTF("%s: done, size %lu, to read %llu", __func__,
+ DPRINTF("%s: done, size %lu, to read %ll", __func__,
size, cre->toread);
if (con->se_done)
goto done;
@@ -427,7 +427,7 @@ relay_read_httpchunks(struct bufferevent *bev, void *arg)
if (gettimeofday(&con->se_tv_last, NULL) == -1)
goto fail;
size = EVBUFFER_LENGTH(src);
- DPRINTF("%s: size %lu, to read %llu", __func__,
+ DPRINTF("%s: size %lu, to read %ll", __func__,
size, cre->toread);
if (!size)
return;
@@ -481,7 +481,7 @@ relay_read_httpchunks(struct bufferevent *bev, void *arg)
if (relay_bufferevent_write_chunk(cre->dst, src, size) == -1)
goto fail;
cre->toread -= size;
- DPRINTF("%s: done, size %lu, to read %llu", __func__,
+ DPRINTF("%s: done, size %lu, to read %ll", __func__,
size, cre->toread);
if (cre->toread == 0) {
Bogdan
- Original Message -
From: Andrew Klettke
To: misc@openbsd.org
Cc: bo...@yahoo.com
Sent: Wednesday, November 21, 2012 1:58 AM
Subject: Re: relayd and header directives
A little more info; turns out this is happening on any POST when you have the
option ``header change "Connection" to "close"`` in your "http protocol"
stanza, and not necessarily when the header(); function is called, as I
previously thought. Here's the simple script I was using to test:
";
echo "";
echo "";
echo "";
?>
Clicking the "submit" button instantly gets me a 500 error from relayd in 5.2
when my http protocol is defined like so:
http protocol httpssl {
header append "$REMOTE_ADDR" to "X-Forwarded-For"
header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarded-By"
header change "Keep-Alive" to "$TIMEOUT"
header change "Connection" to "close"
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
return error
ssl { sslv3, tlsv1, no sslv2, ciphers
"HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM" }
}
Commenting out the ``header change "Connection to "close"`` option makes
everything work just fine, as far as I can tell.
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion
253-830-2943
On 11/20/2012 02:31 PM, Andrew Klettke wrote:
> I'm seeing this exact same issue after upgrading a firewall this afternoon;
> any use of the header(); function in PHP with SSL is causing a big "500
> Internal Server Error" page to be displayed by relayd, while the other
> firewall (which I'm now holding out on upgrading) is having no issues at all
> when it's the CARP master:
>
> Nov 20 13:06:23 fw02 relayd[4423]: relay wwwssl, session 134 (2 active), 0,
> ***.***.127.152 -> 192.168.21.218:443, invalid (500 Internal Server Error)
> Nov 20 13:06:26 fw02 relayd[32703]: relay wwwssl, session 166 (1 active), 0,
> ***.***.114.27 -> 192.168.21.207:443, invalid (500 Internal Server Error)
> Nov 20 13:06:27 fw02 relayd[5856]: relay wwwssl, session 207 (2 active), 0,
> ***.***.192.47 -> 192.168.21.218:443, invalid (500 Internal Server Error)
> Nov 20 13:06:30 fw02 relayd[32703]: relay wwwssl, session 167 (1 active), 0,
> ***.***.130.66 -> 192.168.21.213:443, inva
Re: route -mpath and ping -I issue (with no pf)
Hello, >> Do you have any explanation for this routing inversion >> or a workaround/good practice to have a ping -I always working as intended? > > This is working as intended.. The ping always work without the -I for the same destination, no pf, no multiple route tables. just a classic routing table. The kernel sets the good source address from the routing table. In the case of ping -I the kernel does a choice and this choice is always good or always wrong depending of table order construction for the same destination. Could be clever. Let's forget it. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06
Re: login.conf(5) rpasswd support removed?
On Tue, Nov 20, 2012 at 10:24:26PM -0500, Michael W. Lucas wrote: > Hi, > > login.conf includes the following: > > ... > rpasswdRequest a password and check it against the password in > the rpasswd.db file. > ... > > It seems that there's no reference to rpasswd.db in the current source > code, except for the login.conf man page. > > Should this line be removed from login.conf? I can file a bug report, > but wanted to double-check it first. > > (Credit where it's due: I didn't notice this, Pitr Hansteen caught it > doing the tech review of AO2e). > just removed the entry. thanks! jmc
ladvd - very cool
after instaling ladvd, in ifconfig i've got description from lldp this is so cool ... # ifconfig ix ix0: flags=28b43 mtu 1500 lladdr 90:e2:ba:19:29:a8 description: connected to Srce1 (1:14) priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect (10GbaseSR full-duplex) status: active ix1: flags=28b43 mtu 1500 lladdr 90:e2:ba:19:29:a8 description: connected to Srce2 (1:14) priority: 0 trunk: trunkdev trunk0 media: Ethernet autoselect (10GbaseSR full-duplex) status: active
Re: snort inline
Quick update. It seems to be a nat problem. If I just test by pinging either the 192.168.1.32 interface or the 192.168.0.13 interface it works fine and snort sees the packets. Its only when the traffic is NATed that it fails. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Justin Mayes Sent: Saturday, November 24, 2012 2:21 PM To: misc@openbsd.org Subject: snort inline Anyone running snort 2.9.3.1p0 in inline / IPS mode with 5.2 cuurent? From what I read it's possible with pf divert functionality. This is what I'm doing for testing in pf using simple ping Gateway info internal interface fxp0 - 192.168.1.32 external interface bce0 - 192.168.0.13 Running snort via this cmd line snort --daq-dir /usr/local/lib/daq -Q --daq ipfw -c /etc/snort/snort.conf -v Internal interface is in the skip list hence no active rules for it Pfctl -sr pass out on bce0 all flags S/SA scrub (reassemble tcp) nat-to (bce0:0) pass in on bce0 inet all flags S/SA scrub (reassemble tcp) This works as expected, I can ping 8.8.8.8 and since no diverting is active snort sees nothing I change rules to this to start diverting to snort Pfctl -sr pass out on bce0 all flags S/SA scrub (reassemble tcp) divert-packet port 8000 nat-to (bce0:0) pass in on bce0 inet all flags S/SA scrub (reassemble tcp) Now internal interface sees outgoing ping tcpdump -n -i fxp0 -n host 8.8.8.8 192.168.1.32 > 8.8.8.8: icmp: request: External interface shows it going out and coming back 192.168.0.13 > 8.8.8.8: icmp: request: 8.8.8.8 > 192.168.0.13: icmp: reply: Snort sees it twice, external interface first 192.168.0.13 -> 8.8.8.8 ICMP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF Type:8 Code:0 ID:64870 Seq:2 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 8.8.8.8 -> 192.168.1.32 ICMP TTL:48 TOS:0x20 ID:64655 IpLen:20 DgmLen:84 Type:0 Code:0 ID:52297 Seq:2 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Client @ 192.168.1.32 never sees reply. Any comments or suggestions? Justin Mayes [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: libiconv & openssl & expat
On 25/11/2012 16:53, Raindy Long wrote: It seems that libiconv is not in the base package , right ? libiconv is in packages/ports Port: libiconv-1.14 Path: converters/libiconv Info: character set conversion library Maint: Brad Smith Index: converters devel L-deps: B-deps: devel/gperf R-deps: Archs: any
