RE: Major TCP Vulnerability
CERT has issued a vulnerability email. They seem to think it's a little more serious 8>< Technical Cyber Security Alert TA04-111A archive Vulnerabilities in TCP Original release date: April 20, 2004 Last revised: -- Source: US-CERT Systems Affected * Systems that rely on persistent TCP connections, for example routers supporting BGP 8>< Your info may run over a IPSEC link but if the border routers of your ISP go down, your still stuffed. regards Thing -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phillip Hofmeister Sent: Wednesday, 21 April 2004 8:42 a.m. To: debian-security@lists.debian.org Subject: Re: Major TCP Vulnerability On Tue, 20 Apr 2004 at 02:49:48PM -0400, Thomas Sj?gren wrote: > Since the article is for subscribers only, this is a "wild" guess: > http://www.uniras.gov.uk/vuls/2004/236929/index.htm This article isn't anything I am going to loose sleep over. Any mission critical long term TCP connections over an untrusted network (The Internet) should already be using IPSec. As for non-mission critical connections, the two parties will just reconnect at a later time. Also, unless the attackers know the source port of the client side of the TCP connection, this attack is useless. The only way for them to get the client/source port would be to: A) Have access to the datastream (if this is the case, you have more to worry about than them resetting your connection). B) Have login access to either machine and then run netstat (or a similar) utility which will tell them the information. -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import - End forwarded message - -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Major TCP Vulnerability
CERT has issued a vulnerability email. They seem to think it's a little more serious 8>< Technical Cyber Security Alert TA04-111A archive Vulnerabilities in TCP Original release date: April 20, 2004 Last revised: -- Source: US-CERT Systems Affected * Systems that rely on persistent TCP connections, for example routers supporting BGP 8>< Your info may run over a IPSEC link but if the border routers of your ISP go down, your still stuffed. regards Thing -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phillip Hofmeister Sent: Wednesday, 21 April 2004 8:42 a.m. To: [EMAIL PROTECTED] Subject: Re: Major TCP Vulnerability On Tue, 20 Apr 2004 at 02:49:48PM -0400, Thomas Sj?gren wrote: > Since the article is for subscribers only, this is a "wild" guess: > http://www.uniras.gov.uk/vuls/2004/236929/index.htm This article isn't anything I am going to loose sleep over. Any mission critical long term TCP connections over an untrusted network (The Internet) should already be using IPSec. As for non-mission critical connections, the two parties will just reconnect at a later time. Also, unless the attackers know the source port of the client side of the TCP connection, this attack is useless. The only way for them to get the client/source port would be to: A) Have access to the datastream (if this is the case, you have more to worry about than them resetting your connection). B) Have login access to either machine and then run netstat (or a similar) utility which will tell them the information. -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import - End forwarded message - -- Phillip Hofmeister PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Positive press for Debian's security team
so MS wins Though it looks like the measurement is public disclosure? to fix time, not the best metric possiblyso security experts might contact MS weeks when they find the problem before they publicly comment While it looks like Linux is its own worst enemy as "we" disclose the problem more quickly I suspect via bugtraking how dows it go? lies, damn lies, and statistics regards Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Stone Sent: Wednesday, 31 March 2004 11:10 a.m. To: debian-security@lists.debian.org Subject: Re: Positive press for Debian's security team On Tue, Mar 30, 2004 at 04:59:36PM -0600, Jones wrote: >Positive press for Debian's security team. > >Using numbers from a pair of metrics, Forrester Research's >recommendation was "businesses that value quick patches look to >Microsoft and Debian". That's positive? They put us in the same category as Microsoft! This will lose us some serious street cred. :) Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Positive press for Debian's security team
so MS wins Though it looks like the measurement is public disclosure? to fix time, not the best metric possiblyso security experts might contact MS weeks when they find the problem before they publicly comment While it looks like Linux is its own worst enemy as "we" disclose the problem more quickly I suspect via bugtraking how dows it go? lies, damn lies, and statistics regards Steven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Stone Sent: Wednesday, 31 March 2004 11:10 a.m. To: [EMAIL PROTECTED] Subject: Re: Positive press for Debian's security team On Tue, Mar 30, 2004 at 04:59:36PM -0600, Jones wrote: >Positive press for Debian's security team. > >Using numbers from a pair of metrics, Forrester Research's >recommendation was "businesses that value quick patches look to >Microsoft and Debian". That's positive? They put us in the same category as Microsoft! This will lose us some serious street cred. :) Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: How efficient is mounting /usr ro?
yes, a tape system is partly a security measure, logs are stored offline (and hopefully offsite) as are data. UPS and ECC are uptime features not security IMHO. Is /usr ro, useful? for a web server or firewall that rarely changes its OS files and is at more of a risk then yes it probably is worth the effort, otherwise probably not. My reasoning is security enhancements are often incremental and that small hurdle may just be enough to defeat a script kiddie or an automated worm. regards Steven -Original Message- From: Russell Coker [mailto:[EMAIL PROTECTED] Sent: Friday, 17 October 2003 4:14 PM To: Bernd Eckenfels; debian-security@lists.debian.org Subject: Re: How efficient is mounting /usr ro? On Fri, 17 Oct 2003 07:08, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > A read-only /usr is not a security measure. > > Depends on your definition og it-security. It reduces downtime, prevents > some admin and software failures and therefore is a security measure. So is a tape backup a security measure? What about a UPS? Is ECC memory a security measure? I guess it's a security measure to buy rack mount servers from companies such as Dell rather than assembling your own white-box machines then. :-# Security is about protection from unauthorised access and keeping the system running in the face of attack. A read-only /usr does not help this in the regular case as anyone who has permissions to modify files under /usr also has permissions to remount it read-write. Any measure you take to prevent remounting /usr will probably also prevent file writes as well, so having it mounted read-only gains little. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: How efficient is mounting /usr ro?
yes, a tape system is partly a security measure, logs are stored offline (and hopefully offsite) as are data. UPS and ECC are uptime features not security IMHO. Is /usr ro, useful? for a web server or firewall that rarely changes its OS files and is at more of a risk then yes it probably is worth the effort, otherwise probably not. My reasoning is security enhancements are often incremental and that small hurdle may just be enough to defeat a script kiddie or an automated worm. regards Steven -Original Message- From: Russell Coker [mailto:[EMAIL PROTECTED] Sent: Friday, 17 October 2003 4:14 PM To: Bernd Eckenfels; [EMAIL PROTECTED] Subject: Re: How efficient is mounting /usr ro? On Fri, 17 Oct 2003 07:08, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > A read-only /usr is not a security measure. > > Depends on your definition og it-security. It reduces downtime, prevents > some admin and software failures and therefore is a security measure. So is a tape backup a security measure? What about a UPS? Is ECC memory a security measure? I guess it's a security measure to buy rack mount servers from companies such as Dell rather than assembling your own white-box machines then. :-# Security is about protection from unauthorised access and keeping the system running in the face of attack. A read-only /usr does not help this in the regular case as anyone who has permissions to modify files under /usr also has permissions to remount it read-write. Any measure you take to prevent remounting /usr will probably also prevent file writes as well, so having it mounted read-only gains little. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: services installed and running "out of the box"
There is a debian security manual I believe. I agree with you, leaving services running by default in this day and age is really a no no. regards Steven -Original Message- From: Adam Lydick [mailto:[EMAIL PROTECTED] Sent: Wednesday, 24 September 2003 11:42 PM To: debian-security@lists.debian.org Subject: services installed and running "out of the box" Is there any effort to reduce the number of services running on a default debian install? For example: a typical workstation user doesn't really need to have inetd enabled, nor portmap (unless they are running fam or nfs -- which isn't enabled by default) Is this something that needs to be taken up with individual package maintainers? Or is there a single point of contact that helps choose which packages are present in the base install? Is this already documented somewhere that I should have already read? :) If so, isn't it better to have to RTFM to turn something on as you need it, rather then to need to remember to turn something off that you aren't using? Thanks, Adam Lydick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: services installed and running "out of the box"
There is a debian security manual I believe. I agree with you, leaving services running by default in this day and age is really a no no. regards Steven -Original Message- From: Adam Lydick [mailto:[EMAIL PROTECTED] Sent: Wednesday, 24 September 2003 11:42 PM To: [EMAIL PROTECTED] Subject: services installed and running "out of the box" Is there any effort to reduce the number of services running on a default debian install? For example: a typical workstation user doesn't really need to have inetd enabled, nor portmap (unless they are running fam or nfs -- which isn't enabled by default) Is this something that needs to be taken up with individual package maintainers? Or is there a single point of contact that helps choose which packages are present in the base install? Is this already documented somewhere that I should have already read? :) If so, isn't it better to have to RTFM to turn something on as you need it, rather then to need to remember to turn something off that you aren't using? Thanks, Adam Lydick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: is iptables enough?
I run 2 cronjobs to apt update each machine every night and email me the updates, if I'm happy I login and do the upgrade. For protecting a single machine I have difficulty justifying a seperate firewall machine, I cannot see it achieving much unless the port forwarded ports are proxied, ie no direct connection from outside to the server is allowed. If its protecting multiple machines in a DMZ then yes it has value, however I run iptables on each machine in the DMZ as well such that another machine in the DMZ cannot get to another. I agree with the idea of having more than 1 firewall, using a different firewall system giving defence in depth. Even an ACL on a CISCO router before the firewall is a start. There have been cases of firewall 1 having security holes and being directly connected to the net, yet convincing others to allow me to put a linux box running simple iptables in front has fallen on deaf ears. I suppose it depends on how paranoid you wish to be, or if you prefer "once stung twice shy". If you have not been stung then there are other distractions taking your attention. regards Steven -Original Message- From: Stefan Neufeind [mailto:[EMAIL PROTECTED] Sent: Thursday, 20 March 2003 10:22 To: Ian Garrison Cc: debian-security@lists.debian.org Subject: Re: is iptables enough? What I find astonishing: Let's say you are running a webserver, maybe mailserver and a DNS on a server. What rules do you want to apply to the packets etc.? I would suggest to keep the open ports restricted, check for all current updates regularly (subscribe to several mailinglists etc.) and I guess that would be far enough. What other things does a firewall have to offer? It's good if you want to protect e.g. a network but for a single server I doubt it's that interesting or useful. What do others think? On 19 Mar 2003 at 16:07, Ian Garrison wrote: >Imo iptables is a reasonably good stateful firewall and is fine in >most > cases. However, a very wise person once said that the ideal setup is > to layer more than one implementation of packet filter and firewall > between the wild and a host/network you wish to protect. Ideally > implementations on diverse platforms. > >One example for consideration is a cisco packet filter (acls) that >may > allowed fragmented packets to traverse its filters, but once passed on > to an iptables ruleset might get discarded because iptables was > written seperately from cisco's implementation and happens to catch > this case and a few other cases that were missed. Make your network > an onion if you can engineer a method to easily manage your rules. > >That said, I use only iptables to filter my home network and either >it > is doing a great job or nobody is interested in attacking my host > (likely both). For me, it does the job as nothing is revenue > generating for myself or others -- its important, but not critical. > If I had a client that wanted to sell stuff on the web and handling > ccard ordering of a product, as well as all their corporate email, > then I would be more thoughtful of additional measures to protect the > network. In my work environment every so often developers or others > turn off our iptables rulesets without telling us, as it is easy (one > little command). In such cases the cisco packet filter will offer > some protection and disabling such filters is more work than our > developers care to struggle against. > >Iptables/ipf and any other stateful firewall that attempts to be a > modern contender in the firewalling ring is likely 'good enough'. My > point is that while I like iptables, it and every other filter out > there will fall subject to some method of circumvention/exploitation > at some point, and that how much effort you put into hardening your > network is up to you. Your question almost seems to be "is iptables > developed enough to compete with commercial solutions", to which I > would say "yes, if the person deploying the rules is experienced > enough to write a solid set of rules". If I was you, I would be > satisfied with iptables and the hardware you have selected -- but I am > not you, and this decision is not mine to make. No matter where you > set the bar there will still be more secure solutions. "secure > enough" is all a state of paranoia and budget. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: is iptables enough?
I run 2 cronjobs to apt update each machine every night and email me the updates, if I'm happy I login and do the upgrade. For protecting a single machine I have difficulty justifying a seperate firewall machine, I cannot see it achieving much unless the port forwarded ports are proxied, ie no direct connection from outside to the server is allowed. If its protecting multiple machines in a DMZ then yes it has value, however I run iptables on each machine in the DMZ as well such that another machine in the DMZ cannot get to another. I agree with the idea of having more than 1 firewall, using a different firewall system giving defence in depth. Even an ACL on a CISCO router before the firewall is a start. There have been cases of firewall 1 having security holes and being directly connected to the net, yet convincing others to allow me to put a linux box running simple iptables in front has fallen on deaf ears. I suppose it depends on how paranoid you wish to be, or if you prefer "once stung twice shy". If you have not been stung then there are other distractions taking your attention. regards Steven -Original Message- From: Stefan Neufeind [mailto:[EMAIL PROTECTED] Sent: Thursday, 20 March 2003 10:22 To: Ian Garrison Cc: [EMAIL PROTECTED] Subject: Re: is iptables enough? What I find astonishing: Let's say you are running a webserver, maybe mailserver and a DNS on a server. What rules do you want to apply to the packets etc.? I would suggest to keep the open ports restricted, check for all current updates regularly (subscribe to several mailinglists etc.) and I guess that would be far enough. What other things does a firewall have to offer? It's good if you want to protect e.g. a network but for a single server I doubt it's that interesting or useful. What do others think? On 19 Mar 2003 at 16:07, Ian Garrison wrote: >Imo iptables is a reasonably good stateful firewall and is fine in >most > cases. However, a very wise person once said that the ideal setup is > to layer more than one implementation of packet filter and firewall > between the wild and a host/network you wish to protect. Ideally > implementations on diverse platforms. > >One example for consideration is a cisco packet filter (acls) that >may > allowed fragmented packets to traverse its filters, but once passed on > to an iptables ruleset might get discarded because iptables was > written seperately from cisco's implementation and happens to catch > this case and a few other cases that were missed. Make your network > an onion if you can engineer a method to easily manage your rules. > >That said, I use only iptables to filter my home network and either >it > is doing a great job or nobody is interested in attacking my host > (likely both). For me, it does the job as nothing is revenue > generating for myself or others -- its important, but not critical. > If I had a client that wanted to sell stuff on the web and handling > ccard ordering of a product, as well as all their corporate email, > then I would be more thoughtful of additional measures to protect the > network. In my work environment every so often developers or others > turn off our iptables rulesets without telling us, as it is easy (one > little command). In such cases the cisco packet filter will offer > some protection and disabling such filters is more work than our > developers care to struggle against. > >Iptables/ipf and any other stateful firewall that attempts to be a > modern contender in the firewalling ring is likely 'good enough'. My > point is that while I like iptables, it and every other filter out > there will fall subject to some method of circumvention/exploitation > at some point, and that how much effort you put into hardening your > network is up to you. Your question almost seems to be "is iptables > developed enough to compete with commercial solutions", to which I > would say "yes, if the person deploying the rules is experienced > enough to write a solid set of rules". If I was you, I would be > satisfied with iptables and the hardware you have selected -- but I am > not you, and this decision is not mine to make. No matter where you > set the bar there will still be more secure solutions. "secure > enough" is all a state of paranoia and budget. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Is it so easy to break into an NIS?
yes NIS+ is a bit better, but basically its in-adequate security wise. It should not be considered for a new system/network IMHO. regards Steven -Original Message- From: Haim Ashkenazi [mailto:[EMAIL PROTECTED] Sent: Wednesday, 19 March 2003 12:30 To: Debian Security Subject: OT: Is it so easy to break into an NIS? Hi A friend just asked me this question and I got curious. say I'm equipped with a linux laptop and some knowledge, I can walk into a company that uses NIS, find out the settings (NISDOMAIN, free ip address, etc...) and join their domain. now I can login as root on my computer, su to any user and see/change/delete his files. is it that easy? of-course, administrators should protect their mounts with netgroups permissions, and users should protect their important files with encryption, but how many of these you see? any ideas? suggestions? Bye -- Haim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Is it so easy to break into an NIS?
yes NIS+ is a bit better, but basically its in-adequate security wise. It should not be considered for a new system/network IMHO. regards Steven -Original Message- From: Haim Ashkenazi [mailto:[EMAIL PROTECTED] Sent: Wednesday, 19 March 2003 12:30 To: Debian Security Subject: OT: Is it so easy to break into an NIS? Hi A friend just asked me this question and I got curious. say I'm equipped with a linux laptop and some knowledge, I can walk into a company that uses NIS, find out the settings (NISDOMAIN, free ip address, etc...) and join their domain. now I can login as root on my computer, su to any user and see/change/delete his files. is it that easy? of-course, administrators should protect their mounts with netgroups permissions, and users should protect their important files with encryption, but how many of these you see? any ideas? suggestions? Bye -- Haim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [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
I currently spend a lot of time hardening boxes, is this discussion based on the released doc I can get off the debian web site? or a new draft? Steven -Original Message- From: Peter Cordes [mailto:[EMAIL PROTECTED] Sent: Friday, 14 March 2003 7:41 To: debian-security@lists.debian.org Subject: Re: Review: sect. 4.16.2 of the Securing Debian manual On Thu, Mar 13, 2003 at 10:22:19PM +1100, Frederic Schutz wrote: > Does it answer your questions or did I miss a real loophole in the > strategy that I described ? If an attacker gets root and loads a kernel module, that module could restore the immutable capability. You'd have to disable loadable modules for that to be bulletproof. (unless the commonly used rootkits already do this, it would slow down an attacker and cause them to make more noise.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.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 BC -- 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
I currently spend a lot of time hardening boxes, is this discussion based on the released doc I can get off the debian web site? or a new draft? Steven -Original Message- From: Peter Cordes [mailto:[EMAIL PROTECTED] Sent: Friday, 14 March 2003 7:41 To: [EMAIL PROTECTED] Subject: Re: Review: sect. 4.16.2 of the Securing Debian manual On Thu, Mar 13, 2003 at 10:22:19PM +1100, Frederic Schutz wrote: > Does it answer your questions or did I miss a real loophole in the > strategy that I described ? If an attacker gets root and loads a kernel module, that module could restore the immutable capability. You'd have to disable loadable modules for that to be bulletproof. (unless the commonly used rootkits already do this, it would slow down an attacker and cause them to make more noise.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.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 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Peace is not off topic
have to agree This is not the palce for such discussions Thing Since when did a bunch of Debian/Linux developers, maintainers, users become Politicians? I must have missed that transitional period. If I wanted to here this crap, I'd start watching the news!
RE: iptables and apt-get
IPTABLES FRAGMENTS:#"#iptables -A INPUT -i $outer_nic -f -j DROP iptables -P INPUT DROPecho "INPUT rules now in place" #output tables are default#echo "output rules now in place"#limit logging levels to save clutter and /var from being swampediptables -A FORWARD -m limit -j LOGecho "log limiting in place" #specific defence rules eg DoS attacks#syn-flood protectioniptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT#furtive port scanneriptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit \--limit 1/s -j ACCEPT#ping of deathiptables -A FORWARD -p icmp --icmp-type echo-request -m limit \--limit 1/s -j ACCEPTecho "DoS defences setup" exit regards Thing-Original Message-From: Ian Goodall [mailto:[EMAIL PROTECTED]Sent: Tuesday, 11 March 2003 2:21 To: Jones, Steven; debian-security@lists.debian.orgSubject: Re: iptables and apt-get Here is my rule set: #default input policy/sbin/iptables -P INPUT DROP#allow www/https(ssl)/sbin/iptables -A INPUT -s 0/0 -d 172.16.5.92 -p tcp --dport https -j ACCEPT#allow ssh/sbin/iptables -A INPUT -s 0/0 -d 172.16.5.92 -p tcp --dport ssh -j ACCEPT#allow smtp/sbin/iptables -A INPUT -s 0/0 -d 172.16.5.92 -p tcp --dport smtp -j ACCEPT #create a new rule for drop # log#/sbin/iptables -N drop-and-log-it#log it#/sbin/iptables -A drop-and-log-it -j LOG --log-level info --log-prefix 'DROPIT'#drop it#/sbin/iptables -A drop-and-log-it -j DROP #now call the rule to drop and log /sbin/iptables -A INPUT -j drop-and-log-it --- Thanks ijg0 - Original Message - From: Jones, Steven To: 'Ian Goodall' ; debian-security@lists.debian.org Sent: Tuesday, March 11, 2003 1:11 AM Subject: RE: iptables and apt-get shouldnt do unless you changed the output rules? please provide your ruleset Thing -Original Message-From: Ian Goodall [mailto:[EMAIL PROTECTED]Sent: Tuesday, 11 March 2003 2:06 To: debian-security@lists.debian.orgSubject: iptables and apt-get Hi Guys, I am setting up iptables on my debain woody box. I have decided to close everyting and then open up just ssh and ssl. This obviously prevents my apt-get update from working. What ports do I need to open for this to work. If it helps I am going through a proxy to get to the internet. Thanks ijg0
RE: iptables and apt-get
shouldnt do unless you changed the output rules? please provide your ruleset Thing -Original Message-From: Ian Goodall [mailto:[EMAIL PROTECTED]Sent: Tuesday, 11 March 2003 2:06 To: debian-security@lists.debian.orgSubject: iptables and apt-get Hi Guys, I am setting up iptables on my debain woody box. I have decided to close everyting and then open up just ssh and ssl. This obviously prevents my apt-get update from working. What ports do I need to open for this to work. If it helps I am going through a proxy to get to the internet. Thanks ijg0
RE: Peace is not off topic
have to agree This is not the palce for such discussions Thing Since when did a bunch of Debian/Linux developers, maintainers, users become Politicians? I must have missed that transitional period. If I wanted to here this crap, I'd start watching the news! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: iptables and apt-get
IPTABLES FRAGMENTS:#"#iptables -A INPUT -i $outer_nic -f -j DROP iptables -P INPUT DROPecho "INPUT rules now in place" #output tables are default#echo "output rules now in place"#limit logging levels to save clutter and /var from being swampediptables -A FORWARD -m limit -j LOGecho "log limiting in place" #specific defence rules eg DoS attacks#syn-flood protectioniptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT#furtive port scanneriptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit \--limit 1/s -j ACCEPT#ping of deathiptables -A FORWARD -p icmp --icmp-type echo-request -m limit \--limit 1/s -j ACCEPTecho "DoS defences setup" exit regards Thing-Original Message-From: Ian Goodall [mailto:[EMAIL PROTECTED]Sent: Tuesday, 11 March 2003 2:21 To: Jones, Steven; [EMAIL PROTECTED]Subject: Re: iptables and apt-get Here is my rule set: #default input policy/sbin/iptables -P INPUT DROP#allow www/https(ssl)/sbin/iptables -A INPUT -s 0/0 -d 172.16.5.92 -p tcp --dport https -j ACCEPT#allow ssh/sbin/iptables -A INPUT -s 0/0 -d 172.16.5.92 -p tcp --dport ssh -j ACCEPT#allow smtp/sbin/iptables -A INPUT -s 0/0 -d 172.16.5.92 -p tcp --dport smtp -j ACCEPT #create a new rule for drop # log#/sbin/iptables -N drop-and-log-it#log it#/sbin/iptables -A drop-and-log-it -j LOG --log-level info --log-prefix 'DROPIT'#drop it#/sbin/iptables -A drop-and-log-it -j DROP #now call the rule to drop and log /sbin/iptables -A INPUT -j drop-and-log-it --- Thanks ijg0 - Original Message - From: Jones, Steven To: 'Ian Goodall' ; [EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 1:11 AM Subject: RE: iptables and apt-get shouldnt do unless you changed the output rules? please provide your ruleset Thing -Original Message-From: Ian Goodall [mailto:[EMAIL PROTECTED]Sent: Tuesday, 11 March 2003 2:06 To: [EMAIL PROTECTED]Subject: iptables and apt-get Hi Guys, I am setting up iptables on my debain woody box. I have decided to close everyting and then open up just ssh and ssl. This obviously prevents my apt-get update from working. What ports do I need to open for this to work. If it helps I am going through a proxy to get to the internet. Thanks ijg0
RE: iptables and apt-get
shouldnt do unless you changed the output rules? please provide your ruleset Thing -Original Message-From: Ian Goodall [mailto:[EMAIL PROTECTED]Sent: Tuesday, 11 March 2003 2:06 To: [EMAIL PROTECTED]Subject: iptables and apt-get Hi Guys, I am setting up iptables on my debain woody box. I have decided to close everyting and then open up just ssh and ssl. This obviously prevents my apt-get update from working. What ports do I need to open for this to work. If it helps I am going through a proxy to get to the internet. Thanks ijg0
RE: Sendmail vulnerability : is Debian falling behind?
Debian co-ordinates between quite a few hardware types, that takes time. If at the end of the day you believe Mandrake is better go install Mandrake. Before you do take a look at how many bugs/patches Mandrake has announced v Debian over say the last year. I wouldnt be surprised if 1) Debian is on average quicker, 2) the packaging system and pre-work the developers do means some of these bugs are already ironed out so are never exploitable, so Debian never needs to release an advisory. regards Thing -Original Message- From: Bernard Lheureux [mailto:[EMAIL PROTECTED] Sent: Tuesday, 4 March 2003 12:35 To: debian-security@lists.debian.org Cc: Jeremy T. Bouse Subject: Re: Sendmail vulnerability : is Debian falling behind? On Monday 03 March 2003 23:06, Jeremy T. Bouse wrote: > > In case noone noticed, news of a Sendmail vulnerability appeared > > on Slashdot. The really interesting piece of the story for me was the > > portion of the blurb with said "...RedHat and OpenBSD have already issued > > patches.links to an update from SuSE, too". Mandrake released patched versions for all of their versions a few hours ago too... -- (?- Bernard Lheureux Gestionnaire des MailingLists ML, TechML, LinuxML //\ http://www.bbsoft4.org/Mailinglists.htm ** MailTo:[EMAIL PROTECTED] v_/_ http://www.bbsoft4.org/ << * >> http://www.portalinux.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Sendmail vulnerability : is Debian falling behind?
Debian co-ordinates between quite a few hardware types, that takes time. If at the end of the day you believe Mandrake is better go install Mandrake. Before you do take a look at how many bugs/patches Mandrake has announced v Debian over say the last year. I wouldnt be surprised if 1) Debian is on average quicker, 2) the packaging system and pre-work the developers do means some of these bugs are already ironed out so are never exploitable, so Debian never needs to release an advisory. regards Thing -Original Message- From: Bernard Lheureux [mailto:[EMAIL PROTECTED] Sent: Tuesday, 4 March 2003 12:35 To: [EMAIL PROTECTED] Cc: Jeremy T. Bouse Subject: Re: Sendmail vulnerability : is Debian falling behind? On Monday 03 March 2003 23:06, Jeremy T. Bouse wrote: > > In case noone noticed, news of a Sendmail vulnerability appeared > > on Slashdot. The really interesting piece of the story for me was the > > portion of the blurb with said "...RedHat and OpenBSD have already issued > > patches.links to an update from SuSE, too". Mandrake released patched versions for all of their versions a few hours ago too... -- (?- Bernard Lheureux Gestionnaire des MailingLists ML, TechML, LinuxML //\ http://www.bbsoft4.org/Mailinglists.htm ** MailTo:[EMAIL PROTECTED] v_/_ http://www.bbsoft4.org/ << * >> http://www.portalinux.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail ( fwd)
Debian systems tend to use Exim by default? my installs certainly do. Mind you I remove it and install Sendmail usually as its our "standard". So Im a we bit concerned. No updates from security.debian as of 2:00AM NZT. Im not blaming Debian ppl here of being slow or anything, they do a fine job of issuing patches, just that I run a cron job every day at 2am and it emails me and i take a peak at 7am NZT, there was nothing. regards Steven -Original Message- From: Ramon Kagan [mailto:[EMAIL PROTECTED] Sent: Tuesday, 4 March 2003 10:21 To: debian-security@lists.debian.org Subject: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail (fwd) HI, I don't see Debian listed in the notification list at the bottom of the CERT Advisory. Is there any estimate on the release of patched sendmail packages? Ramon Kagan York University, Computing and Network Services Unix Team - Intermediate System Administrator (416)736-2100 #20263 [EMAIL PROTECTED] - I have not failed. I have just found 10,000 ways that don't work. - Thomas Edison - -- Forwarded message -- Date: Mon, 3 Mar 2003 13:06:09 -0500 From: CERT Advisory To: cert-advisory@cert.org Subject: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail -BEGIN PGP SIGNED MESSAGE- CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail Original release date: March 3, 2003 Last revised: -- Source: CERT/CC A complete revision history can be found at the end of this file. Systems Affected * Sendmail Pro (all versions) * Sendmail Switch 2.1 prior to 2.1.5 * Sendmail Switch 2.2 prior to 2.2.5 * Sendmail Switch 3.0 prior to 3.0.3 * Sendmail for NT 2.X prior to 2.6.2 * Sendmail for NT 3.0 prior to 3.0.3 * Systems running open-source sendmail versions prior to 8.12.8, including UNIX and Linux systems Overview There is a vulnerability in sendmail that may allow remote attackers to gain the privileges of the sendmail daemon, typically root. I. Description Researchers at Internet Security Systems (ISS) have discovered a remotely exploitable vulnerability in sendmail. This vulnerability could allow an intruder to gain control of a vulnerable sendmail server. Most organizations have a variety of mail transfer agents (MTAs) at various locations within their network, with at least one exposed to the Internet. Since sendmail is the most popular MTA, most medium-sized to large organizations are likely to have at least one vulnerable sendmail server. In addition, many UNIX and Linux workstations provide a sendmail implementation that is enabled and running by default. Thisvulnerabilityismessage-orientedasopposedto connection-oriented. That means that the vulnerability is triggered by the contents of a specially-crafted email message rather than by lower-level network traffic. This is important because an MTA that does not contain the vulnerability will pass the malicious message along to other MTAs that may be protected at the network level. In other words, vulnerable sendmail servers on the interior of a network are still at risk, even if the site's border MTA uses software other than sendmail. Also, messages capable of exploiting this vulnerability may pass undetected through many common packet filters or firewalls. Sendmail has indicated to the CERT/CC that this vulnerability has been successfully exploited in a laboratory environment. We do not believe that this exploit is available to the public. However, this vulnerability is likely to draw significant attention from the intruder community, so the probability of a public exploit is high. A successful attack against an unpatched sendmail system will not leave any messages in the system log. However, on a patched system, an attempt to exploit this vulnerability will leave the following log message: Dropped invalid comments from header address Although this does not represent conclusive evidence of an attack, it may be useful as an indicator. A patched sendmail server will drop invalid headers, thus preventing downstream servers from receiving them. The CERT/CC is tracking this issue as VU#398025. This reference number corresponds to CVE candidate CAN-2002-1337. For more information, please see http://www.sendmail.org http://www.sendmail.org/8.12.8.html http://www.sendmail.com/security/ http://www.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21950 http://www.kb.cert.org/vuls/id/398025 II. Impact Successful exploitation of this vulnerability may allow an attacker to gain the privileges of the sendmail daemon, typically root.
RE: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail (fwd)
Debian systems tend to use Exim by default? my installs certainly do. Mind you I remove it and install Sendmail usually as its our "standard". So Im a we bit concerned. No updates from security.debian as of 2:00AM NZT. Im not blaming Debian ppl here of being slow or anything, they do a fine job of issuing patches, just that I run a cron job every day at 2am and it emails me and i take a peak at 7am NZT, there was nothing. regards Steven -Original Message- From: Ramon Kagan [mailto:[EMAIL PROTECTED] Sent: Tuesday, 4 March 2003 10:21 To: [EMAIL PROTECTED] Subject: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail (fwd) HI, I don't see Debian listed in the notification list at the bottom of the CERT Advisory. Is there any estimate on the release of patched sendmail packages? Ramon Kagan York University, Computing and Network Services Unix Team - Intermediate System Administrator (416)736-2100 #20263 [EMAIL PROTECTED] - I have not failed. I have just found 10,000 ways that don't work. - Thomas Edison - -- Forwarded message -- Date: Mon, 3 Mar 2003 13:06:09 -0500 From: CERT Advisory <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail -BEGIN PGP SIGNED MESSAGE- CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail Original release date: March 3, 2003 Last revised: -- Source: CERT/CC A complete revision history can be found at the end of this file. Systems Affected * Sendmail Pro (all versions) * Sendmail Switch 2.1 prior to 2.1.5 * Sendmail Switch 2.2 prior to 2.2.5 * Sendmail Switch 3.0 prior to 3.0.3 * Sendmail for NT 2.X prior to 2.6.2 * Sendmail for NT 3.0 prior to 3.0.3 * Systems running open-source sendmail versions prior to 8.12.8, including UNIX and Linux systems Overview There is a vulnerability in sendmail that may allow remote attackers to gain the privileges of the sendmail daemon, typically root. I. Description Researchers at Internet Security Systems (ISS) have discovered a remotely exploitable vulnerability in sendmail. This vulnerability could allow an intruder to gain control of a vulnerable sendmail server. Most organizations have a variety of mail transfer agents (MTAs) at various locations within their network, with at least one exposed to the Internet. Since sendmail is the most popular MTA, most medium-sized to large organizations are likely to have at least one vulnerable sendmail server. In addition, many UNIX and Linux workstations provide a sendmail implementation that is enabled and running by default. Thisvulnerabilityismessage-orientedasopposedto connection-oriented. That means that the vulnerability is triggered by the contents of a specially-crafted email message rather than by lower-level network traffic. This is important because an MTA that does not contain the vulnerability will pass the malicious message along to other MTAs that may be protected at the network level. In other words, vulnerable sendmail servers on the interior of a network are still at risk, even if the site's border MTA uses software other than sendmail. Also, messages capable of exploiting this vulnerability may pass undetected through many common packet filters or firewalls. Sendmail has indicated to the CERT/CC that this vulnerability has been successfully exploited in a laboratory environment. We do not believe that this exploit is available to the public. However, this vulnerability is likely to draw significant attention from the intruder community, so the probability of a public exploit is high. A successful attack against an unpatched sendmail system will not leave any messages in the system log. However, on a patched system, an attempt to exploit this vulnerability will leave the following log message: Dropped invalid comments from header address Although this does not represent conclusive evidence of an attack, it may be useful as an indicator. A patched sendmail server will drop invalid headers, thus preventing downstream servers from receiving them. The CERT/CC is tracking this issue as VU#398025. This reference number corresponds to CVE candidate CAN-2002-1337. For more information, please see http://www.sendmail.org http://www.sendmail.org/8.12.8.html http://www.sendmail.com/security/ http://www.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21950 http://www.kb.cert.org/vuls/id/398025 II. Impact Successful exploitation of this vulnerability may allow an attacker to gain the privileges of the sendmail daemon, typically root.
RE: VPN performance with tunnelv
I find with freeswan the cpu hit is very high, on a ppro 200 with 64 meg of ram a load factor of 1.7 I get around 1.2~1.2~1.5 meg a second across a LAN. thing -Original Message- From: Dale Amon [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 February 2003 11:41 To: debian-security Subject: Re: VPN performance with tunnelv On Mon, Feb 24, 2003 at 06:39:08PM +0100, Ivo Marino wrote: > I'm actually considering to switch the VPN from tunnelv to freeswan if > this could increase the network performance. > > Any suggestions or pointers for this kind of problem? All I can say is, I'm running a 486 firewall machine with freeswan and other security features and it has no problems at all (unless you want to do a sid dselect upgrade, which takes HOURS) -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: VPN performance with tunnelv
I find with freeswan the cpu hit is very high, on a ppro 200 with 64 meg of ram a load factor of 1.7 I get around 1.2~1.2~1.5 meg a second across a LAN. thing -Original Message- From: Dale Amon [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 February 2003 11:41 To: debian-security Subject: Re: VPN performance with tunnelv On Mon, Feb 24, 2003 at 06:39:08PM +0100, Ivo Marino wrote: > I'm actually considering to switch the VPN from tunnelv to freeswan if > this could increase the network performance. > > Any suggestions or pointers for this kind of problem? All I can say is, I'm running a 486 firewall machine with freeswan and other security features and it has no problems at all (unless you want to do a sid dselect upgrade, which takes HOURS) -- -- IN MY NAME:Dale Amon, CEO/MD No Mushroom clouds over Islandone Society London and New York. www.islandone.org -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Spammers using a non-existant address as return-path
ive had a few cases of this myself, an irrate admin somewhere else whining its my fault ad i have , yet the relay test via telent shows all OK. I wonder if they firge known addresses on purpsoe to seed discontent. I dont want to teach you to suck eggs, but I would suggest this test is run as an independant way to verify your safe. I always run it after a sendmail change, as i pay for volume personally and at 2 gig + a day a spam hit would do to me would break me finiancially. I have found Debian always passes by default, but sleeping at night is good. regards Thing -Original Message- From: Kjetil Kjernsmo [mailto:[EMAIL PROTECTED] Sent: Tuesday, 26 November 2002 10:39 To: debian-security@lists.debian.org Subject: Spammers using a non-existant address as return-path Dear all, I have just received a spam complaint, and unfortunately, some spammers have been using an address on one of my domains in their Return-Path and From-headers. How nice of them :-( . This address has never existed. I'm using the Exim packages from Woody. For quite some time, I have seen it show up in my server logs, I'm rotating them too often, I guess, and I don't remember exactly what I have seen long ago, but recently I have seen things like: 2002-11-15 01:48:08 verify failed for SMTP recipient [EMAIL PROTECTED] from <> H=mta458.mail.yahoo.com [216.136.130.123] I allow VRFY, and most of these come from yahoo.com or hotmail.com, I guess that has to do with spam filters they use. This address is probably getting a lot of bounces, which is then bounced off my server, and I don't want to waste my resources with accepting those, all in all I want to conserve as much as I can. But, is there something I _should_ do in this situation, like including some text in the bounce saying that this address has never existed, and is being abused by spammers? If yes, _how_ should I do it? I hope this is the right forum to ask... Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Spammers using a non-existant address as return-path
ive had a few cases of this myself, an irrate admin somewhere else whining its my fault ad i have , yet the relay test via telent shows all OK. I wonder if they firge known addresses on purpsoe to seed discontent. I dont want to teach you to suck eggs, but I would suggest this test is run as an independant way to verify your safe. I always run it after a sendmail change, as i pay for volume personally and at 2 gig + a day a spam hit would do to me would break me finiancially. I have found Debian always passes by default, but sleeping at night is good. regards Thing -Original Message- From: Kjetil Kjernsmo [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 26 November 2002 10:39 To: [EMAIL PROTECTED] Subject: Spammers using a non-existant address as return-path Dear all, I have just received a spam complaint, and unfortunately, some spammers have been using an address on one of my domains in their Return-Path and From-headers. How nice of them :-( . This address has never existed. I'm using the Exim packages from Woody. For quite some time, I have seen it show up in my server logs, I'm rotating them too often, I guess, and I don't remember exactly what I have seen long ago, but recently I have seen things like: 2002-11-15 01:48:08 verify failed for SMTP recipient [EMAIL PROTECTED] from <> H=mta458.mail.yahoo.com [216.136.130.123] I allow VRFY, and most of these come from yahoo.com or hotmail.com, I guess that has to do with spam filters they use. This address is probably getting a lot of bounces, which is then bounced off my server, and I don't want to waste my resources with accepting those, all in all I want to conserve as much as I can. But, is there something I _should_ do in this situation, like including some text in the bounce saying that this address has never existed, and is being abused by spammers? If yes, _how_ should I do it? I hope this is the right forum to ask... Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: spam
same way I do, go into /etc/mail/access and block the entire country by IP address ranges. I also blcok China and taiwan the same way, its all squiggly stuff which i cannot read anyway. I can post my list if required, but it blocks a LOT of addresses. the advantage of access (while crude) is, it stops the remote server connecting so you dont pay for the volume of the email (which I do) regards Thing -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]Sent: Monday, 11 November 2002 4:01 To: debian-security@lists.debian.orgSubject: spamhow can i block these bastards from korea from spaming me 10 times per day?
RE: spam
same way I do, go into /etc/mail/access and block the entire country by IP address ranges. I also blcok China and taiwan the same way, its all squiggly stuff which i cannot read anyway. I can post my list if required, but it blocks a LOT of addresses. the advantage of access (while crude) is, it stops the remote server connecting so you dont pay for the volume of the email (which I do) regards Thing -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Sent: Monday, 11 November 2002 4:01 To: [EMAIL PROTECTED]Subject: spamhow can i block these bastards from korea from spaming me 10 times per day?
RE: DHCP
ik campus ik ik so zilch physical security you didnt say this in your earlier post, this has severe security implications, in fact Id suggest you'd be a danger to the internet I'd suggest a letter to the ppl that want this and tell them of the severe secuity implications of what they want. you'd be a hackers/spammers dream...sit in the carpark with a laptop and wi-fi and spam the world. cant use static mapping of IPs to MACs.to many unknown MACs, well you can request each person registers thier machine with the helldesk and gets a static IP given out locked to the MAC address they provide. Run arpwatch to look for illegal connections We are trialing wi-fi city wide, the wi-fi lan is behind a firewall and are blocking port 25, then opening up ports as requested based on merits. DHCP is the least of your worries... This is not really a debian security issue but a general security issue, I would suggest you get a security policy written and get it agreed with "management". its your best set of defences from getting screwed over when something goes wrong. Also writing this and getting it agreed will give you time to research and get up to speed. Also the DHCP server should have a firewall of its own at the very least. It suggests careful planning is needed before implimentation, possibly a campus wide audit after a policy is agreed (you audit against the policy) regards Im writing a policy myself and its taking a while.it will be posted on the Internet once done for free use and comment. The debian security howto is good, if you have not read it please do. I'd split campus network up into a trusted and untrusted LAN )incl wi-fi network), the untrusted LAN should be treated as the Internet ie a danger zone and firewalled... i could go on and on..i suspect you have a lot to do.. regards Steven -Original Message- From: Stewart James [mailto:[EMAIL PROTECTED] Sent: Tuesday, 29 October 2002 12:53 To: debian-security@lists.debian.org Subject: RE: DHCP I had the very same thoughts, being a university you can imagine what physical security is like, plus management wants to give students the ability to walk on campus and plugin, plus start wireless services too. >From what people have sent back from my question, I don;t think we will be any worse of security wise as far as moving to DHCP will go. Thanks for the various responses, if someone still thinks of a big issue I would love to hear it. Cheers, Stewart On Tue, 29 Oct 2002, Jones, Steven wrote: > Date: Tue, 29 Oct 2002 12:19:06 +1300 > From: "Jones, Steven" <[EMAIL PROTECTED]> > To: 'Stewart James' <[EMAIL PROTECTED]>, > debian-security@lists.debian.org > Subject: RE: DHCP > Resent-Date: Mon, 28 Oct 2002 17:24:16 -0600 (CST) > Resent-From: debian-security@lists.debian.org > > u could set dhcp to give out a fixed address dependant on a mac address, > this would stop just anybody plugging a box into a network, if your network > is physically secure then thats not a worry. (a cat5 jack in reception or > some other public place is dodgy) > > Otherwise dhcp makes life easier...its the only way to manage a decent sized > network. > > :) >
RE: DHCP
u could set dhcp to give out a fixed address dependant on a mac address, this would stop just anybody plugging a box into a network, if your network is physically secure then thats not a worry. (a cat5 jack in reception or some other public place is dodgy) Otherwise dhcp makes life easier...its the only way to manage a decent sized network. :) Steven -Original Message- From: Stewart James [mailto:[EMAIL PROTECTED] Sent: Tuesday, 29 October 2002 12:03 To: debian-security@lists.debian.org Subject: DHCP I was hoping someone could help me out here. Currently I am still on a netowrk using static IP configurationon each machine, we are finally moving towards DHCP. Are there any security considerations to be made to ensure there is no gapping security hole. the various howto's I have seen don;t seem to have a clear "Security" section and I havent seen it mentioned in any of the faq's Thanks for any assistance, Stewart James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: DHCP
ik campus ik ik so zilch physical security you didnt say this in your earlier post, this has severe security implications, in fact Id suggest you'd be a danger to the internet I'd suggest a letter to the ppl that want this and tell them of the severe secuity implications of what they want. you'd be a hackers/spammers dream...sit in the carpark with a laptop and wi-fi and spam the world. cant use static mapping of IPs to MACs.to many unknown MACs, well you can request each person registers thier machine with the helldesk and gets a static IP given out locked to the MAC address they provide. Run arpwatch to look for illegal connections We are trialing wi-fi city wide, the wi-fi lan is behind a firewall and are blocking port 25, then opening up ports as requested based on merits. DHCP is the least of your worries... This is not really a debian security issue but a general security issue, I would suggest you get a security policy written and get it agreed with "management". its your best set of defences from getting screwed over when something goes wrong. Also writing this and getting it agreed will give you time to research and get up to speed. Also the DHCP server should have a firewall of its own at the very least. It suggests careful planning is needed before implimentation, possibly a campus wide audit after a policy is agreed (you audit against the policy) regards Im writing a policy myself and its taking a while.it will be posted on the Internet once done for free use and comment. The debian security howto is good, if you have not read it please do. I'd split campus network up into a trusted and untrusted LAN )incl wi-fi network), the untrusted LAN should be treated as the Internet ie a danger zone and firewalled... i could go on and on..i suspect you have a lot to do.. regards Steven -Original Message- From: Stewart James [mailto:stewart.james@;vu.edu.au] Sent: Tuesday, 29 October 2002 12:53 To: [EMAIL PROTECTED] Subject: RE: DHCP I had the very same thoughts, being a university you can imagine what physical security is like, plus management wants to give students the ability to walk on campus and plugin, plus start wireless services too. >From what people have sent back from my question, I don;t think we will be any worse of security wise as far as moving to DHCP will go. Thanks for the various responses, if someone still thinks of a big issue I would love to hear it. Cheers, Stewart On Tue, 29 Oct 2002, Jones, Steven wrote: > Date: Tue, 29 Oct 2002 12:19:06 +1300 > From: "Jones, Steven" <[EMAIL PROTECTED]> > To: 'Stewart James' <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > Subject: RE: DHCP > Resent-Date: Mon, 28 Oct 2002 17:24:16 -0600 (CST) > Resent-From: [EMAIL PROTECTED] > > u could set dhcp to give out a fixed address dependant on a mac address, > this would stop just anybody plugging a box into a network, if your network > is physically secure then thats not a worry. (a cat5 jack in reception or > some other public place is dodgy) > > Otherwise dhcp makes life easier...its the only way to manage a decent sized > network. > > :) > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: DHCP
u could set dhcp to give out a fixed address dependant on a mac address, this would stop just anybody plugging a box into a network, if your network is physically secure then thats not a worry. (a cat5 jack in reception or some other public place is dodgy) Otherwise dhcp makes life easier...its the only way to manage a decent sized network. :) Steven -Original Message- From: Stewart James [mailto:stewart.james@;vu.edu.au] Sent: Tuesday, 29 October 2002 12:03 To: [EMAIL PROTECTED] Subject: DHCP I was hoping someone could help me out here. Currently I am still on a netowrk using static IP configurationon each machine, we are finally moving towards DHCP. Are there any security considerations to be made to ensure there is no gapping security hole. the various howto's I have seen don;t seem to have a clear "Security" section and I havent seen it mentioned in any of the faq's Thanks for any assistance, Stewart James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Security on an old machine
Having done this (floppy install) its a pain to find enough floppies and time consuming. removing hd and shoving it in another machine is way quicker, a netboot install is the other option. regards Thing Since it's Debian, you don't need to stick it in a separate machine. Just get enough floppies and do the install over a network :) The only way this would be insecure is if someone broke into the machine you're installing from and you copied over bad files. -Anne --
RE: Security on an old machine
yes it should work Ive done this a few times due to various issues like a broken bios not allowing boot off a floppy or cdrom. It should not effect your security any worse than doing it straight off, the debian hardening howto should be followed to make it secure afterwards. regards Steven -Original Message- From: Steve Meyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, 16 October 2002 7:48 To: debian-security@lists.debian.org Subject: Security on an old machine I have an old 486 without a cdrom in it. If I pull the hard drive and stick it in another machine to perform the install will this work? And if it does work will it make the system any less secure?
RE: Security on an old machine
Having done this (floppy install) its a pain to find enough floppies and time consuming. removing hd and shoving it in another machine is way quicker, a netboot install is the other option. regards Thing Since it's Debian, you don't need to stick it in a separate machine. Just get enough floppies and do the install over a network :) The only way this would be insecure is if someone broke into the machine you're installing from and you copied over bad files. -Anne -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Security on an old machine
yes it should work Ive done this a few times due to various issues like a broken bios not allowing boot off a floppy or cdrom. It should not effect your security any worse than doing it straight off, the debian hardening howto should be followed to make it secure afterwards. regards Steven -Original Message- From: Steve Meyer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 16 October 2002 7:48 To: [EMAIL PROTECTED] Subject: Security on an old machine I have an old 486 without a cdrom in it. If I pull the hard drive and stick it in another machine to perform the install will this work? And if it does work will it make the system any less secure? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Mail relay attempts
Ive found port sentry really good for detecting port scans and then routeing the return packets to no where. :) Thing -Original Message- From: Rolf Kutz [mailto:[EMAIL PROTECTED] Sent: Wednesday, 28 August 2002 4:10 To: [EMAIL PROTECTED] Debian. Org Subject: Re: Mail relay attempts * Quoting Craig Sanders ([EMAIL PROTECTED]): > > PS: actually, the only other thing you could do is set firewall rules > blocking inbound tcp port 25. if your mail server is the primary MX for > your domain then you would also need a secondary MX and open the > firewall for just that machine. spammers will still try - the only real > difference is that you'll get entries in your kernel log rather than in > your mail log. if you do this, i recommend using iptables and DROP the > packet rather than REJECT itthis wastes the spammer's time while the > connection times out. Drop doesn't really prevent scans and spammers will scan for open ports first. If you really want to achive something like that, you should install a 'Teergrube': http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: [SECURITY] [DSA-134-1] OpenSSH remote vulnerability
I would suggest it means either write a tight firewall ruleset to restrict access or dont allow connections from the interneta t all. Ive now donethe latter, after the previous weakness its just to great a risk. regards Steven -Original Message- From: Phillip Hofmeister [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 June 2002 11:14 To: debian-security@lists.debian.org Subject: Re: [SECURITY] [DSA-134-1] OpenSSH remote vulnerability Sowhat does this mean for us running potato on internet servers? Does this effect the daemon or the client? If it effects the daemon, is the potato version vulnerable? Phil On Mon, Jun 24, 2002 at 11:56:04PM +0200, Wichert Akkerman wrote: > > Debian Security Advisory DSA-134-1 [EMAIL PROTECTED] > http://www.debian.org/security/ Wichert Akkerman > June 24, 2002 > > > > Package: ssh > Problem type : remote exploit > Debian-specific: no > > Theo de Raadt announced that the OpenBSD team is working with ISS > on a remote exploit for OpenSSH (a free implementation of the > Secure SHell protocol). They are refusing to provide any details on > the vulnerability but instead are advising everyone to upgrade to > the latest release, version 3.3. > > This version was released 3 days ago and introduced a new feature > to reduce the effect of exploits in the network handling code > called privilege separation. Unfortunately this release has a few > known problems: compression does not work on all operating systems > since the code relies on specific mmap features, and the PAM > support has not been completed. There may be other problems as > well. > > The new privilege separation support from Niels Provos changes ssh > to use a separate non-privileged process to handle most of the > work. This means any vulnerability in this part of OpenSSH can > never lead to a root compromise but only to access to a separate > account restricted to a chroot. > > Theo made it very clear this new version does not fix the > vulnerability, instead by using the new privilege separation code > it merely reduces the risk since the attacker can only gain access > to a special account restricted in a chroot. > > Since details of the problem have not been released we were forced > to move to the latest release of OpenSSH portable, version 3.3p1. > > Due to the short time frame we have had we have not been able to > update the ssh package for Debian GNU/Linux 2.2 / potato yet. > Packages for the upcoming 3.0 release (woody) are available for > most architectures. > > Please note that we have not had the time to do proper QA on these > packages; they might contain bugs or break things unexpectedly. If > you notice any such problems please file a bug-report so we can > investigate. > > This package introduce a new account called `sshd' that is used in > the privilege separation code. If no sshd account exists the > package will try to create one. If the account already exists it > will be re-used. If you do not want this to happen you will have > to fix this manually. > > > wget url > will fetch the file for you > dpkg -i file.deb > will install the referenced file. > > > Debian GNU/Linux 2.2 alias potato > - > > Potato was released for alpha, arm, i386, m68k, powerpc and sparc. > > Package for potato are not available at the moment > > > Debian GNU/Linux 3.0 alias woody > - > > Woody will be released for alpha, arm, hppa, i386, ia64, m68k, mips, > mipsel, powerpc, s390 and sparc. Packages for m68k are not yet > available at this moment. > > > Source archives: > > http://security.debian.org/pool/updates/main/o/openssh/openssh_3.3p1-0.0wood y1.dsc > Size/MD5 checksum: 751 2409524dc15e3de36ebfaa702c0311ea > http://security.debian.org/pool/updates/main/o/openssh/openssh_3.3p1.orig.ta r.gz > Size/MD5 checksum: 831189 226fdde5498c56288e777c7a697996e0 > http://security.debian.org/pool/updates/main/o/openssh/openssh_3.3p1-0.0wood y1.diff.gz > Size/MD5 checksum:33009 4850f4a167cb515cc20301288e751e27 > > alpha architecture (DEC Alpha) > > http://security.debian.org/pool/updates/main/o/openssh/ssh_3.3p1-0.0woody1_a lpha.deb > Size/MD5 checksum: 844556 7ef1518babcb185b5ef61fde2bd881c5 > http://security.debian.org/pool/updates/main/o/openssh/ssh-askpass-gnome_3.3 p1-0.0woody1_alpha.deb > Size/MD5 checksum:33422 ba9145a70719500ba56940e79e2cba02 > > arm architecture (Arm) > > http://security.debian.org/pool/updates/main/o/openssh/ssh_3.3p1-0.0woody1_a rm.deb > Size/MD5 checksum: 653454 4b6553ed08622525c6f22e7dc488f7c6 > http://security.debian.org/pool/updates/main/o/openssh/ssh-askpass-gnome_3.3 p1-0.0woody1_arm.deb > Size/MD5 checksum:
