Re: Physically securing FreeBSD workstations /boot/boot2
I seem to have found the answer to my own question. The question was: How do I prevent the boot2 bootstrap step from displaying a prompt where the user can load a custom boot program and/or force booting with options such as single user mode? The answer that seems to work for me: Add -n to /boot.config, I found this by ing the boot(8) man page. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Physically securing FreeBSD workstations /boot/boot2
Hi. I am attempting to secure some workstations in such a way that a user would not be able gain full control of the computer (only user access). However, they are able to see and touch the physical workstation. Things I'm trying to avoid, to list a couple of examples: 1. Go to BIOS settings and configure it to boot from CD first, then stick in a CD. To prevent this I've put BIOS to only boot from hard drive and I've password-locked the BIOS. 2. Go to loader menu and load (boot kernel) with some custom parameters or something. I've secured the loader menu by password-protecting it (/boot/loader.conf has password) and /boot/loader.conf is not world-readable. And I'm sure there are other things, I just forgot them. So my question is: Is this [securing of the workstation] worthwhile, or should I just forget about this kind of security? I want to make it so that the only way to gain full control of the computer is by physically opening up the box. I noticed that boot2 brings up a menu like this one when I press space during the initial boot blocks: FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: I guess it would be possible to stick in a floppy disk or something and boot from there? So my question is, is this a threat to my plan, and if so, how can I disable this prompt? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Physically securing FreeBSD workstations /boot/boot2
On 8/6/09, Nerius Landys nlan...@gmail.com wrote: Hi. I am attempting to secure some workstations in such a way that a user would not be able gain full control of the computer (only user access). However, they are able to see and touch the physical workstation. Things I'm trying to avoid, to list a couple of examples: 1. Go to BIOS settings and configure it to boot from CD first, then stick in a CD. To prevent this I've put BIOS to only boot from hard drive and I've password-locked the BIOS. You can't beat physical security. If you have access to the hardware, you can TAKE the box, saw it open, unmount the hard drive, slave it into another system, mount it as a data drive and steal the info. geli encryping the drive can secure the data on the disk, but they have your disk. it's as good as stolen data, even if they are unable to decrypt it. After sawing open the case, move the jumper to reset CMOS data, power up, change boot order, and boot off CD. After BIOS is back to normal, stick in a USB drive, boot off the HDD, which is self-decrypting the geli encryption, copy the data off, and scrub the HDD and install Windows on it. The hacker's OS (Just Kidding, all. Little humor is all I'm doing). 2. Go to loader menu and load (boot kernel) with some custom parameters or something. I've secured the loader menu by password-protecting it (/boot/loader.conf has password) and /boot/loader.conf is not world-readable. If you can do the above, even booting from alternate medium, no other means of security will apply. And I'm sure there are other things, I just forgot them. So my question is: Is this [securing of the workstation] worthwhile, or should I just forget about this kind of security? I want to make it so that the only way to gain full control of the computer is by physically opening up the box. I noticed that boot2 brings up a menu like this one when I press space during the initial boot blocks: FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: I guess it would be possible to stick in a floppy disk or something and boot from there? So my question is, is this a threat to my plan, and if so, how can I disable this prompt? Only security in these days is to physically secure the box and leave it off the network. Flaws and security problems will always allow unauthorized access. But a computer that's not on the network is of no use. So it's a loose-loose situation. Best effort is to know your people, and either trust them, or fire them. --TJ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Physically securing FreeBSD workstations /boot/boot2
On Thu, Aug 06, 2009 at 01:35:55PM -0600, Tim Judd wrote: On 8/6/09, Nerius Landys nlan...@gmail.com wrote: Hi. I am attempting to secure some workstations in such a way that a user would not be able gain full control of the computer (only user access). However, they are able to see and touch the physical workstation. Things I'm trying to avoid, to list a couple of examples: 1. Go to BIOS settings and configure it to boot from CD first, then stick in a CD. To prevent this I've put BIOS to only boot from hard drive and I've password-locked the BIOS. You can't beat physical security. If you have access to the hardware, you can TAKE the box, saw it open, unmount the hard drive, slave it into another system, mount it as a data drive and steal the info. geli encryping the drive can secure the data on the disk, but they have your disk. it's as good as stolen data, even if they are unable to decrypt it. After sawing open the case, move the jumper to reset CMOS data, power up, change boot order, and boot off CD. After BIOS is back to normal, stick in a USB drive, boot off the HDD, which is self-decrypting the geli encryption, copy the data off, and scrub the HDD and install Windows on it. The hacker's OS (Just Kidding, all. Little humor is all I'm doing). You can (and should) set geli up to require a passphrase, instead of or next to a key-file. Using only a key-file is like sticking a tin-opener to the tin. 2. Go to loader menu and load (boot kernel) with some custom parameters or something. I've secured the loader menu by password-protecting it (/boot/loader.conf has password) and /boot/loader.conf is not world-readable. If you can do the above, even booting from alternate medium, no other means of security will apply. And I'm sure there are other things, I just forgot them. So my question is: Is this [securing of the workstation] worthwhile, or should I just forget about this kind of security? I want to make it so that the only way to gain full control of the computer is by physically opening up the box. I noticed that boot2 brings up a menu like this one when I press space during the initial boot blocks: FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: I guess it would be possible to stick in a floppy disk or something and boot from there? So my question is, is this a threat to my plan, and if so, how can I disable this prompt? Disconnect or remove the floppy. Adn disable booting from USB devices. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp0APKNpOUAz.pgp Description: PGP signature
Re: Physically securing FreeBSD workstations /boot/boot2
Nerius Landys wrote: Hi. I am attempting to secure some workstations in such a way that a user would not be able gain full control of the computer (only user access). However, they are able to see and touch the physical workstation. I assume that users cannot tingle with the hardware, take it apart, add a different disk etc. and that only authorized users can physically access the computer. That's what physical security is about. I understand you may have some authorized user who will nevertheless try to gain elevated privileges. That's really logical security, local that is as opposed to remote/network security. 2. Go to loader menu and load (boot kernel) with some custom parameters or something. I've secured the loader menu by password-protecting it (/boot/loader.conf has password) and /boot/loader.conf is not world-readable. And I'm sure there are other things, I just forgot them. You can configure the loader such as not to present any loader menu but boot right away. If you need the option of booting into single user mode, then you can password protect single user mode. So my question is: Is this [securing of the workstation] worthwhile, or should I just forget about this kind of security? I want to make it so that the only way to gain full control of the computer is by physically opening up the box. You can always make it more difficult, which should give you less to worry about. You have to weigh how much work it takes against how much you really have to worry about, then decide when it's enough. How about running diskless? How about centralized authentication with NIS or LDAP? Another option is to disable root locally, that is the account still exist but with * in the password field.. If each workstation runs sshd you can use key based authentication to gain privileged access remotely while local access is disabled. I noticed that boot2 brings up a menu like this one when I press space during the initial boot blocks: FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: I guess it would be possible to stick in a floppy disk or something and boot from there? So my question is, is this a threat to my plan, and if so, how can I disable this prompt? you've still got floppies? wow. How about trying to boot a floppy with your current configuration? I'm not sure that it will work at that stage if it has been disabled in the bios. It might be possible to load the kernel from the harddisk then tell the kernel to mount the floppy as root device. You could solve that by compiling a kernel without floppy support and delete the kernel module. You need to learn how to script the loader, read the source code, I don't recall finding much documentation on that last time I looked. Others suggest you encrypt the harddrive, I don't find it very useful in your case, I assume your users need to access the systems and use them for the intended purposes and you just want to protect against someone trying to escalate his privileges. If you encrypt partitions with geli then you'll have to enter the password every time somebody reboots. However, you should consider encrypted swap and temporary partition, together with forced reboot on logout you avoid session data getting in the hands of the next user. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
securing FreeBSD
hi guys I would like to secure my FreeBSD server. I don't want anyone to be able to access to the disk using a bootable CD (or by setting the actual hdd to secondary and plug an other primary hdd). I just don't want anyone to be able to hack this box nor any password. Do you have a solution? Cheers Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: securing FreeBSD
[EMAIL PROTECTED] wrote: hi guys I would like to secure my FreeBSD server. I don't want anyone to be able to access to the disk using a bootable CD (or by setting the actual hdd to secondary and plug an other primary hdd). I just don't want anyone to be able to hack this box nor any password. Do you have a solution? Cheers Alex You can start by looking in the handbook, chapter 14, about security. Then you also have security(7) manual page to look at for information about how to secure a FreeBSD server. Regards! //Niclas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: securing FreeBSD
[EMAIL PROTECTED] wrote: hi guys I would like to secure my FreeBSD server. I don't want anyone to be able to access to the disk using a bootable CD (or by setting the actual hdd to secondary and plug an other primary hdd). I just don't want anyone to be able to hack this box nor any password. Do you have a solution? Securing a platform against a determined attacker who can put their hands on the physical hardware is a significant challenge for any OS. To protect against the type of attack you describe, encrypting all disk content (or at least the sensitive parts) is probably the only effective thing you can do, short of sealing the whole thing inside some other physically protected environment. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html Short of that, you could use a case with a trigger mechanism that informs the BIOS that the case has been opened, so that a warning is emitted at boot time re: physical security has been violated. Of course, that doesn't prevent intrusion, it just tells you that it occurred (and then, only if the intruder doesn't also violate your BIOS security and simply reset the case has been opened bits). -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) gregb at scls.lib.wi.us, (608) 266-6348 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: securing FreeBSD
On 7/13/05, Greg Barniskis [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: hi guys I would like to secure my FreeBSD server. I don't want anyone to be able to access to the disk using a bootable CD (or by setting the actual hdd to secondary and plug an other primary hdd). I just don't want anyone to be able to hack this box nor any password. Do you have a solution? Securing a platform against a determined attacker who can put their hands on the physical hardware is a significant challenge for any OS. To protect against the type of attack you describe, encrypting all disk content (or at least the sensitive parts) is probably the only effective thing you can do, short of sealing the whole thing inside some other physically protected environment. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html Short of that, you could use a case with a trigger mechanism that informs the BIOS that the case has been opened, so that a warning is emitted at boot time re: physical security has been violated. Of course, that doesn't prevent intrusion, it just tells you that it occurred (and then, only if the intruder doesn't also violate your BIOS security and simply reset the case has been opened bits). -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) gregb at scls.lib.wi.us, (608) 266-6348 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Plus, use google: +hardening freebsd. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: securing FreeBSD
On Wed, Jul 13, 2005 at 01:05:43PM +0200, [EMAIL PROTECTED] wrote: I would like to secure my FreeBSD server. I don't want anyone to be able to access to the disk using a bootable CD (or by setting the actual hdd to secondary and plug an other primary hdd). Put the machine in a locked cabinet (which should have enough ventilation holes). The cabinet should be bolted to the floor or the wall. How sturdy the cabinet needs to be depends on what kind of attack it should withstand, and for how long... I just don't want anyone to be able to hack this box nor any password. Disable all unneeded services and accounts. Allow root login from the console only. If you have physical access, disallow remote login entirely. Use long random passwords. Keep on top of security updates. Install intrusion detection systems. Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgpatuSRyzdl0.pgp Description: PGP signature
Re: securing FreeBSD
or by setting the actual hdd to secondary and plug an other primary hdd Once the hardware is compromised, it is really tricky to keep secure. If you cannot protect your hardware (secure room) then your hard disk has to auto protect itself: encrypt the data, and have no saved password on the disk itself (means you will have to enter a passphrase each time your disk is mounted). I'd have 2 physical disks, one for the system and one for the data. The system disk is cleartext, the data is encrypted. And I'd have the private key on a removable device (like USB for exeample). Be sure that your system does not dump any memory image in case of panic. Another solution (expensive and only valid for a limited amount of data) have a RAM disk (and secure your electric power supply). An intruder would have to turn off the power to grab the memory. Doing so he would delete the data... Depends what is your level of paranoia :) Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
suid bit files and securing FreeBSD
Hello everybody, I'm a newbie in this list, so I don't know if it's the appropriate place for my question. Anyway, I'd be happy to find out the solution. Please, has anyone simple answer for: I'm looking for an exact list of files, which: 1. MUST have... 2. HAVE FROM BSD INSTALLATION... 3. DO NOT NEED... 4. NEVER MAY... ...the suid-bit set. Of course, it's no problem to find-out which files ALREADY HAS suid-bit set. But what files REALLY MUST have it ? I know generalities, as e.g. shell should never have suid bit set, but what if someone has copied any shell to some other location and have set the suid bit ? It's security hole, isn't it ? And what if I have more such files on my machine ? It is not about my machine has been compromited, it is only WHAT IF... Second question is: Has anybody an exact wizard, how to secure the FreeBSD machine. Imagine the situation, the only person who can do anything on that machine is me, and nobody other. I have set very restrictive firewalling, I have removed ALL tty's except two local tty's (I need to work on that machine), but there are still open port 25 and 53 (must be forever), so someone very tricky can compromite my machine. I'm a little bit paranoic, don't I :-))) Cheers, Peter Rosa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suid bit files and securing FreeBSD
Sorry for disturbing you. This was for security mailing list and I sent it here by mistake Cheers, Peter Rosa - Original Message - From: Peter Rosa [EMAIL PROTECTED] To: FreeBSD Questions [EMAIL PROTECTED] Sent: Saturday, July 26, 2003 7:11 PM Subject: suid bit files and securing FreeBSD Hello everybody, I'm a newbie in this list, so I don't know if it's the appropriate place for my question. Anyway, I'd be happy to find out the solution. Please, has anyone simple answer for: I'm looking for an exact list of files, which: 1. MUST have... 2. HAVE FROM BSD INSTALLATION... 3. DO NOT NEED... 4. NEVER MAY... ...the suid-bit set. Of course, it's no problem to find-out which files ALREADY HAS suid-bit set. But what files REALLY MUST have it ? I know generalities, as e.g. shell should never have suid bit set, but what if someone has copied any shell to some other location and have set the suid bit ? It's security hole, isn't it ? And what if I have more such files on my machine ? It is not about my machine has been compromited, it is only WHAT IF... Second question is: Has anybody an exact wizard, how to secure the FreeBSD machine. Imagine the situation, the only person who can do anything on that machine is me, and nobody other. I have set very restrictive firewalling, I have removed ALL tty's except two local tty's (I need to work on that machine), but there are still open port 25 and 53 (must be forever), so someone very tricky can compromite my machine. I'm a little bit paranoic, don't I :-))) Cheers, Peter Rosa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suid bit files and securing FreeBSD
Second question is: Has anybody an exact wizard, how to secure the FreeBSD machine. Imagine the situation, the only person who can do anything on that machine is me, and nobody other. I have set very restrictive firewalling, I have removed ALL tty's except two local tty's (I need to work on that machine), but there are still open port 25 and 53 (must be forever), so someone very tricky can compromite my machine. I'm a little bit paranoic, don't I :-))) Uhm, yes, you *are* just a wee bit paranoid. But it helps to be paranoid if you're root on somebody else's machine. Great power and great responsibility, right? But if you're concerned with security uber alles, I'm surprised you didn't look into OpenBSD first. According to their site (openbsd.org), they've had only one remote hole in the default install, in more than 7 years! FreeBSD certainly can be secured, but it appears that the developers put performance and reliability first, and then security. Theo de Raadt puts security first. -- Matthew Graybosch http://www.starbreaker.net I am become root, shatterer of kernels. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suid bit files and securing FreeBSD
Hello Matthew,
thank you very much. It's excatly you say. FreeBSD is my option because of
historical reasons. Someone has installed it for me two years ago, and now
I love it (he installed it after two hacks and two reinstallations of RedHat
Linux [I don't want to say, RHL is not good, but FBSD is better :-) {now I
see the storm, like with I'm christian.. mail to this list :-))) } ] ).
Wow, such a short sentence I just produced :-)
Peter Rosa
- Original Message -
From: Matthew Graybosch [EMAIL PROTECTED]
To: Peter Rosa [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, July 26, 2003 7:22 PM
Subject: Re: suid bit files and securing FreeBSD
Second question is: Has anybody an exact wizard, how to secure
the FreeBSD machine. Imagine the situation, the only person who
can do anything on that machine is me, and nobody other. I have
set very restrictive firewalling, I have removed ALL tty's except
two local tty's (I need to work on that machine), but there are
still open port 25 and 53 (must be forever), so someone very
tricky can compromite my machine.
I'm a little bit paranoic, don't I :-)))
Uhm, yes, you *are* just a wee bit paranoid. But it helps to be
paranoid if you're root on somebody else's machine. Great power and
great responsibility, right?
But if you're concerned with security uber alles, I'm surprised you
didn't look into OpenBSD first. According to their site
(openbsd.org), they've had only one remote hole in the default
install, in more than 7 years!
FreeBSD certainly can be secured, but it appears that the developers
put performance and reliability first, and then security. Theo de
Raadt puts security first.
--
Matthew Graybosch
http://www.starbreaker.net
I am become root, shatterer of kernels.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suid bit files and securing FreeBSD
Matthew Graybosch wrote: But if you're concerned with security uber alles, I'm surprised you didn't look into OpenBSD first. According to their site (openbsd.org), they've had only one remote hole in the default install, in more than 7 years! Caveat: the default install has almost nothing in it. This is fine if you plan to do almost nothing, but if you install any software, you'll be about as well off as if you were installing that software anywhere else. FreeBSD certainly can be secured, but it appears that the developers put performance and reliability first, and then security. Theo de Raadt puts security first. The BSDs borrow freely from each other. OpenBSD perhaps is a little more aggressive about cryptography in the base system, but the results of OpenBSD audits are often used by Net and Free. Please look up from your BSD Executive Summary article :-) To claim that FreeBSD puts reliability ahead of security doesn't make sense; a compromised system is usually not reliable. Security (and more broadly, stability/reliability) are given a little more consideration than performance, if you want to order them. A competent administrator can secure any system. An incompetent administrator should become competent (on machines unreachable from the internet) before running anything important in publically-reachable space. To the original poster: I take it you are running DNS and SMTP on the FreeBSD machine? Try to avoid BIND 8; use BIND 9 or djbdns for your DNS. Qmail and Postfix have better security records than Sendmail for SMTP; I prefer Postfix for ease of configuration. If you're running a BIND version, run it as user bind in a chroot (at least). I'd worry more about your public services than about SUID bits: if there is no shell access, nobody will be able to take advantage of SUID without first finding a hole allowing shell access. Subscribe to freebsd-security-notifications for, well, security notifications. Keep your ears open for bugs in your MTA or DNS server. With a little vigilance you have little to fear. Good luck, -- Daniel Harris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suid bit files and securing FreeBSD
Peter Rosa wrote: [ ... ] I'm looking for an exact list of files, which: 1. MUST have... 2. HAVE FROM BSD INSTALLATION... 3. DO NOT NEED... 4. NEVER MAY... ...the suid-bit set. Of course, it's no problem to find-out which files ALREADY HAS suid-bit set. But what files REALLY MUST have it ? The files which ship setuid REALLY MUST have the setuid-bit for the underlying programs to work normally for a non-root user. If you don't care about non-root users having a normal environment, you can probably remove the setuid-bit from every program. [ Things like 'su' won't function, nor will 'ping', any utility like ps, netstat, etc which grovel in kernel data structures, etc. ] I know generalities, as e.g. shell should never have suid bit set, but what if someone has copied any shell to some other location and have set the suid bit ? It's security hole, isn't it ? Yes. And what if I have more such files on my machine ? You would have more security holes. It is not about my machine has been compromited, it is only WHAT IF... Second question is: Has anybody an exact wizard, how to secure the FreeBSD machine. Imagine the situation, the only person who can do anything on that machine is me, and nobody other. I have set very restrictive firewalling, I have removed ALL tty's except two local tty's (I need to work on that machine), but there are still open port 25 and 53 (must be forever), so someone very tricky can compromite my machine. Disconnect the machine from the network and lock it in a vault: that's a secure system. If you can't do that, say because you need to run network services on this system, then you need to stay up-to-date with regard to those services, and upgrade or apply patches as appropriate, ie, if a security hole is announced. Contorting the system in the fashion you describe gives little security benefit. -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
