zlib MALLOC_CHECK
Hi Group, ist there someone who is using the MALLOC_CHECK environment variables? How is the Performance? cu thomas -- Thomas Braun WESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 [EMAIL PROTECTED] Internet Security for ProfessionalsFax 0241/911879 WESTEND ist CISCO Systems Partner - Premier Certified -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: wierd connection attempt
Stephen Gran wrote: This one time, at band camp, Hal said: I run a potato server on an ethernet behind a firewall connected by dsl to the internet. The only service exposed is ftp, In the middle of last night ippl reported an ftp connection attempt from 192.168.1,1 The network behind my firewall uses 192.168.75.xx addressses for one Redhat and a couple of Windows machines as well as the debian ftp server. Any idea where the 192.168.1.1 attempt is coming from? Is it likely to have been spoofed over the internet as part of an attack? -- --- Hal [EMAIL PROTECTED] --- -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] It may have been, or it may have been somebody else on a LAN, with IP addressing schema 192.168.1.x, who forgot to use passive-ftp. I guess you'd have to look around and see what they tried to do. HTH, Steve I thought class C networks were non-routable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: wierd connection attempt
On Fri, Mar 15, 2002 at 06:40:45AM -0500, Josh Frick wrote: I thought class C networks were non-routable. I think you're confused. First of all I think you're confused as to what a class C network is, and second of all I think you're confused as to what networks are non-routable and what it means for them to be non-routable. The internet used to be divided into class A, B, and C (and D and E, but we don't care so much about those). Class C networks were /24s in the range 192.0.0.0 to 223.255.255.255. Those netblocks certainly were routable, and in fact most netblock allocation was done from the class C address space. Non-routable addresses are defined by RFC 1918. 10.0.0.0/8, 192.168.0.0/16, and 172.16.0.0/12. The only thing that makes these non-routable is the fact that you'd be in violation of the RFC to advertise a route for them. There's nothing built in to routers that prevents them from being routable Now, it does seem a bit weird that the person reporting this unusual traffic had RFC 1918 traffic routed to their internal network. They should probably be filtering on the border router (or NAT box, or whatever it was). noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html msg05992/pgp0.pgp Description: PGP signature
udp port 32794
Hello, since a few days i have tons like this in my log: grobi kernel: Packet log: input DENY ppp0 PROTO=17 xxx.xxx.xxx.xxx: xxx.xxx.xxx.xxx:32794 L=37 S=0x00 I=41867 F=0x T=117 (#4) the packets come from many different addresses and always in a bunch of 3 - 5. i'm wondering what this could be. Is it a known exploit, or just a new P2P software like gnutella/kaza/etc ? Regards, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udp port 32794
On Fri, Mar 15, 2002 at 09:09:15PM +0100, Roland Stoll wrote: i'm wondering what this could be. Is it a known exploit, or just a new P2P software like gnutella/kaza/etc ? It is traceroute. -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html msg05994/pgp0.pgp Description: PGP signature
ipmasq + port filtering recipe?
I've searched http://groups.google.com and and the web for a quick recipe. I've also scanned the general documentation, but I haven't figured out exactly how to do this yet. I have a machine that's running Debian Potato a web server and an ipmasq. The machine has an internal and external network card. The internal network runs on 10.0.0.0/24 and the external network has a static IP address. I've apt-get install'd the ipmasq package and the IPMasq functionality works great. What I'd like to do now is to use ipchains to do the following: 1. On the external interface, I would like to only accept traffic from port 22 and port 80. 2. The internal interface should be wide open - the internal network we trust the users who are physically in the room not to be malicious. Can you all point me to a recipe on how to do this? Is there any documentation that applies to this specific situation? Thanks in advance! -Luke -- Luke Scharf, Jack of Several Trades http://www.ccm.ece.vt.edu/~lscharf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.2.18 exploit, and updating the kernel
I have a potato system - with the 2.2.18 kernel. Somone has gotten into a box on my network and used this exploit to gain root: http://:infected.ilm.net/xpl0itz/l1nux/epcs2.c+epcs2hl=enie=ISO-8859-1 The other boxes that are net accessible are openbsd -- This system is a dual p6 so I need debian for smp. Is there a proper 'debian' way to go about patching the kernel against this exploit, or updating the kernel to 2.4. Thanks, David Rolfe @ work -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ipmasq + port filtering recipe?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In message 1016230298.20826.8.camel@garcon, Luke Scharf writes:
I have a machine that's running Debian Potato a web server and an
ipmasq. The machine has an internal and external network card. The
internal network runs on 10.0.0.0/24 and the external network has a
static IP address.
I've apt-get install'd the ipmasq package and the IPMasq functionality
works great. What I'd like to do now is to use ipchains to do the
following:
1. On the external interface, I would like to only accept traffic from
port 22 and port 80.
2. The internal interface should be wide open - the internal network we
trust the users who are physically in the room not to be malicious.
The ipmasq package sets up things pretty open, so all you need to do is lock
down the external interface. Just make a copy of the
/etc/ipmasq/rules/I90external.def file as I90external.rul and add lines.
Here's the netfilter section of my I90external.rul file. As configured it
allows ssh, smtp, dns (both tcp and udp) and http traffic.
netfilter)
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $IPOFIF/32 -m state --state
ESTABLISHED,RELATED
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $IPOFIF/32 -p tcp --dport
22:22 -m state --state NEW
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $IPOFIF/32 -p tcp --dport
25:25 -m state --state NEW
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $IPOFIF/32 -p tcp --dport
53:53 -m state --state NEW
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $IPOFIF/32 -p udp --dport
53:53
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $IPOFIF/32 -p tcp --dport
80:80 -m state --state NEW
if [ -n $BCOFIF ]; then
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $BCOFIF/32 -m state
--state ESTABLISHED,RELATED
fi
;;
Since there's no general accept line here, (it used to be that first line, but
I changed it to use state) anything that doesn't match falls through and is
denied. You may also want to add '-m state --state ESTABLISHED,RELATED' to
the ACCEPT line in I90extbcast.def as well, or otherwise you'll end up
allowing general broadcast packets. If you want to be excessively paranoid,
you'll want a rule that re-assembles any fragments. I have a I85fragments.rul
file that does this. Here's the relevant line:
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -f
- --
Ted Cabeen http://www.pobox.com/~secabeen[EMAIL PROTECTED]
Check Website or Keyserver for PGP/GPG Key BA0349D2 [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]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (OpenBSD)
Comment: Exmh version 2.5 07/13/2001
iD8DBQE8koyHoayJfLoDSdIRAv/VAJ9Umn2wZYU11cXmJy1WtZw1D6+hJQCgkFMU
w3jTmgWJbG7owU9EXnXY64E=
=aAp+
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ipmasq + port filtering recipe?
At 03:11 PM 3/15/2002, Luke Scharf wrote: I've searched http://groups.google.com and and the web for a quick recipe. I've also scanned the general documentation, but I haven't figured out exactly how to do this yet. I have a machine that's running Debian Potato a web server and an ipmasq. The machine has an internal and external network card. The internal network runs on 10.0.0.0/24 and the external network has a static IP address. I've apt-get install'd the ipmasq package and the IPMasq functionality works great. What I'd like to do now is to use ipchains to do the following: 1. On the external interface, I would like to only accept traffic from port 22 and port 80. 2. The internal interface should be wide open - the internal network we trust the users who are physically in the room not to be malicious. Can you all point me to a recipe on how to do this? Is there any documentation that applies to this specific situation? Here's a (really really super) basic recipe In this example, eth0 is external and eth1 is internal == echo - Disabling IP Spoofing attacks. for file in /proc/sys/net/ipv4/conf/*/rp_filter do echo 1 $file done echo - Changing IP masquerading timeouts. /sbin/ipchains -M -S 7200 10 60 /sbin/modprobe ip_masq_ftp ipchains -F ipchains -P input DENY ipchains -P output ACCEPT ipchains -P forward DENY ipchains -A input -i eth0 -d 0/0 22 -j ACCEPT ipchains -A input -i eth0 -d 0/0 80 -j ACCEPT ipchains -A input -i eth1 -j ACCEPT ipchains -A forward -s 10.0.0.0/24 -j MASQ == No port forwarding, really basic (this script has no warranty that it will work... but it *is* a highly condensed simple version of what we run here. so, I rate the chances as pretty good that it'll work) One question though... while you trust your users not to be malicious, do you trust your users not to accidentally open a malicious email attachment, accidentally browse a malicious website with a vulnerable browser, or other mistakes? If not, you might want to tighten down outbound traffic as well. Jer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.2.18 exploit, and updating the kernel
On Fri, 15 Mar 2002 18:16:22 EST [EMAIL PROTECTED] wrote: I get: Could not connect to remote server when I try to follow that link. I get: The address is not available from this machine when I strip out the extra leading : :) I am curious as to seeing what potato is vulnerable to. However: if you want the 2.4.* kernel on your deb box, you should upgrade to woody. Not only for the 2.4 kernel, but also for more up to date packages and security patches. so do this: debian# vi /etc/apt/sources.list substitute potato w/ woody to upgrade to woody deb http://security.debian.org/debian-security potato/updates main contrib non-free deb http://security.debian.org/debian-non-US potato/non-US main contrib non-free deb http://security.debian.org potato/updates main contrib non-free debian# apt-get dist-upgrade debian# apt-get update debian# apt-get upgrade That's the proper 'debian' way to do it. But if you've already been rooted you'll probably want to start from a fresh install. Download the install floppy images from http://ftp.us.debian.org/debian/dists/woody/main/disks-i386/current/images-1.44/ Hope that helps, and sorry to hear about the root job :( Brad Beck - linux guru in beta I have a potato system - with the 2.2.18 kernel. Somone has gotten into a box on my network and used this exploit to gain root: http://:infected.ilm.net/xpl0itz/l1nux/epcs2.c+epcs2hl=enie=ISO-8859-1 The other boxes that are net accessible are openbsd -- This system is a dual p6 so I need debian for smp. Is there a proper 'debian' way to go about patching the kernel against this exploit, or updating the kernel to 2.4. Thanks, David Rolfe @ work -- 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: wierd connection attempt
Noah L. Meyerhans wrote: On Fri, Mar 15, 2002 at 06:40:45AM -0500, Josh Frick wrote: I thought class C networks were non-routable. I think you're confused. First of all I think you're confused as to what a class C network is, and second of all I think you're confused as to what networks are non-routable and what it means for them to be non-routable. The internet used to be divided into class A, B, and C (and D and E, but we don't care so much about those). Class C networks were /24s in the range 192.0.0.0 to 223.255.255.255. Those netblocks certainly were routable, and in fact most netblock allocation was done from the class C address space. Non-routable addresses are defined by RFC 1918. 10.0.0.0/8, 192.168.0.0/16, and 172.16.0.0/12. The only thing that makes these non-routable is the fact that you'd be in violation of the RFC to advertise a route for them. There's nothing built in to routers that prevents them from being routable Now, it does seem a bit weird that the person reporting this unusual traffic had RFC 1918 traffic routed to their internal network. They should probably be filtering on the border router (or NAT box, or whatever it was). noah Yes, I most definitely was confused. Thank you for the clarification. I'm not familiar with the RFCs. My question, however, remains: aren't network addresses in that range supposed to be prevented from crossing (i.e. being routed) the internet? If they are, then it's possible this traffic is local, is it not? I believe my DSL ISP assigns a private class IP address before connection. Would this then indicate that the connection attempt was made by another customer of the person's ISP? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: wierd connection attempt
Josh Frick wrote: Yes, I most definitely was confused. Thank you for the clarification. I'm not familiar with the RFCs. My question, however, remains: aren't network addresses in that range supposed to be prevented from crossing (i.e. being routed) the internet? If they are, then it's possible this traffic is local, is it not? I believe my DSL ISP assigns a private class IP address before connection. Would this then indicate that the connection attempt was made by another customer of the person's ISP? Exactly. Perhaps this person's ISP is not the filtering the bogus messages from reaching it's other customers, or perhaps the messages are passing through outside routers that are not complying with the RFC, and allowing them to travel so far. It's most likely that it is coming from another subscriber to the ISP's network. -Will Wesley, CCNA A prediction is worth twenty explanations. -- K. Brecher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.2.18 exploit, and updating the kernel
On Fri, Mar 15, 2002 at 06:16:22PM -0500, [EMAIL PROTECTED] wrote: I have a potato system - with the 2.2.18 kernel. Somone has gotten into a box on my network and used this exploit to gain root: http://:infected.ilm.net/xpl0itz/l1nux/epcs2.c+epcs2hl=enie=ISO-8859-1 The other boxes that are net accessible are openbsd -- This system is a dual p6 so I need debian for smp. Is there a proper 'debian' way to go about patching the kernel against this exploit, or updating the kernel to 2.4. 2.2.18 is deprecated. Use the latest one (2.2.19) in potato. It's rock solid (some security patches were backported in it). -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udp port 32794
Noah L. Meyerhans wrote: On Fri, Mar 15, 2002 at 09:09:15PM +0100, Roland Stoll wrote: i'm wondering what this could be. Is it a known exploit, or just a new P2P software like gnutella/kaza/etc ? It is traceroute. Ah, i remember that traceroute connects to high ports, increments the ttl and waits for a dest.-unreachable icmp. funny, that i got traces from over hundred unique IP addresses. thank you for the hint and regards, Roland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
zlib MALLOC_CHECK
Hi Group, ist there someone who is using the MALLOC_CHECK environment variables? How is the Performance? cu thomas -- Thomas Braun WESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 [EMAIL PROTECTED] Internet Security for ProfessionalsFax 0241/911879 WESTEND ist CISCO Systems Partner - Premier Certified
Re: wierd connection attempt
Stephen Gran wrote: This one time, at band camp, Hal said: I run a potato server on an ethernet behind a firewall connected by dsl to the internet. The only service exposed is ftp, In the middle of last night ippl reported an ftp connection attempt from 192.168.1,1 The network behind my firewall uses 192.168.75.xx addressses for one Redhat and a couple of Windows machines as well as the debian ftp server. Any idea where the 192.168.1.1 attempt is coming from? Is it likely to have been spoofed over the internet as part of an attack? -- --- Hal [EMAIL PROTECTED] --- -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] It may have been, or it may have been somebody else on a LAN, with IP addressing schema 192.168.1.x, who forgot to use passive-ftp. I guess you'd have to look around and see what they tried to do. HTH, Steve I thought class C networks were non-routable.
Re: wierd connection attempt
On Fri, Mar 15, 2002 at 06:40:45AM -0500, Josh Frick wrote: I thought class C networks were non-routable. I think you're confused. First of all I think you're confused as to what a class C network is, and second of all I think you're confused as to what networks are non-routable and what it means for them to be non-routable. The internet used to be divided into class A, B, and C (and D and E, but we don't care so much about those). Class C networks were /24s in the range 192.0.0.0 to 223.255.255.255. Those netblocks certainly were routable, and in fact most netblock allocation was done from the class C address space. Non-routable addresses are defined by RFC 1918. 10.0.0.0/8, 192.168.0.0/16, and 172.16.0.0/12. The only thing that makes these non-routable is the fact that you'd be in violation of the RFC to advertise a route for them. There's nothing built in to routers that prevents them from being routable Now, it does seem a bit weird that the person reporting this unusual traffic had RFC 1918 traffic routed to their internal network. They should probably be filtering on the border router (or NAT box, or whatever it was). noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpgrTFH5L1uW.pgp Description: PGP signature
udp port 32794
Hello, since a few days i have tons like this in my log: grobi kernel: Packet log: input DENY ppp0 PROTO=17 xxx.xxx.xxx.xxx: xxx.xxx.xxx.xxx:32794 L=37 S=0x00 I=41867 F=0x T=117 (#4) the packets come from many different addresses and always in a bunch of 3 - 5. i'm wondering what this could be. Is it a known exploit, or just a new P2P software like gnutella/kaza/etc ? Regards, Roland
Re: udp port 32794
On Fri, Mar 15, 2002 at 09:09:15PM +0100, Roland Stoll wrote: i'm wondering what this could be. Is it a known exploit, or just a new P2P software like gnutella/kaza/etc ? It is traceroute. -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpL4JBP6WhSC.pgp Description: PGP signature
ipmasq + port filtering recipe?
I've searched http://groups.google.com and and the web for a quick recipe. I've also scanned the general documentation, but I haven't figured out exactly how to do this yet. I have a machine that's running Debian Potato a web server and an ipmasq. The machine has an internal and external network card. The internal network runs on 10.0.0.0/24 and the external network has a static IP address. I've apt-get install'd the ipmasq package and the IPMasq functionality works great. What I'd like to do now is to use ipchains to do the following: 1. On the external interface, I would like to only accept traffic from port 22 and port 80. 2. The internal interface should be wide open - the internal network we trust the users who are physically in the room not to be malicious. Can you all point me to a recipe on how to do this? Is there any documentation that applies to this specific situation? Thanks in advance! -Luke -- Luke Scharf, Jack of Several Trades http://www.ccm.ece.vt.edu/~lscharf
2.2.18 exploit, and updating the kernel
I have a potato system - with the 2.2.18 kernel. Somone has gotten into a box on my network and used this exploit to gain root: http://:infected.ilm.net/xpl0itz/l1nux/epcs2.c+epcs2hl=enie=ISO-8859-1 The other boxes that are net accessible are openbsd -- This system is a dual p6 so I need debian for smp. Is there a proper 'debian' way to go about patching the kernel against this exploit, or updating the kernel to 2.4. Thanks, David Rolfe @ work
Re: ipmasq + port filtering recipe?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
In message [EMAIL PROTECTED], Luke Scharf writes:
I have a machine that's running Debian Potato a web server and an
ipmasq. The machine has an internal and external network card. The
internal network runs on 10.0.0.0/24 and the external network has a
static IP address.
I've apt-get install'd the ipmasq package and the IPMasq functionality
works great. What I'd like to do now is to use ipchains to do the
following:
1. On the external interface, I would like to only accept traffic from
port 22 and port 80.
2. The internal interface should be wide open - the internal network we
trust the users who are physically in the room not to be malicious.
The ipmasq package sets up things pretty open, so all you need to do is lock
down the external interface. Just make a copy of the
/etc/ipmasq/rules/I90external.def file as I90external.rul and add lines.
Here's the netfilter section of my I90external.rul file. As configured it
allows ssh, smtp, dns (both tcp and udp) and http traffic.
netfilter)
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $IPOFIF/32 -m state
--state ESTABLISHED,RELATED
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $IPOFIF/32 -p tcp
--dport 22:22 -m state --state NEW
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $IPOFIF/32 -p tcp
--dport 25:25 -m state --state NEW
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $IPOFIF/32 -p tcp
--dport 53:53 -m state --state NEW
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $IPOFIF/32 -p udp
--dport 53:53
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $IPOFIF/32 -p tcp
--dport 80:80 -m state --state NEW
if [ -n $BCOFIF ]; then
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -d $BCOFIF/32 -m state
--state ESTABLISHED,RELATED
fi
;;
Since there's no general accept line here, (it used to be that first line, but
I changed it to use state) anything that doesn't match falls through and is
denied. You may also want to add '-m state --state ESTABLISHED,RELATED' to
the ACCEPT line in I90extbcast.def as well, or otherwise you'll end up
allowing general broadcast packets. If you want to be excessively paranoid,
you'll want a rule that re-assembles any fragments. I have a I85fragments.rul
file that does this. Here's the relevant line:
$IPTABLES -A INPUT -j ACCEPT -i ${i%%:*} -f
- --
Ted Cabeen http://www.pobox.com/~secabeen[EMAIL
PROTECTED]
Check Website or Keyserver for PGP/GPG Key BA0349D2 [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]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (OpenBSD)
Comment: Exmh version 2.5 07/13/2001
iD8DBQE8koyHoayJfLoDSdIRAv/VAJ9Umn2wZYU11cXmJy1WtZw1D6+hJQCgkFMU
w3jTmgWJbG7owU9EXnXY64E=
=aAp+
-END PGP SIGNATURE-
Re: ipmasq + port filtering recipe?
At 03:11 PM 3/15/2002, Luke Scharf wrote: I've searched http://groups.google.com and and the web for a quick recipe. I've also scanned the general documentation, but I haven't figured out exactly how to do this yet. I have a machine that's running Debian Potato a web server and an ipmasq. The machine has an internal and external network card. The internal network runs on 10.0.0.0/24 and the external network has a static IP address. I've apt-get install'd the ipmasq package and the IPMasq functionality works great. What I'd like to do now is to use ipchains to do the following: 1. On the external interface, I would like to only accept traffic from port 22 and port 80. 2. The internal interface should be wide open - the internal network we trust the users who are physically in the room not to be malicious. Can you all point me to a recipe on how to do this? Is there any documentation that applies to this specific situation? Here's a (really really super) basic recipe In this example, eth0 is external and eth1 is internal == echo - Disabling IP Spoofing attacks. for file in /proc/sys/net/ipv4/conf/*/rp_filter do echo 1 $file done echo - Changing IP masquerading timeouts. /sbin/ipchains -M -S 7200 10 60 /sbin/modprobe ip_masq_ftp ipchains -F ipchains -P input DENY ipchains -P output ACCEPT ipchains -P forward DENY ipchains -A input -i eth0 -d 0/0 22 -j ACCEPT ipchains -A input -i eth0 -d 0/0 80 -j ACCEPT ipchains -A input -i eth1 -j ACCEPT ipchains -A forward -s 10.0.0.0/24 -j MASQ == No port forwarding, really basic (this script has no warranty that it will work... but it *is* a highly condensed simple version of what we run here. so, I rate the chances as pretty good that it'll work) One question though... while you trust your users not to be malicious, do you trust your users not to accidentally open a malicious email attachment, accidentally browse a malicious website with a vulnerable browser, or other mistakes? If not, you might want to tighten down outbound traffic as well. Jer
Re: 2.2.18 exploit, and updating the kernel
On Fri, 15 Mar 2002 18:16:22 EST [EMAIL PROTECTED] wrote: I get: Could not connect to remote server when I try to follow that link. I get: The address is not available from this machine when I strip out the extra leading : :) I am curious as to seeing what potato is vulnerable to. However: if you want the 2.4.* kernel on your deb box, you should upgrade to woody. Not only for the 2.4 kernel, but also for more up to date packages and security patches. so do this: debian# vi /etc/apt/sources.list substitute potato w/ woody to upgrade to woody deb http://security.debian.org/debian-security potato/updates main contrib non-free deb http://security.debian.org/debian-non-US potato/non-US main contrib non-free deb http://security.debian.org potato/updates main contrib non-free debian# apt-get dist-upgrade debian# apt-get update debian# apt-get upgrade That's the proper 'debian' way to do it. But if you've already been rooted you'll probably want to start from a fresh install. Download the install floppy images from http://ftp.us.debian.org/debian/dists/woody/main/disks-i386/current/images-1.44/ Hope that helps, and sorry to hear about the root job :( Brad Beck - linux guru in beta I have a potato system - with the 2.2.18 kernel. Somone has gotten into a box on my network and used this exploit to gain root: http://:infected.ilm.net/xpl0itz/l1nux/epcs2.c+epcs2hl=enie=ISO-8859-1 The other boxes that are net accessible are openbsd -- This system is a dual p6 so I need debian for smp. Is there a proper 'debian' way to go about patching the kernel against this exploit, or updating the kernel to 2.4. Thanks, David Rolfe @ work -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: wierd connection attempt
Noah L. Meyerhans wrote: On Fri, Mar 15, 2002 at 06:40:45AM -0500, Josh Frick wrote: I thought class C networks were non-routable. I think you're confused. First of all I think you're confused as to what a class C network is, and second of all I think you're confused as to what networks are non-routable and what it means for them to be non-routable. The internet used to be divided into class A, B, and C (and D and E, but we don't care so much about those). Class C networks were /24s in the range 192.0.0.0 to 223.255.255.255. Those netblocks certainly were routable, and in fact most netblock allocation was done from the class C address space. Non-routable addresses are defined by RFC 1918. 10.0.0.0/8, 192.168.0.0/16, and 172.16.0.0/12. The only thing that makes these non-routable is the fact that you'd be in violation of the RFC to advertise a route for them. There's nothing built in to routers that prevents them from being routable Now, it does seem a bit weird that the person reporting this unusual traffic had RFC 1918 traffic routed to their internal network. They should probably be filtering on the border router (or NAT box, or whatever it was). noah Yes, I most definitely was confused. Thank you for the clarification. I'm not familiar with the RFCs. My question, however, remains: aren't network addresses in that range supposed to be prevented from crossing (i.e. being routed) the internet? If they are, then it's possible this traffic is local, is it not? I believe my DSL ISP assigns a private class IP address before connection. Would this then indicate that the connection attempt was made by another customer of the person's ISP?
