Re: NAT/pf before IPSEC
Sorry for the late reply.
Indeed 192.168.8.254 is the IP Address of the internal NIC. In fact I
only have one NIC on my OpenBSD Server (it's a Mac Cube, so I cannot
add another one). It's setup as the default router for the other
systems (through DHCP). Below is the contents of my isakmpd.conf. I
made a mistake in the first mail, my vpnid is 192.168.2.1.
[General]
Default-phase-1=lifetime= 28800,60:86400
Default-phase-2=lifetime= 28800,60:86400
Default-phase-2-suites= QM-ESP-3DES-SHA-SUITE
Default-phase-1-ID= My-ID
Use-Keynote=yes
Logverbose= yes
[X509-certificates]
CA-directory= /etc/isakmpd/ca/
Cert-directory= /etc/isakmpd/certs/
Private-key=/etc/isakmpd/private/my.work.nl.key
Accept-self-signed= yes
[Phase 1]
Default=WORK-Phase1
[Phase 2]
Connections=WORK-Phase2
[WORK-Phase1]
Phase= 1
Transport= udp
Configuration= WORK-Phase1-mode
Address=REMOTE-ADDRESS
ID= My-ID
Remote-ID= WORK-ID
[My-ID]
ID-type=FQDN
Name= my.work.nl
[WORK-ID]
ID-type=FQDN
Name= vpn.work.nl
[WORK-Phase2]
Phase= 2
ISAKMP-peer=WORK-Phase1
Configuration= WORK-Phase2-mode
Local-ID= Recursive-Address
Remote-ID= WORK-Network
Flags= Active-only
[Recursive-Address]
ID-Type=IPV4_ADDR
Address=192.168.2.1
[WORK-Network]
ID-Type=IPV4_ADDR_SUBNET
Network=192.168.1.0
Netmask=255.255.255.0
[WORK-Phase1-mode]
DOI=IPSEC
EXCHANGE_TYPE= ID_PROT
Transforms= 3DES-SHA
[WORK-Phase2-mode]
DOI=IPSEC
EXCHANGE_TYPE= QUICK_MODE
Suites= QM-ESP-3DES-SHA-SUITE
[3DES-SHA]
AUTHENTICATION_METHOD= RSA_SIG
And off course, there are also these rules in /etc/pf.conf
pass quick on { lo, enc0, tun0 }
pass quick inet proto esp all keep state
pass quick inet proto udp to any port { 500, 4500 } keep state
pass quick inet proto icmp all icmp-type { $icmp_types } keep state
block return quick on gem0 inet proto tcp to any port { auth }
This is all I have. So traffic comming in from the clients to the
target network 192.168.0.0 will be 'grabbed' by the SA which was
added from hostname.enc0. The traffic will then be natted by the pf
rule and flow towards the remote network.
Hope this helps.
Still I think if you can you should give OpenVPN a try.
Regards,
--
Stephan
On 21-dec-2005, at 22:45, Matthew Closson wrote:
On your question, this is what I have used form my IPSec tunnel's
nat:
Internal network 192.168.8.0/24
Remote network 192.168.1.0/24
vpnip=192.168.1.1
scrub in
nat on enc0 from { gem0, gem0:network } - $vpnip
Together with:
# cat /etc/hostname.enc0
up
!ipsecadm flow -out -require -proto esp -src 192.168.8.254 -dst
REMOTE-ENDPOINT -addr 192.168.8.0/24 192.168.1.0/24
Is 192.168.8.254 is the IP address of your internal NIC?
Once this has been done, and a fake phase2 entry has been made for
the internal network in the isakmpd.conf file, what else needs to
be done.
I tried this and added the flow and phase2 connection (on my end
only) and when I try to access hosts across the tunnel from my
internal LAN and run tcpdump -i enc0 I still see no traffic coming
across.
Any ideas of what I could be missing? I did
ipsecadm flow -out -require -proto esp -src 192.168.20.250 -dst
a.b.c.d -addr 192.168.20.0/24 192.168.60.0/24
Thanks,
-Matt-
And that worked fine for me. So you'll need to 'manually' add a
Security Association.
Kind regards,
--
Stephan
On 21-dec-2005, at 10:09, Matthew Closson wrote:
Hello,
I'm running into an issue which was brought up on the list
before, the last reference I found was in 2004:
http://archive.openbsd.nu/?ml=openbsd-pfa=2004-10m=430206
I have an OpenBSD 3.8 machine.
dc0 is an internal NIC assigned 192.168.20.250
fxp0 is an external NIC assigned a.b.c.d public_IP_address
10.0.20.254 is an inet alias on fxp0
192.168.20.0/24 is my internal network.
192.168.20.0/24
|
|
|
192.168.20.250 - dc0
10.0.20.254 - inet alias on fxp0
a.b.c.d - fxp0 public_IP
|
|
IPSEC Tunnel
|
|
e.f.g.h - public_IP tunnel endpoint
192.168.60.0/24 remote network
According to the parameters of the tunnel setup (of which I
cannot change) the remote IPSEC tunnel endpoint expects traffic
from my network to look like it is coming from 10.0.20.254/32.
This works:
ping -I 10.0.20.254 192.168.20.10
I get responses back from the pings, now I need to nat my
internal network to appear to be coming from 10.0.20.254
So I can do:
nat pass on enc0 from 192.168.20.0/24 to 192.168.60.0/24 -
How to log all entered commands?
Hello I'm trying to log all command which are entered by users but till now still without success. I think I was close with accton and lastcomm commands but unfortunetaly it logs only commands without parameters, so for instance if I disable pf, pfctl -d I have in log only pfctl so there is now way, to figure out what exactly happened. I also modified syslog.conf to log all in debug mode but as I expected it didn't help. It seems that Google doesn't have any idea as well. Is there any solution for my needs? Thanks a lot for any idea MK
Re: How to log all entered commands?
On Saturday 24 December 2005 05:16 am, MK wrote: Hello I'm trying to log all command which are entered by users but till now still without success. I think I was close with accton and lastcomm commands but unfortunetaly it logs only commands without parameters, so for instance if I disable pf, pfctl -d I have in log only pfctl so there is now way, to figure out what exactly happened. I also modified syslog.conf to log all in debug mode but as I expected it didn't help. It seems that Google doesn't have any idea as well. Is there any solution for my needs? Have you tried the script command?
Re: How to log all entered commands?
I'm trying to log all command which are entered by users but till now still without success. sudosh, but it's not in ports.
Re: How to log all entered commands?
Thank you for your suggestion. But there is some problem during the source compile. In fact I have same problem as described here: http://www.bsdforums.org/forums/showthread.php?t=27287 and of course there is no answer. :( Thank you MK - Original Message - From: Stuart Henderson [EMAIL PROTECTED] To: Qv6 [EMAIL PROTECTED] Cc: misc@openbsd.org Sent: Saturday, December 24, 2005 1:47 PM Subject: Re: How to log all entered commands? I'm trying to log all command which are entered by users but till now still without success. sudosh, but it's not in ports.
Re: How to log all entered commands?
On 12/24/05, MK [EMAIL PROTECTED] wrote: Hello I'm trying to log all command which are entered by users but till now still without success. I think I was close with accton and lastcomm commands but unfortunetaly it logs only commands without parameters, so for instance if I disable pf, pfctl -d I have in log only pfctl so there is now way, to figure out what exactly happened. script is in base. $script -a /var/user/terminal-session.txt will log every thing to that file. Or and other file you choose. Some problems exist if users run screen manipulating programs like vi. They are documented in $man script Hope this helps :-) Kind Regards -- Siju Oommen George, Network Consultant. HiFX IT MEDIA SERVICES PVT. LTD. http://www.hifx.net
Re: How to log all entered commands?
Unfortunately not, because there is no timestamp in the log file and there is no easy way how to analyze which user executed particular command on the system. I'm looking for something such as logs generated by sudo. Thanks anyway MK - Original Message - From: Siju George [EMAIL PROTECTED] To: MK [EMAIL PROTECTED] Cc: misc@openbsd.org Sent: Saturday, December 24, 2005 7:26 PM Subject: Re: How to log all entered commands? On 12/24/05, MK [EMAIL PROTECTED] wrote: Hello I'm trying to log all command which are entered by users but till now still without success. I think I was close with accton and lastcomm commands but unfortunetaly it logs only commands without parameters, so for instance if I disable pf, pfctl -d I have in log only pfctl so there is now way, to figure out what exactly happened. script is in base. $script -a /var/user/terminal-session.txt will log every thing to that file. Or and other file you choose. Some problems exist if users run screen manipulating programs like vi. They are documented in $man script Hope this helps :-) Kind Regards -- Siju Oommen George, Network Consultant. HiFX IT MEDIA SERVICES PVT. LTD. http://www.hifx.net
Re: Backup Techniques onto DVD+-RW
Steve Shockley wrote: Whyzzi wrote: Hi gang. Running a lightweight mail server here (50 users total) on OpenBSD, and being the cheap bastard that I am I am looking forward to scripting a nightly backup onto some DVD-RW media. Can I assume that dump/restore is out of the question because of the special commands burners require to begin the writing process? And if that is indeed the case, any recommendations or uber cool few liners that would have say get maximum compression of the contents in /home where all related mail is stored (sendmail/procmail-maildir/dovecot). BTW: Happy Holidays to you and yours! You could dump to a file piped through gzip/bzip2, then copy that to CD/DVD. I back up several OpenBSD machines at work by dump|bzip2 to an nfs share on Windows (SFU), then the Windows box gets backed up to tape. (No Commvault agents for Open.) Works well and doesn't require changing our existing corporate backup process. If compression is a consideration, I have to mention something I discovered recently for a similar issue: If your e-mail flow has a lot of binary attachments (our people are very fond of e-mailing PDF files out of scanners), gzip is not very good. bzip2 was hardly any better, but many times slower -- most certainly not worth the tiny improvement in size. A solution turned out to be rzip, which was slightly faster than bzip2, but delivers MUCH better compression numbers, returning better than 2:1 compression most of the time (and sometimes, a WHOLE LOT more than that), compared to bzip2 and gzip, which were doing something like 30% and 35% reductions, respectively (vs. 65% reductions for rzip on the same file). These are on big (400+MB) mbox files (I'd suspect tar files would produce similar savings, but individual files in an Maildir would probably be different). A few warnings: 1) you can not pipe/redirect rzip. Apparently, it needs non-sequential seeks on the file to find redundancies. However, disk space is cheap, just compress/expand from a local HD partition. 2) memory, memory, memory: it works by looking over a much larger window than bzip/gzip/etc. use looking for redundancy, so for big files, a gig of RAM is not very wasteful. Un-rzipping a file, however, can be done on very modest machines -- I have the system burn to DVD-R, then unpack it and verify MD5 numbers, all on a old P4/128M RAM (old RAMBUS machine, thus it probably never will get another stick of RAM unless another machine dies). The actual image is created on a amd64 system with a gig of RAM. 3) I have been unable to find a Windows port of the rzip application, which really doesn't matter a whole lot, unless you want to get to your data out on a Windows system. rzip is in OpenBSD ports, and apparently can be compiled easily enough on most Unix-like platforms. (No, I really don't care how easily it could be ported to Windows, unless you actually have done it.) Nick.
Xwindows Security Hole in OpenBSD 3.8
I hate to send this Christmas present to misc, but there is definitely a security hole in Xwindows which permits exploits to be committed at least with user permissions, if not root permissions. Since the problem appears to be in Xwindows, using KDE may be inadviseable. I'm considering going back totally to console mode now that I'm aware of the problem. Dave Feustel -- Lose, v., experience a loss, get rid of, lose the weight Loose, adj., not tight, let go, free, loose clothing
Re: How to log all entered commands?
On Sat, Dec 24, 2005 at 07:41:45PM +0100, MK wrote: Unfortunately not, because there is no timestamp in the log file and there is no easy way how to analyze which user executed particular command on the system. I'm looking for something such as logs generated by sudo. There actual is a timestamp in the log file, at least in mine. Script started on Sat Dec 24 20:37:56 2005 [snip] Script done on Sat Dec 24 20:38:01 2005 Merry Christmas! Jonathan Thanks anyway MK - Original Message - From: Siju George [EMAIL PROTECTED] To: MK [EMAIL PROTECTED] Cc: misc@openbsd.org Sent: Saturday, December 24, 2005 7:26 PM Subject: Re: How to log all entered commands? On 12/24/05, MK [EMAIL PROTECTED] wrote: Hello I'm trying to log all command which are entered by users but till now still without success. I think I was close with accton and lastcomm commands but unfortunetaly it logs only commands without parameters, so for instance if I disable pf, pfctl -d I have in log only pfctl so there is now way, to figure out what exactly happened. script is in base. $script -a /var/user/terminal-session.txt will log every thing to that file. Or and other file you choose. Some problems exist if users run screen manipulating programs like vi. They are documented in $man script Hope this helps :-) Kind Regards -- Siju Oommen George, Network Consultant. HiFX IT MEDIA SERVICES PVT. LTD. http://www.hifx.net -- | /\ ASCII Ribbon | Jonathan Glaschke - Lorenz-Goertz-Stra_e 71, | \ / Campaign Against | 41238 Moenchengladbach, Germany; | XHTML In Mail | jabber: [EMAIL PROTECTED] | / \ And News | http://jonathan-glaschke.de/ [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Xwindows Security Hole in OpenBSD 3.8
On Sat, 24 Dec 2005, Dave Feustel wrote: I hate to send this Christmas present to misc, but there is definitely a security hole in Xwindows which permits exploits to be committed at least with user permissions, if not root permissions. Since the problem appears to be in Xwindows, using KDE may be inadviseable. I'm considering going back totally to console mode now that I'm aware of the problem. Dave Feustel -- Lose, v., experience a loss, get rid of, lose the weight Loose, adj., not tight, let go, free, loose clothing Dave, And do you care to share this monumental discovery of yours? Also if your flaw is in X then what does KDE have to do with that? Merry Christmas, -Matt-
Re: Xwindows Security Hole in OpenBSD 3.8
On 24/12/05, Matthew Closson [EMAIL PROTECTED] wrote: On Sat, 24 Dec 2005, Dave Feustel wrote: I hate to send this Christmas present to misc, but there is definitely a security hole in Xwindows which permits exploits to be committed at least with user permissions, if not root permissions. Since the problem appears to be in Xwindows, using KDE may be inadviseable. I'm considering going back totally to console mode now that I'm aware of the problem. And do you care to share this monumental discovery of yours? Also if your flaw is in X then what does KDE have to do with that? Merry Christmas, What? You want proof as well? Is his word alone not good enough? I for one shall be torching my machine and running for the hills.
Re: Xwindows Security Hole in OpenBSD 3.8
What kind of post is this? Rico Dave Feustel wrote: I hate to send this Christmas present to misc, but there is definitely a security hole in Xwindows which permits exploits to be committed at least with user permissions, if not root permissions. Since the problem appears to be in Xwindows, using KDE may be inadviseable. I'm considering going back totally to console mode now that I'm aware of the problem. Dave Feustel
Re: Xwindows Security Hole in OpenBSD 3.8
On Saturday 24 December 2005 14:57, Matthew Closson wrote: On Sat, 24 Dec 2005, Dave Feustel wrote: I hate to send this Christmas present to misc, but there is definitely a security hole in Xwindows which permits exploits to be committed at least with user permissions, if not root permissions. Since the problem appears to be in Xwindows, using KDE may be inadviseable. I'm considering going back totally to console mode now that I'm aware of the problem. Dave Feustel -- Lose, v., experience a loss, get rid of, lose the weight Loose, adj., not tight, let go, free, loose clothing Dave, And do you care to share this monumental discovery of yours? Should I assume from the comment above that you already know about this security hole? Also if your flaw is in X then what does KDE have to do with that? As far as I can guess so far, the security hole is via Xwindows and the exploit of that security hole appears to involve some combination of kde's kio, konsole and uiserver which permits the perp to execute commands with the permissions of the account using kde. The lack of kgrant_pty on openbsd seems also to facilitate the exploit. At this point I have hard evidence (for myself, but probably not for others) that certain security-related file permissions are being changed by someone else but me, and I am the only (authorized) user of this system. (I am the person doing the authorization :-) ). So far I have seen nothing that could not be done with my user permissions (ie no sign of changes requiring root privileges). The penetrating perp seems to know Xwindows and kde inside and out - certainly a lot better than I do. I *am* learning things while poking around though :-). Merry Christmas, -Matt- -- Lose, v., experience a loss, get rid of, lose the weight Loose, adj., not tight, let go, free, loose clothing
Re: Xwindows Security Hole in OpenBSD 3.8
On 24/12/05, Rico [EMAIL PROTECTED] wrote: What kind of post is this? Dave Feustel wrote: I hate to send this Christmas present to misc, but there is definitely a security hole in Xwindows which permits exploits to be committed at least with user permissions, if not root permissions. Since the problem appears to be in Xwindows, using KDE may be inadviseable. I'm considering going back totally to console mode now that I'm aware of the problem. The stupid kind? It's probably something to do with http://groups.google.co.uk/group/lucky.openbsd.misc/browse_thread/thread/5a1c60d75b905f9e/b7d91d68b5b21117
utilizing screen real estate without X
Currently, I do not run X on my openbsd box and really would rather not. I am thinking of a way to have multiple ttys available for monitoring without switching back and forth between them. It might seem silly to some, when you have a dual headed vidcard and multiple displays and prefer not to use X, but I am curious to know what options I have for utilizing the real estate. I am thinking of writing an ncurses based app, but wanted to hear some suggestions first.. Thanks, Mike
Re: Xwindows Security Hole in OpenBSD 3.8
On 24/12/05, Dave Feustel [EMAIL PROTECTED] wrote: I hate to send this Christmas present to misc, but there is definitely a security hole in Xwindows which permits exploits to be committed at least with user permissions, if not root permissions. Since the problem appears to be in Xwindows, using KDE may be inadviseable. I'm considering going back totally to console mode now that I'm aware of the problem. How very descriptive Please elaborate... Regards
Re: Xwindows Security Hole in OpenBSD 3.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 24, 2005, at 3:50 PM, Edd Barrett wrote: On 24/12/05, Dave Feustel [EMAIL PROTECTED] wrote: I hate to send this Christmas present to misc, but there is definitely a security hole in Xwindows One wonders how software that doesn't exist can have security holes? snip - -- If you aren't solving your problems with violence, you aren't using enough. iD8DBQFDreE5+jjCYjWs3d0RArl5AJ0cJU9gDkBs6u78ecipar1DmYFExACcCpAJ 4fscKMrk0xFTLwdw1/7/aHQ= =b5sL -END PGP SIGNATURE-
Re: utilizing screen real estate without X
On Dec 24, 2005, at 3:16 PM, Michael Steinfeld wrote: Currently, I do not run X on my openbsd box and really would rather not. I am thinking of a way to have multiple ttys available for monitoring without switching back and forth between them. It might seem silly to some, when you have a dual headed vidcard and multiple displays and prefer not to use X, but I am curious to know what options I have for utilizing the real estate. screen I am thinking of writing an ncurses based app, but wanted to hear some suggestions first.. Thanks, Mike -- If you aren't solving your problems with violence, you aren't using enough.
Re: utilizing screen real estate without X
For my next trick I can pick the correct lottery numbers moments after the drawing. --thanks On 12/24/05, Ray Percival [EMAIL PROTECTED] wrote: On Dec 24, 2005, at 3:16 PM, Michael Steinfeld wrote: Currently, I do not run X on my openbsd box and really would rather not. I am thinking of a way to have multiple ttys available for monitoring without switching back and forth between them. It might seem silly to some, when you have a dual headed vidcard and multiple displays and prefer not to use X, but I am curious to know what options I have for utilizing the real estate. screen I am thinking of writing an ncurses based app, but wanted to hear some suggestions first.. Thanks, Mike -- If you aren't solving your problems with violence, you aren't using enough.
[Terra Mail] Alerta de Seguran�a !!
Detectamos que seu e-mail esta enviando mensagems contaminadas com o vmrus [EMAIL PROTECTED] Uma variante do vmrus [EMAIL PROTECTED] O worm [EMAIL PROTECTED] i: * Uma variante do vmrus [EMAIL PROTECTED] * Um worm de distribuigco em massa que tambim se propaga atravis dos compartilhamentos de rede. * Polimsrfico e tambim infecta uma lista seleta de arquivos executaveis. * Apropria-se das atividades de teclado e possui capacidades de backdoor. * Tenta finalizar os processos de varios programas antivmrus e firewall. * Atualizagco Crmtica * Acabe com este problema agora totalmente gratis Baixe ja a vacina para eliminar esse vmrus de seu sistema! Baixe Aqui! [IMAGE]
new snapshots, special treats
the new i386 snapshot heading out now contains a few uncommited little pieces which enable a potpourri of i2c goodness. mostly, this will provide some sensor stuff to people who do not have ipmi(4) or esm(4) support. i2c sensor devices appear on lots of machines (not just i386). some might have noticed the recent macppc sensors, well, those were i2c devices too, but the nice thing is the ROM told us where they are on the i2c busses. on other architectures, nothing tells us where these devices exist, so we have to utilize lots of heuristic checking, to try to find them, without messing up other devices. some people trying this in the past have messed up machines, but we are trying to be really careful and move slowly to not let such a situation happen. to get this support working, we depend on working i2c bus drivers (which we now have 3 i386 ones) and then on i2c sensor-chip drivers (almost 20 now). but it also requires this nasty heuristic code which carefully probes the busses to decide which drivers match which chips. this cannot be done like PCI or ISA matching, but don't worry about the details.) so go ahead, try it out, and see if on some of your machines you see a few new sensors (using sysctl hw.sensors). if things go weird, i would appreciate a private mail (that means just to me, but I will show it to 2-3 other people) which details: 1. what kind of machine, 2 lines of text 2. full dmesg, please 3. hw.sensors output note, not all machines have these; in particular, most laptops do not because they hide this stuff behind the keyboard controller (kind of like a per-vendor custom undocumented ESM-style thing, but maybe kind of supplied via ACPI on some machines... we'll see someday). that said, i am happy to see this on a SuperMicro machine here.. (minus some debug messages you will see, and which I need in the mail): piixpm0 at pci0 dev 15 function 0 ServerWorks CSB5 rev 0x93 iic0 at piixpm0 admtemp0 at iic0 addr 0x18: Xeon admtemp1 at iic0 addr 0x29: Xeon lmenv0 at iic0 addr 0x2d: LM87 rev 6 lmenv1 at iic0 addr 0x2e: LM87 rev 6 hw.sensors.0=admtemp0, Xeon, temp, 25.00 degC / 77.00 degF hw.sensors.1=admtemp1, Xeon, temp, 26.00 degC / 78.80 degF hw.sensors.2=lmenv0, +2.5Vin, volts_dc, 1.67 V hw.sensors.3=lmenv0, Vccp1, volts_dc, 0.00 V hw.sensors.4=lmenv0, +Vcc, volts_dc, 3.28 V hw.sensors.5=lmenv0, +5Vin/Vcc, volts_dc, 0.00 V hw.sensors.6=lmenv0, +12Vin, volts_dc, 12.12 V hw.sensors.7=lmenv0, Vccp2, volts_dc, 0.00 V hw.sensors.9=lmenv0, Int. Temp., temp, 29.00 degC / 84.20 degF hw.sensors.10=lmenv0, FAN1, fanrpm, 3341 RPM hw.sensors.11=lmenv0, FAN2, fanrpm, 3341 RPM hw.sensors.12=lmenv1, +2.5Vin, volts_dc, 2.55 V hw.sensors.13=lmenv1, Vccp1, volts_dc, 1.49 V hw.sensors.14=lmenv1, +Vcc, volts_dc, 3.28 V hw.sensors.15=lmenv1, +5Vin/Vcc, volts_dc, 5.05 V hw.sensors.16=lmenv1, +12Vin, volts_dc, 11.62 V hw.sensors.17=lmenv1, Vccp2, volts_dc, 1.52 V hw.sensors.19=lmenv1, Int. Temp., temp, 26.00 degC / 78.80 degF hw.sensors.20=lmenv1, FAN1, fanrpm, 5192 RPM hw.sensors.21=lmenv1, FAN2, fanrpm, 5273 RPM Yeah, that's even the temperatures right on the Xeon processor chips; right on the chip..
