On Thu, Dec 15, 2005 at 10:19:48PM +0000, kevin bailey wrote:
> good point - also the fact that the users stick their email passwords to
> their monitors using postits!

Well, at least there's still *some* level of physical security there;
an attacker has to be at your user's desk to get the password.  Plus,
given the choice between having your users use weak but easy to remember
passwords and having them use complex passwords that they have to write
down, the latter is the better option.  I'd suggest that they keep their
password in their wallet or something, though, and only take it out when
they need it.  Treat it like a credit card or something, and it's
basically safe.

> i'm almost thinking to switch the webmail service to normal apache - this
> would save me from having to run apache-ssl altogether.
> 
> the email accounts are virtual accounts and are not system/FTP accounts run
> on a courier email server.

Apache+mod_ssl is the way to go.  If your users will only access their
mail via the web interface, then configure your your IMAP server to only
listen on the loopback interface.

> > It may be nothing.  The fact that it showed up as filterd in the nmap
> > output indicates that nmap didn't received a TCP RST packet back when it
> > tried to contact that port.  That may mean you have iptables configured
> > to DROP packets to that port.
> 
> iptables has not been set up - but i take what you say.
> 
> so if i set up a firewall and drop nearly all packets does nmap report ports
> as unfiltered?
     ^^^^^^^^^^  
You mean filtered.  Yes.  Normally, when a TCP SYN is sent to a port
with nothing on it, the OS sends back a TCP RST packet, basically saying
"there's nothing here".  If you configure iptables to DROP the packets,
then nmap realizes that it didn't get the RST back and lists the port as
filtered.  If you want to firewall off a port such that it appears to
the outside world that there is nothing on that port at all, use 
"-j REJECT --reject-with tcp-reset" in the iptables rule.

As Florian pointed out, though, it's likely that your ISP is actually
dropping the SYN packet, and that's why nmap isn't getting the RST back.
Your OS never sees the SYN at all so it never sends back the RST.

noah

Attachment: signature.asc
Description: Digital signature

Reply via email to