Sir/madam,
I need your help,I am KENETH MADAMBE, the son of
a
Late minister during the reign of mobutu seseko,
I came to know you in the course of my search for
a reliable and God fearing partner and I decide
to contact you because I believe you are a reputable
person and I felt you ca
Am Donnerstag, 5. Juni 2003 09:30 schrieb Luis Gomez - InfoEmergencias:
> We'd like to protect that content, so that even if someone unplugs the
> machine and connects the HD to another Linux box, they can't access that
> information. Of course it's difficult to do, but we think there might be a
>
> "Vinai" == Vinai Kopp <[EMAIL PROTECTED]> writes:
[...]
Vinai> There seem to be problems using both the grsecurity and the
Vinai> freeswan patches (at least I haven't been successfull applying
Vinai> the patches - I tried the debian versions and the "official" ones
Vinai> from the different
On Thu, Jun 05, 2003 at 10:44:47AM +0200, Lars Ellenberg wrote:
>
> or keep an encrypted copy of all relevant files separately, and on
> bootup / service startup you decrypt it temporarily to the correct
> location, start the service, and unlink it again (after you wiped it
> with garbage, of cour
On Thu, Jun 05, 2003 at 10:32:59PM +0200, Vinai Kopp wrote:
>Hi,
>
>currently I'm setting up a gateway machine for a small office
>network. After the recent threads about rooted woody boxes I feel it
>would be iresponsible to set up a box without a grsecurity patched
>kernel.
>The problem is I als
Luis Gomez - InfoEmergencias wrote:
We're already looking at that (btw, IIRC loop-aes is included into the
cryptoapi of kerneli.org). The problem is what Dariush points: if your
machine has the pass to mount the filesystem, someone can put the HD in
another machine, remove the root password, pu
On Thu, Jun 05, 2003 at 09:30:51AM +0200, Luis Gomez - InfoEmergencias wrote:
> We'd like to protect that content, so that even if someone unplugs the machine
> and connects the HD to another Linux box, they can't access that information.
> Of course it's difficult to do, but we think there might
> accesses the HD can do it as well. btw, what does SOL mean?
So Out of Luck?
--
Dariush Pietrzak,
She swore and she cursed, that she never would deceive me
Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "uns
On Jueves, 5 de Junio de 2003 10:02, Dariush Pietrzak wrote:
> > We'd like to protect that content, so that even if someone unplugs the
> > machine and connects the HD to another Linux box, they can't access that
> > information.
>
> Hm? Maybe you need encrypted filesystem, something like cfs?
> W
On Jueves, 5 de Junio de 2003 10:19, Adam ENDRODI wrote:
> On Thu, Jun 05, 2003 at 09:30:51AM +0200, Luis Gomez - InfoEmergencias
wrote:
> > We'd like to protect that content, so that even if someone unplugs the
> > machine and connects the HD to another Linux box, they can't access that
> > infor
On Thu, Jun 05, 2003 at 09:30:51AM +0200, Luis Gomez - InfoEmergencias wrote:
>
> We'd like to protect that content, so that even if someone unplugs the machine
> and connects the HD to another Linux box, they can't access that information.
Default answer: encrypt your file system.
http://www.k
> We'd like to protect that content, so that even if someone unplugs the machine
> and connects the HD to another Linux box, they can't access that information.
Hm? Maybe you need encrypted filesystem, something like cfs?
With schemes like this there are problems - you need to provide some kind
On Thu, Jun 05, 2003 at 08:58:43PM +0200, Luis Gomez - InfoEmergencias wrote:
> Other interesting things to look at:
>
> - LICENSING ISSUES. As Peter Cordes commented, the kernel is GPL so if we
> integrate code into it, we cannot provide a binary-only version, we should
> also give away the sou
Hello world...
In my company, we've been working for some months in what I consider a rather
interesting product... but well, this mail is not spam ;)
Seriously, the fact is this: we are going to install Linux servers in some
companies, in order to serve mail, files, databases... We have develo
My idea: connection coming from inside network to the firewall going to
the web server are not considered by the rules
> >>$PROG -t nat -A PREROUTING -i $NIC_EXTERNAL -p tcp \
> >> -s 0/0 --dport http \
> >> -j DNAT --to-destination 192.168.1.2:80
> >>$PROG -t mangle -A FORWARD -i
> -Original Message-
> From: Hanasaki JiJi [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 5 June 2003 4:17 PM
> To: List - Debian Security
> Subject: Re: question squid + firewall + http server inside firewall
>
>
> Michael,
>
> unfortunately, that didnt work. Your logic makes sense.
> B
On Thursday 05 June 2003 22:32, Vinai Kopp wrote:
Hi Vinai,
> There seem to be problems using both the grsecurity and the freeswan
> patches (at least I haven't been successfull applying the patches - I
> tried the debian versions and the "official" ones from the different
> project sites of the
Michael,
unfortunately, that didnt work. Your logic makes sense. Below is the
output of the relavant lines: iptables -L -t nat
any other ideas would be great!
SNAT tcp -- 192.168.1.0/24 [internalhost] tcp dpt:www to:65.30.34.80
Michael Sharman wrote:
-Original Message-
From: Hanasaki
On Thu, Jun 05, 2003 at 10:02:53PM +0200, Christoph Haas wrote:
> So most probably you see just the second. That's the way TCP works.
> Sequential port numbers may show up because the counter of used
> high-ports (1024 ff.) is just increased.
No, it's not at all uncommon to see incoming traffic fr
> -Original Message-
> From: Hanasaki JiJi [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 5 June 2003 2:42 PM
> To: List - Debian Security
> Subject: question squid + firewall + http server inside firewall
>
>
> I have the below rules in my firewall. the http server is inside the
> firewal
Hi,
currently I'm setting up a gateway machine for a small office
network. After the recent threads about rooted woody boxes I feel it
would be iresponsible to set up a box without a grsecurity patched
kernel.
The problem is I also need the box to be a VPN gateway. One of
the reasons I got the d
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
>I've noticed some strange traffic on our firewalls recently. Someone (Or
>multiple someones) are attempting to send tcp packets inbound to our
>network FROM well known ports (e.g. port 80)
Some firewalls that don't do proper connection
On Thu, Jun 05, 2003 at 08:29:10PM +0100, Hamish Marson wrote:
> I've noticed some strange traffic on our firewalls recently. Someone (Or
> multiple someones) are attempting to send tcp packets inbound to our
> network FROM well known ports (e.g. port 80) to multiple port numbers,
> and usually
I have the below rules in my firewall. the http server is inside the
firewall on 192.168.1.2:80
people can hit it fine from the outside
squid is running on the firewall
inside can browser ouside via squid just fine
inside cannot browse the outside address
Any thought/input would be apprecia
I've noticed some strange traffic on our firewalls recently. Someone (Or
multiple someones) are attempting to send tcp packets inbound to our
network FROM well known ports (e.g. port 80) to multiple port numbers,
and usually multiple addresses as well. Sometimes they are randomised,
(Port and
W liście z czw, 05-06-2003, godz. 07:30, Luis Gomez - InfoEmergencias
pisze:
Hello!
> We'd like to protect that content, so that even if someone unplugs the
> machine
> and connects the HD to another Linux box, they can't access that information.
> Of course it's difficult to do, but we think
Good evening (here in Spain) to all of you.
I want to sincerely thank you all for the great feedback received on this
topic. I would never have expected to receive some 20 answers in such a short
time! Let me take my time to write your names, because you deserve it:
Thank you Dariush, Adam, Marc
On Thu, 5 Jun 2003 14:15:45 -0300, Peter Cordes <[EMAIL PROTECTED]>
wrote:
If the attacker runs it under an x86 emulator like bochs, they don't need
to sniff the network, just look at memory after it's decrypted. Also,
what
I suggested was an attempt to avoid dependence on a network. I'd be
On Thu, Jun 05, 2003 at 12:53:43PM -0300, Koba wrote:
> Think about this:
> Use a encrypted loopback. To get the key without storing it on
> the computer:
> Get some kind of unique combined fingerprint of the computer and hd
> through a c/c++ programmed algorithm and sendi
Harry Brueckner wrote:
On the other hand - what will you do if your server gets a hardware
problem and you have to replace/expand the system with a new NIC, add
another CPU, exchange anything in the box.
So after a simple hardware problem all your own data is lost as well,
even if the harddri
On Thursday 05 June 2003 17:16, Peter Cordes wrote:
> kernel. (Even if you put the password in the kernel, you want to hide the
> initrd, because it will have mount(8) getting a password from /proc/sekret,
> or something.) Use some sort of encrypted filesystem on the hard drive.
When you're hac
Harry Brueckner wrote:
Hey there,
Making the encryption key hardware dependent would make it a hard job to
decrypt the harddrive in another computer...
On the other hand - what will you do if your server gets a hardware
problem and you have to replace/expand the system with a new NIC, add
Think about this:
Use a encrypted loopback. To get the key without storing it on the
computer:
Get some kind of unique combined fingerprint of the computer and hd
through a c/c++ programmed algorithm and sending them to a secure
"password" server using some kind of (variable server provided
Hey there,
--On Thursday, June 05, 2003 11:14:36 AM +0200 Marcel Weber
<[EMAIL PROTECTED]> wrote:
Luis Gomez - InfoEmergencias wrote:
We're already looking at that (btw, IIRC loop-aes is included into the
cryptoapi of kerneli.org). The problem is what Dariush points: if your
machine has the
> Against a sophisticated attacker, it's totally impossible to do what you
> want. They could run bochs an boot the x86 emulator from the new hard
> drive, and examine the contents of the system's memory whenever they wanted.
> Obviously, that's not easy, since you have to figure out where the
>
You can encode your php scripts (in standalone cgi mode or apache served)
with the open source gpl php encoder/optimizer turck mmcache. The readme
says that the encoding it's not recommended for production use yet, but it
works like a charm.
Good Luck,
Koba
On Thu, 5 Jun 2003 09:30:51 +0200,
On Thu, Jun 05, 2003 at 09:30:51AM +0200, Luis Gomez - InfoEmergencias wrote:
> We'd like to protect that content, so that even if someone unplugs the
> machine
> and connects the HD to another Linux box, they can't access that information.
> Of course it's difficult to do, but we think there mi
Sir/madam,
I need your help,I am KENETH MADAMBE, the son of
a
Late minister during the reign of mobutu seseko,
I came to know you in the course of my search for
a reliable and God fearing partner and I decide
to contact you because I believe you are a reputable
person and I felt you ca
Am Donnerstag, 5. Juni 2003 09:30 schrieb Luis Gomez - InfoEmergencias:
> We'd like to protect that content, so that even if someone unplugs the
> machine and connects the HD to another Linux box, they can't access that
> information. Of course it's difficult to do, but we think there might be a
>
On Thu, Jun 05, 2003 at 10:44:47AM +0200, Lars Ellenberg wrote:
>
> or keep an encrypted copy of all relevant files separately, and on
> bootup / service startup you decrypt it temporarily to the correct
> location, start the service, and unlink it again (after you wiped it
> with garbage, of cour
Luis Gomez - InfoEmergencias wrote:
We're already looking at that (btw, IIRC loop-aes is included into the
cryptoapi of kerneli.org). The problem is what Dariush points: if your
machine has the pass to mount the filesystem, someone can put the HD in
another machine, remove the root password,
On Thu, Jun 05, 2003 at 09:30:51AM +0200, Luis Gomez - InfoEmergencias wrote:
> We'd like to protect that content, so that even if someone unplugs the
> machine
> and connects the HD to another Linux box, they can't access that information.
> Of course it's difficult to do, but we think there mi
> accesses the HD can do it as well. btw, what does SOL mean?
So Out of Luck?
--
Dariush Pietrzak,
She swore and she cursed, that she never would deceive me
Key fingerprint = 40D0 9FFB 9939 7320 8294 05E0 BCC7 02C4 75CC 50D9
On Jueves, 5 de Junio de 2003 10:02, Dariush Pietrzak wrote:
> > We'd like to protect that content, so that even if someone unplugs the
> > machine and connects the HD to another Linux box, they can't access that
> > information.
>
> Hm? Maybe you need encrypted filesystem, something like cfs?
> W
On Jueves, 5 de Junio de 2003 10:19, Adam ENDRODI wrote:
> On Thu, Jun 05, 2003 at 09:30:51AM +0200, Luis Gomez - InfoEmergencias
wrote:
> > We'd like to protect that content, so that even if someone unplugs the
> > machine and connects the HD to another Linux box, they can't access that
> > infor
On Thu, Jun 05, 2003 at 09:30:51AM +0200, Luis Gomez - InfoEmergencias wrote:
>
> We'd like to protect that content, so that even if someone unplugs the
> machine
> and connects the HD to another Linux box, they can't access that information.
Default answer: encrypt your file system.
http://ww
> We'd like to protect that content, so that even if someone unplugs the
> machine
> and connects the HD to another Linux box, they can't access that information.
Hm? Maybe you need encrypted filesystem, something like cfs?
With schemes like this there are problems - you need to provide some ki
Hello world...
In my company, we've been working for some months in what I consider a rather
interesting product... but well, this mail is not spam ;)
Seriously, the fact is this: we are going to install Linux servers in some
companies, in order to serve mail, files, databases... We have develo
My idea: connection coming from inside network to the firewall going to
the web server are not considered by the rules
> >>$PROG -t nat -A PREROUTING -i $NIC_EXTERNAL -p tcp \
> >> -s 0/0 --dport http \
> >> -j DNAT --to-destination 192.168.1.2:80
> >>$PROG -t mangle -A FORWARD -i
> -Original Message-
> From: Hanasaki JiJi [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 5 June 2003 4:17 PM
> To: List - Debian Security
> Subject: Re: question squid + firewall + http server inside firewall
>
>
> Michael,
>
> unfortunately, that didnt work. Your logic makes sense.
> B
Michael,
unfortunately, that didnt work. Your logic makes sense. Below is the
output of the relavant lines: iptables -L -t nat
any other ideas would be great!
SNAT tcp -- 192.168.1.0/24 [internalhost] tcp dpt:www to:65.30.34.80
Michael Sharman wrote:
-Original Message-
From: Hanas
> -Original Message-
> From: Hanasaki JiJi [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 5 June 2003 2:42 PM
> To: List - Debian Security
> Subject: question squid + firewall + http server inside firewall
>
>
> I have the below rules in my firewall. the http server is inside the
> firewal
Am 12:14 2003-06-01 +1000 hat Aníbal Monsalve Salazar geschrieben:
>
>A month ago or so, Martin Schulze sent a message about his guidelines
>to help with security in debian. It included a URL at infodrom.org.
>
>Could someone please send me the message and the URL?
>
>Attachment Converted: "c:\tama
I have the below rules in my firewall. the http server is inside the
firewall on 192.168.1.2:80
people can hit it fine from the outside
squid is running on the firewall
inside can browser ouside via squid just fine
inside cannot browse the outside address
Any th
54 matches
Mail list logo
