Re: idea for improving security

2003-05-07 Thread Alexander Reelsen
Hi

On Tue, May 06, 2003 at 10:05:49PM -0400, Robert B Wilson wrote:
 On Tue, 06 May 2003 20:13:41 + Deger Cenk Erdil
 [EMAIL PROTECTED] writes:
  But, if I can intercept your trigger sequence messages as an 
  attacker 
  on your subnet, or even on the Net, I can replicate the same 
  sequence 
  quite easily!
 what if the trigger sequence changed each time?  then if someone
 intercepted the trigger sequence, it wouldn't do them any good, unless
 they collected enough trigger sequences to be able to determine the
 next
 one, but that would take a lot of work...
This is already implemented and is called One time passwords

Why the heck would you want to do that on osi layers 3/4 instead of the
application?

And it would be hard to implement.. changing one flag per IP packet sent
or what? In a random non guessable order? Hard work... useless IMO


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://tretmine.org
[EMAIL PROTECTED]



Re: idea for improving security

2003-05-07 Thread Alexander Reelsen
Hi

On Tue, May 06, 2003 at 06:22:54PM -0600, Will Aoki wrote:
 I believe that there are rootkits in the wild which do this.
Yepp. Found some standard rootkits with that thing as addition.

 Although I can't find the reference I had to it, I believe that some
 listen for traffic on a rare or unallocated protocol before opening a
 backdoor.
http://www.phenoelit.de/stuff/cd00r.c
has been used sometimes on compromised machines...


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://tretmine.org
[EMAIL PROTECTED]



Re: idea for improving security

2003-05-07 Thread Alexander Reelsen
Hi

On Tue, May 06, 2003 at 11:26:35PM +0200, Horst Pflugstaedt wrote:
 On Tue, May 06, 2003 at 01:07:24PM -0500, Mark Edgington wrote:
  2) the port(s) to make available upon receiving this trigger sequence
  3) whether the ports to be made available are available for a) the next n 
  connections only, 
 what if someone else tries to connect exactly this one time?
You can always differentiate between different source ips.

  and/or b) the next n minutes
 what happens if you need more(tm) time?
You configure it with greater timeout values?

  3) how long to disable watching for the sequence after an invalid sequence 
  has been detected.
 how do you define an invalid sequence? how would you determine wether
 someone else tries to trigger your port or is simply scanning you?
If you have a combination and 80% of that combination were guessed
correctly (by say, 5 different ip packets, it would be quite a strange
coincidence), you could define an invalid sequence.

 I'd rather work with some other mechanism like granting acces to/from
 one single IP/Port. you migth for example realize this with two
 encrypted Emails where the server-generated Mail includes some random
 Data (for extra security) and the Client-generated Mail includes the
 Clients IP...
Who said you need listening ports for that? Just use libpcap, open up a
raw socket and catch the packets before they are processed. So you
don't need any listening service but still can evaluate the packets.

  makes a connection to 4385, this would invalidate the sequence) -- if these 
  trigger-sequence ports are all connected to in order (and the 
  disable-sequence-listen timeout has elapsed), then port 22 becomes open to 
  connect to.
 You'll have to rely on many people not trying to connect to your magic
 ports while you don't want them to...
Who said ports? Specially crafted IP packets are absolutely sufficient :)

I think the main goal of this question was not that end users can connect
to the services, but only administrators. If you have 100 machines on the
net placed at customers it might be pretty handy, if you dont have to
worry about ssh auto rooters after the new 0day exploit, because they
don't try the magic-ip-packet-sequence. This adds another layer of security
against dumb attacks, not against directed attacks.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://tretmine.org
[EMAIL PROTECTED]



Re: idea for improving security

2003-05-06 Thread Alexander Reelsen
Hi

On Tue, May 06, 2003 at 01:07:24PM -0500, Mark Edgington wrote:
   I'm not sure whether this idea has been considered or implemented 
   anywhere, but I have been thinking about it, and believe it would provide a 
 fairly high-level of security for systems which only run a few public 
 services.  The gist of it is this:
 incorporate functionality into inetd/xinetd/rinetd which listens for a 
 predefined sequence of connection attempts on certain ports.  Upon noticing 
 the correct sequence (as specified somewhere in the config file), it opens 
 up certain ports (i.e. SSH) for a specified amount of time or for the next 
 connection attempt only.  The parameters which could be set in the config 
 file would be:
Sadoor

http://cmn.listprojects.darklab.org/


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://tretmine.org
[EMAIL PROTECTED]



Re: speaking of squid ports...

2003-03-26 Thread Alexander Reelsen
On Wed, Mar 26, 2003 at 03:18:36PM -0500, Noah L. Meyerhans wrote:
 On Wed, Mar 26, 2003 at 02:15:28PM -0500, Kevin Cheek wrote:
  I believe that UDP port is for receiving DNS responses.
 It's used for ICP, a protocol for intercommunication between squid
 caches.  For example, at my site we have two different caches.  One is
 basically transparent.  The other provides anonymizing services.  But,
 through ICP, both caches can make use of each other's cached objects.
 
 Dunno how you turn it off, though.  Iptables?  shrug
Should work by setting the icp_port to '0'... If it is written via -u in
the init scripts the config file settings are overwritten, so beware.


Regards, Alexander

-- 
Alexander Reelsen
http://tretmine.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: speaking of squid ports...

2003-03-26 Thread Alexander Reelsen
On Wed, Mar 26, 2003 at 03:18:36PM -0500, Noah L. Meyerhans wrote:
 On Wed, Mar 26, 2003 at 02:15:28PM -0500, Kevin Cheek wrote:
  I believe that UDP port is for receiving DNS responses.
 It's used for ICP, a protocol for intercommunication between squid
 caches.  For example, at my site we have two different caches.  One is
 basically transparent.  The other provides anonymizing services.  But,
 through ICP, both caches can make use of each other's cached objects.
 
 Dunno how you turn it off, though.  Iptables?  shrug
Should work by setting the icp_port to '0'... If it is written via -u in
the init scripts the config file settings are overwritten, so beware.


Regards, Alexander

-- 
Alexander Reelsen
http://tretmine.org



Re: Review: sect. 4.16.2 of the Securing Debian manual

2003-03-13 Thread Alexander Reelsen
Hi

On Thu, Mar 13, 2003 at 09:02:47PM +1100, Frederic Schutz wrote:
 p A better solution is to use the capabilities, as described in ref
 id=proactive. The capability of interest is called
 ttCAP_LINUX_IMMUTABLE/tt: if you remove it from the capabilities
 bounding set (using for example the command ttlcap
 CAP_LINUX_IMMUTABLE/tt) it won't be possible to change any 'a' or 'i'
 attribute on your system anymore, even by the superuser ! A complete
 strategy could be as follows:
 
 enumlist
   item Set the attributes 'a' and 'i' on any file you want;
   item Add the command ttlcap CAP_LINUX_IMMUTABLE/tt to one of
  the startup scripts;
   item Set the 'i' attribute on this script and other startup files, as
  well as on the prgnlcap/prgn binary itself;
   item Execute the above command manually (or reboot your system to
  make sure everything works as planned).
 /enumlist
I always thought of CAP_LINUX_IMMUTABLE as a not-used extension. If you are
not root, you may have the capability to set files immutable or
append-only if it is given to you. If you are root (in your above
described scenario), you can switch on that capability everytime again,
or am I missing something obvious? At least in the above described way
this is possible, if you do not want to do that, you would need set
capabilities that way, that you cannot change them anymore.

 Now that the capability has been removed from the system, an intruder
 can not change any extended attribute on the protected files, and thus
 can not change or remove the files. If he forces the machine to reboot
 (which is the only way to restore the capabilities bounding set), it
 will easily be detected, and the capability will be removed again as
 soon as the system restarts anyway. The only way to change a
 protected file would be to boot the system in single-user mode or
 using another bootdisk, two operations that require physical access to
 the machine !
Are you sure on this one?

rwblinux2:~ # sysctl -A | grep cap-bound
kernel.cap-bound = -257

Being it a sysctl parameter makes me wonder whether you can set things
runtime (if you have the appropriate capability of course). lcap does
exactly that, writing in this procfile.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://tretmine.org
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Review: sect. 4.16.2 of the Securing Debian manual

2003-03-13 Thread Alexander Reelsen
Hi

On Thu, Mar 13, 2003 at 10:22:19PM +1100, Frederic Schutz wrote:
 On Thu, 13 Mar 2003, Alexander Reelsen wrote:
  Are you sure on this one?
 
  # sysctl -A | grep cap-bound
  kernel.cap-bound = -257
 
  Being it a sysctl parameter makes me wonder whether you can set things
  runtime (if you have the appropriate capability of course). lcap does
  exactly that, writing in this procfile.
 Capabilities is the next section that I plan to write/rewrite :-) The
 interesting point about capabilities is that once one of them has been
 removed, it can not be added back -- so lcap can only remove capabilities,
 and not add them again. You can have a look at the current section 9.3.2.1
 of the manual, there is a very short blurb on the subject (with some
 references)
Ok. I wasn't sure anymore, whether it is completely impossible to add back
a capability. Do you have some reference about that? I have something in
mind about that but I can't remember exactly.

 Does it answer your questions or did I miss a real loophole in the
 strategy that I described ?
If you provide some reference, then for sure :)


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://tretmine.org
[EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: Review: sect. 4.16.2 of the Securing Debian manual

2003-03-13 Thread Alexander Reelsen
Hi

On Thu, Mar 13, 2003 at 09:02:47PM +1100, Frederic Schutz wrote:
 p A better solution is to use the capabilities, as described in ref
 id=proactive. The capability of interest is called
 ttCAP_LINUX_IMMUTABLE/tt: if you remove it from the capabilities
 bounding set (using for example the command ttlcap
 CAP_LINUX_IMMUTABLE/tt) it won't be possible to change any 'a' or 'i'
 attribute on your system anymore, even by the superuser ! A complete
 strategy could be as follows:
 
 enumlist
   item Set the attributes 'a' and 'i' on any file you want;
   item Add the command ttlcap CAP_LINUX_IMMUTABLE/tt to one of
  the startup scripts;
   item Set the 'i' attribute on this script and other startup files, as
  well as on the prgnlcap/prgn binary itself;
   item Execute the above command manually (or reboot your system to
  make sure everything works as planned).
 /enumlist
I always thought of CAP_LINUX_IMMUTABLE as a not-used extension. If you are
not root, you may have the capability to set files immutable or
append-only if it is given to you. If you are root (in your above
described scenario), you can switch on that capability everytime again,
or am I missing something obvious? At least in the above described way
this is possible, if you do not want to do that, you would need set
capabilities that way, that you cannot change them anymore.

 Now that the capability has been removed from the system, an intruder
 can not change any extended attribute on the protected files, and thus
 can not change or remove the files. If he forces the machine to reboot
 (which is the only way to restore the capabilities bounding set), it
 will easily be detected, and the capability will be removed again as
 soon as the system restarts anyway. The only way to change a
 protected file would be to boot the system in single-user mode or
 using another bootdisk, two operations that require physical access to
 the machine !
Are you sure on this one?

rwblinux2:~ # sysctl -A | grep cap-bound
kernel.cap-bound = -257

Being it a sysctl parameter makes me wonder whether you can set things
runtime (if you have the appropriate capability of course). lcap does
exactly that, writing in this procfile.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://tretmine.org
[EMAIL PROTECTED]



Re: Review: sect. 4.16.2 of the Securing Debian manual

2003-03-13 Thread Alexander Reelsen
Hi

On Thu, Mar 13, 2003 at 10:22:19PM +1100, Frederic Schutz wrote:
 On Thu, 13 Mar 2003, Alexander Reelsen wrote:
  Are you sure on this one?
 
  # sysctl -A | grep cap-bound
  kernel.cap-bound = -257
 
  Being it a sysctl parameter makes me wonder whether you can set things
  runtime (if you have the appropriate capability of course). lcap does
  exactly that, writing in this procfile.
 Capabilities is the next section that I plan to write/rewrite :-) The
 interesting point about capabilities is that once one of them has been
 removed, it can not be added back -- so lcap can only remove capabilities,
 and not add them again. You can have a look at the current section 9.3.2.1
 of the manual, there is a very short blurb on the subject (with some
 references)
Ok. I wasn't sure anymore, whether it is completely impossible to add back
a capability. Do you have some reference about that? I have something in
mind about that but I can't remember exactly.

 Does it answer your questions or did I miss a real loophole in the
 strategy that I described ?
If you provide some reference, then for sure :)


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://tretmine.org
[EMAIL PROTECTED]



Re: Strange warning

2002-08-17 Thread Alexander Reelsen
On Sat, Aug 17, 2002 at 09:25:07PM +0100, Dale Amon wrote:
 Anyone know what this means? Even google draws a blank.
 
 tcpspy[29190]: /proc/net/tcp: warning: incomplete line
Taking a very quick look at the source along with reading the description
of tcpspy makes you feel, it's nothing to totally worry about. That error
occures if a sscanf() fails when reading the above mentiond file.

description
Description: Incoming and Outgoing TCP/IP connections logger.
 tcpspy is an administrator's tool that logs information
 about incoming and outgoing TCP/IP connections. It's
 written in C and uses no libpcap functions, unlike tcpdump.
 .
 Connections are selected for logging with rules, similarly
 to the filter expressions accepted by tcpdump. The
 following information is logged: username, local address
 and port, remote address and port, and, optionally, the
 executable filename.
 .
 At present, only the IPv4 protocol is supported.
/description

Are you using IPv6 and the parsing then fails possibly? Or something like
that?

If you find the problem, please tell.


Greets, Alexander



Re: best way to create pop only accounts

2002-03-11 Thread Alexander Reelsen

Hiya

On Mon, Mar 11, 2002 at 03:40:18PM +0100, Javier Fernández-Sanguino Peña wrote:
 On Mon, Mar 11, 2002 at 09:21:45AM -0300, Pedro Zorzenon Neto wrote:
 Which is the best way to create a POP only account? just change the
  last field in /etc/passwd to /bin/false?
   No. My 2 cents (of Euro): use a directory for POP authentication
 using the appropiate PAM modules, you could easily setup LDAP for this and
 there are quite a number of POP3 daemons that provide LDAP schemas which
 can be readily used in, for example, OpenLDAP.
PAM is definately the way to go here. You can use the debian packages of
for example your popdeamon-of-choice and just install the backend yourself
(if you need to). Doing this via LDAP is a neat way, but you could also do
the authentication and/or storing of all the mail via MySQL.

I bet you are already using PAM to authenticate via /etc/passwd, you're
just not realize this :-)

Check out the (not always easy to read) documentation about PAM, however
it's worth a read.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: best way to create pop only accounts

2002-03-11 Thread Alexander Reelsen
Hiya

On Mon, Mar 11, 2002 at 03:40:18PM +0100, Javier Fernández-Sanguino Peña wrote:
 On Mon, Mar 11, 2002 at 09:21:45AM -0300, Pedro Zorzenon Neto wrote:
 Which is the best way to create a POP only account? just change the
  last field in /etc/passwd to /bin/false?
   No. My 2 cents (of Euro): use a directory for POP authentication
 using the appropiate PAM modules, you could easily setup LDAP for this and
 there are quite a number of POP3 daemons that provide LDAP schemas which
 can be readily used in, for example, OpenLDAP.
PAM is definately the way to go here. You can use the debian packages of
for example your popdeamon-of-choice and just install the backend yourself
(if you need to). Doing this via LDAP is a neat way, but you could also do
the authentication and/or storing of all the mail via MySQL.

I bet you are already using PAM to authenticate via /etc/passwd, you're
just not realize this :-)

Check out the (not always easy to read) documentation about PAM, however
it's worth a read.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C



Re: IP accounting per user

2002-01-08 Thread Alexander Reelsen

On Mon, Jan 07, 2002 at 03:42:56PM +0100, Ralf Dreibrodt wrote:
  yeah, that looks nice, but who'd run a 2.4.6 these days???
  dammit, i don't really want to patch 2.2.20 or 2.4.17 myself
 i use the patch with a 2.4.16.
 some parts of the patch failed (after the lids patch), it took less than
 two minutes to correct this by hand.
 i don't think, that there are too much more changes for the 2.4.17.
Has it become SMP safe for 2.4 kernels? It never was for 2.2...


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: IP accounting per user

2002-01-08 Thread Alexander Reelsen
On Mon, Jan 07, 2002 at 03:42:56PM +0100, Ralf Dreibrodt wrote:
  yeah, that looks nice, but who'd run a 2.4.6 these days???
  dammit, i don't really want to patch 2.2.20 or 2.4.17 myself
 i use the patch with a 2.4.16.
 some parts of the patch failed (after the lids patch), it took less than
 two minutes to correct this by hand.
 i don't think, that there are too much more changes for the 2.4.17.
Has it become SMP safe for 2.4 kernels? It never was for 2.2...


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C



Re: Security on debian

2001-09-30 Thread Alexander Reelsen

Hiya

On Sun, Sep 30, 2001 at 12:17:00AM -0600, Stefan Srdic wrote:
 This is the link that I have for the Securing Debian HOW-TO, it appears 
 to be down too
 
 http://joker.rhwd.de/doc/Securing-Debian-HOWTO/Securing-Debian-HOWTO.htm
First it does not seem down (to me at least), second you should change
.htm to .html and third this document is completely obsoleted as Javier
Fernandez has incorporated it into an official Debian Document Project
Paper on www.debian.org/doc, which should be used as reference. :)


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED]7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Security on debian

2001-09-30 Thread Alexander Reelsen
Hiya

On Sun, Sep 30, 2001 at 12:17:00AM -0600, Stefan Srdic wrote:
 This is the link that I have for the Securing Debian HOW-TO, it appears 
 to be down too
 
 http://joker.rhwd.de/doc/Securing-Debian-HOWTO/Securing-Debian-HOWTO.htm
First it does not seem down (to me at least), second you should change
.htm to .html and third this document is completely obsoleted as Javier
Fernandez has incorporated it into an official Debian Document Project
Paper on www.debian.org/doc, which should be used as reference. :)


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED]7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO



Re: Listening Ports

2001-09-10 Thread Alexander Reelsen

On Mon, Sep 10, 2001 at 02:14:56PM +0200, Bernhard R. Link wrote:
 On Mon, 10 Sep 2001, Alexander Reelsen wrote:
  First binding then firewalling is a bad idea, someone might be able to
  access that service via spoofing or other dirty tricks...
 I do not know very much in this area, but I was of the impression, that
 firewalling might be more secure than giving ip, as you can only specify
 the ip, and not the network-interface the connection comes from.
Well, I consider listening on a certain IP as quite secure, because you
mostly know what ip is bound to what interface. If you want to do extra
firewalling per-interface then you need something else than inetd.

Both is useful, what I meant was the fact, that starting unnecessary
services per-ip (per-interface as well ;)) and firewalling those
afterwards is not that securitywise as not starting them at all.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED]7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Listening Ports

2001-09-10 Thread Alexander Reelsen
On Sun, Sep 09, 2001 at 06:31:57PM -0400, hpknight wrote:
 It depends on the process that is binding the port.  If you're using
 xinetd you can specify which interface to bind the port on.  If the
 program/daemon doesn't allow you to specify interfaces, then you're stuck
 .. unless you want to do some fancy stuff with ipchains/iptables to
 redirect ports, or hack up the daemon.
inetd also has this feature (not very well documented).
use [EMAIL PROTECTED] in inetd.conf in order to use that feature.
xinetd is nicer, anyway :-)

First binding then firewalling is a bad idea, someone might be able to
access that service via spoofing or other dirty tricks...


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED]7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO



Re: Listening Ports

2001-09-10 Thread Alexander Reelsen
On Mon, Sep 10, 2001 at 02:14:56PM +0200, Bernhard R. Link wrote:
 On Mon, 10 Sep 2001, Alexander Reelsen wrote:
  First binding then firewalling is a bad idea, someone might be able to
  access that service via spoofing or other dirty tricks...
 I do not know very much in this area, but I was of the impression, that
 firewalling might be more secure than giving ip, as you can only specify
 the ip, and not the network-interface the connection comes from.
Well, I consider listening on a certain IP as quite secure, because you
mostly know what ip is bound to what interface. If you want to do extra
firewalling per-interface then you need something else than inetd.

Both is useful, what I meant was the fact, that starting unnecessary
services per-ip (per-interface as well ;)) and firewalling those
afterwards is not that securitywise as not starting them at all.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED]7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO



Re: Daemon init scripts and apt-get [was: Re: red worm amusement]

2001-08-13 Thread Alexander Reelsen

Hi

On Fri, Aug 10, 2001 at 05:17:58PM +0200, Marko Kreen wrote:
 On Thu, Aug 09, 2001 at 02:01:30PM -0700, Dale Southard wrote:
  Marko Kreen [EMAIL PROTECTED] writes:
   Well, then we are on back on square one - how do we disable a
   service?
  If there is an interest in IRIX-style chkconfig, I can probably throw
  something together from the scripts and docs I have lying around
 I would be interested.  :)
You might want to check file-rc or rcconf as well...


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED]7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: Daemon init scripts and apt-get [was: Re: red worm amusement]

2001-08-13 Thread Alexander Reelsen
Hi

On Fri, Aug 10, 2001 at 05:17:58PM +0200, Marko Kreen wrote:
 On Thu, Aug 09, 2001 at 02:01:30PM -0700, Dale Southard wrote:
  Marko Kreen marko@l-t.ee writes:
   Well, then we are on back on square one - how do we disable a
   service?
  If there is an interest in IRIX-style chkconfig, I can probably throw
  something together from the scripts and docs I have lying around
 I would be interested.  :)
You might want to check file-rc or rcconf as well...


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED]7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO



Re: CGI Buffer Overflow?

2001-07-19 Thread Alexander Reelsen

Hi

On Thu, Jul 19, 2001 at 05:17:26PM -0400, Brian Rectanus wrote:
 xxx.xxx.xxx.xxx - - [19/Jul/2001:14:28:23 -0400] GET
 /default.ida?NNN
 
 
 N%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9
 090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0
 078%u%u00=a  HTTP/1.0 400 328
New IIS exploit (a worm flooding whitehouse.gov and infecting other hosts).
Check bugtraq/securityfocus for more.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED]7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: CGI Buffer Overflow?

2001-07-19 Thread Alexander Reelsen
Hi

On Thu, Jul 19, 2001 at 05:17:26PM -0400, Brian Rectanus wrote:
 xxx.xxx.xxx.xxx - - [19/Jul/2001:14:28:23 -0400] GET
 /default.ida?NNN
 
 
 N%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9
 090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0
 078%u%u00=a  HTTP/1.0 400 328
New IIS exploit (a worm flooding whitehouse.gov and infecting other hosts).
Check bugtraq/securityfocus for more.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED]7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO



Re: was I cracked? (rpc.statd, new version)

2001-07-12 Thread Alexander Reelsen

On Thu, Jul 12, 2001 at 05:33:29AM -0700, Krause, Oliver wrote:
 Can dpkg check the files in my filesystem against the version which is
 in the packages database? So i can verify if the binary was modified.
 Then the only thing i need is a signing of the dep-packages and the
 database itself (perhaps with an external key).
 Is something like this possible or is it planned?
apt-get install debsums


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]




Re: was I cracked? (rpc.statd, new version)

2001-07-12 Thread Alexander Reelsen
On Thu, Jul 12, 2001 at 05:33:29AM -0700, Krause, Oliver wrote:
 Can dpkg check the files in my filesystem against the version which is
 in the packages database? So i can verify if the binary was modified.
 Then the only thing i need is a signing of the dep-packages and the
 database itself (perhaps with an external key).
 Is something like this possible or is it planned?
apt-get install debsums


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO



Applications using Linux capabilities

2001-03-22 Thread Alexander Reelsen
Hi folks

I'm currently collecting a list of applications which make use of the
capabilities introduced in Linux 2.2. However this list is quite short and
I'm wondering whether I am searching wrong or the capabilities aren't
advocated enough yet or just not used as they're bad or whatever (huge
huh? here from my side).

So if anyone has a application to add to this list, please tell me so.

Incredibly long list of apps:
- proftpd
- xntp3 w/patch (just keeps CAP_SYS_TIME, drops uid 0)


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO



Re: Network security

2001-03-08 Thread Alexander Reelsen
On Thu, Mar 08, 2001 at 04:43:14PM +0100, [EMAIL PROTECTED] wrote:
 Now, I wonder why this problem occours. I'll have to take a look at some RFC
 to figure out.. anyone who can point me in the right direction??
Best would be to take a look at linux-net mailinglist archives or
netfilter, the issue is explained there in a long, good and clear
fashion...


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO



Re: howto check the integrity of installed packets

2001-03-07 Thread Alexander Reelsen

Hi

On Wed, Mar 07, 2001 at 03:34:14PM +0100, Jrgen Persson wrote:
 the subject is clear enough... I'm looking for ''native'' support for 
 checking the integrity of installed packets.
You might want to try the package 'debsums'. However those files are easy
to change, but perhaps it's a start if you monitor the md5sums files as
well, or mark them readonly with LIDS, whatever...


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: Updating the Securing HOWTO

2001-02-04 Thread Alexander Reelsen
Hi

On Sun, Feb 04, 2001 at 12:56:11PM +0100, Javier Fdz-Sanguino Pen~a wrote:
   I have just today commited some changes I made about a week ago
 regarding the Securing-Debian HOWTO (available at
 http://www.debian.org/ddp). I have added some comments regarding information
 more Debian-oriented, and have on my TODO list a lot of stuff to add to this
 document (checklist for securing a Debian system, pointers to other good
 documents, recommendations on how to use several packages)
Heh. Incidentally I updated my own HOWTO yesterday as well. Here are the
changes:
- Added a security update after installation paragraph
- Added a proftpd paragraph
- This time really wrote something about XDM, sorry for last time

You mind to share the stuff on your TODO? Perhaps I could do something as
well. I will have some free time next week.

   I would appreciate any improvements from other people so the
 document does not becomes out-of-date. Many recent threads currently in
 debian-security could make very good sections of this document.
Yep. The cleaning your screen buffer thing should be included for
privacy issues, ie. Perhaps a small paragraph about netfilter/iptables as
well.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO



Re: Encrypted file transfer

2001-01-02 Thread Alexander Reelsen

On Tue, Jan 02, 2001 at 02:57:40PM -0200, Pedro Zorzenon Neto wrote:
 I know how to use gnupg and scp and they would work fine, but the
 other computer does't have them installed. I sent an email to
 root@remote_computer and they answer me that they can't install
 anything for me.
 
 Does anyone know a way to install gnupg, ssh-client or some other
 program in the remote computer as an normal user and encript data to
 send to my home computer If you know more than one way to do this,
 I'd prefer some assimetric encription method (public/private key).
I've got a source of a netcat with crypt capabilities floating around
somewhere. If you want I can mail it to you or so. It's called cryptcat
iirc, perhaps you can find it one the need. However it is quite limited.
(I don't have any URL for it atm)

Another idea would be to use a small perl client/server modell with
Crypt::CBC and IDEA...

You could also wrap your ftpd into SSL or use a httpsd. There are dozens
of possibilites...


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: Encrypted file transfer

2001-01-02 Thread Alexander Reelsen
On Tue, Jan 02, 2001 at 02:57:40PM -0200, Pedro Zorzenon Neto wrote:
 I know how to use gnupg and scp and they would work fine, but the
 other computer does't have them installed. I sent an email to
 [EMAIL PROTECTED] and they answer me that they can't install
 anything for me.
 
 Does anyone know a way to install gnupg, ssh-client or some other
 program in the remote computer as an normal user and encript data to
 send to my home computer If you know more than one way to do this,
 I'd prefer some assimetric encription method (public/private key).
I've got a source of a netcat with crypt capabilities floating around
somewhere. If you want I can mail it to you or so. It's called cryptcat
iirc, perhaps you can find it one the need. However it is quite limited.
(I don't have any URL for it atm)

Another idea would be to use a small perl client/server modell with
Crypt::CBC and IDEA...

You could also wrap your ftpd into SSL or use a httpsd. There are dozens
of possibilites...


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO



Re: sunrpc

2000-12-07 Thread Alexander Reelsen

Hi

On Thu, Dec 07, 2000 at 08:57:38PM +, Kozman Balint wrote:
 Sorry for the stupid question, but what is the funny 'sunrpc - 111' port?
 I scanned my site, and found it open, but I didn't set it up in inetd.conf
 and don't know which daemon listens it.
As 'lsof -i' or 'fuser -n tcp 111' will tell you, it is the portmapper,
which is listening on that port (/sbin/portmap) usually. If you don't use
NFS you can turn it off without problems.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: sunrpc

2000-12-07 Thread Alexander Reelsen
Hi

On Thu, Dec 07, 2000 at 08:57:38PM +, Kozman Balint wrote:
 Sorry for the stupid question, but what is the funny 'sunrpc - 111' port?
 I scanned my site, and found it open, but I didn't set it up in inetd.conf
 and don't know which daemon listens it.
As 'lsof -i' or 'fuser -n tcp 111' will tell you, it is the portmapper,
which is listening on that port (/sbin/portmap) usually. If you don't use
NFS you can turn it off without problems.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO



Securing Debian HOWTO - Now in SGML

2000-12-03 Thread Alexander Reelsen

Hi folks

As I've had sometime during the weekend I rewrote the HOWTO in SGML as
some of you had wished. The URL is (note the slash ;))

http://joker.rhwd.de/doc/Securing-Debian-HOWTO/

Currently there is the text, html and SGML version available. Ought to be
enough for everybody. I cleaned up some paragraphs (I wonder what awful
grammar I'm able to write, so some rhetoric geniuses, please correct my
failures), and added a few things. Not too much has changed.

However it needs some more content, I didn't update for quite a long time.
I will try to do this in the next days.

Oh, and if someone volunteers to write a paragraph about
dpkg-statoverrides, I would not be the only one to be grateful I guess ;)
I don't have a working woody station at the moment so I am not able to
write something about it.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Securing Debian HOWTO - Now in SGML

2000-12-03 Thread Alexander Reelsen
Hi folks

As I've had sometime during the weekend I rewrote the HOWTO in SGML as
some of you had wished. The URL is (note the slash ;))

http://joker.rhwd.de/doc/Securing-Debian-HOWTO/

Currently there is the text, html and SGML version available. Ought to be
enough for everybody. I cleaned up some paragraphs (I wonder what awful
grammar I'm able to write, so some rhetoric geniuses, please correct my
failures), and added a few things. Not too much has changed.

However it needs some more content, I didn't update for quite a long time.
I will try to do this in the next days.

Oh, and if someone volunteers to write a paragraph about
dpkg-statoverrides, I would not be the only one to be grateful I guess ;)
I don't have a working woody station at the moment so I am not able to
write something about it.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO



Re: Debian Security-HOWTO

2000-11-30 Thread Alexander Reelsen

Hi

On Thu, Nov 30, 2000 at 01:55:33PM -0500, Jacob Kuntz wrote:
  I do not know if other developers are aware, but there is
  a nice Security HOWTO available in
  http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by
  Alexander Reelsen (which I am sending this to in case he is
  not on the list). 
 does the docbook source to this exist somewhere? i'd rather read this as
 html.
No. It's plain text only, as I do not have enough free time at the moment
to take a closer look a docbook.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: Debian Security-HOWTO

2000-11-30 Thread Alexander Reelsen
Hi

On Thu, Nov 30, 2000 at 01:55:33PM -0500, Jacob Kuntz wrote:
  I do not know if other developers are aware, but there is
  a nice Security HOWTO available in
  http://joker.rhwd.de/doc/Securing-Debian-HOWTO and made by
  Alexander Reelsen (which I am sending this to in case he is
  not on the list). 
 does the docbook source to this exist somewhere? i'd rather read this as
 html.
No. It's plain text only, as I do not have enough free time at the moment
to take a closer look a docbook.


MfG/Regards, Alexander

-- 
Alexander Reelsen   http://joker.rhwd.de
[EMAIL PROTECTED]   GnuPG: pub 1024D/F0D7313C  sub 2048g/6AA2EDDB
[EMAIL PROTECTED] 7D44 F4E3 1993 FDDF 552E  7C88 EE9C CBD1 F0D7 313C
Securing Debian:http://joker.rhwd.de/doc/Securing-Debian-HOWTO