Table 6-21. REJECT target
Option --reject-with
Example iptables -A FORWARD -p TCP --dport 22 -j REJECT --reject-with tcp-reset
Explanation This option tells the REJECT target what response to send to
the host that sent the packet that we are rejecting. Once we get a packet
that matches a rule in which we have specified this target, our host will
first of all send the associated reply, and the packet will then be dropped
dead, just as the DROP target would drop it. The following reject types
are currently valid: icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable,
icmp-proto-unreachable, icmp-net-prohibited and icmp-host-prohibited. The
default error message is to send an port-unreachable to the host. All of
the above are ICMP error messages and may be set as you wish. You can find
further information on their various purposes in the appendix ICMP types.
There is also the option echo-reply, but this option may only be used in
conjunction with rules which would match ICMP ping packets. Finally, there
is one more option called tcp-reset, which may only be used together with
the TCP protocol. The tcp-reset option will tell REJECT to send an TCP RST
packet in reply to the sending host. TCP RST packets are used to close open
TCP connections gracefully. For more information about the TCP RST read
RFC 793 - Transmission Control Protocol. As stated in the iptables man page,
this is mainly useful for blocking ident probes which frequently occur when
sending mail to broken mail hosts, that won't otherwise accept your mail.
6.5.3. DROP target
The DROP target does just what it says, it drops packets dead and will not
carry out any further processing. A packet that matches a rule perfectly
and is then Dropped will be blocked. Note that this action might in certain
cases have an unwanted effect, since it could leave dead sockets around
on either host. A better solution in cases where this is likely would be
to use the REJECT target, especially when you want to block port scanners
from getting too much information, such on as filtered ports and so on.
Also note that if a packet has the DROP action taken on it in a subchain,
the packet will not be processed in any of the main chains either in the
present or in any other table. The packet is in other words totally dead.
As we've seen previously, the target will not send any kind of information
in either direction, nor to intermediaries such as routers.
--------------------------------------------------------------------------------
-----Original Message-----
From: Edward Chow [mailto:chow@cs.uccs.edu]
Sent: Saturday, April 19, 2003 8:04 PM
To: 'Sunil S. Bhave'
Cc: 'Edward Chow'; CS691@cs.uccs.edu
Subject: RE: HW3Sunil,
Good question. Firewall is a virtual machine that was brought down many
times and was not set up with NTP (Network Time Protocol) to synchronize
its time with master time server. We should set up NTP so that the time
and date is correct.Why the log show 192.168.0.4 instead of 128.198.61.29? Excellent
question!
For that you need to understand how the firewall processes the request
and what is the order those firewall rules are exercised. If you
remember how various tables/chains are processed in the handout and in
the iptables tutorial, the HTTP request with 128.198.162.60 as
destination address goes through PREROUTING chain and the destination IP
address was substituted by the rule with DNAT target to 192.168.0.4. The
route decision then forwards this request through the FORWARD chain.
There, the rule with LOG target records this "bad guy" instance.What you said about the ping is correct but does not apply or help to
explain the situation we have here. Note that the 128.198.61.29 is
associated with the firewall machine's eth0 interface. Therefore it is
the firewall that is responding to the ping to 128.198.61.28 not the web
server which is behind the firewall. Even if we shut down the web
server, the firewall will still respond the ICMP echo request with ICMP
echo reply for 128.198.61.29.The lynx is a text-based web browser. The "lynx 128.198.61.29" command
will trigger the TCP Sync segment of the three way handshake to be sent
to the firewall. The destination IP address of the packet carrying TCP
Sync segment will be modified as 192.168.0.4 and routed to the FORWARD
chain and trigger the rule that matches the source IP address
128.198.162.60, logs and drops the packets.The explanation " So the lynx command tries to penetrate the firewall
and hence can result
in bad guy entries, whereas ping does not try to penetrate it to that
extent and the result is that the request only gets blocked and does not
get into the log as bad guy." Is not quite right. The firewall rules in
the forward chain drops the packet.Note that the situation we have here can also apply to some of server
clusters.Edward
-----Original Message-----
From: Sunil S. Bhave [mailto:ssbhave@cs.uccs.edu]
Sent: Friday, April 18, 2003 1:52 PM
To: chow@cs.uccs.edu
Subject: RE: HW3Dr Chow
Today is April 18, So I wonder why the date shown is Apr 1? Also if we
are doing lynx 128.198.61.29, why does the log shows DST as 192.168.0.4,
why does it now show 128.168.61.29? Why do we need to access
192.168.0.4 ?As I understand it, PING command is merely sending packets to the
intended machine and it is not expecting any data from the intended
machine except the acknowledgement. So the primary function of ping is
to check if the other machine is atleast alive or not. But ping alone
can not guarantee if the machine is up or not. Beacuse if the machine is
configured to not respond to ping requests, then it will not respond,
but the machine is still up.On the other hand, lynx is a web browser. When we do lynx url/ip address
it is going to ask for the index.html file on that server, using a tcp
connection. If the machine is behind the firewall, this entry may be
prohibited depending on the firewall setting. Also TCP connection may be
disallowed.So the lynx command tries to penetrate the firewall and hence can result
in bad guy entries, whereas ping does not try to penetrate it to that
extent and the result is that the request only gets blocked and does not
get into the log as bad guy.I hope my understanding is correct. Please correct me if I am wrong.
Thanks & Regards
Sunil> Sunil,
>
> I just repeated the experiment and the /var/log/messages was left with
> the following records.
>
> Apr 1 13:36:59 firewall kernel: bad guy:IN=eth0 OUT=eth1
> SRC=128.198.162.60 DST=192.168.0.4 LEN=60 TOS=0x00 PREC=0x00 TTL=62
> ID=27032 DF PROTO=TCP SPT=33362 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
> Apr 1 13:37:23 firewall kernel: bad guy:IN=eth0 OUT=eth1
> SRC=128.198.162.60 DST=192.168.0.4 LEN=60 TOS=0x00 PREC=0x00 TTL=62
> ID=27033 DF PROTO=TCP SPT=33362 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
>
> As I indicated, you probably only execute "ping 128.198.61.29" instead
> of use "lynx 128.198.61.29". Think about the difference and explain
> why ping 128.198.61.29 will not trigger the "bad guy" rule.
>
> Edward
>
>
> -----Original Message-----
> From: Sunil S. Bhave [mailto:ssbhave@cs.uccs.edu]
> Sent: Friday, April 18, 2003 11:37 AM
> To: chow@cs.uccs.edu
> Subject: HW3
>
> Dr Chow
>
> I have not yet received mail from you about what we discussed
> yesterday night.
>
> Following is what I have observed until yesterday for action 5
>
>
> Answer :
> [root@firewall firewall]# ./rejectHost.sh
> [ssbhave@blanca ~]$ ping 192.168.0.4
> PING 192.168.0.4 (192.168.0.4) from 128.198.162.60 : 56(84) bytes of
> data.
> It did not get any response.
>
> I tried to see if entries are present for the bad guy in messages
> file. I
> could not find the bad guy entries. I checked both firewall and rh8
> machines. Only entries I can see with bad guy are in firewall machine
> /var/log/messages but the date on that is mar 31, so it was not my
> packet
> that reached firewall for blocking. Another thing that I noticed is I
> did
> not see any April entries in that file. I suspect that the log command
> is
> not working as expected.
>
> Please let me know if there is any update.
>
> Thanks & Regards
>
> Sunil Bhave