Re: your mail
On Thu, Mar 16, 2000 at 02:19:53PM -0800, Brian Kimball wrote: > Peter Cordes wrote: > > > This isn't specific to identd, but I'm wondering why you would bother > > filtering the port instead of just not running identd? (I assume you would > > have/do turn off identd in /etc/inetd.conf as well as using doing port > > filtering.) I've never really understood why people filter all kinds of > > ports on their own machine when the ports are closed anyway. > > While inetd + tcp_wrappers is sufficient for something like identd, it > offers no protection for things that aren't launched from inetd -- a > category that the vast majority of debian daemons falls under (apache, > lpd, X, etc). What you're saying is that if you want to serve web pages to some IPs, but not the whole internet, then you have a job for ipchains, which is true. OTOH, my point was that if you're not running httpd (at all), then you don't need packet filtering on port 80. The kernel handles packets to port 80 by replying with "port's closed, have a nice day" (paraphrased :), so you don't need to use ipchains to make it do that. (Unless you really want the packets to be dropped outright with no reply, which is of limited usefulness, AFAIK.) -- #define X(x,y) x##y DUPS Secretary ; http://is2.dal.ca/~dups/ Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: your mail
On Thu, Mar 16, 2000 at 10:07:37PM +, Tim Haynes wrote: > Alternatively, people might filter based on different incoming host, network > or interface[1]; if it's from a site I trust I might allow it for speed and/or > identity "checking" if required; if I'm not sure about them I might let them > through to tcp wrappers so an incoming request sparks a scan/finger straight > back whence it came; otherwise I might just DENY altogether. True. However, IIRC the docs for identd say not to put identd behind tcpd, because if two computers do this, and then one tries to ident the other one, you've got a packet storm brewing. -- #define X(x,y) x##y DUPS Secretary ; http://is2.dal.ca/~dups/ Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
Re: your mail
Peter Cordes wrote: > This isn't specific to identd, but I'm wondering why you would bother > filtering the port instead of just not running identd? (I assume you would > have/do turn off identd in /etc/inetd.conf as well as using doing port > filtering.) I've never really understood why people filter all kinds of > ports on their own machine when the ports are closed anyway. While inetd + tcp_wrappers is sufficient for something like identd, it offers no protection for things that aren't launched from inetd -- a category that the vast majority of debian daemons falls under (apache, lpd, X, etc). -- Brian Kimball
Re: your mail
Yes, the best policy is always to disable anything on your machine that you're not using. Those you _are_ using, you then filter the crap out of. Personally, my workstation-type machines only listen on port 6000 (X), 22 (ssh), and occasionally ftp and tftp if I need them for a specific purpose. For my server-type machines, subtract X, then add what services they are providing, which would then be heavily protected. On Thu, 16 Mar 2000, Peter Cordes wrote: > This isn't specific to identd, but I'm wondering why you would bother > filtering the port instead of just not running identd? (I assume you would > have/do turn off identd in /etc/inetd.conf as well as using doing port > filtering.) I've never really understood why people filter all kinds of > ports on their own machine when the ports are closed anyway. The only > advantage I can see is that if someone hits you with a trojan > something-or-other, the the bad guys won't be able to talk to it if it picks > a blocked port. Is this the reason for doing it, or am I missing something? > > Filtering ports makes sense when you are protecting a bunch of machines, > especially ones which you don't run directly, but for a machine filtering > traffic for only itself, it seems like a waste. > > Thanks,
Re: your mail
On Thu, Mar 16, 2000 at 05:58:00PM -0400, Peter Cordes wrote: > This isn't specific to identd, but I'm wondering why you would bother > filtering the port instead of just not running identd? (I assume you would > have/do turn off identd in /etc/inetd.conf as well as using doing port > filtering.) I've never really understood why people filter all kinds of > ports on their own machine when the ports are closed anyway. The only > advantage I can see is that if someone hits you with a trojan > something-or-other, the the bad guys won't be able to talk to it if it picks > a blocked port. Is this the reason for doing it, or am I missing something? > > Filtering ports makes sense when you are protecting a bunch of machines, > especially ones which you don't run directly, but for a machine filtering > traffic for only itself, it seems like a waste. If the port's closed then admittedly there's not a lot of point, BUT if you have 'DENY' by default then at least you're slowing someone's scanner down quite a bit - you have to consider whether you want an ICMP 'dest unreachable' going back or not, but that's your choice. Alternatively, people might filter based on different incoming host, network or interface[1]; if it's from a site I trust I might allow it for speed and/or identity "checking" if required; if I'm not sure about them I might let them through to tcp wrappers so an incoming request sparks a scan/finger straight back whence it came; otherwise I might just DENY altogether. [1] it gets really exciting when you start doing NAT/tunnelling of some description as e.g. tap0 basically tunnels over ppp0, for example. ~Tim -- | Geek Code: GCS dpu s-:+ a-- C UBLUAVHSC P+++ L++ E--- W+++(--) N++ | w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y- | The sun is melting over the hills, | http://piglet.is.dreaming.org/ | All our roads are waiting / To be revealed | [EMAIL PROTECTED]
Re: your mail
On Thu, Mar 16, 2000 at 04:39:05PM +, Tim Haynes wrote: > For most (home) purposes it's best to make it REJECT instead of DENY, if you > choose to block it, so that e.g. remote FTP sites don't have to wait for a > timeout before letting you in. This isn't specific to identd, but I'm wondering why you would bother filtering the port instead of just not running identd? (I assume you would have/do turn off identd in /etc/inetd.conf as well as using doing port filtering.) I've never really understood why people filter all kinds of ports on their own machine when the ports are closed anyway. The only advantage I can see is that if someone hits you with a trojan something-or-other, the the bad guys won't be able to talk to it if it picks a blocked port. Is this the reason for doing it, or am I missing something? Filtering ports makes sense when you are protecting a bunch of machines, especially ones which you don't run directly, but for a machine filtering traffic for only itself, it seems like a waste. Thanks, -- #define X(x,y) x##y DUPS Secretary ; http://is2.dal.ca/~dups/ Peter Cordes ; e-mail: X([EMAIL PROTECTED] , dal.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BCE
RE: Identification Protocol (was: Re: your mail)
On Thu, 16 Mar 2000, Fredrik Liljegren wrote: > > i'd turn auth off for security reasons if your box has a direct > > connection to internet. > Many people misunderstand the usefulness of identd, and so disable it or > block all off site requests for it. identd is not there to help out remote > sites. There is no way of knowing if the data you get from the remote identd > is correct or not. There is no authentication in identd requests. maybe i am one of these people :) identd takes two parameters, the server and the source port of a tcp connection. it gives back the userid of the user who started it. am i right so far? i think, the userid may be useful for some purposes but in most cases it is not but gives a hacker a little piece of information. but, you're right, it could be worth while tracking down some attack from your own computer. hmm... i will think about it :-) thanks
Re: your mail
On Thu, Mar 16, 2000 at 03:01:40PM +, Mark Brown wrote: > On Thu, Mar 16, 2000 at 03:45:50PM +0100, Ivan Ivanovic wrote: > > > On my Slink placed on Inernet often appears auth port connection attempts > > from various sites... What (common) application needs this port? > > The auth port provides a facility for a remote machine to identify who's > on your end of a TCP connection. Many servers collect and log this > information to help provide an audit trail. Yup. OTOH the relevant RFCs don't stipulate that the data presented has to be *valid* so it's up to "your local admin" to choose between closing it off or blocking it... In any event letting on a valid username for "who owns this socket/connection" increases security risks, albeit not necessarily by much. Things like MTAs (sendmail et al) tend to do an identd check back on you to see who you claim to be when sending mail; similarly the TCP wrappers (tcpd) also do an identd check back if you use a filter with 'user@' in it. For most (home) purposes it's best to make it REJECT instead of DENY, if you choose to block it, so that e.g. remote FTP sites don't have to wait for a timeout before letting you in. ~Tim -- | Geek Code: GCS dpu s-:+ a-- C UBLUAVHSC P+++ L++ E--- W+++(--) N++ | w--- O- M-- V-- PS PGP++ t--- X+(-) b D+ G e++(*) h++(*) r--- y- | The sun is melting over the hills, | http://piglet.is.dreaming.org/ | All our roads are waiting / To be revealed | [EMAIL PROTECTED]
Re: your mail
On Thu, Mar 16, 2000 at 03:45:50PM +0100, Ivan Ivanovic wrote: > On my Slink placed on Inernet often appears auth port connection attempts > from various sites... > What (common) application needs this port? The auth port provides a facility for a remote machine to identify who's on your end of a TCP connection. Many servers collect and log this information to help provide an audit trail. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpDpqxscBOrt.pgp Description: PGP signature
RE: Identification Protocol (was: Re: your mail)
> irc server make ident connections to clients. > squid can use ident for authorization. > sendmail sometimes uses ident. > > maybe you want to read rfc1413. > > i'd turn auth off for security reasons if your box has a direct > connection to internet. Hmm, that's an easy approach, but from Security-HOWTO: Many people misunderstand the usefulness of identd, and so disable it or block all off site requests for it. identd is not there to help out remote sites. There is no way of knowing if the data you get from the remote identd is correct or not. There is no authentication in identd requests. Why would you want to run it then? Because it helps you out, and is another data-point in tracking. - Well, the rest is to read there.. (part 8.4). If you trust this writer, there is no harm in having it going and it could be good.. Mvh EOF
Identification Protocol (was: Re: your mail)
On Thu, 16 Mar 2000, Ivan Ivanovic wrote: > On my Slink placed on Inernet often appears auth port connection attempts > from various sites... > What (common) application needs this port? irc server make ident connections to clients. squid can use ident for authorization. sendmail sometimes uses ident. maybe you want to read rfc1413. i'd turn auth off for security reasons if your box has a direct connection to internet. from rfc1413: An Identification server may reveal information about users, entities, objects or processes which might normally be considered private. An Identification server provides service which is a rough analog of the CallerID services provided by some phone companies and many of the same privacy considerations and arguments that apply to the CallerID service apply to Identification. If you wouldn't run a "finger" server due to privacy considerations you may not want to run this protocol. seb
Re: password length
In message <[EMAIL PROTECTED]>, Alexa nder Hvostov writes: >MD5 as an algorithm supports a theoretically infinitely sized password (or >other string), though of course it becomes less secure as the string's >size increases. That said, I think the maximum password length supported >by glibc (and, thus, PAM) is 128 bytes long. Are the MD5 passwords affected by the max=8 setting in the pam.d/passwd entry, or does it ignore them? -- Ted Cabeen http://www.pobox.com/~secabeen [EMAIL PROTECTED] Check Website or finger for PGP Public Key[EMAIL PROTECTED] "I have taken all knowledge to be my province." -F. Bacon [EMAIL PROTECTED] "Human kind cannot bear very much reality."-T.S.Eliot [EMAIL PROTECTED]
[no subject]
On my Slink placed on Inernet often appears auth port connection attempts from various sites... What (common) application needs this port? P. S. V. P. U. http://www.pobox.sk/
Re: password length
Ethan, MD5 as an algorithm supports a theoretically infinitely sized password (or other string), though of course it becomes less secure as the string's size increases. That said, I think the maximum password length supported by glibc (and, thus, PAM) is 128 bytes long. Indeed, PAM is a potato thing, and as far as I know, everything in /etc/login.defs is rendered obsolete by PAM. Regards, Alex. -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM d- s:+ a--- C UL P L+++ E W++ N o-- K- w O--- M- V- PS+ PE- Y PGP t+ 5 X- R tv+ b DI--- D+ G e-- h++ r--- y --END GEEK CODE BLOCK-- On Wed, 15 Mar 2000, Ethan Benson wrote: > On Wed, Mar 15, 2000 at 07:18:21PM -0600, Kama Lar wrote: > > On Wed, Mar 15, 2000 at 04:18:43PM -0700, Kevin wrote: > > > I find my rather upset that by default slink only allows a password length > > > of 7 characters max. Unfortunately I am not sure how to change it, and > > > > [clipped for sake of brevity] > > > > Enable md5 in /etc/pam/passwd, and in /etc/login.defs > > (actaully its /etc/pam.d/passwd but pam is a potato thing) > > there is also a PASS_MAX_LEN which is set to 8 by default, I presume > this has to be increased, (or is it obsolete with PAM??) what is the > maximum password length that MD5 supports? > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: password length
On Wed, Mar 15, 2000 at 07:18:21PM -0600, Kama Lar wrote: > On Wed, Mar 15, 2000 at 04:18:43PM -0700, Kevin wrote: > > I find my rather upset that by default slink only allows a password length > > of 7 characters max. Unfortunately I am not sure how to change it, and > > [clipped for sake of brevity] > > Enable md5 in /etc/pam/passwd, and in /etc/login.defs (actaully its /etc/pam.d/passwd but pam is a potato thing) there is also a PASS_MAX_LEN which is set to 8 by default, I presume this has to be increased, (or is it obsolete with PAM??) what is the maximum password length that MD5 supports? -- Ethan Benson http://www.alaska.net/~erbenson/
Re: password length
On Wed, Mar 15, 2000 at 04:18:43PM -0700, Kevin wrote: > I find my rather upset that by default slink only allows a password length > of 7 characters max. Unfortunately I am not sure how to change it, and [clipped for sake of brevity] Enable md5 in /etc/pam/passwd, and in /etc/login.defs Curt
