Actions
Bug #479
closed
Filter log doesn't properly drop some broken/unparsable lines
Start date:
04/04/2010
Due date:
% Done:
0%
Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.0
Affected Architecture:
Description
Reported by a user on IRC who had an infected/compromised machine on his LAN:
Some bad packets which show in the log with incomplete information should either be handled better or dropped entirely. Here is the raw log info from the time of the incident:
Mar 8 20:57:36 jailbox pf: 000041 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 49709, offset 0, flags [none], proto Options (0), length 20) 127.0.0.95 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000041 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 57716, offset 0, flags [none], proto Options (0), length 20) 127.0.0.156 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000042 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 60960, offset 0, flags [none], proto Options (0), length 20) 127.0.0.195 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000040 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 21550, offset 0, flags [none], proto Options (0), length 20) 127.0.0.99 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000041 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 36683, offset 0, flags [none], proto Options (0), length 20) 127.0.0.56 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000041 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 2582, offset 0, flags [none], proto Options (0), length 20) 127.0.0.3 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000042 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 19222, offset 0, flags [none], proto Options (0), length 20) 127.0.0.166 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000041 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 61008, offset 0, flags [none], proto Options (0), length 20) 127.0.0.103 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000041 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 18217, offset 0, flags [none], proto Options (0), length 20) 127.0.0.226 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000042 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 15374, offset 0, flags [none], proto Options (0), length 20) 127.0.0.111 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000046 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 46408, offset 0, flags [none], proto Options (0), length 20) 127.0.0.115 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000040 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 1058, offset 0, flags [none], proto Options (0), length 20) 127.0.0.211 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000043 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 6418, offset 0, flags [none], proto Options (0), length 20) 127.0.0.73 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000041 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 56656, offset 0, flags [none], proto Options (0), length 20) 127.0.0.31 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000041 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 21256, offset 0, flags [none], proto Options (0), length 20) 127.0.0.77 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000041 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 13888, offset 0, flags [none], proto Options (0), length 20) 127.0.0.119 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000042 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 1109, offset 0, flags [none], proto Options (0), length 20) 127.0.0.120 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000041 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 44, offset 0, flags [none], proto Options (0), length 20) 127.0.0.59 > 108.122.0.0: ip 0 Mar 8 20:57:36 jailbox pf: 000040 rule 42/0(match): block in on em1: (tos 0x7,CE, ttl 255, id 5922, offset 0, flags [none], proto Options (0), length 20) 127.0.0.40 > 108.122.0.0: ip 0
Updated by Jim Pingle over 14 years ago
- Status changed from New to Resolved
I added a check so that the protocol will show as "none" in the case of a packet like this happening in the future.
Actions