Re: recommended input methods?
On Tue, Oct 14, 2014 at 3:14 PM, Bryan Linton wrote: > On 2014-10-14 14:02:52, Joel Rees wrote: >> What're the recommended input methods for Japanese and Spanish? >> > > [...] > The only complaint I have is that for some applications, namely > xombrero and xfe, they either do not accept Japanese input unless > their locale is specifically changed to Japanese, such as is the > case with xombrero, which has the side-effect of changing all > fonts to Japanese equivalents which makes for rather "ugly" font > choices made for the Latin alphabet, > [...] Yeah. The so-called two-byte characters are not appropriate for those. If somebody doesn't beat be to it, I'll have to see if I can find where to fix that. But it's not going to be this month or next I'm afraid. I'm still trying to figure out whether I've got enough of the locale system set up to do something sensible when I say "export LANG=ja_JP.UTF-8". -- Joel Rees Be careful when you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself.
Re: looking for coding hints with ptrace(2)
On Fri, Oct 17, 2014 at 1:34 PM, Peter J. Philipp wrote:
> I'm trying to read the stack of another process that has the same user
> credentials. Here is my program, I am stuck with this, it doesn't work
> for me. Printing 0's is rewrapped to '.' and you should use this program
> with hexdump like so: ./memtest [pid] | hexdump -C | less
> Sometimes I get a bit of the stack but it seems random, dunno what the
> deal is.
...
> int
> main(int argc, char *argv[])
> {
> int64_t stackend = USRSTACK;
> int64_t offset;
So 'offset' is a variable in the stack of this process...
> memset(&ptid, 0, sizeof(ptid));
> ptid.piod_op = PIOD_READ_I;
> ptid.piod_offs = (void*)&offset;
...and you're telling ptrace() to take the address of 'offset' in
_this_ process and read from that address in the _target_ process.
That's not what you want; the '&' in that line should be removed.
After that, the program works for me.
> status = ptrace(PT_IO, pid, (caddr_t)&ptid, sizeof(ptid));
The 4th argument to ptrace(...PT_IO...) is ignored and doesn't need to
be the size of the ptid structure.
Finally, if a ptrace() call after the PT_ATTACH fails then you
probably want to jump to detaching instead of exiting while attached
(which will kill the target process).
Philip Guenther
Re: looking for coding hints with ptrace(2)
On 10/17/14 22:38, Theo de Raadt wrote: >> I'm trying to read the stack of another process that has the same user >> credentials. Here is my program, I am stuck with this, it doesn't work >> for me. Printing 0's is rewrapped to '.' and you should use this program >> with hexdump like so: ./memtest [pid] | hexdump -C | less >> Sometimes I get a bit of the stack but it seems random, dunno what the >> deal is. > > In OpenBSD, each process has the same 'stack space' (a large region), > but actual area in use is biased randomly up to 256K or so. > > % sysctl kern.stackgap_random > kern.stackgap_random=262144 > Stackgap! That's awesome! Too bad I forgot about it. And like it wasted my time it'll waste attackers time. Let me share what I was able to do on another OS. I wrote a proof-of-concept that reads crypto keys out of a certain program's stack while the user is hitting saving the crypto to a file. I'm not going to name that program but what's important, and I learned this lesson from OpenBSD, is that that cryptokeys and passwords are zero'ed right after their use. So thanks for both the stackgap and zero'ing keys! That's simply brilliant and makes attackers life harder. Cheers, -peter
Re: Fix xfe (Was: sudo bad practice or inconsistency?)
On Fri 17/10 17:39, Raimo Niskanen wrote: > > As I read the man page for su it is the target's login shell that is > invoked, and it need not always be /bin/sh - it can be changed. > > Therefore I suspect that you want "-s /bin/sh " between "su " and "root". I'm confused: just22@poseidon:[~]> sudo su -s /bin/sh root -c date Sat Oct 18 07:21:40 CEST 2014 just22@poseidon:[~]> su -s /bin/sh root -c date su: only the superuser may specify a login shell (this is really weird). Moreover, using the following: #define SUCMD "-fn 7x14 -geometry 60x4 -e su root -c 'nohup xfe >/dev/null 2>&1 & sleep 1'" xfe correctly opens the password's window, but the echo is active during typing... (the same doesn't happen when I use sudo). It's just me? -- Alessandro DE LAURENZIS [mailto:just22@gmail.com] LinkedIn: http://it.linkedin.com/in/delaurenzis
Re: LibreSSL 2.1.1 released.
On Thu, Oct 16, 2014 at 9:15 AM, Bob Beck wrote: > We have released LibreSSL 2.1.1- which should be arriving in the > LIbreSSL directory of an OpenBSD mirror near you very soon. If I clone the GitHub repo from Bolivia, do I have to cut my eyeballs out or stand guilty of re-exporting munitions from the USA? Ian
Re: looking for coding hints with ptrace(2)
> I'm trying to read the stack of another process that has the same user > credentials. Here is my program, I am stuck with this, it doesn't work > for me. Printing 0's is rewrapped to '.' and you should use this program > with hexdump like so: ./memtest [pid] | hexdump -C | less > Sometimes I get a bit of the stack but it seems random, dunno what the > deal is. In OpenBSD, each process has the same 'stack space' (a large region), but actual area in use is biased randomly up to 256K or so. % sysctl kern.stackgap_random kern.stackgap_random=262144
looking for coding hints with ptrace(2)
I'm trying to read the stack of another process that has the same user
credentials. Here is my program, I am stuck with this, it doesn't work
for me. Printing 0's is rewrapped to '.' and you should use this program
with hexdump like so: ./memtest [pid] | hexdump -C | less
Sometimes I get a bit of the stack but it seems random, dunno what the
deal is.
#include
#include
#include
#include
#include
#include
#include
#include
#include
int
main(int argc, char *argv[])
{
int64_t stackend = USRSTACK;
int64_t offset;
int64_t memsize;
char page[4096];
int pid, i;
size_t len;
int status;
char *p;
struct ptrace_io_desc ptid;
struct reg myreg;
if (argc < 2) {
perror("args");
exit(1);
}
fprintf(stderr, "stackend = %llx\n", stackend);
pid = atoi(argv[1]);
if (ptrace(PT_ATTACH, pid, NULL, 0) < 0) {
perror("ptrace");
exit(1);
}
waitpid(pid, NULL, 0);
if (ptrace(PT_GETREGS, pid, (caddr_t)&myreg, sizeof(myreg)) < 0) {
perror("ptrace getregs");
exit(1);
}
offset = myreg.r_rsp;
fprintf(stderr, "bottom of stack = %llx\n", offset);
memsize = stackend - offset;
p = calloc(1, memsize);
if (p == NULL) {
perror("malloc");
exit(1);
}
fprintf(stderr, "memsize = %llx\n", memsize);
memset(&ptid, 0, sizeof(ptid));
ptid.piod_op = PIOD_READ_I;
ptid.piod_offs = (void*)&offset;
ptid.piod_addr = (void*)p;
ptid.piod_len = memsize;
status = ptrace(PT_IO, pid, (caddr_t)&ptid, sizeof(ptid));
for (i = 0; i < ptid.piod_len; i++) {
printf("%c", ((p[i] != 0) ? p[i] : '.'));
}
status = ptrace(PT_DETACH, pid, NULL, 0);
if (status < 0) {
perror("ptrace detach");
exit(1);
}
exit(0);
}
Thanks for any hints,
-peter
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 02:59:26PM -0400, Ian Grant wrote: > On Fri, Oct 17, 2014 at 2:49 PM, Bret Lambert wrote: > > Well, if, as Herr Schroeder seems to be implying, this is used to > > avoid port scans, I'd look for traffic to/from address:port which > > don't show up on scans. > > That's why I want to hide it behind an ordinary service. The point being, Herr Schroeder appears to be a man who would become one of your users, and has apparently missed that step. A manual that includes an advisory to do so would likely be a good idea. > > >> Also, the VPN could be tunneled > >> over HTTP if necessary. > > > I know of at least one company which sells a product which doesn't > > just read headers, but classifies traffic based upon behavior, e.g., > > "small request receives large response -> bulk transfer", or > > "series of tiny packets which receive a single, larger response -> > > interactive session". I assume nation-states have developed similar > > capabilities. > > That's fine. But they have to analyze all the traffic. This is a > needle in a haystack. It's a good thing we don't know any nation-states that analyze all the traffic, then. That would probably be bad. > > > The ability to use statistical methods to eavesdrop on encrypted > > SIP sessions comes to mind as an example of traffic analysis as a > > tool to defeat adversaries who are attempting to secure their > > communications. > > Again, a needle in a haystack. Assuming that your adversary is going into this blind, and hasn't been given a list of interesting targets that includes your systems. States also have access to human intelligence as well. > > Please read the OP before refuting stuff on the list. If you want to > argue, and you aren't sure of your argument, e-mail me off the list. > Otherwise it just adds to the general level of confusion, which is > already higher than I'd expected on this list. Quoting the original email you sent: > If anyone here has a better idea, or any other useful advice (even if > it's "this has already been done!" or "It won't work," but please > explain exactly why.) or pointers I'm not attempting to refute the validity of what you're attempting, I'm pointing out things that probably should be taken into consideration during implementation/deployment, which I think falls under the heading of "useful advice". Whether or not it's useful is a judgement left to the reader.
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 2:49 PM, Bret Lambert wrote: > Well, if, as Herr Schroeder seems to be implying, this is used to > avoid port scans, I'd look for traffic to/from address:port which > don't show up on scans. That's why I want to hide it behind an ordinary service. >> Also, the VPN could be tunneled >> over HTTP if necessary. > I know of at least one company which sells a product which doesn't > just read headers, but classifies traffic based upon behavior, e.g., > "small request receives large response -> bulk transfer", or > "series of tiny packets which receive a single, larger response -> > interactive session". I assume nation-states have developed similar > capabilities. That's fine. But they have to analyze all the traffic. This is a needle in a haystack. > The ability to use statistical methods to eavesdrop on encrypted > SIP sessions comes to mind as an example of traffic analysis as a > tool to defeat adversaries who are attempting to secure their > communications. Again, a needle in a haystack. Please read the OP before refuting stuff on the list. If you want to argue, and you aren't sure of your argument, e-mail me off the list. Otherwise it just adds to the general level of confusion, which is already higher than I'd expected on this list. Thanks, Ian
Re: Shadow TCP stacks
2014-10-17 20:49 GMT+02:00 Bret Lambert : > Well, if, as Herr Schroeder seems to be implying, this is used to > avoid port scans, I'd look for traffic to/from address:port which > don't show up on scans. That's certainly possible but more expensive than "find all ssh servers". Best Martin
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 12:13:55PM -0400, Ian Grant wrote: > On Fri, Oct 17, 2014 at 4:24 AM, Bret Lambert wrote: > > On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: > >> 2014-10-16 13:16 GMT+02:00 Kevin Chadwick : > >> The impossibility to scan for services - which the NSA/GHCQ/... do. > > > > It's a good thing that traffic analysis isn't a thing, then. Otherwise > > they'd be able to check if traffic purporting to go to port 80/443 > > doesn't look like HTTP traffic, or something. > > They don't have any clue which traffic to analyze though, so this > traffic is a needle in a haystack. Well, if, as Herr Schroeder seems to be implying, this is used to avoid port scans, I'd look for traffic to/from address:port which don't show up on scans. > Also, the VPN could be tunneled > over HTTP if necessary. I know of at least one company which sells a product which doesn't just read headers, but classifies traffic based upon behavior, e.g., "small request receives large response -> bulk transfer", or "series of tiny packets which receive a single, larger response -> interactive session". I assume nation-states have developed similar capabilities. The ability to use statistical methods to eavesdrop on encrypted SIP sessions comes to mind as an example of traffic analysis as a tool to defeat adversaries who are attempting to secure their communications.
Re: Fix xfe (Was: sudo bad practice or inconsistency?)
On Fri, Oct 17, 2014 at 05:51:08AM -0600, David Coppa wrote: > > From: Thorsten Glaser > > Date: Fri, Oct 17, 2014 at 10:44 AM > > Subject: Re: sudo bad practice or inconsistency? > > To: misc@openbsd.org > > > > > > Alessandro DE LAURENZIS gmail.com> writes: > > > > (line-wrapped because of GMane) > > > > > #define SUDOCMD "-fn 7x14 -geometry 60x4 -e sudo su -c 'nohup \ > > > xfe >& /dev/null & sleep 1'" > > ^^ > > > > Note that this will not work on OpenBSD anyway; even mksh, which > > does implement this bashism, will not parse this as expected in > > POSIX mode. > > > > So, besides the changes the others already pointed out: > > > > #define SUDOCMD "-fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup \ > > xfe >/dev/null 2>&1 & sleep 1'" As I read the man page for su it is the target's login shell that is invoked, and it need not always be /bin/sh - it can be changed. Therefore I suspect that you want "-s /bin/sh " between "su " and "root". > > > Brian et al., ok for the diff below? > > Index: Makefile > === > RCS file: /cvs/ports/x11/xfe/Makefile,v > retrieving revision 1.33 > diff -u -p -u -p -r1.33 Makefile > --- Makefile 25 Nov 2013 18:39:02 - 1.33 > +++ Makefile 17 Oct 2014 11:45:34 - > @@ -3,7 +3,7 @@ > COMMENT= MS-Explorer like file manager for X > > DISTNAME=xfe-1.37 > -REVISION=0 > +REVISION=1 > CATEGORIES= x11 > > HOMEPAGE=http://roland65.free.fr/xfe/ > Index: patches/patch-src_xfedefs_h > === > RCS file: patches/patch-src_xfedefs_h > diff -N patches/patch-src_xfedefs_h > --- /dev/null 1 Jan 1970 00:00:00 - > +++ patches/patch-src_xfedefs_h 17 Oct 2014 11:45:35 - > @@ -0,0 +1,20 @@ > +$OpenBSD$ > + > +Unbreak launching Xfe as root with sudo or su > + > +--- src/xfedefs.h.orig Fri Oct 17 13:41:26 2014 > src/xfedefs.hFri Oct 17 13:43:44 2014 > +@@ -157,11 +157,11 @@ > + > + // Command to launch Xfe as root with sudo or su, using Xvt as a terminal > + #ifndef SUDOCMD > +-#define SUDOCMD "-fn 7x14 -geometry 60x4 -e sudo su -c 'nohup xfe >& > /dev/null & sleep 1'" > ++#define SUDOCMD "-fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup xfe > >/dev/null 2>&1 & sleep 1'" > + #endif > + > + #ifndef SUCMD > +-#define SUCMD "-fn 7x14 -geometry 60x4 -e su -c 'nohup xfe >& /dev/null & > sleep 1'" > ++#define SUCMD "-fn 7x14 -geometry 60x4 -e su root -c 'nohup xfe >/dev/null > 2>&1 & sleep 1'" > + #endif > + > + // Tooltips setup time and duration -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: httpd, php, and httpd.conf in 5.6
On Fri, Oct 17, 2014 at 9:51 AM, Zé Loff wrote: > > > Installed 5.6-current last night and saw that the new httpd daemon will > be > > using the config file /etc/httpd.conf (which looks like it needs to be > > created by hand, fine). > > > > At the risk of sounding like a knucklehead, are there good examples of > how > > to hook php to the new daemon? (Or for that matter a complete starter > > httpd.conf to use as reference material?) > > > > I've looked through man httpd.conf > > > > From reading thus far, it looks like the process will be similar to the > > process of connecting nginx with php, I'd just love to see some examples > if > > they exist to minimize the learning curve. > > /etc/examples/httpd.conf > Thanks for the speedy replies everyone. :-)
Re: httpd, php, and httpd.conf in 5.6
On Fri, Oct 17, 2014 at 09:45:41AM -0700, Kevin wrote: > All, > > Installed 5.6-current last night and saw that the new httpd daemon will be > using the config file /etc/httpd.conf (which looks like it needs to be > created by hand, fine). > > At the risk of sounding like a knucklehead, are there good examples of how > to hook php to the new daemon? (Or for that matter a complete starter > httpd.conf to use as reference material?) > > I've looked through man httpd.conf > > From reading thus far, it looks like the process will be similar to the > process of connecting nginx with php, I'd just love to see some examples if > they exist to minimize the learning curve. > > As always, thanks, > Kevin > /etc/examples/httpd.conf --
httpd, php, and httpd.conf in 5.6
All, Installed 5.6-current last night and saw that the new httpd daemon will be using the config file /etc/httpd.conf (which looks like it needs to be created by hand, fine). At the risk of sounding like a knucklehead, are there good examples of how to hook php to the new daemon? (Or for that matter a complete starter httpd.conf to use as reference material?) I've looked through man httpd.conf >From reading thus far, it looks like the process will be similar to the process of connecting nginx with php, I'd just love to see some examples if they exist to minimize the learning curve. As always, thanks, Kevin
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 9:13 AM, Ian Grant wrote: > On Fri, Oct 17, 2014 at 4:24 AM, Bret Lambert wrote: >> On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: >>> 2014-10-16 13:16 GMT+02:00 Kevin Chadwick : >>> The impossibility to scan for services - which the NSA/GHCQ/... do. >> >> It's a good thing that traffic analysis isn't a thing, then. Otherwise >> they'd be able to check if traffic purporting to go to port 80/443 >> doesn't look like HTTP traffic, or something. > > They don't have any clue which traffic to analyze though, so this > traffic is a needle in a haystack. Also, the VPN could be tunneled > over HTTP if necessary. > > Ian > Right. Because the NSA/GHCQ don't have the resources to accomplish such a goal.
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 4:24 AM, Bret Lambert wrote: > On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: >> 2014-10-16 13:16 GMT+02:00 Kevin Chadwick : >> The impossibility to scan for services - which the NSA/GHCQ/... do. > > It's a good thing that traffic analysis isn't a thing, then. Otherwise > they'd be able to check if traffic purporting to go to port 80/443 > doesn't look like HTTP traffic, or something. They don't have any clue which traffic to analyze though, so this traffic is a needle in a haystack. Also, the VPN could be tunneled over HTTP if necessary. Ian
GCC Undefined Behavior Sanitizer – ubsan
Hallo, "Undefined behavior is a concept known especially in the C and C++ languages which means that the semantics of certain operations is undefined and the compiler presumes that such operations never happen. For instance, using non-static variable before it has been initialized is undefined. If an undefined behavior occurs, the compiler is free to do anything. The application can produce wrong results, crash, or print the complete text of Proustâs oeuvre." https://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ Is it useful for OpenBSD?
relayd question - from the man page
Hi folks,
The manpage for relayd.conf has this basic construct in it a couple of times :
table { 192.168.1.1, 192.168.1.2, 192.168.2.3 }
table disable { 10.1.5.1 retry 2 }
redirect "www" {
listen on www.example.com port 80
forward to check http "/" code 200
forward to check http "/" code 200
}
And also has this to say about the "disable" attribute.
disable
The redirection is initially disabled. It can be later enabled
through relayctl(8).
What I don't understand from the given examples is how ""
above is getting re-enabled. It starts out with the table disabled -
I get that. But then within the redirect we are basically saying
(correct me if I am wrong) "always use unless it is not
availble, in which case use "
But I don't see anywhere that was re-enabled so how can it
be used? And I search through the manpage and don't see any mention
of this. Does it automatically get re-enabled within the "redirect -
forward"? And if that is the case, what was the point of starting it
disabled in the first place?
thanks,
-Alan
--
"Don't eat anything you've ever seen advertised on TV"
- Michael Pollan, author of "In Defense of Food"
Fix xfe (Was: sudo bad practice or inconsistency?)
> From: Thorsten Glaser > Date: Fri, Oct 17, 2014 at 10:44 AM > Subject: Re: sudo bad practice or inconsistency? > To: misc@openbsd.org > > > Alessandro DE LAURENZIS gmail.com> writes: > > (line-wrapped because of GMane) > > > #define SUDOCMD "-fn 7x14 -geometry 60x4 -e sudo su -c 'nohup \ > > xfe >& /dev/null & sleep 1'" > ^^ > > Note that this will not work on OpenBSD anyway; even mksh, which > does implement this bashism, will not parse this as expected in > POSIX mode. > > So, besides the changes the others already pointed out: > > #define SUDOCMD "-fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup \ > xfe >/dev/null 2>&1 & sleep 1'" Brian et al., ok for the diff below? Index: Makefile === RCS file: /cvs/ports/x11/xfe/Makefile,v retrieving revision 1.33 diff -u -p -u -p -r1.33 Makefile --- Makefile25 Nov 2013 18:39:02 - 1.33 +++ Makefile17 Oct 2014 11:45:34 - @@ -3,7 +3,7 @@ COMMENT= MS-Explorer like file manager for X DISTNAME= xfe-1.37 -REVISION= 0 +REVISION= 1 CATEGORIES=x11 HOMEPAGE= http://roland65.free.fr/xfe/ Index: patches/patch-src_xfedefs_h === RCS file: patches/patch-src_xfedefs_h diff -N patches/patch-src_xfedefs_h --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-src_xfedefs_h 17 Oct 2014 11:45:35 - @@ -0,0 +1,20 @@ +$OpenBSD$ + +Unbreak launching Xfe as root with sudo or su + +--- src/xfedefs.h.orig Fri Oct 17 13:41:26 2014 src/xfedefs.h Fri Oct 17 13:43:44 2014 +@@ -157,11 +157,11 @@ + + // Command to launch Xfe as root with sudo or su, using Xvt as a terminal + #ifndef SUDOCMD +-#define SUDOCMD "-fn 7x14 -geometry 60x4 -e sudo su -c 'nohup xfe >& /dev/null & sleep 1'" ++#define SUDOCMD "-fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup xfe >/dev/null 2>&1 & sleep 1'" + #endif + + #ifndef SUCMD +-#define SUCMD "-fn 7x14 -geometry 60x4 -e su -c 'nohup xfe >& /dev/null & sleep 1'" ++#define SUCMD "-fn 7x14 -geometry 60x4 -e su root -c 'nohup xfe >/dev/null 2>&1 & sleep 1'" + #endif + + // Tooltips setup time and duration
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 12:56:48PM +0200, Martin Schr??der wrote: > 2014-10-17 10:24 GMT+02:00 Bret Lambert : > > On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: > >> The impossibility to scan for services - which the NSA/GHCQ/... do. > > > > It's a good thing that traffic analysis isn't a thing, then. Otherwise > > they'd be able to check if traffic purporting to go to port 80/443 > > doesn't look like HTTP traffic, or something. > > That's not the scenario here. The scenario is defense against port scans. > > You look like a fool who hasn't read the original paper. > Quoting the OP a few emails back: > The idea is that the existence of this entire 'ultranet' is > undetectable by even someone snooping all national traffic. So a TCP > port 80 connection looks to the snooper _exactly_ like an HTTP > connection handshake. Only the ISN and the source address mark the > connection as 'ultra' and take it into a back room where it connects > to the real network. Just sayin'.
Re: Shadow TCP stacks
2014-10-17 10:24 GMT+02:00 Bret Lambert : > On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: >> The impossibility to scan for services - which the NSA/GHCQ/... do. > > It's a good thing that traffic analysis isn't a thing, then. Otherwise > they'd be able to check if traffic purporting to go to port 80/443 > doesn't look like HTTP traffic, or something. That's not the scenario here. The scenario is defense against port scans. You look like a fool who hasn't read the original paper.
Re: sudo bad practice or inconsistency?
Alessandro DE LAURENZIS gmail.com> writes: (line-wrapped because of GMane) > #define SUDOCMD "-fn 7x14 -geometry 60x4 -e sudo su -c 'nohup \ > xfe >& /dev/null & sleep 1'" ^^ Note that this will not work on OpenBSD anyway; even mksh, which does implement this bashism, will not parse this as expected in POSIX mode. So, besides the changes the others already pointed out: #define SUDOCMD "-fn 7x14 -geometry 60x4 -e sudo su root -c 'nohup \ xfe >/dev/null 2>&1 & sleep 1'" bye, //mirabilos
Re: Shadow TCP stacks
On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: > 2014-10-16 13:16 GMT+02:00 Kevin Chadwick : > > I still don't see the benefit though but do see added complexity or > > more code to audit. > > > > Reducing DDOS against a visible SSH service maybe? Reduce password > > attempts on your logs allowing them to go after targets that might > > actually use passwords (port change also works there, I find)? > > The impossibility to scan for services - which the NSA/GHCQ/... do. It's a good thing that traffic analysis isn't a thing, then. Otherwise they'd be able to check if traffic purporting to go to port 80/443 doesn't look like HTTP traffic, or something.
