IPTABLES & APACHE

Hello,

Recently I have been trying to set up my firewall to block attempts to
access apache (running on the same machine listening on port 8080,
virtual-hosting a few domains) from a specific machine (or machines) on the
internet. I'm aware that apache can be configured to achieve a certain kind
of result through htaccess, but which I don't desire.. I'm looking to truly
block certain IPs making it appear this machine's web server isn't even
working or that there is no route to host when a blocked IP or IP's are
attempting to access it. My rules start out with a default drop policy.

I've tried the following unsuccessfully, attempting to block just one IP,
remember my server listens on 8080:

$IPTABLES -A INPUT -i $EXTIF -p TCP -s $BLOCKEDIP \
-d $EXTIP -m state --state NEW,ESTABLISHED,RELATED --dport 8080 -j REJECT

$IPTABLES -A INPUT -i $EXTIF -p UDP -s $BLOCKEDIP \
-d $EXTIP -m state --state NEW,ESTABLISHED,RELATED --dport 8080 -j DROP

I have to put a:
$IPTABLES -A INPUT -i $EXTIF -p TCP -s $UNIVERSE-d $EXTIP --dport 8080 -j
ACCEPT
in the script or nothing can access the server, but then access to the
server is still granted to the BLOCKEDIP address. This seems to make sense
as it overrides.. but...

Since none of this worked the way I hoped, I also tried the following (note
the ! not expression before the BLOCKEDIP):

$IPTABLES -A INPUT -i $EXTIF -p TCP -s ! $BLOCKEDIP \
-d $EXTIP -m state --state NEW,ESTABLISHED,RELATED --dport 8080 -j ACCEPT

$IPTABLES -A INPUT -i $EXTIF -p UDP -s ! $BLOCKEDIP \
-d $EXTIP -m state --state NEW,ESTABLISHED,RELATED --dport 8080 -j ACCEPT

One might expect the above two lines to allow access to port 8080 from
everywhere EXCEPT the blocked ip. But no. I must still put the same line or
nobody has access again:
$IPTABLES -A INPUT -i $EXTIF -p TCP -s $UNIVERSE -d $EXTIP --dport 8080 -j
ACCEPT

As a side note, I have also found that iptables will only DROP or REJECT if
those rules are loaded before any ACCEPT rules, and conversely if there is a
DROP or REJECT after an ACCEPT, that DROP or REJECT rule will be ignored.
Because of this, I have tried moving the 'required' UNIVERSE line above to
positions before and after the selective IP blocking lines, and have even
put it before and after in the same script at the same time. Nothing works,
of course, and the blocked IP can still access the web server. <pulling
what's left of my hair out now>

I was beginning to think Apache might bypass this, but that cannot be
possible since iptables is what controls the kernel routing. No applications
or daemons running on the system should be able to override the rules set in
iptables.

I have even created my own chain to match the IP and drop or reject, but
that also did not work. And just for the record, everything else works fine.
NAT works, and other services are available as defined in the firewall
script.

So back to the problem at hand-- Besides configuring apache to deny access
by certain IPs in htaccess- which I don't want to do, what *can* I do to
have IPTABLES make the web server not to be there when one or more blocked
IP's attempt to access it. (and please don't say to go buy a router ! hehe)

Thanks for your time and TIA,
JJ

"JJMMPP" <(E-Mail Removed)> said:
>Hello,
>
>Recently I have been trying to set up my firewall to block attempts to
>access apache (running on the same machine listening on port 8080,
>virtual-hosting a few domains) from a specific machine (or machines) on the
>internet.

Ok.

>I've tried the following unsuccessfully, attempting to block just one IP,
>remember my server listens on 8080:
>
>$IPTABLES -A INPUT -i $EXTIF -p TCP -s $BLOCKEDIP \
>-d $EXTIP -m state --state NEW,ESTABLISHED,RELATED --dport 8080 -j REJECT

First, what do you have before this, and what do you have after this,
in your active configuration. Check that with "iptables -vL INPUT".

Then, you're much too fancy here; just do
$IPTABLES -A INPUT -p tcp -s $BLOCKEDIP --dport 8080 -j REJECT
(or, the same with "-j DROP").

>I have to put a:
>$IPTABLES -A INPUT -i $EXTIF -p TCP -s $UNIVERSE-d $EXTIP --dport 8080 -j ACCEPT
>in the script or nothing can access the server, but then access to the
>server is still granted to the BLOCKEDIP address. This seems to make sense
>as it overrides.. but...

This depends on the default policy for the INPUT chain, and also on the
other rules in the INPUT chain.

Overall, you seem to have some misunderstandings on how the iptables
rules work, so I'll try to clarify that here. ACCEPT, DROP and REJECT
are considered "terminal" rules. the conditions on an iptables rule
match, and the action (-j XXX) on the iptables rule is one of these
three, the action is taken, and processing of the packet ends there.

If a packet doesn't match any of the rules in an iptables rule list,
then either the processing continues in the calling rule list (if
the rule list that just ended was a user-defined one), or the default
policy of the rule list is applied (for INPUT, OUTPUT and FORWARD lists).

So, if you have an INPUT rule list with:
- policy ACCEPT
- -p tcp -s some-addr --dport port -j DROP
.... then all packets, except those that are coming from some-addr, and
targeted to TCP port "port" are accepted. Packets from that one source
address, targeted to the one TCP port, are silently dropped. The sending
site will at some point time out the connection.

If the rule list was:
- policy DROP
- -p tcp --dport port -j ACCEPT
- -p tcp -s some-addr --dport port -j DROP
.... then all traffic to TCP port "port" would be accepted (even from
"some-addr", because the first rule matches also that source address),
but all other traffic would be dropped. So, here one could guess that
the order of the two rules (policy isn't a rule as such) should be the
opposite.


>I was beginning to think Apache might bypass this, but that cannot
>be possible since iptables is what controls the kernel routing. No
>applications or daemons running on the system should be able to
>override the rules set in iptables.

Pretty much so. However, applications opening RAW network sockets work
"outside" iptables. But typically applications don't do this (..hmm;
dhcp client could be the only one that I know of, and then the various
network traffic loggers).

>So back to the problem at hand-- Besides configuring apache to deny access
>by certain IPs in htaccess- which I don't want to do, what *can* I do to
>have IPTABLES make the web server not to be there when one or more blocked
>IP's attempt to access it.

I hope you found your answer above -- my best guess is that you're somewhere
before dropping the offending traffic, accepting it via some other rule.

If you still don't find what is wrong, please post output of
"iptables -nvL INPUT" on your machine. Mask out the actual IP numbers,
though.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Thank you for the explanation, it cleared up a few things that I wasn't
exactly sure about. I did read that it's not very secure to have a default
policy of ACCEPT, which is why I wanted to keep mine as DROP. Then you
cleared up why certain rules worked in a certain order-- it's all relative
to your policy.

Anyhow, as it turns out, I had been testing all of this using a remote shell
account and couldn't understand why lynx on that machine kept successfully
loading pages off my webserver when I defined many different rules in
iptables attempting unsuccessfully to block the remote computer's IP.. Rules
that I know work because I had used some of them in the past.. (!)

Then just now after trying some of your suggestions out, I realized that a
year ago I had read that the remote machine I had been using to test this,
runs an HTTP Proxy server.

I suppose I could have checked my http log files, or even ran a tcpdump to
get the correct IP, but no. I'm a bone head hehe.

The IP addresses for the proxy server and shell server were very close
though, and since I don't know the addresses by heart, I didn't notice the
last number being off by one.

So now, using the rules in the proper order, it works perfectly. I was
beginning to worry.

Again, thank you!

"JJMMPP" <(E-Mail Removed)> said:
>Thank you for the explanation, it cleared up a few things that I wasn't
>exactly sure about. I did read that it's not very secure to have a default
>policy of ACCEPT, which is why I wanted to keep mine as DROP. Then you
>cleared up why certain rules worked in a certain order-- it's all relative
>to your policy.

Oh, and one more clarification.

Having "-j DROP" as the last rule in the input chain (i.e. no match
conditions, just DROP any packet that made it this far on the rule list)
is equivalent to having the policy as DROP.

The rule of thumb to set the default policy to DROP is a reasonable one;
the possibility to accept something by accident is much smaller then
(esp. when considering rare or obscure protocols). F.ex., if your default
policy is ACCEPT, and you decide to hide a machine from some remote host,
and do this by just dropping all packets from that host that are of protocol
tcp or udp, the machine will still happily respond to any ICMP and ARP
traffic from the "prohibited" host - which possibly wasn't the desired
outcome.

>I suppose I could have checked my http log files, or even ran a tcpdump to
>get the correct IP, but no. I'm a bone head hehe.
>
>The IP addresses for the proxy server and shell server were very close
>though, and since I don't know the addresses by heart, I didn't notice the
>last number being off by one.

This sounds familiar; I think I've been bitten by something similar myself.
:-)

--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)