A question for the IPCHAINS folks out there. My curiosity has got the better of me & I would like to find out more about these particular entries that are showing up in our messages log. F.Y.I, The box is an RH 6.2 firewall/router on a broadband connection & ppp0 is our external i/f. When users connect to micro$oft.com through a proxy server that hangs off this box, I get the following denied traffic;

Jan 16 09:37:00 gateway kernel: Packet log: input REJECT ppp0 PROTO=6 207.46.197.102:65535 203.10.nnn.nnn:65535 L=28 S=0x00 I=52072 F=0x00B8 T=51 (#68)
Jan 16 09:51:01 gateway kernel: Packet log: input REJECT ppp0 PROTO=6 207.46.230.219:65535 203.10.nnn.nnn:65535 L=28 S=0x00 I=42637 F=0x00B8 T=49 (#68)


N.B. Our proxy server is 203.10. . in this case & I have replaced the last 2 octets in this example with nnn.nnn

Because both source and destination tcp ports are the same in this example, I can't tell which direction the denied traffic was heading. From my limited understanding, because the SYN bit was not set, the traffic appear to have originated from the 207.46 end (i.e. micro$oft.com) - or have I got it arse-about & am totally clueless :-)

Why would both the source and the destination ports be the same & why would they pick the highest possible tcp port # ?.

I have one word to say "FRAGMENTATION"

The incoming packet was fragmented from that address, so it has no data on the source port or destination as that's in the header of the first ip. "which wasn't rejected"

Always drop fragmented packets! or make sure the kernel rebuilds them before the firewall does. "you can have a major DOS attack on yourself if you do allow them, so it's better just to drop them"
I don't know if it's the same but in RH7.0 you would use "echo 1 > /proc/sys/net/ipv4/ip_always_defrag" to do this.
Then a rule in ipchains to drop all fragmented packets.

check out your ipchains rule no, 68 to see if this is the case.
ipchains -v -n --68 -L input

It's fragmenting because the packets MTU's are too large when coming into your interface. "should be 1500"

/Raz

Raz,

Thanks for the reply & tips on possible DOS vulnerability. Packet fragmentation didn't cross my mind. I'll check the kernel & ipchains fragmentation handling when next in the office.

About the your comment on MTU size. Our ppp i/f uses pppoe & hence adsl to connect to our ISP. My understanding is that the MTU size on an xDSL connection had to be less than 1500 bytes. From memory, there is an entry in our pppoe.conf file that sets the MTU at 1412 bytes.

The MTU size mis-match could also explain why sometimes I get this in /var/log/messages

Jan 16 17:59:57 gateway pppoe[803]: Packet too big! Check MTU on PPP interface

I know its a bit OT, but I can't find much useful info on this error. Your thoughts would be appreciated.

David.

P.S. Can I assume from the REJECT entry from my first post that ipchains is indeed blocking (dropping ??) fragmented packets, but it really should be DENYing to prevent a response message going back out.

Ok now I'm going to have to get technical..

The MTU should be 1500 for most devices as the router that's talking to your DSL will have this setting.

Other MTU's would be:
65535 = Hyperchannel
17914 = 16 Mbit/sec token ring
8166 = Token Bus (IEEE 802.4)
4464 = 4 Mbit/sec token ring (IEEE 802.5)
1500 = Ethernet
1500 = PPP (typical; can vary widely)
576 = X.25 Networks


The problem is cause because your MTU is lower then 1500, So when TCP packets go out of your DSL the MSS "maximum segment size" is announced when establishment of a new TCP connection is made, so the responding server turns the DF bit off so the routers can fragment to your allowed MTU size.

The main problems you have is that the MTU is set to 1412.
And your ipchains script probably has denied all ICMP responses out.

If a ICMP can't fragment error "type 3 code 4 " cannot get back to the source host due to the filter, the host will never know that the packets it is sending are too large.
This means it will keep trying to send the same large packet, and it will keep being dropped--silently dropped from the view of any system on the other side of the filter.

I would change the MTU to 1500 and allow the correct ICMP messages to get back to the source, ICMP messages are an important part of a healthy network, only drop the following type of ICMP messages on a firewall.

Allow out of network:
required-option-missing
parameter-problem
ip-header-bad
TOS-host-unreachable
source-route-failed
network-unknown
echo-reply
timestamp-reply
address-mask-reply
fragmentation-needed

Don't Allow out of network:

time-exceeded
destination-unreachable
network-unreachable
host-unreachable
protocol-unreachable
port-unreachable
host-unknown
network-prohibited
host-prohibited
TOS-network-unreachable
communication-prohibited
host-precedence-violation
precedence-cutoff
source-quench
redirect
network-redirect
host-redirect
TOS-network-redirect
TOS-host-redirect
echo-request
router-advertisement
router-solicitation
ttl-zero-during-transit
ttl-zero-during-reassembly
timestamp-request
address-mask-request

/Raz

Raz, why does it show the -(s,d)port like this?
Is this some bizarre form of defaulting by the kernel's fwcode?
Does netfilter/iptables show this behaviour as well?

Hi unSpawn,
I'm guessing it's the default option if ipchains can't see the header with the source and destination data.

I never let frag packets get to the stage when they would be logged on an iptables firewall due to the overlap frag problem lots of firewalls fall victim to so I've never seen a frag log entry.

Maybe I'll test this a see what it show when I get time.

/Raz