Fw: Can a daemon listen only on some interfaces?
grr...forgot to reply to list... - Original Message - From: Phillip Hofmeister <[EMAIL PROTECTED]> To: Guido Hennecke <[EMAIL PROTECTED]> Sent: Saturday, December 08, 2001 3:10 PM Subject: Re: Can a daemon listen only on some interfaces? > ORyou could use IPCHAINS or IPTABLES to REJECT (or DENY) the interface > on that port > - Original Message - > From: Guido Hennecke <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: Michael Wood <[EMAIL PROTECTED]> > Sent: Saturday, December 08, 2001 2:09 PM > Subject: Re: Can a daemon listen only on some interfaces? > > > > At 08.12.2001, Michael Wood wrote: > > > On Sat, Dec 08, 2001 at 07:40:06PM +1000, [EMAIL PROTECTED] wrote: > > [...] > > > > So my question is: > > > > Is there some way to make certain daemons, (say postfix) > > > > listen only on some interfaces? For example, I have > > > > everything firewalled from outside, so I really only need > > > > postfix to listen on the loopback interface for local > > > > connections. Is this possible? > > > It's technically possible, but this depends on if the particular > > > daemon has support for this. Postfix does. > > > > It is a little bit different on Linux: > > > > It is not possible to configure a deamon to listen on an interface only. > > It is only possible to bind it to an ip address. > > > > The problem on linux is, that all local ip addresses are reachable over > > all local interfaces. The only problem is the routing and that depends > > on your infrastructure. > > > > But it is posible to use a packetfilter and configure it, that packets > > for an interface must come in over the target interface. > > > > Regards, Guido > > -- > > Nur weil Du paranoid bist, heisst das noch lange nicht, dass Du nicht > > verfolgt wirst. > > > > > > -- > > 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]
Fw: Can a daemon listen only on some interfaces?
grr...forgot to reply to list... - Original Message - From: Phillip Hofmeister <[EMAIL PROTECTED]> To: Guido Hennecke <[EMAIL PROTECTED]> Sent: Saturday, December 08, 2001 3:10 PM Subject: Re: Can a daemon listen only on some interfaces? > ORyou could use IPCHAINS or IPTABLES to REJECT (or DENY) the interface > on that port > - Original Message - > From: Guido Hennecke <[EMAIL PROTECTED]> > To: > Cc: Michael Wood <[EMAIL PROTECTED]> > Sent: Saturday, December 08, 2001 2:09 PM > Subject: Re: Can a daemon listen only on some interfaces? > > > > At 08.12.2001, Michael Wood wrote: > > > On Sat, Dec 08, 2001 at 07:40:06PM +1000, [EMAIL PROTECTED] wrote: > > [...] > > > > So my question is: > > > > Is there some way to make certain daemons, (say postfix) > > > > listen only on some interfaces? For example, I have > > > > everything firewalled from outside, so I really only need > > > > postfix to listen on the loopback interface for local > > > > connections. Is this possible? > > > It's technically possible, but this depends on if the particular > > > daemon has support for this. Postfix does. > > > > It is a little bit different on Linux: > > > > It is not possible to configure a deamon to listen on an interface only. > > It is only possible to bind it to an ip address. > > > > The problem on linux is, that all local ip addresses are reachable over > > all local interfaces. The only problem is the routing and that depends > > on your infrastructure. > > > > But it is posible to use a packetfilter and configure it, that packets > > for an interface must come in over the target interface. > > > > Regards, Guido > > -- > > Nur weil Du paranoid bist, heisst das noch lange nicht, dass Du nicht > > verfolgt wirst. > > > > > > -- > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > > > > > > >
Re: Fw: Can a daemon listen only on some interfaces?
On Sat, Dec 08, 2001 at 11:57:51PM +0100, Guido Hennecke wrote: > At 08.12.2001, Phillip Hofmeister wrote: > > grr...forgot to reply to list... > > It was not necessary because... > > > From: Phillip Hofmeister <[EMAIL PROTECTED]> > > > ORyou could use IPCHAINS or IPTABLES to REJECT (or DENY) the interface > > > on that port > > > > From: Guido Hennecke <[EMAIL PROTECTED]> > [...] > > > > But it is posible to use a packetfilter and configure it, that packets > > > > for an interface must come in over the target interface. > > Your quoting sucks! > OK, now now - no fighting. I do already have a packet filtering firewall (iptables) and everything is blocked from the internet side except ssh. I did mention this in my first post. I was just trying to go the extra mile in terms of security by making sure everything unnecessary was turned off and those that were necessary were only listening on the interfaces I need them to. And thanks for all the replies. In fact I was most interested to hear that you could not make daemons listen on only one interface but you could make them bind to an IP address range. I guess that is what I achieved in my postfix main.cf file with the line: inet_interfaces = localhost Cheers. Mark. msg04696/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Sun, 09 Dec 2001, Guido Hennecke wrote: > 127.0.0.1 GatewayInterface externel interface> > > he can reach your service bound to 127.0.0.1. And this without > activating ip_forward on your computer! Is this true even if the policy of the forward chain (for ipchains) is set to deny ? (and the equivalent, for iptables) ? If it is so, at least the ipmasq package needs an update to take that into account... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
- Original Message - From: Guido Hennecke <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, December 09, 2001 8:14 AM Subject: Re: Fw: Can a daemon listen only on some interfaces? > At 09.12.2001, [EMAIL PROTECTED] wrote: > [...] > > And thanks for all the replies. In fact I was most interested to hear > > that you could not make daemons listen on only one interface but you > > could make them bind to an IP address range. I guess that is what I > > achieved in my postfix main.cf file with the line: > > inet_interfaces = localhost > > Yes, if you take a look with "netstat -ln | grep 25" you will see > something like that: > > tcp0 0 127.0.0.1:25 0.0.0.0:*LISTEN > > This means, that the service is listening on 127.0.0.1. The Interface is > "lo". If an attacker in the same network sets a route like that: > > 127.0.0.1 GatewayInterface externel interface> Couldn't this be countered with: ipchains -i !lo -d 127.0.0.1 -j DENY ? Phil > > he can reach your service bound to 127.0.0.1. And this without > activating ip_forward on your computer! > > This is easy to circumvent with ipchains or iptables. > > Regards, Guido > > > -- > 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: Fw: Can a daemon listen only on some interfaces?
"Phillip Hofmeister" <[EMAIL PROTECTED]> writes: [snip] > > If an attacker in the same network sets a route like that: > > > > 127.0.0.1 GatewayInterface > externel interface> > Couldn't this be countered with: > ipchains -i !lo -d 127.0.0.1 -j DENY > ? Better, iptables -A INPUT -m state --state INVALID -j LOG iptables -A INPUT -m state --state INVALID -j DROP (and OUTPUT as well, for those paranoid enough to do egress filtering). Also, echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter withecho 1 > /proc/sys/net/ipv4/conf/*/log_martians for logging/fun purposes. ~Tim -- Another day,|[EMAIL PROTECTED] Another kernel recompile|http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
On Sun, 09 Dec 2001, Guido Hennecke wrote: > At 09.12.2001, Henrique de Moraes Holschuh wrote: > > On Sun, 09 Dec 2001, Guido Hennecke wrote: > > > 127.0.0.1 GatewayInterface > > externel interface> > > > > > > he can reach your service bound to 127.0.0.1. And this without > > > activating ip_forward on your computer! > > Is this true even if the policy of the forward chain (for ipchains) is set > > to deny ? (and the equivalent, for iptables) ? > > Those packets did not go throught the forwards chain. For local > interfaces no routing is needed. If they came over the network, they should have. That is a broken behaviour (breaks principle of less surprise, at the very least). Well, ipmasq needs an update to trash anything incoming and outgoing from !lo with a destination of 127.0.0.1/8 then. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, 10 Dec 2001, Guido Hennecke wrote: > All packets come over the network an want to go to an ip address a local > interface is bound to, will not be routed to come to that interface. > Thats the problem. Indeed. > > Well, ipmasq needs an update to trash anything incoming and outgoing from > > !lo with a destination of 127.0.0.1/8 then. > > Well, ipmasq has nothing to do with that. ip masquerading might not. The Debian ipmasq package is a firewall, and one that attempts to explicitly avoid stuff like that, so it should be fixed to deal with the lo problem. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
On Sun, Dec 09, 2001 at 07:45:52PM +0100, Guido Hennecke wrote: > Please dont answer to the list _and_ to me. Thank you. > > At 09.12.2001, Tim Haynes wrote: > > "Phillip Hofmeister" <[EMAIL PROTECTED]> writes: > > [snip] > > > > If an attacker in the same network sets a route like that: > > > > > > > > 127.0.0.1 GatewayInterface > > > externel interface> > > > Couldn't this be countered with: > > > ipchains -i !lo -d 127.0.0.1 -j DENY > > > ? > > Better, > > iptables -A INPUT -m state --state INVALID -j LOG > > iptables -A INPUT -m state --state INVALID -j DROP > > (and OUTPUT as well, for those paranoid enough to do egress filtering). > > > > Also, > > echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter > > withecho 1 > /proc/sys/net/ipv4/conf/*/log_martians > > for logging/fun purposes. > > rp_filter will not help with that. > OK, you guys have started to confuse me a little just when I thought I was getting a handle on this firewalling stuff. Now, please explain what an attacker would do in your example above. Do you mean the following?: 1. The attacker (on your LAN) alters his routing table so that all packets destined for 127.0.0.1 go to your official IP address via his LAN interface. ie. something like: # route add -net 127.0.0.0 gw 192.168.1.1 eth0 (Where 192.168.1.1 is the address of your firewall box running ssh - which you are trying to prevent the attacker from logging into.) 2. Then when he does ssh into 127.0.0.1 Is that what you meant? Would that mean that your firewall box (running ssh) would see the packets as coming from source 192.168.1.2 (the attacker's IP address on the LAN) and going to destination 127.0.0.1 (local)? Then the sshd daemon would see the connection attempt as seeming to be a local connection (127.0.0.1). If I have got the reasoning correct, then I can see the problem. It would seem easy to do this from the LAN, but I don't think possible from the internet - since packets with destination 127.0.0.1 would not get routed. Second question: Why does the state INVALID match match these packets. Are they flagged as invalid because they have come in from eth0 but with a destination of 127.0.0.1 (which should be impossible)? Thanks to anyone who can make this a little clearer. Cheers. Mark. msg04724/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: > I try to explain again: > > You have a Linux box with "eth0" and "eth1". "eth0" is the Internet > interface, "eth1" is the interface to the LAN. > > IP addresses: eth0 - 123.123.123.123 > eth1 - 192.168.0.1 > > You want remote access from your LAN to the Linux Box with ssh. So you > bind the sshd to 192.168.0.1 and think, now the sshd is only reachable > from your LAN. > > The atacker is client at the same provider than you are and in the same > network segment (sorry for my english!). > > The atacker sets a route like this: > > route add 192.168.0.1 gw 123.123.123.123 > > And now "ssh 192.168.0.1" will work without routing on _your_ box > activated. So the FORWARD chain from ipchains will not work for that. OK I just tried something similar. Here is what I just did: 1. First to prove that I can indeed ssh in on loopback I did: ssh 127.0.0.1 ---> worked OK 2. I added a route for my LAN IP address (192.168.0.2) via loopback route add 192.168.0.2 gw 127.0.0.1 3. Then I edited /etc/ssh/sshd_config and changed the IP addresses that sshd will bind to so that it only binds to 192.168.0.2 ListenAddress 192.168.0.2 4. Then told sshd to reload its config /etc/init.d/ssh reload 5. Then tried to ssh in on loopback again (should now refuse). ssh 127.0.0.1 ---> Secure connection to 127.0.0.1 refused 6. Then tried to ssh in on 192.168.0.2 (should work) ssh 192.168.0.2---> ssh_exchange_identification: Connection closed by remote host What is the go here? From what you were saying above, No 6. should have worked, right? > > > Second question: > > Why does the state INVALID match match these packets. Are they flagged > > as invalid because they have come in from eth0 but with a destination of > > 127.0.0.1 (which should be impossible)? > > I don't know. I am not very experianced with iptables. > Also, my firewall (iptables) which does have the following rules: iptables -A INPUT -m state --state INVALID -j LOG iptables -A INPUT -m state --state INVALID -j DROP Did not log anything during this experiment. So I still not sure about the state INVALID match for these packets. Can you explain why the above test did not work? Cheers. Mark. msg04725/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 01:52:51PM +1000, mdevin wrote: > On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: > > I try to explain again: > > > > You have a Linux box with "eth0" and "eth1". "eth0" is the Internet > > interface, "eth1" is the interface to the LAN. > > > > IP addresses: eth0 - 123.123.123.123 > > eth1 - 192.168.0.1 > > > > You want remote access from your LAN to the Linux Box with ssh. So you > > bind the sshd to 192.168.0.1 and think, now the sshd is only reachable > > from your LAN. > > > > The atacker is client at the same provider than you are and in the same > > network segment (sorry for my english!). > > > > The atacker sets a route like this: > > > > route add 192.168.0.1 gw 123.123.123.123 > > > > And now "ssh 192.168.0.1" will work without routing on _your_ box > > activated. So the FORWARD chain from ipchains will not work for that. > > OK I just tried something similar. Here is what I just did: > 1. First to prove that I can indeed ssh in on loopback I did: > ssh 127.0.0.1 ---> worked OK > 2. I added a route for my LAN IP address (192.168.0.2) via loopback > route add 192.168.0.2 gw 127.0.0.1 > 3. Then I edited /etc/ssh/sshd_config and changed the IP addresses that > sshd will bind to so that it only binds to 192.168.0.2 > ListenAddress 192.168.0.2 > 4. Then told sshd to reload its config > /etc/init.d/ssh reload > 5. Then tried to ssh in on loopback again (should now refuse). > ssh 127.0.0.1 ---> Secure connection to 127.0.0.1 refused > 6. Then tried to ssh in on 192.168.0.2 (should work) > ssh 192.168.0.2---> ssh_exchange_identification: Connection closed > by remote host > > What is the go here? From what you were saying above, No 6. should have > worked, right? Whoops. It does actually work sorry. I forgot that my /etc/hosts.deny file had this in it: ALL: PARANOID After commenting this out, things worked for No 6. above which goes to show that what you were saying works exactly as you said. Thanks for pointing this out, it has really edemucated (sic) me. > > > > > Second question: > > > Why does the state INVALID match match these packets. Are they flagged > > > as invalid because they have come in from eth0 but with a destination of > > > 127.0.0.1 (which should be impossible)? > > > > I don't know. I am not very experianced with iptables. > > > Also, my firewall (iptables) which does have the following rules: > iptables -A INPUT -m state --state INVALID -j LOG > iptables -A INPUT -m state --state INVALID -j DROP > > Did not log anything during this experiment. Now after proving that it does actually work, still nothing was logged by my firewall despite exactly the above iptables rules right at the head of my INPUT chain. Thus I can only conclude that the state INVALID match does not stop this sort of thing. Please someone refute this if I am wrong. Cheers. Mark. msg04726/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: > With ipchains you can make the following: > > ipchains -A input -i ! eth1 -d 192.168.0.1 -j DENY What this says is: all packets with destination 192.168.0.1 must not have come from eth1 or they will be denied. Why do you choose to specify the rule this way and not like this: ipchains -A input -i eth0 ! -d 192.168.0.1 -j DENY In other words: all packets coming from eth0 must have destination 192.168.0.1 or they will be denied? Please explain. Is it because you may later want to put your ethernet card into promiscuous mode and thus receive packets with any destination as if they were for you? My rule above would prevent this whereas your rule would not. Both rules would prevent the attacker trying to circumvent the sshd bound IP address restriction however. Can you explain why you choose your rule. Cheers. Mark. msg04727/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, 2001-12-10 at 08:19, mdevin wrote: > On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: > > With ipchains you can make the following: > > > > ipchains -A input -i ! eth1 -d 192.168.0.1 -j DENY > > What this says is: all packets with destination 192.168.0.1 must not > have come from eth1 or they will be denied. > > Why do you choose to specify the rule this way and not like this: > ipchains -A input -i eth0 ! -d 192.168.0.1 -j DENY > In other words: all packets coming from eth0 must have destination > 192.168.0.1 or they will be denied? I'm not the original author, but I use ! too. Using ! would break ip forwarding. If your box is a gateway/router/firewall, it will drop all packets not destined for 192.168.0.1 (itself). > > Please explain. Is it because you may later want to put your ethernet > card into promiscuous mode and thus receive packets with any destination > as if they were for you? My rule above would prevent this whereas your > rule would not. Both rules would prevent the attacker trying to > circumvent the sshd bound IP address restriction however. > > Can you explain why you choose your rule. > > Cheers. > Mark. -- Berend De Schouwer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
On Sun, Dec 09, 2001 at 07:45:52PM +0100, Guido Hennecke wrote: > At 09.12.2001, Tim Haynes wrote: > > echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter > > withecho 1 > /proc/sys/net/ipv4/conf/*/log_martians > > for logging/fun purposes. > > rp_filter will not help with that. I thought that rp_filter was for precisely this. Doesn't it stop packets which appear on interfaces with invalid IP addresses for that interface from getting through? Plato -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
Plato <[EMAIL PROTECTED]> writes: > > > echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter > > > withecho 1 > /proc/sys/net/ipv4/conf/*/log_martians > > > for logging/fun purposes. > > > > rp_filter will not help with that. > > I thought that rp_filter was for precisely this. Doesn't it stop packets > which appear on interfaces with invalid IP addresses for that interface > from getting through? It's a return-path filter; if flipping the src/dest IP#s wouldn't send it back out the same interface, it doesn't come in at all. So a specially routed packet from a.b.c.d -> 127.0.0.1 coming in on eth0 becomes a packet from 127.0.0.1 -> a.b.c.d going back out That certainly looks wrong to me, although I'm not /sure/ it would produce the required interface conflict for rp_filter. ~Tim -- We're just souls across a |[EMAIL PROTECTED] shrinking world |http://spodzone.org.uk/ In a distant starlit night | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 09:31:09AM +0200, Berend De Schouwer wrote: > On Mon, 2001-12-10 at 08:19, mdevin wrote: > > On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: > > > With ipchains you can make the following: > > > > > > ipchains -A input -i ! eth1 -d 192.168.0.1 -j DENY > > > > What this says is: all packets with destination 192.168.0.1 must not > > have come from eth1 or they will be denied. > > > > Why do you choose to specify the rule this way and not like this: > > ipchains -A input -i eth0 ! -d 192.168.0.1 -j DENY > > In other words: all packets coming from eth0 must have destination > > 192.168.0.1 or they will be denied? > > I'm not the original author, but I use ! too. > > Using ! would break ip forwarding. If your box is a > gateway/router/firewall, it will drop all packets not destined for > 192.168.0.1 (itself). > > OK, I see the problem. However, I think this only applies to ipchains where forwarded packets traverse the input and output chains. Sorry, I was transposing my thoughts into ipchains rules. Actually my firewall is iptables based. In iptables, packets that are being masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT chains. Thus if the rule was: iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP this should be OK I guess. Since packets on the INPUT are destined only to localhost. All packets that need to be forwarded will traverse only the FORWARD chain and thus will not be checked against this rule. Thus on an iptables based firewall is there a preferance for which is the better approach? It is just that I came up with the rule above because it seemed more straightforward. In other words: If the packet came from interface eth0 and it is directed to localhost (INPUT chain) then it must have destination address 192.168.0.1 or we will DROP it. And you can make similar rules for every interface the firewall has. But I guess the same applies for the ipchains rule you use. It is just that the primary focus is on the IP address of each interface rather than the interface itself. The more I think about it, it doesn't seem to matter in iptables, unless you are putting your ethernet card into promiscuous mode or something. 'Cause then I guess you would see lots of packets not addressed to you coming in your INPUT chain. Then that iptables rule would DROP them all unless they were specifically addressed to you, whereas if I used your style of rule then other packets not addressed to my box directly would still get through. I don't know anything about ethernet cards in promiscuous mode - so not sure about this. What do you think? And thanks for highlighting that ipchains difference, I had forgotten about that. Since January, I have only been using iptables. Cheers. Mark. msg04734/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
Guido Hennecke <[EMAIL PROTECTED]> writes: > > Sorry, I was transposing my thoughts into ipchains rules. Actually my > > firewall is iptables based. In iptables, packets that are being > > masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT > > chains. Thus if the rule was: > > iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP > > this should be OK I guess. Since packets on the INPUT are destined only > > to localhost. > > Pakets came from the externel interface from a ip address from this > externel network will be masqeraded? I think the will not! I've got a problem with this, btw. Increasingly, I'm needing FORWARDING rules on various sites; what I want to know is, when I've got the following layout: | #Chain for incoming/forwarding filtering | iptables -N block | #chain to drop & log stuff | iptables -N DLOG | ... | several `block' rules incl stateful allowing ESTABLISHED,RELATED | ... | ## Jump to that chain from INPUT and FORWARD chains. | iptables -A INPUT -j block | iptables -A FORWARD -j block how come packets still seem to get dropped when being forwarded between interfaces? (If this isn't the place for this question, point me at a *decent* bit of documentation by all means! (With emphasis on `decent', as in something that explains and details simultaneously.)) ~Tim -- 12:51:17 up 33 days, 14:46, 17 users, load average: 0.15, 0.18, 0.17 [EMAIL PROTECTED] |And your radiance shines http://piglet.is.dreaming.org |Like the moon of all innocent grace -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 12:22:44PM +, Tim Haynes wrote: > Plato <[EMAIL PROTECTED]> writes: > > > > > echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter > > > > withecho 1 > /proc/sys/net/ipv4/conf/*/log_martians > > > > for logging/fun purposes. > > > > > > rp_filter will not help with that. > > > > I thought that rp_filter was for precisely this. Doesn't it stop packets > > which appear on interfaces with invalid IP addresses for that interface > > from getting through? > > It's a return-path filter; if flipping the src/dest IP#s wouldn't send it > back out the same interface, it doesn't come in at all. > > So a specially routed packet from a.b.c.d -> 127.0.0.1 coming in on eth0 > becomes a packet from 127.0.0.1 -> a.b.c.d going back out > > That certainly looks wrong to me, although I'm not /sure/ it would produce > the required interface conflict for rp_filter. > Hmmm. I don't know. On the test I ran in another part of this thread where I put a rule into my routing table to make packets destined for 192.168.0.2 get sent via loopback. Then made sshd bind to address 192.168.0.2. Then I was able to ssh into my box via the loopback interface by doing this: ssh 192.168.0.2 Even though: ssh 127.0.0.1 was refused. All this was done while my iptables firewall was loaded and it does have the following in it: # Enable IP spoofing protection - turn on Source Address Verification for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done # Log Spoofed Packets, Source Routed Packets, Redirect Packets for f in /proc/sys/net/ipv4/conf/*/log_martians; do echo 1 > $f done However, the difference is that the packets that were being sent actually have destination address 192.168.0.2 and source address 192.168.0.2. And this didn't cause any problem for the return path filter. Whereas it might if it was trying to send back packets with a source of 127.0.0.1 and a destination of a.b.c.d. I can't test this at present since I don't have another computer I can network with this one for a couple of days. But a test could be run similar to the one I did earlier to check. Cheers. Mark. msg04736/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 12:54:31PM +, Tim Haynes wrote: > Guido Hennecke <[EMAIL PROTECTED]> writes: > > > > Sorry, I was transposing my thoughts into ipchains rules. Actually my > > > firewall is iptables based. In iptables, packets that are being > > > masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT > > > chains. Thus if the rule was: > > > iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP > > > this should be OK I guess. Since packets on the INPUT are destined only > > > to localhost. > > > > Pakets came from the externel interface from a ip address from this > > externel network will be masqeraded? I think the will not! > > I've got a problem with this, btw. Increasingly, I'm needing FORWARDING > rules on various sites; what I want to know is, when I've got the following > layout: > > | #Chain for incoming/forwarding filtering > | iptables -N block > | #chain to drop & log stuff > | iptables -N DLOG > | ... > | several `block' rules incl stateful allowing ESTABLISHED,RELATED > | ... > | ## Jump to that chain from INPUT and FORWARD chains. > | iptables -A INPUT -j block > | iptables -A FORWARD -j block > > how come packets still seem to get dropped when being forwarded between > interfaces? > I am not sure I have totall gotten what you are trying to do here. But, the packets will be dropped instead of being forwarded between interfaces because that is exactly what you have specified in your rules. What happens is this: 1. A packet comes in through one of your interfaces. 2. It hits the PREROUTING chain - where DNAT can occur or any tracked connections are de-SNATted or de-MASQUERADED. 3. Routing decision is made. Here is where the decision is made whether the packet is destined for localhost or to go out another interface. 4a. If the packet is destined for localhost then it traverses the INPUT chain. 4b. If the packet is for another host then it traverses the FORWARD chain. Thus what your rules will do is: Any packet not destined for localhost will traverse the FORWARD chain and will be -j (jumpped) to your block (user defined) chain. This will presumably LOG and the DROP the packets. Thus all your FORWARDED packets will be DROPPED. This is of course only if you don't have other rules in your FORWARD chain which explicitly ACCEPT the packets before they hit the FORWARD chain rule you have written above. HTH. Cheers. Mark. msg04737/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
mdevin <[EMAIL PROTECTED]> writes: [snip firewall overview] > > how come packets still seem to get dropped when being forwarded between > > interfaces? > > I am not sure I have totall gotten what you are trying to do here. But, > the packets will be dropped instead of being forwarded between interfaces > because that is exactly what you have specified in your rules. > > What happens is this: > 1. A packet comes in through one of your interfaces. > 2. It hits the PREROUTING chain - where DNAT can occur or any tracked > connections are de-SNATted or de-MASQUERADED. > 3. Routing decision is made. Here is where the decision is made whether > the packet is destined for localhost or to go out another interface. > 4a. If the packet is destined for localhost then it traverses the INPUT > chain. > 4b. If the packet is for another host then it traverses the FORWARD > chain. Righty. That's much as I expected. > Thus what your rules will do is: > Any packet not destined for localhost will traverse the FORWARD chain > and will be -j (jumpped) to your block (user defined) chain. This will > presumably LOG and the DROP the packets. Thus all your FORWARDED > packets will be DROPPED. Ultimately, I want input & forward to be drop-by-default. However, the `block' chain is meant to be good for both input & forward scenarios; it has rules for stateful filtering and `open' things, then a drop & log. If I put in a rule matching -i and/or -o as appropriate, it still doesn't seem to work. Maybe I've done something wrong (and I don't really want to post ork's firewall in any more detail). > This is of course only if you don't have other rules in your FORWARD > chain which explicitly ACCEPT the packets before they hit the FORWARD > chain rule you have written above. What about if I kick *all* packets from forward onto `block', though? That's the bit I'm not wholly happy about. ~Tim -- A spark of life |[EMAIL PROTECTED] On a wire from heaven |http://spodzone.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 10:55:07PM +1000, mdevin wrote: > On Mon, Dec 10, 2001 at 12:22:44PM +, Tim Haynes wrote: > > Plato <[EMAIL PROTECTED]> writes: > > > > > > > echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter > > > > > withecho 1 > /proc/sys/net/ipv4/conf/*/log_martians > > > > > for logging/fun purposes. > > > > > > > > rp_filter will not help with that. > > > > > > I thought that rp_filter was for precisely this. Doesn't it stop packets > > > which appear on interfaces with invalid IP addresses for that interface > > > from getting through? > > > > It's a return-path filter; if flipping the src/dest IP#s wouldn't send it > > back out the same interface, it doesn't come in at all. > > > > So a specially routed packet from a.b.c.d -> 127.0.0.1 coming in on eth0 > > becomes a packet from 127.0.0.1 -> a.b.c.d going back out > > > > That certainly looks wrong to me, although I'm not /sure/ it would produce > > the required interface conflict for rp_filter. > > > > Hmmm. I don't know. > > On the test I ran in another part of this thread > where I put a rule into my routing table to make packets destined for > 192.168.0.2 get sent via loopback. Then made sshd bind to address > 192.168.0.2. Then I was able to ssh into my box via the loopback > interface by doing this: ssh 192.168.0.2 Even though: ssh 127.0.0.1 was > refused. > > All this was done while my iptables firewall was loaded and it does have > the following in it: > # Enable IP spoofing protection - turn on Source Address Verification > for f in /proc/sys/net/ipv4/conf/*/rp_filter; do > echo 1 > $f > done > # Log Spoofed Packets, Source Routed Packets, Redirect Packets > for f in /proc/sys/net/ipv4/conf/*/log_martians; do > echo 1 > $f > done > > However, the difference is that the packets that were being sent > actually have destination address 192.168.0.2 and source address > 192.168.0.2. And this didn't cause any problem for the return path > filter. Whereas it might if it was trying to send back packets with a > source of 127.0.0.1 and a destination of a.b.c.d. > > I can't test this at present since I don't have another computer I can > network with this one for a couple of days. But a test could be run > similar to the one I did earlier to check. No. On reading another post by Guido, this seems to do only what I have written in the comments above. ie. turn on Source Address Verification. It hasn't got anything to do with destination addresses. Cheers. Mark. msg04739/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 01:21:15PM +, Tim Haynes wrote: > Ultimately, I want input & forward to be drop-by-default. However, the > `block' chain is meant to be good for both input & forward scenarios; it > has rules for stateful filtering and `open' things, then a drop & log. If I > put in a rule matching -i and/or -o as appropriate, it still doesn't seem > to work. Maybe I've done something wrong (and I don't really want to post > ork's firewall in any more detail). > > What about if I kick *all* packets from forward onto `block', though? > That's the bit I'm not wholly happy about. > I think you are better to break your rules up into separate connection orientated rulesets. I will reply off list with more details as this is getting a little off topic now. Cheers. Mark. msg04740/pgp0.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message <20011209210331.A24517@khazad-dum>, Henrique de Moraes Holschuh writ es: >On Sun, 09 Dec 2001, Guido Hennecke wrote: >> At 09.12.2001, Henrique de Moraes Holschuh wrote: >> > On Sun, 09 Dec 2001, Guido Hennecke wrote: >> > > 127.0.0.1 GatewayInterface > > > externel interface> >> > > >> > > he can reach your service bound to 127.0.0.1. And this without >> > > activating ip_forward on your computer! >> > Is this true even if the policy of the forward chain (for ipchains) is set >> > to deny ? (and the equivalent, for iptables) ? >> >> Those packets did not go throught the forwards chain. For local >> interfaces no routing is needed. > >If they came over the network, they should have. That is a broken behaviour >(breaks principle of less surprise, at the very least). > >Well, ipmasq needs an update to trash anything incoming and outgoing from >!lo with a destination of 127.0.0.1/8 then. It already does this. Check out /etc/ipmasq/rules/I15lospoof.def. It also blocks and logs packets coming from external interfaces claiming to be from an internal address in the /etc/ipmasq/rules/I70masq.def file. The ipmasq firewall is very careful about blocking these sorts of attacks. The only change I make to its default operation is to lock down the external interface. - -- 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 iD8DBQE8FO+BoayJfLoDSdIRAgxhAKCYYeJrtaUAtbbeGowq1hBE2GyaCACgkKhf gmdv3uF0kXlJkN2V/gukl9k= =bm4W -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
Greetings! > > At 09.12.2001, [EMAIL PROTECTED] wrote: > > [...] > > > And thanks for all the replies. In fact I was most interested to hear > > > that you could not make daemons listen on only one interface but you > > > could make them bind to an IP address range. I guess that is what I > > > achieved in my postfix main.cf file with the line: > > > inet_interfaces = localhost If using the meta-daemon XINETD instead of INETD you can specify the interface (= bind) option where you can specify on which interface the service should listen only. See man xinetd.conf HTH Volker -- Volker Tanger [EMAIL PROTECTED] -===- Research & Development Division, WYAE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Can a daemon listen only on some interfaces?
On Sat, Dec 08, 2001 at 11:57:51PM +0100, Guido Hennecke wrote: > At 08.12.2001, Phillip Hofmeister wrote: > > grr...forgot to reply to list... > > It was not necessary because... > > > From: Phillip Hofmeister <[EMAIL PROTECTED]> > > > ORyou could use IPCHAINS or IPTABLES to REJECT (or DENY) the interface > > > on that port > > > > From: Guido Hennecke <[EMAIL PROTECTED]> > [...] > > > > But it is posible to use a packetfilter and configure it, that packets > > > > for an interface must come in over the target interface. > > Your quoting sucks! > OK, now now - no fighting. I do already have a packet filtering firewall (iptables) and everything is blocked from the internet side except ssh. I did mention this in my first post. I was just trying to go the extra mile in terms of security by making sure everything unnecessary was turned off and those that were necessary were only listening on the interfaces I need them to. And thanks for all the replies. In fact I was most interested to hear that you could not make daemons listen on only one interface but you could make them bind to an IP address range. I guess that is what I achieved in my postfix main.cf file with the line: inet_interfaces = localhost Cheers. Mark. pgpNTDgyJNJks.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Sun, 09 Dec 2001, Guido Hennecke wrote: > 127.0.0.1 GatewayInterface externel interface> > > he can reach your service bound to 127.0.0.1. And this without > activating ip_forward on your computer! Is this true even if the policy of the forward chain (for ipchains) is set to deny ? (and the equivalent, for iptables) ? If it is so, at least the ipmasq package needs an update to take that into account... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Fw: Can a daemon listen only on some interfaces?
- Original Message - From: Guido Hennecke <[EMAIL PROTECTED]> To: Sent: Sunday, December 09, 2001 8:14 AM Subject: Re: Fw: Can a daemon listen only on some interfaces? > At 09.12.2001, [EMAIL PROTECTED] wrote: > [...] > > And thanks for all the replies. In fact I was most interested to hear > > that you could not make daemons listen on only one interface but you > > could make them bind to an IP address range. I guess that is what I > > achieved in my postfix main.cf file with the line: > > inet_interfaces = localhost > > Yes, if you take a look with "netstat -ln | grep 25" you will see > something like that: > > tcp0 0 127.0.0.1:25 0.0.0.0:*LISTEN > > This means, that the service is listening on 127.0.0.1. The Interface is > "lo". If an attacker in the same network sets a route like that: > > 127.0.0.1 GatewayInterface externel interface> Couldn't this be countered with: ipchains -i !lo -d 127.0.0.1 -j DENY ? Phil > > he can reach your service bound to 127.0.0.1. And this without > activating ip_forward on your computer! > > This is easy to circumvent with ipchains or iptables. > > Regards, Guido > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > >
Re: Fw: Can a daemon listen only on some interfaces?
"Phillip Hofmeister" <[EMAIL PROTECTED]> writes: [snip] > > If an attacker in the same network sets a route like that: > > > > 127.0.0.1 GatewayInterface > externel interface> > Couldn't this be countered with: > ipchains -i !lo -d 127.0.0.1 -j DENY > ? Better, iptables -A INPUT -m state --state INVALID -j LOG iptables -A INPUT -m state --state INVALID -j DROP (and OUTPUT as well, for those paranoid enough to do egress filtering). Also, echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter withecho 1 > /proc/sys/net/ipv4/conf/*/log_martians for logging/fun purposes. ~Tim -- Another day,|[EMAIL PROTECTED] Another kernel recompile|http://spodzone.org.uk/
Re: Fw: Can a daemon listen only on some interfaces?
On Sun, 09 Dec 2001, Guido Hennecke wrote: > At 09.12.2001, Henrique de Moraes Holschuh wrote: > > On Sun, 09 Dec 2001, Guido Hennecke wrote: > > > 127.0.0.1 GatewayInterface > > externel interface> > > > > > > he can reach your service bound to 127.0.0.1. And this without > > > activating ip_forward on your computer! > > Is this true even if the policy of the forward chain (for ipchains) is set > > to deny ? (and the equivalent, for iptables) ? > > Those packets did not go throught the forwards chain. For local > interfaces no routing is needed. If they came over the network, they should have. That is a broken behaviour (breaks principle of less surprise, at the very least). Well, ipmasq needs an update to trash anything incoming and outgoing from !lo with a destination of 127.0.0.1/8 then. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, 10 Dec 2001, Guido Hennecke wrote: > All packets come over the network an want to go to an ip address a local > interface is bound to, will not be routed to come to that interface. > Thats the problem. Indeed. > > Well, ipmasq needs an update to trash anything incoming and outgoing from > > !lo with a destination of 127.0.0.1/8 then. > > Well, ipmasq has nothing to do with that. ip masquerading might not. The Debian ipmasq package is a firewall, and one that attempts to explicitly avoid stuff like that, so it should be fixed to deal with the lo problem. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Fw: Can a daemon listen only on some interfaces?
On Sun, Dec 09, 2001 at 07:45:52PM +0100, Guido Hennecke wrote: > Please dont answer to the list _and_ to me. Thank you. > > At 09.12.2001, Tim Haynes wrote: > > "Phillip Hofmeister" <[EMAIL PROTECTED]> writes: > > [snip] > > > > If an attacker in the same network sets a route like that: > > > > > > > > 127.0.0.1 GatewayInterface > > > externel interface> > > > Couldn't this be countered with: > > > ipchains -i !lo -d 127.0.0.1 -j DENY > > > ? > > Better, > > iptables -A INPUT -m state --state INVALID -j LOG > > iptables -A INPUT -m state --state INVALID -j DROP > > (and OUTPUT as well, for those paranoid enough to do egress filtering). > > > > Also, > > echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter > > withecho 1 > /proc/sys/net/ipv4/conf/*/log_martians > > for logging/fun purposes. > > rp_filter will not help with that. > OK, you guys have started to confuse me a little just when I thought I was getting a handle on this firewalling stuff. Now, please explain what an attacker would do in your example above. Do you mean the following?: 1. The attacker (on your LAN) alters his routing table so that all packets destined for 127.0.0.1 go to your official IP address via his LAN interface. ie. something like: # route add -net 127.0.0.0 gw 192.168.1.1 eth0 (Where 192.168.1.1 is the address of your firewall box running ssh - which you are trying to prevent the attacker from logging into.) 2. Then when he does ssh into 127.0.0.1 Is that what you meant? Would that mean that your firewall box (running ssh) would see the packets as coming from source 192.168.1.2 (the attacker's IP address on the LAN) and going to destination 127.0.0.1 (local)? Then the sshd daemon would see the connection attempt as seeming to be a local connection (127.0.0.1). If I have got the reasoning correct, then I can see the problem. It would seem easy to do this from the LAN, but I don't think possible from the internet - since packets with destination 127.0.0.1 would not get routed. Second question: Why does the state INVALID match match these packets. Are they flagged as invalid because they have come in from eth0 but with a destination of 127.0.0.1 (which should be impossible)? Thanks to anyone who can make this a little clearer. Cheers. Mark. pgplDUeycgJO7.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: > I try to explain again: > > You have a Linux box with "eth0" and "eth1". "eth0" is the Internet > interface, "eth1" is the interface to the LAN. > > IP addresses: eth0 - 123.123.123.123 > eth1 - 192.168.0.1 > > You want remote access from your LAN to the Linux Box with ssh. So you > bind the sshd to 192.168.0.1 and think, now the sshd is only reachable > from your LAN. > > The atacker is client at the same provider than you are and in the same > network segment (sorry for my english!). > > The atacker sets a route like this: > > route add 192.168.0.1 gw 123.123.123.123 > > And now "ssh 192.168.0.1" will work without routing on _your_ box > activated. So the FORWARD chain from ipchains will not work for that. OK I just tried something similar. Here is what I just did: 1. First to prove that I can indeed ssh in on loopback I did: ssh 127.0.0.1 ---> worked OK 2. I added a route for my LAN IP address (192.168.0.2) via loopback route add 192.168.0.2 gw 127.0.0.1 3. Then I edited /etc/ssh/sshd_config and changed the IP addresses that sshd will bind to so that it only binds to 192.168.0.2 ListenAddress 192.168.0.2 4. Then told sshd to reload its config /etc/init.d/ssh reload 5. Then tried to ssh in on loopback again (should now refuse). ssh 127.0.0.1 ---> Secure connection to 127.0.0.1 refused 6. Then tried to ssh in on 192.168.0.2 (should work) ssh 192.168.0.2---> ssh_exchange_identification: Connection closed by remote host What is the go here? From what you were saying above, No 6. should have worked, right? > > > Second question: > > Why does the state INVALID match match these packets. Are they flagged > > as invalid because they have come in from eth0 but with a destination of > > 127.0.0.1 (which should be impossible)? > > I don't know. I am not very experianced with iptables. > Also, my firewall (iptables) which does have the following rules: iptables -A INPUT -m state --state INVALID -j LOG iptables -A INPUT -m state --state INVALID -j DROP Did not log anything during this experiment. So I still not sure about the state INVALID match for these packets. Can you explain why the above test did not work? Cheers. Mark. pgpfpaqkRRtsB.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 01:52:51PM +1000, mdevin wrote: > On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: > > I try to explain again: > > > > You have a Linux box with "eth0" and "eth1". "eth0" is the Internet > > interface, "eth1" is the interface to the LAN. > > > > IP addresses: eth0 - 123.123.123.123 > > eth1 - 192.168.0.1 > > > > You want remote access from your LAN to the Linux Box with ssh. So you > > bind the sshd to 192.168.0.1 and think, now the sshd is only reachable > > from your LAN. > > > > The atacker is client at the same provider than you are and in the same > > network segment (sorry for my english!). > > > > The atacker sets a route like this: > > > > route add 192.168.0.1 gw 123.123.123.123 > > > > And now "ssh 192.168.0.1" will work without routing on _your_ box > > activated. So the FORWARD chain from ipchains will not work for that. > > OK I just tried something similar. Here is what I just did: > 1. First to prove that I can indeed ssh in on loopback I did: > ssh 127.0.0.1 ---> worked OK > 2. I added a route for my LAN IP address (192.168.0.2) via loopback > route add 192.168.0.2 gw 127.0.0.1 > 3. Then I edited /etc/ssh/sshd_config and changed the IP addresses that > sshd will bind to so that it only binds to 192.168.0.2 > ListenAddress 192.168.0.2 > 4. Then told sshd to reload its config > /etc/init.d/ssh reload > 5. Then tried to ssh in on loopback again (should now refuse). > ssh 127.0.0.1 ---> Secure connection to 127.0.0.1 refused > 6. Then tried to ssh in on 192.168.0.2 (should work) > ssh 192.168.0.2---> ssh_exchange_identification: Connection closed > by remote host > > What is the go here? From what you were saying above, No 6. should have > worked, right? Whoops. It does actually work sorry. I forgot that my /etc/hosts.deny file had this in it: ALL: PARANOID After commenting this out, things worked for No 6. above which goes to show that what you were saying works exactly as you said. Thanks for pointing this out, it has really edemucated (sic) me. > > > > > Second question: > > > Why does the state INVALID match match these packets. Are they flagged > > > as invalid because they have come in from eth0 but with a destination of > > > 127.0.0.1 (which should be impossible)? > > > > I don't know. I am not very experianced with iptables. > > > Also, my firewall (iptables) which does have the following rules: > iptables -A INPUT -m state --state INVALID -j LOG > iptables -A INPUT -m state --state INVALID -j DROP > > Did not log anything during this experiment. Now after proving that it does actually work, still nothing was logged by my firewall despite exactly the above iptables rules right at the head of my INPUT chain. Thus I can only conclude that the state INVALID match does not stop this sort of thing. Please someone refute this if I am wrong. Cheers. Mark. pgpkjdMy7UAhe.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: > With ipchains you can make the following: > > ipchains -A input -i ! eth1 -d 192.168.0.1 -j DENY What this says is: all packets with destination 192.168.0.1 must not have come from eth1 or they will be denied. Why do you choose to specify the rule this way and not like this: ipchains -A input -i eth0 ! -d 192.168.0.1 -j DENY In other words: all packets coming from eth0 must have destination 192.168.0.1 or they will be denied? Please explain. Is it because you may later want to put your ethernet card into promiscuous mode and thus receive packets with any destination as if they were for you? My rule above would prevent this whereas your rule would not. Both rules would prevent the attacker trying to circumvent the sshd bound IP address restriction however. Can you explain why you choose your rule. Cheers. Mark. pgpGi2Wj4MGIX.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, 2001-12-10 at 08:19, mdevin wrote: > On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: > > With ipchains you can make the following: > > > > ipchains -A input -i ! eth1 -d 192.168.0.1 -j DENY > > What this says is: all packets with destination 192.168.0.1 must not > have come from eth1 or they will be denied. > > Why do you choose to specify the rule this way and not like this: > ipchains -A input -i eth0 ! -d 192.168.0.1 -j DENY > In other words: all packets coming from eth0 must have destination > 192.168.0.1 or they will be denied? I'm not the original author, but I use ! too. Using ! would break ip forwarding. If your box is a gateway/router/firewall, it will drop all packets not destined for 192.168.0.1 (itself). > > Please explain. Is it because you may later want to put your ethernet > card into promiscuous mode and thus receive packets with any destination > as if they were for you? My rule above would prevent this whereas your > rule would not. Both rules would prevent the attacker trying to > circumvent the sshd bound IP address restriction however. > > Can you explain why you choose your rule. > > Cheers. > Mark. -- Berend De Schouwer
Re: Fw: Can a daemon listen only on some interfaces?
On Sun, Dec 09, 2001 at 07:45:52PM +0100, Guido Hennecke wrote: > At 09.12.2001, Tim Haynes wrote: > > echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter > > withecho 1 > /proc/sys/net/ipv4/conf/*/log_martians > > for logging/fun purposes. > > rp_filter will not help with that. I thought that rp_filter was for precisely this. Doesn't it stop packets which appear on interfaces with invalid IP addresses for that interface from getting through? Plato
Re: Fw: Can a daemon listen only on some interfaces?
Plato <[EMAIL PROTECTED]> writes: > > > echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter > > > withecho 1 > /proc/sys/net/ipv4/conf/*/log_martians > > > for logging/fun purposes. > > > > rp_filter will not help with that. > > I thought that rp_filter was for precisely this. Doesn't it stop packets > which appear on interfaces with invalid IP addresses for that interface > from getting through? It's a return-path filter; if flipping the src/dest IP#s wouldn't send it back out the same interface, it doesn't come in at all. So a specially routed packet from a.b.c.d -> 127.0.0.1 coming in on eth0 becomes a packet from 127.0.0.1 -> a.b.c.d going back out That certainly looks wrong to me, although I'm not /sure/ it would produce the required interface conflict for rp_filter. ~Tim -- We're just souls across a |[EMAIL PROTECTED] shrinking world |http://spodzone.org.uk/ In a distant starlit night |
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 09:31:09AM +0200, Berend De Schouwer wrote: > On Mon, 2001-12-10 at 08:19, mdevin wrote: > > On Mon, Dec 10, 2001 at 01:50:19AM +0100, Guido Hennecke wrote: > > > With ipchains you can make the following: > > > > > > ipchains -A input -i ! eth1 -d 192.168.0.1 -j DENY > > > > What this says is: all packets with destination 192.168.0.1 must not > > have come from eth1 or they will be denied. > > > > Why do you choose to specify the rule this way and not like this: > > ipchains -A input -i eth0 ! -d 192.168.0.1 -j DENY > > In other words: all packets coming from eth0 must have destination > > 192.168.0.1 or they will be denied? > > I'm not the original author, but I use ! too. > > Using ! would break ip forwarding. If your box is a > gateway/router/firewall, it will drop all packets not destined for > 192.168.0.1 (itself). > > OK, I see the problem. However, I think this only applies to ipchains where forwarded packets traverse the input and output chains. Sorry, I was transposing my thoughts into ipchains rules. Actually my firewall is iptables based. In iptables, packets that are being masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT chains. Thus if the rule was: iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP this should be OK I guess. Since packets on the INPUT are destined only to localhost. All packets that need to be forwarded will traverse only the FORWARD chain and thus will not be checked against this rule. Thus on an iptables based firewall is there a preferance for which is the better approach? It is just that I came up with the rule above because it seemed more straightforward. In other words: If the packet came from interface eth0 and it is directed to localhost (INPUT chain) then it must have destination address 192.168.0.1 or we will DROP it. And you can make similar rules for every interface the firewall has. But I guess the same applies for the ipchains rule you use. It is just that the primary focus is on the IP address of each interface rather than the interface itself. The more I think about it, it doesn't seem to matter in iptables, unless you are putting your ethernet card into promiscuous mode or something. 'Cause then I guess you would see lots of packets not addressed to you coming in your INPUT chain. Then that iptables rule would DROP them all unless they were specifically addressed to you, whereas if I used your style of rule then other packets not addressed to my box directly would still get through. I don't know anything about ethernet cards in promiscuous mode - so not sure about this. What do you think? And thanks for highlighting that ipchains difference, I had forgotten about that. Since January, I have only been using iptables. Cheers. Mark. pgpfk8ar4ESTJ.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
Guido Hennecke <[EMAIL PROTECTED]> writes: > > Sorry, I was transposing my thoughts into ipchains rules. Actually my > > firewall is iptables based. In iptables, packets that are being > > masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT > > chains. Thus if the rule was: > > iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP > > this should be OK I guess. Since packets on the INPUT are destined only > > to localhost. > > Pakets came from the externel interface from a ip address from this > externel network will be masqeraded? I think the will not! I've got a problem with this, btw. Increasingly, I'm needing FORWARDING rules on various sites; what I want to know is, when I've got the following layout: | #Chain for incoming/forwarding filtering | iptables -N block | #chain to drop & log stuff | iptables -N DLOG | ... | several `block' rules incl stateful allowing ESTABLISHED,RELATED | ... | ## Jump to that chain from INPUT and FORWARD chains. | iptables -A INPUT -j block | iptables -A FORWARD -j block how come packets still seem to get dropped when being forwarded between interfaces? (If this isn't the place for this question, point me at a *decent* bit of documentation by all means! (With emphasis on `decent', as in something that explains and details simultaneously.)) ~Tim -- 12:51:17 up 33 days, 14:46, 17 users, load average: 0.15, 0.18, 0.17 [EMAIL PROTECTED] |And your radiance shines http://piglet.is.dreaming.org |Like the moon of all innocent grace
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 12:22:44PM +, Tim Haynes wrote: > Plato <[EMAIL PROTECTED]> writes: > > > > > echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter > > > > withecho 1 > /proc/sys/net/ipv4/conf/*/log_martians > > > > for logging/fun purposes. > > > > > > rp_filter will not help with that. > > > > I thought that rp_filter was for precisely this. Doesn't it stop packets > > which appear on interfaces with invalid IP addresses for that interface > > from getting through? > > It's a return-path filter; if flipping the src/dest IP#s wouldn't send it > back out the same interface, it doesn't come in at all. > > So a specially routed packet from a.b.c.d -> 127.0.0.1 coming in on eth0 > becomes a packet from 127.0.0.1 -> a.b.c.d going back out > > That certainly looks wrong to me, although I'm not /sure/ it would produce > the required interface conflict for rp_filter. > Hmmm. I don't know. On the test I ran in another part of this thread where I put a rule into my routing table to make packets destined for 192.168.0.2 get sent via loopback. Then made sshd bind to address 192.168.0.2. Then I was able to ssh into my box via the loopback interface by doing this: ssh 192.168.0.2 Even though: ssh 127.0.0.1 was refused. All this was done while my iptables firewall was loaded and it does have the following in it: # Enable IP spoofing protection - turn on Source Address Verification for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done # Log Spoofed Packets, Source Routed Packets, Redirect Packets for f in /proc/sys/net/ipv4/conf/*/log_martians; do echo 1 > $f done However, the difference is that the packets that were being sent actually have destination address 192.168.0.2 and source address 192.168.0.2. And this didn't cause any problem for the return path filter. Whereas it might if it was trying to send back packets with a source of 127.0.0.1 and a destination of a.b.c.d. I can't test this at present since I don't have another computer I can network with this one for a couple of days. But a test could be run similar to the one I did earlier to check. Cheers. Mark. pgpjH6YLjXNpS.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 12:54:31PM +, Tim Haynes wrote: > Guido Hennecke <[EMAIL PROTECTED]> writes: > > > > Sorry, I was transposing my thoughts into ipchains rules. Actually my > > > firewall is iptables based. In iptables, packets that are being > > > masqueraded traverse only the FORWARD chain and not the INPUT or OUTPUT > > > chains. Thus if the rule was: > > > iptables -A INPUT -i eth0 ! -d 192.168.0.1 -j DROP > > > this should be OK I guess. Since packets on the INPUT are destined only > > > to localhost. > > > > Pakets came from the externel interface from a ip address from this > > externel network will be masqeraded? I think the will not! > > I've got a problem with this, btw. Increasingly, I'm needing FORWARDING > rules on various sites; what I want to know is, when I've got the following > layout: > > | #Chain for incoming/forwarding filtering > | iptables -N block > | #chain to drop & log stuff > | iptables -N DLOG > | ... > | several `block' rules incl stateful allowing ESTABLISHED,RELATED > | ... > | ## Jump to that chain from INPUT and FORWARD chains. > | iptables -A INPUT -j block > | iptables -A FORWARD -j block > > how come packets still seem to get dropped when being forwarded between > interfaces? > I am not sure I have totall gotten what you are trying to do here. But, the packets will be dropped instead of being forwarded between interfaces because that is exactly what you have specified in your rules. What happens is this: 1. A packet comes in through one of your interfaces. 2. It hits the PREROUTING chain - where DNAT can occur or any tracked connections are de-SNATted or de-MASQUERADED. 3. Routing decision is made. Here is where the decision is made whether the packet is destined for localhost or to go out another interface. 4a. If the packet is destined for localhost then it traverses the INPUT chain. 4b. If the packet is for another host then it traverses the FORWARD chain. Thus what your rules will do is: Any packet not destined for localhost will traverse the FORWARD chain and will be -j (jumpped) to your block (user defined) chain. This will presumably LOG and the DROP the packets. Thus all your FORWARDED packets will be DROPPED. This is of course only if you don't have other rules in your FORWARD chain which explicitly ACCEPT the packets before they hit the FORWARD chain rule you have written above. HTH. Cheers. Mark. pgpReAk6ndWZ9.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
mdevin <[EMAIL PROTECTED]> writes: [snip firewall overview] > > how come packets still seem to get dropped when being forwarded between > > interfaces? > > I am not sure I have totall gotten what you are trying to do here. But, > the packets will be dropped instead of being forwarded between interfaces > because that is exactly what you have specified in your rules. > > What happens is this: > 1. A packet comes in through one of your interfaces. > 2. It hits the PREROUTING chain - where DNAT can occur or any tracked > connections are de-SNATted or de-MASQUERADED. > 3. Routing decision is made. Here is where the decision is made whether > the packet is destined for localhost or to go out another interface. > 4a. If the packet is destined for localhost then it traverses the INPUT > chain. > 4b. If the packet is for another host then it traverses the FORWARD > chain. Righty. That's much as I expected. > Thus what your rules will do is: > Any packet not destined for localhost will traverse the FORWARD chain > and will be -j (jumpped) to your block (user defined) chain. This will > presumably LOG and the DROP the packets. Thus all your FORWARDED > packets will be DROPPED. Ultimately, I want input & forward to be drop-by-default. However, the `block' chain is meant to be good for both input & forward scenarios; it has rules for stateful filtering and `open' things, then a drop & log. If I put in a rule matching -i and/or -o as appropriate, it still doesn't seem to work. Maybe I've done something wrong (and I don't really want to post ork's firewall in any more detail). > This is of course only if you don't have other rules in your FORWARD > chain which explicitly ACCEPT the packets before they hit the FORWARD > chain rule you have written above. What about if I kick *all* packets from forward onto `block', though? That's the bit I'm not wholly happy about. ~Tim -- A spark of life |[EMAIL PROTECTED] On a wire from heaven |http://spodzone.org.uk/
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 10:55:07PM +1000, mdevin wrote: > On Mon, Dec 10, 2001 at 12:22:44PM +, Tim Haynes wrote: > > Plato <[EMAIL PROTECTED]> writes: > > > > > > > echo 1 > /proc/sys/net/ipv4/conf/*/rp_filter > > > > > withecho 1 > /proc/sys/net/ipv4/conf/*/log_martians > > > > > for logging/fun purposes. > > > > > > > > rp_filter will not help with that. > > > > > > I thought that rp_filter was for precisely this. Doesn't it stop packets > > > which appear on interfaces with invalid IP addresses for that interface > > > from getting through? > > > > It's a return-path filter; if flipping the src/dest IP#s wouldn't send it > > back out the same interface, it doesn't come in at all. > > > > So a specially routed packet from a.b.c.d -> 127.0.0.1 coming in on eth0 > > becomes a packet from 127.0.0.1 -> a.b.c.d going back out > > > > That certainly looks wrong to me, although I'm not /sure/ it would produce > > the required interface conflict for rp_filter. > > > > Hmmm. I don't know. > > On the test I ran in another part of this thread > where I put a rule into my routing table to make packets destined for > 192.168.0.2 get sent via loopback. Then made sshd bind to address > 192.168.0.2. Then I was able to ssh into my box via the loopback > interface by doing this: ssh 192.168.0.2 Even though: ssh 127.0.0.1 was > refused. > > All this was done while my iptables firewall was loaded and it does have > the following in it: > # Enable IP spoofing protection - turn on Source Address Verification > for f in /proc/sys/net/ipv4/conf/*/rp_filter; do > echo 1 > $f > done > # Log Spoofed Packets, Source Routed Packets, Redirect Packets > for f in /proc/sys/net/ipv4/conf/*/log_martians; do > echo 1 > $f > done > > However, the difference is that the packets that were being sent > actually have destination address 192.168.0.2 and source address > 192.168.0.2. And this didn't cause any problem for the return path > filter. Whereas it might if it was trying to send back packets with a > source of 127.0.0.1 and a destination of a.b.c.d. > > I can't test this at present since I don't have another computer I can > network with this one for a couple of days. But a test could be run > similar to the one I did earlier to check. No. On reading another post by Guido, this seems to do only what I have written in the comments above. ie. turn on Source Address Verification. It hasn't got anything to do with destination addresses. Cheers. Mark. pgpZGaGhkST8Q.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
On Mon, Dec 10, 2001 at 01:21:15PM +, Tim Haynes wrote: > Ultimately, I want input & forward to be drop-by-default. However, the > `block' chain is meant to be good for both input & forward scenarios; it > has rules for stateful filtering and `open' things, then a drop & log. If I > put in a rule matching -i and/or -o as appropriate, it still doesn't seem > to work. Maybe I've done something wrong (and I don't really want to post > ork's firewall in any more detail). > > What about if I kick *all* packets from forward onto `block', though? > That's the bit I'm not wholly happy about. > I think you are better to break your rules up into separate connection orientated rulesets. I will reply off list with more details as this is getting a little off topic now. Cheers. Mark. pgpEbZPBkAy9n.pgp Description: PGP signature
Re: Fw: Can a daemon listen only on some interfaces?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message <[EMAIL PROTECTED]>, Henrique de Moraes Holschuh writ es: >On Sun, 09 Dec 2001, Guido Hennecke wrote: >> At 09.12.2001, Henrique de Moraes Holschuh wrote: >> > On Sun, 09 Dec 2001, Guido Hennecke wrote: >> > > 127.0.0.1 GatewayInterface > > > externel interface> >> > > >> > > he can reach your service bound to 127.0.0.1. And this without >> > > activating ip_forward on your computer! >> > Is this true even if the policy of the forward chain (for ipchains) is set >> > to deny ? (and the equivalent, for iptables) ? >> >> Those packets did not go throught the forwards chain. For local >> interfaces no routing is needed. > >If they came over the network, they should have. That is a broken behaviour >(breaks principle of less surprise, at the very least). > >Well, ipmasq needs an update to trash anything incoming and outgoing from >!lo with a destination of 127.0.0.1/8 then. It already does this. Check out /etc/ipmasq/rules/I15lospoof.def. It also blocks and logs packets coming from external interfaces claiming to be from an internal address in the /etc/ipmasq/rules/I70masq.def file. The ipmasq firewall is very careful about blocking these sorts of attacks. The only change I make to its default operation is to lock down the external interface. - -- 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 iD8DBQE8FO+BoayJfLoDSdIRAgxhAKCYYeJrtaUAtbbeGowq1hBE2GyaCACgkKhf gmdv3uF0kXlJkN2V/gukl9k= =bm4W -END PGP SIGNATURE-
Re: Fw: Can a daemon listen only on some interfaces?
Greetings! > > At 09.12.2001, [EMAIL PROTECTED] wrote: > > [...] > > > And thanks for all the replies. In fact I was most interested to hear > > > that you could not make daemons listen on only one interface but you > > > could make them bind to an IP address range. I guess that is what I > > > achieved in my postfix main.cf file with the line: > > > inet_interfaces = localhost If using the meta-daemon XINETD instead of INETD you can specify the interface (= bind) option where you can specify on which interface the service should listen only. See man xinetd.conf HTH Volker -- Volker Tanger [EMAIL PROTECTED] -===- Research & Development Division, WYAE
