Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 10:09:13PM -0600, Ted Cabeen wrote: > Actually we trap illegal packets like this one in I15lospoof.def. > > :#: Deny and log all packets trying to come in from a 127.0.0.0/8 address > :#: over a non-'lo' interface Double-check that against the original question: "is debian protected beforeconnecting from remote hosts to address 127.0.0.0/8 ?" Notice he said "_to_ 127.0.0.0/8" and not "_from_" which is what I15lospoof.def blocks. I made the same mistake in my first post, then re-read his question.
Re: 127.0.0.0/8 addresses from the network
In message <[EMAIL PROTECTED]>, Jim Breton writes: >On Fri, Mar 09, 2001 at 08:49:54PM +, Jim Breton wrote: >> # deny and log all packets trying to come in from a 127.0.0.0/8 address >> # over a non-'lo' interface > >Oops. Just occurred to me that this is not what you were asking about. >Why do I do such things? > >Anyway. > >/etc/ipmasq/rules/I90external.def >Since we have a default drop and log coming later in the rules >(/etc/ipmasq/rules/ZZZdenyandlog.def), this will take care of your >concern. Actually we trap illegal packets like this one in I15lospoof.def. :#: Deny and log all packets trying to come in from a 127.0.0.0/8 address :#: over a non-'lo' interface case $MASQMETHOD in ipfwadm) if [ -n "$INTERNAL" -o -n "$EXTERNAL" ]; then for i in $INTERNAL $EXTERNAL; do $IPFWADM -I -a deny -W $i -S 127.0.0.1/255.0.0.0 -o done fi ;; ipchains) $IPCHAINS -A input -j DENY -i ! lo -s 127.0.0.1/255.0.0.0 -l ;; netfilter) $IPTABLES -A INPUT -j LOG -i ! lo -s 127.0.0.1/255.0.0.0 ;; esac Although there is a final deny rule, thie one works better. -- 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]
Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 08:49:54PM +, Jim Breton wrote: > # deny and log all packets trying to come in from a 127.0.0.0/8 address > # over a non-'lo' interface Oops. Just occurred to me that this is not what you were asking about. Why do I do such things? Anyway. /etc/ipmasq/rules/I90external.def # accept incoming packets from external networks on external interfaces ipchains) $IPCHAINS -A input -j ACCEPT -i $i -d $IPOFIF/32 if [ -n "$BCOFIF" ]; then $IPCHAINS -A input -j ACCEPT -i $i -d $BCOFIF/32 fi ;; Since we have a default drop and log coming later in the rules (/etc/ipmasq/rules/ZZZdenyandlog.def), this will take care of your concern.
Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 10:09:13PM -0600, Ted Cabeen wrote: > Actually we trap illegal packets like this one in I15lospoof.def. > > :#: Deny and log all packets trying to come in from a 127.0.0.0/8 address > :#: over a non-'lo' interface Double-check that against the original question: "is debian protected beforeconnecting from remote hosts to address 127.0.0.0/8 ?" Notice he said "_to_ 127.0.0.0/8" and not "_from_" which is what I15lospoof.def blocks. I made the same mistake in my first post, then re-read his question. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
In message <[EMAIL PROTECTED]>, Jim Breton writes: >On Fri, Mar 09, 2001 at 08:49:54PM +, Jim Breton wrote: >> # deny and log all packets trying to come in from a 127.0.0.0/8 address >> # over a non-'lo' interface > >Oops. Just occurred to me that this is not what you were asking about. >Why do I do such things? > >Anyway. > >/etc/ipmasq/rules/I90external.def >Since we have a default drop and log coming later in the rules >(/etc/ipmasq/rules/ZZZdenyandlog.def), this will take care of your >concern. Actually we trap illegal packets like this one in I15lospoof.def. :#: Deny and log all packets trying to come in from a 127.0.0.0/8 address :#: over a non-'lo' interface case $MASQMETHOD in ipfwadm) if [ -n "$INTERNAL" -o -n "$EXTERNAL" ]; then for i in $INTERNAL $EXTERNAL; do $IPFWADM -I -a deny -W $i -S 127.0.0.1/255.0.0.0 -o done fi ;; ipchains) $IPCHAINS -A input -j DENY -i ! lo -s 127.0.0.1/255.0.0.0 -l ;; netfilter) $IPTABLES -A INPUT -j LOG -i ! lo -s 127.0.0.1/255.0.0.0 ;; esac Although there is a final deny rule, thie one works better. -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 08:49:54PM +, Jim Breton wrote: > # deny and log all packets trying to come in from a 127.0.0.0/8 address > # over a non-'lo' interface Oops. Just occurred to me that this is not what you were asking about. Why do I do such things? Anyway. /etc/ipmasq/rules/I90external.def # accept incoming packets from external networks on external interfaces ipchains) $IPCHAINS -A input -j ACCEPT -i $i -d $IPOFIF/32 if [ -n "$BCOFIF" ]; then $IPCHAINS -A input -j ACCEPT -i $i -d $BCOFIF/32 fi ;; Since we have a default drop and log coming later in the rules (/etc/ipmasq/rules/ZZZdenyandlog.def), this will take care of your concern. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Segfault in login
I don't know if this could be exploited is any way, but here's something that I've seen. This is on x86 on two machines and a ppc g3. #su #login login: ^D Segmentation fault Maybe you guys can check this more. Mike
Re: kernel patches
Am Samstag, 10. März 2001 00:05 schrieb Kevin: > Then they only have to compile their own version. Openwall shows only > you when you run 'w' but shows everyone if you 'who'. Anyone know > why? No experience with tools like this (LIDS/Openwall etc.) w and who are different binaries on my system, so they might use different ways of accessing the information. If users can actually compile their own stuff in a restricted environment there are many possibilities of circumventing restrictions. The only restrictions which are not easily circumvented are those imposed by the kernel and its components. -- Patrick Dreker - > Is there anything else I can contribute? The latitude and longtitude of the bios writers current position, and a ballistic missile. Alan Cox on linux-kernel@vger.kernel.org
Re: Re[2]: kernel patches
also sprach Kevin (on Fri, 09 Mar 2001 04:05:17PM -0700): > Then they only have to compile their own version. Openwall shows only > you when you run 'w' but shows everyone if you 'who'. Anyone know > why? well, afaik w and who are two separate programs. it appears that who uses utmp information whereas w collects its information from the /proc filesystem. martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] -- "declared guilty... of displaying feelings of an almost human nature." -- roger waters, 1979
Re: Re[2]: kernel patches
On Fri, Mar 09, 2001 at 04:05:17PM -0700, Kevin wrote: > > > Then they only have to compile their own version. Openwall shows only > you when you run 'w' but shows everyone if you 'who'. Anyone know > why? > Because 'who' just read /var/log/wtmp, where as 'w' looks at the process that currently logged in users are running, reading /proc, which under the openwall patches is restricted. To limit 'who' you'd need a restricted /var/log/wtmp.. -- - U "Memory is like an orgasm. It's a lot better if you don't have to fake it." -- Seymour Cray commenting on virtual memory
Re[2]: kernel patches
Then they only have to compile their own version. Openwall shows only you when you run 'w' but shows everyone if you 'who'. Anyone know why? -- Kevin - [EMAIL PROTECTED] -- Original message -- > Am Freitag, 9. März 2001 23:40 schrieb Robert Mognet: >> Hello, >> >> On Wed, Mar 07, 2001 at 05:03:55PM +0100, Niklas H?glund wrote: >> > Hi! >> > Anyone know where I can find a kernel patch that restricts users so.. >> > 'who' shows only the user himself >> "who" is not a kernel function, it's a system utility. >> >> Something like this will work: >> alias who="me=`whoami`; who | grep $me" >> You could put it in /home/user/.bashrc ... > Brilliant idea. The user then does > unalias who > and the restrictions are gone. > The Openwall and LIDS Patches should provide some functionality to restrict > users from doing some things they are not supposed to. If one really needs a > system which is strongly tied up one maybe even has to change some utilities > to provide a different and more restrictive behaviour (i.e. who only > returning oneself, for example)
Re: kernel patches
Am Freitag, 9. März 2001 23:40 schrieb Robert Mognet: > Hello, > > On Wed, Mar 07, 2001 at 05:03:55PM +0100, Niklas H?glund wrote: > > Hi! > > Anyone know where I can find a kernel patch that restricts users so.. > > 'who' shows only the user himself > "who" is not a kernel function, it's a system utility. > > Something like this will work: > alias who="me=`whoami`; who | grep $me" > You could put it in /home/user/.bashrc ... Brilliant idea. The user then does unalias who and the restrictions are gone. The Openwall and LIDS Patches should provide some functionality to restrict users from doing some things they are not supposed to. If one really needs a system which is strongly tied up one maybe even has to change some utilities to provide a different and more restrictive behaviour (i.e. who only returning oneself, for example) -- Patrick Dreker - > Is there anything else I can contribute? The latitude and longtitude of the bios writers current position, and a ballistic missile. Alan Cox on linux-kernel@vger.kernel.org
Re: kernel patches
On Fri, Mar 09, 2001 at 05:40:03PM -0500, Robert Mognet wrote: > > Anyone know where I can find a kernel patch that restricts users so.. > > 'who' shows only the user himself > > "who" is not a kernel function, it's a system utility. That doesn't mean a kernel patch can't modify its behavior. Have you ever seen the Knark module in action? It's frightening. All filesystem, process listings, user listings, etc come straight from the kernel. With Knark you can modify any of it. You can hide users, files, processes and so on. You can even modify the behavior of executables without actually changing them (i.e. run 'ls' and suddently your system reboots itself...just as an example). Knark can also completely hide itself from tools like lsmod and rmmod, making it *impossible* to remove or detect (without rebooting to a trusted kernel). Not that this is directly on topic, and it's not what the original poster is looking for. I just wanted to let you know that on some level, everything calls kernel functions, and you can definitely modify their behavior. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpEB5sZPmZo9.pgp Description: PGP signature
Re: kernel patches
Hello, On Wed, Mar 07, 2001 at 05:03:55PM +0100, Niklas H?glund wrote: > Hi! > Anyone know where I can find a kernel patch that restricts users so.. > 'who' shows only the user himself "who" is not a kernel function, it's a system utility. Something like this will work: alias who="me=`whoami`; who | grep $me" You could put it in /home/user/.bashrc ... Regards, Robert > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 08:47:41AM -0400, Peter Cordes wrote: > Yes. It uses rp_filter (this is controlled in /proc/sys/... Read Also by: /etc/ipmasq/rules/I15lospoof.def if you have the ipmasq package installed: # deny and log all packets trying to come in from a 127.0.0.0/8 address # over a non-'lo' interface [snip] ipchains) $IPCHAINS -A input -j DENY -i !lo -s 127.0.0.1/255.0.0.0 -l ;; Btw, to the original poster: any rules said to apply to "2.1" kernels also apply to 2.2 kernels... not to worry. HTH.
Segfault in login
I don't know if this could be exploited is any way, but here's something that I've seen. This is on x86 on two machines and a ppc g3. #su #login login: ^D Segmentation fault Maybe you guys can check this more. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel patches
Am Samstag, 10. März 2001 00:05 schrieb Kevin: > Then they only have to compile their own version. Openwall shows only > you when you run 'w' but shows everyone if you 'who'. Anyone know > why? No experience with tools like this (LIDS/Openwall etc.) w and who are different binaries on my system, so they might use different ways of accessing the information. If users can actually compile their own stuff in a restricted environment there are many possibilities of circumventing restrictions. The only restrictions which are not easily circumvented are those imposed by the kernel and its components. -- Patrick Dreker - > Is there anything else I can contribute? The latitude and longtitude of the bios writers current position, and a ballistic missile. Alan Cox on [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re[2]: kernel patches
also sprach Kevin (on Fri, 09 Mar 2001 04:05:17PM -0700): > Then they only have to compile their own version. Openwall shows only > you when you run 'w' but shows everyone if you 'who'. Anyone know > why? well, afaik w and who are two separate programs. it appears that who uses utmp information whereas w collects its information from the /proc filesystem. martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck -- "declared guilty... of displaying feelings of an almost human nature." -- roger waters, 1979 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re[2]: kernel patches
On Fri, Mar 09, 2001 at 04:05:17PM -0700, Kevin wrote: > > > Then they only have to compile their own version. Openwall shows only > you when you run 'w' but shows everyone if you 'who'. Anyone know > why? > Because 'who' just read /var/log/wtmp, where as 'w' looks at the process that currently logged in users are running, reading /proc, which under the openwall patches is restricted. To limit 'who' you'd need a restricted /var/log/wtmp.. -- - U "Memory is like an orgasm. It's a lot better if you don't have to fake it." -- Seymour Cray commenting on virtual memory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re[2]: kernel patches
Then they only have to compile their own version. Openwall shows only you when you run 'w' but shows everyone if you 'who'. Anyone know why? -- Kevin - [EMAIL PROTECTED] -- Original message -- > Am Freitag, 9. März 2001 23:40 schrieb Robert Mognet: >> Hello, >> >> On Wed, Mar 07, 2001 at 05:03:55PM +0100, Niklas H?glund wrote: >> > Hi! >> > Anyone know where I can find a kernel patch that restricts users so.. >> > 'who' shows only the user himself >> "who" is not a kernel function, it's a system utility. >> >> Something like this will work: >> alias who="me=`whoami`; who | grep $me" >> You could put it in /home/user/.bashrc ... > Brilliant idea. The user then does > unalias who > and the restrictions are gone. > The Openwall and LIDS Patches should provide some functionality to restrict > users from doing some things they are not supposed to. If one really needs a > system which is strongly tied up one maybe even has to change some utilities > to provide a different and more restrictive behaviour (i.e. who only > returning oneself, for example) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel patches
Am Freitag, 9. März 2001 23:40 schrieb Robert Mognet: > Hello, > > On Wed, Mar 07, 2001 at 05:03:55PM +0100, Niklas H?glund wrote: > > Hi! > > Anyone know where I can find a kernel patch that restricts users so.. > > 'who' shows only the user himself > "who" is not a kernel function, it's a system utility. > > Something like this will work: > alias who="me=`whoami`; who | grep $me" > You could put it in /home/user/.bashrc ... Brilliant idea. The user then does unalias who and the restrictions are gone. The Openwall and LIDS Patches should provide some functionality to restrict users from doing some things they are not supposed to. If one really needs a system which is strongly tied up one maybe even has to change some utilities to provide a different and more restrictive behaviour (i.e. who only returning oneself, for example) -- Patrick Dreker - > Is there anything else I can contribute? The latitude and longtitude of the bios writers current position, and a ballistic missile. Alan Cox on [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel patches
On Fri, Mar 09, 2001 at 05:40:03PM -0500, Robert Mognet wrote: > > Anyone know where I can find a kernel patch that restricts users so.. > > 'who' shows only the user himself > > "who" is not a kernel function, it's a system utility. That doesn't mean a kernel patch can't modify its behavior. Have you ever seen the Knark module in action? It's frightening. All filesystem, process listings, user listings, etc come straight from the kernel. With Knark you can modify any of it. You can hide users, files, processes and so on. You can even modify the behavior of executables without actually changing them (i.e. run 'ls' and suddently your system reboots itself...just as an example). Knark can also completely hide itself from tools like lsmod and rmmod, making it *impossible* to remove or detect (without rebooting to a trusted kernel). Not that this is directly on topic, and it's not what the original poster is looking for. I just wanted to let you know that on some level, everything calls kernel functions, and you can definitely modify their behavior. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html PGP signature
Re: kernel patches
Hello, On Wed, Mar 07, 2001 at 05:03:55PM +0100, Niklas H?glund wrote: > Hi! > Anyone know where I can find a kernel patch that restricts users so.. > 'who' shows only the user himself "who" is not a kernel function, it's a system utility. Something like this will work: alias who="me=`whoami`; who | grep $me" You could put it in /home/user/.bashrc ... Regards, Robert > > -- > 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: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 08:47:41AM -0400, Peter Cordes wrote: > Yes. It uses rp_filter (this is controlled in /proc/sys/... Read Also by: /etc/ipmasq/rules/I15lospoof.def if you have the ipmasq package installed: # deny and log all packets trying to come in from a 127.0.0.0/8 address # over a non-'lo' interface [snip] ipchains) $IPCHAINS -A input -j DENY -i !lo -s 127.0.0.1/255.0.0.0 -l ;; Btw, to the original poster: any rules said to apply to "2.1" kernels also apply to 2.2 kernels... not to worry. HTH. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel patches
On Wed, 7 Mar 2001, [iso-8859-1] Niklas H?glund wrote: > Hi! > Anyone know where I can find a kernel patch that restricts users so.. > 'who' shows only the user himself > 'netstat -a' only ports that root/the user owns > 'ls' only files that are owned by root/the user > ?? > //Niklas Take a look at http://www.openwall.com/linux ... Here you find the kernel patches ( 2.2.18 is the latest ). A look at www.lids.org might be usefull too bye Faith
Re: 127.0.0.0/8 addresses from the network
-> > is debian protected beforeconnecting from remote hosts to address
-> > 127.0.0.0/8 ?
-> >
-> > how?
->
->
-> [amos]:~/# grep spoof-protect /etc/init.d/networking
-> if [ -e /etc/network/spoof-protect ]; then
-> . /etc/network/spoof-protect
->
-> [amos]:~/# grep 127.0.0.1 /etc/network/spoof-protect
-> LOCAL_IPS="127.0.0.1/8"
->
-> [amos]:~/# grep LOCAL_IPS /etc/init.d/networking -A4|tail -5
-> for ip in $LOCAL_IPS; do
-> ipchains -D input -j DENY -l -s $ip -i ! lo 2>/dev/null || true
-> ipchains -A input -j DENY -l -s 127.0.0.0/8 -i ! lo
-> done
well but this one is (according to the source) called only on 2.0 and 2.1
kernels.
I have kernel 2.2 and no ipchains rule in kernel set up
btw shouldn't ipchains stay BEFORE ipfwadm ? (afaik ipchains is newer then
ipfwadm)
spoofprotect () {
echo -n "Setting up IP spoofing protection: "
if spoofprotect_rp_filter; then
echo "rp_filter."
elif spoofprotect_ipfwadm; then
echo "ipfwadm."
elif spoofprotect_ipchains; then
echo "ipchains."
else
echo "FAILED"
fi
}
i runned this command:
up route add -net 127.0.0.0/8 dev lo
into /etc/network/interfaces into lo configl;
is that ok, isn't it superflous etc?
--
Matus "fantomas" Uhlar, sysadmin at NEXTRA, Slovakia; IRCNET admin of *.sk
[EMAIL PROTECTED] ; http://www.fantomas.sk/ ; http://www.nextra.sk/
Support bacteria - they're the only culture some people have.
Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 11:30:23AM +0100, Matus fantomas Uhlar wrote: > HEllo, > > is debian protected beforeconnecting from remote hosts to address > 127.0.0.0/8 ? > > how? Yes. It uses rp_filter (this is controlled in /proc/sys/... Read linux/Documentation/filesystems/proc.txt, in the kernel source tree.) Read /etc/init.d/networking to see what gets set up when you config networking. -- #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 BCE
Re: kernel patches
On Wed, 7 Mar 2001, [iso-8859-1] Niklas Höglund wrote: > Hi! > Anyone know where I can find a kernel patch that restricts users so.. > 'who' shows only the user himself > 'netstat -a' only ports that root/the user owns > 'ls' only files that are owned by root/the user > ?? > //Niklas Take a look at http://www.openwall.com/linux ... Here you find the kernel patches ( 2.2.18 is the latest ). A look at www.lids.org might be usefull too bye Faith -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
-> > is debian protected beforeconnecting from remote hosts to address
-> > 127.0.0.0/8 ?
-> >
-> > how?
->
->
-> [amos]:~/# grep spoof-protect /etc/init.d/networking
-> if [ -e /etc/network/spoof-protect ]; then
-> . /etc/network/spoof-protect
->
-> [amos]:~/# grep 127.0.0.1 /etc/network/spoof-protect
-> LOCAL_IPS="127.0.0.1/8"
->
-> [amos]:~/# grep LOCAL_IPS /etc/init.d/networking -A4|tail -5
-> for ip in $LOCAL_IPS; do
-> ipchains -D input -j DENY -l -s $ip -i ! lo 2>/dev/null || true
-> ipchains -A input -j DENY -l -s 127.0.0.0/8 -i ! lo
-> done
well but this one is (according to the source) called only on 2.0 and 2.1
kernels.
I have kernel 2.2 and no ipchains rule in kernel set up
btw shouldn't ipchains stay BEFORE ipfwadm ? (afaik ipchains is newer then
ipfwadm)
spoofprotect () {
echo -n "Setting up IP spoofing protection: "
if spoofprotect_rp_filter; then
echo "rp_filter."
elif spoofprotect_ipfwadm; then
echo "ipfwadm."
elif spoofprotect_ipchains; then
echo "ipchains."
else
echo "FAILED"
fi
}
i runned this command:
up route add -net 127.0.0.0/8 dev lo
into /etc/network/interfaces into lo configl;
is that ok, isn't it superflous etc?
--
Matus "fantomas" Uhlar, sysadmin at NEXTRA, Slovakia; IRCNET admin of *.sk
[EMAIL PROTECTED] ; http://www.fantomas.sk/ ; http://www.nextra.sk/
Support bacteria - they're the only culture some people have.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
On Fri, Mar 09, 2001 at 11:30:23AM +0100, Matus fantomas Uhlar wrote: > HEllo, > > is debian protected beforeconnecting from remote hosts to address > 127.0.0.0/8 ? > > how? Yes. It uses rp_filter (this is controlled in /proc/sys/... Read linux/Documentation/filesystems/proc.txt, in the kernel source tree.) Read /etc/init.d/networking to see what gets set up when you config networking. -- #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 BCE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
127.0.0.0/8 addresses from the network
HEllo, is debian protected beforeconnecting from remote hosts to address 127.0.0.0/8 ? how? -- Matus "fantomas" Uhlar, sysadmin at NEXTRA, Slovakia; IRCNET admin of *.sk [EMAIL PROTECTED] ; http://www.fantomas.sk/ ; http://www.nextra.sk/ If Barbie is so popular, why do you have to buy her friends?
Re: saft port
On Thu, Mar 08, 2001 at 09:07:01PM -0800, Alexander Hvostov wrote: > SAFT is a nifty little protocol that lets you send a file to some other > user on the internet without them having to explicitly accept it. Instead, > the SAFT server will receive the file and place it in a queue for access > later on. The protocol itself is quite new; an implementation is in the > `sendfile' package. I strongly suggest checking it out. > > This same thing, by the way, can also be done with email, with only one > small problem: most email servers will refuse emails exceeding a certain > (extremely conservative) size, making this protocol impractical for > transferring large files. If a site doesn't want to receive large files, they won't be running SAFT either. The only thing it appears to be useful for is bypassing the sender's ISP's mail limits, but if your ISP is that mean you should switch anyway. > On Thu, 8 Mar 2001, Kozman Balint wrote: > > what is the funny saft (487 - udp/tcp) port? Is that a possible security > > hole? It has had some issues... http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sendfile It's an unnecessary protocol; if you aren't using it, remove it. -- Colin Phippshttp://www.netcraft.com/
127.0.0.0/8 addresses from the network
HEllo, is debian protected beforeconnecting from remote hosts to address 127.0.0.0/8 ? how? -- Matus "fantomas" Uhlar, sysadmin at NEXTRA, Slovakia; IRCNET admin of *.sk [EMAIL PROTECTED] ; http://www.fantomas.sk/ ; http://www.nextra.sk/ If Barbie is so popular, why do you have to buy her friends? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: saft port
On Thu, Mar 08, 2001 at 09:07:01PM -0800, Alexander Hvostov wrote: > SAFT is a nifty little protocol that lets you send a file to some other > user on the internet without them having to explicitly accept it. Instead, > the SAFT server will receive the file and place it in a queue for access > later on. The protocol itself is quite new; an implementation is in the > `sendfile' package. I strongly suggest checking it out. > > This same thing, by the way, can also be done with email, with only one > small problem: most email servers will refuse emails exceeding a certain > (extremely conservative) size, making this protocol impractical for > transferring large files. If a site doesn't want to receive large files, they won't be running SAFT either. The only thing it appears to be useful for is bypassing the sender's ISP's mail limits, but if your ISP is that mean you should switch anyway. > On Thu, 8 Mar 2001, Kozman Balint wrote: > > what is the funny saft (487 - udp/tcp) port? Is that a possible security > > hole? It has had some issues... http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sendfile It's an unnecessary protocol; if you aren't using it, remove it. -- Colin Phippshttp://www.netcraft.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
