This is a discussion on ipchains question within the Linux Security forums, part of the System Security and Security Related category; Gary Petersen wrote: > Julia Thorne, on Wed, 12 May 2004 14:57:45 -0500, in > <Zkvoc.4373322$...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Gary Petersen wrote:
> Julia Thorne, on Wed, 12 May 2004 14:57:45 -0500, in > <Zkvoc.4373322$iA2.513727@news.easynews.com>, said this: >> Connections with spoofed IP sources are NEVER legitimate traffic, >> and shouldn't be allowed just because they appear to be normal >> traffic, going to a publicly accessible port. > > If a packet spoofs an address that doesn't belong to > a private network, is there any way to detect > that it's fake? If a packet shows up with a source IP address on the "wrong" side of your router (i.e., a packet with an inside source shows up on the outside, or a packet with an outside source shows up on the inside), then it's either spoofed, or there's a backdoor into your network. -- ZZzz |\ _,,,---,,_ Travis S. Casey <efindel@earthlink.net> /,`.-'`' -. ;-;;,_ No one agrees with me. Not even me. |,4- ) )-,_..;\ ( `'-' '---''(_/--' `-'\_) |
|
|||
|
PapaBear schrieb:
> After flushing all rules, I start out making standard strategies as > follows: > > # ### Standard strategy is DENY ### ipchains > -P input DENY # No answer for invalid incoming ipchains -P > output REJECT # Error for invalid outgoing ipchains -P forward > REJECT # Error for invalid forwarding > > Now the book I'm using suggests to put all kinds of rules in the file > to deny access from for example class A, B and C networks. > > Why is this? (since the standard strategy is to DENY or REJECT) > > imho I can just ACCEPT only those packages I would want and discard > the others, since they would be denied or rejected, am I right? This book doesen't happen to be Robert Zieglers 'Linux Firewalls'? The answer is: yes: you can just ACCEPT what you want and leave the other packages to the policy of the chain, but there are some ways an intruder might take you will be interested in knowing he tried. Giving certain adresses and subnets, that should not come along on your $EXTERNAL_INTERFACE a rule of their own provides you with information of what happens to you box. Just don't forget the old military rule: "A barricade without monitoring is a danger for yourself!" BTW: Switching to iptables really _is_ a good idea, even if you didn't want to hear (or rather read) that now :-) Matthias -- All personal mail please to matthias.ruckenbauer(AT)aon.at I'm sorry for the inconveniences. Thank you! |
|
|||
|
Op Wed, 12 May 2004 19:57:45 GMT schreef Julia Thorne:
> On Wed, 12 May 2004 19:08:00 +0200, PapaBear wrote:>> >> Well, in the light of all the reactions above: it seems that with the >> upcoming of the internet the ability to read properly has diminished. >> >> The question was very, very simple: Why should I enter rules to deny >> packets when the default is set to deny anyway? >> >> Pfff... >> >> Instead of reading my question and trying to answer it, I get al >> kinds of yibberish about switching to iptables and lectures about >> addresses of such and such class... > > Those people DID answer your question! You just didn't get the > answer you wanted (the answer that would save you some effort), > so you disregarded it. > > 1: DROP, don't REJECT or DENY. The reasons for this are well > documented. Probably in the book you refered to. Not in my man-page it isn't, and I quote: TARGETS A firewall rule specifies criteria for a packet, and a target. If the packet does not match, the next rule in the chain is the examined; if it does match, then the next rule is specified by the value of the target, which can be the name of a user-defined chain, or one of the special values ACCEPT, DENY, REJECT, MASQ, REDIRECT, or RETURN. [snip] -- -----=====##### PapaBear #####=====----- Jesus is alive, I spoke with Him this morning! ---------------------------------------------- |
|
|||
|
Op Thu, 13 May 2004 13:59:48 +0200 schreef Ruckenbauer Matthias:
> PapaBear schrieb: > [etc] > > This book doesen't happen to be Robert Zieglers 'Linux Firewalls'? Yes it would! I found it rather usefull. The only thing is: using the standard filtering rules (I check again and again and ....) I cannot seem to be able to let the firewall pass my POP3 and SMTP requests. Any ideas? > The answer is: yes: you can just ACCEPT what you want and leave the > other packages to the policy of the chain, but there are some ways an > intruder might take you will be interested in knowing he tried. > Giving certain adresses and subnets, that should not come along on your > $EXTERNAL_INTERFACE a rule of their own provides you with information of > what happens to you box. > Just don't forget the old military rule: > "A barricade without monitoring is a danger for yourself!" OK, I agree. I'll re-consider the rules for this pupose, thanks. > BTW: Switching to iptables really _is_ a good idea, even if you didn't > want to hear (or rather read) that now :-) How come? I mean, there are a number of people suggesting this, but no-one has given me a clue as to the reason for this :( Isn't it true that both ipchains and iptables setup the kernel firewall? And see furthermore the scraped text from my console below: -------------------------------------------- [root@levi /root]# iptables -L iptables v1.1.1: can't initialize iptables table `filter': iptables who? (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. [root@levi /root]# -------------------------------------------- Is this so, should I use insmod to be able to use iptables, and again, why is it so much better? > Matthias -- -----=====##### PapaBear #####=====----- Jesus is alive, I spoke with Him this morning! ---------------------------------------------- |
|
|||
|
PapaBear schrieb:
>> This book doesen't happen to be Robert Zieglers 'Linux Firewalls'? > > > Yes it would! I found it rather usefull. The only thing is: using the > standard filtering rules (I check again and again and ....) I cannot > seem to be able to let the firewall pass my POP3 and SMTP requests. > Any ideas? > *scratch-on-the-head* It was a bit ago when I last had this book in my hand, bat AFAIR he suggested kind of a one-rule-per-server approach, so you have to define seperate rules for each POP3 and SMTP server you want to use. So take a look: Does it work only for one server, for some or for none at all? Let the rejected and denied packets be logged for all rules concerning SMTP and POP3, incoming, outgoing and forwarded. What does the log say? >> BTW: Switching to iptables really _is_ a good idea, even if you >> didn't want to hear (or rather read) that now :-) > > > How come? I mean, there are a number of people suggesting this, but > no-one has given me a clue as to the reason for this :( > > Isn't it true that both ipchains and iptables setup the kernel > firewall? > There is quite some difference in functionality between ipchains and iptables. Though they may look similar, iptables is a lot more flexible and has some feature you don't want to miss (stateful inspection, filtering packages based on user, group or PID of the sending program, enhanced logging features, pre- and postrouting operations, ...) The difference is so big, that Robert Ziegler in " Linux Firewalls 2nd ed", which is based on iptables, wrote a whole section only on this :-) Ipchains is considered out-of-date and taking a look at my (translated, german) edition of 'Linux Firewalls 2nd ed.' I see, that it is from 2002. You can guess how long ago the change from ipchains to iptables had been made. > And see furthermore the scraped text from my console below: > -------------------------------------------- [root@levi /root]# > iptables -L iptables v1.1.1: can't initialize iptables table > `filter': iptables who? (do you need to insmod?) Perhaps iptables or > your kernel needs to be upgraded. [root@levi /root]# > -------------------------------------------- > > Is this so, should I use insmod to be able to use iptables, and > again, why is it so much better? > No, AFAIK it isn't wise to have the IPFW (ipchains) and netfilter (iptables) simultaniously installed (or worse - running). You would have to kick ipchains and get in iptables. Do _not_ try just to insmod (or modprobe) the iptables-modules. This would not give you the desired result. Matthias -- All personal mail please to matthias.ruckenbauer(AT)aon.at I'm sorry for the inconveniences. Thank you! |
|
|||
|
PapaBear, on Thu, 13 May 2004 08:51:47 -0500, in
<rjrmjb0htmn4$.pdystzyhmwef$.dlg@40tude.net>, said this: > > Isn't it true that both ipchains and iptables setup the kernel firewall? > Yes, but they are different systems. > And see furthermore the scraped text from my console below: > -------------------------------------------- > [root@levi /root]# iptables -L > iptables v1.1.1: can't initialize iptables table `filter': iptables who? > (do you need to insmod?) > Perhaps iptables or your kernel needs to be upgraded. > [root@levi /root]# > -------------------------------------------- > > Is this so, should I use insmod to be able to use iptables, and again, why > is it so much better? > What I did was to rebuild my kernel with netfilter/iptables support built as modules. With kmod, the modules are loaded automatically, so I don't have to do any "modprobe ...." |
|
|||
|
Brad Olin, on Thu, 13 May 2004 09:47:50 -0500, in
<4907a0h3iiqhom94mo2661b2epqoreggmi@4ax.com>, said this: > 3) What if they spoof a valid Internet address? It doesn't make sense > to me that they would do this and I think it would be hard to figure it > out without using alot of resources. But I could be wrong. > I've heard that some attackers use echo requests with false (spoofed) source IPs to perform DoS attacks against real machines on the 'net. The way I see it, one way to not become part of the attack is to disable echo. Another way is to use the firewall to allow icmp echo requests only for locally controlled networks. For example, if you get a ping from v4.windowsupdate.microsoft.com (a frequent DDoS target), it's probably a fake :O |
|
|||
|
Brad Olin, on Thu, 13 May 2004 13:24:57 -0500, in
<cue7a05omtnvq8adn4l97nrr41eobbfn1r@4ax.com>, said this: > [...] > You can also limit the amount of ping packet reply by controlling icmp > input. This keeps ping as a functional tool and it protects you from > icmp DoS attachs. Example rules below. Again, watch for line wrap > issues... > > # allow certain inbound ICMP types > /sbin/iptables -A INPUT -p icmp --icmp-type echo-request -m limit > --limit 50/second -j ACCEPT > /sbin/iptables -A INPUT -p icmp --icmp-type destination-unreachable -j > ACCEPT > /sbin/iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT > /sbin/iptables -A INPUT -p icmp -j DROP > > > Brad Thanks. I might use this. |
|
|||
|
Op Thu, 13 May 2004 16:51:08 +0200 schreef Ruckenbauer Matthias:
> PapaBear schrieb: > >> using the >> standard filtering rules (I check again and again and ....) I cannot >> seem to be able to let the firewall pass my POP3 and SMTP requests. >> Any ideas? >> > *scratch-on-the-head* It was a bit ago when I last had this book in my > hand, bat AFAIR he suggested kind of a one-rule-per-server approach, so > you have to define seperate rules for each POP3 and SMTP server you want > to use. > So take a look: > Does it work only for one server, for some or for none at all? Check. It does not work for my server. (none at all, that is ;) > Let the rejected and denied packets be logged for all rules concerning > SMTP and POP3, incoming, outgoing and forwarded. > What does the log say? Will try that... >>> BTW: Switching to iptables really _is_ a good idea, even if you >>> didn't want to hear (or rather read) that now :-) >> >> How come? I mean, there are a number of people suggesting this, but >> no-one has given me a clue as to the reason for this :( >> >> Isn't it true that both ipchains and iptables setup the kernel >> firewall? >> > > There is quite some difference in functionality between ipchains and > iptables. Though they may look similar, iptables is a lot more flexible > and has some feature you don't want to miss (stateful inspection, > filtering packages based on user, group or PID of the sending program, > enhanced logging features, pre- and postrouting operations, ...) > The difference is so big, that Robert Ziegler in " Linux Firewalls 2nd > ed", which is based on iptables, wrote a whole section only on this :-) > Ipchains is considered out-of-date and taking a look at my (translated, > german) edition of 'Linux Firewalls 2nd ed.' I see, that it is from > 2002. You can guess how long ago the change from ipchains to iptables > had been made. OK, I'll look into this, Thanks. >> And see furthermore the scraped text from my console below: >> -------------------------------------------- [root@levi /root]# >> iptables -L iptables v1.1.1: can't initialize iptables table >> `filter': iptables who? (do you need to insmod?) Perhaps iptables or >> your kernel needs to be upgraded. [root@levi /root]# >> -------------------------------------------- >> >> Is this so, should I use insmod to be able to use iptables, and >> again, why is it so much better? >> > > No, AFAIK it isn't wise to have the IPFW (ipchains) and netfilter > (iptables) simultaniously installed (or worse - running). You would have > to kick ipchains and get in iptables. > Do _not_ try just to insmod (or modprobe) the iptables-modules. This > would not give you the desired result. > > Matthias Thanks Matthias, I'll try the several suggestions you made. -- -----=====##### PapaBear #####=====----- Jesus is alive, I spoke with Him this morning! ---------------------------------------------- |
|
|||
|
Op Thu, 13 May 2004 17:07:34 GMT schreef Gary Petersen:
> PapaBear, on Thu, 13 May 2004 08:51:47 -0500, in > <rjrmjb0htmn4$.pdystzyhmwef$.dlg@40tude.net>, said this: > >> >> Isn't it true that both ipchains and iptables setup the kernel firewall? >> > > Yes, but they are different systems. > >> And see furthermore the scraped text from my console below: >> -------------------------------------------- >> [root@levi /root]# iptables -L >> iptables v1.1.1: can't initialize iptables table `filter': iptables who? >> (do you need to insmod?) >> Perhaps iptables or your kernel needs to be upgraded. >> [root@levi /root]# >> -------------------------------------------- >> >> Is this so, should I use insmod to be able to use iptables, and again, why >> is it so much better? >> > > What I did was to rebuild my kernel with netfilter/iptables support > built as modules. With kmod, the modules are loaded automatically, > so I don't have to do any "modprobe ...." And might I want to go to iptables, How do I "switch off" ipchains again? Do I just disable the initialization script and reboot? -- -----=====##### PapaBear #####=====----- Jesus is alive, I spoke with Him this morning! ---------------------------------------------- |