[pfSense Support] New blocked traffic
I am seeing alot of the messages below. Is this any thing special I need to watch out for? These seemed to start recently and just want to see if this is something new or ??? I like to know what I am up against when I see increases in certain traffic and googling this(I may not know what to look for in this case) is not giving me a concrete answer as to what this is about. I am also seeing various source ip addresses. The ones I have checked have reverse lookups indicating DSL service. This is from a Soekris net4801 running pfSense 1.2.3rc1. Thanks, Lyle Giese LCR Computer Services, Inc. Jun 8 00:38:32 FW2 pf: 000410 rule 104/0(match): block in on ng0: (tos 0x0, ttl 47, id 53817, offset 0, flags [none], proto UDP (17), length 122) 99.180.11.164.61891 public ip.19295: UDP, length 94 Jun 8 00:38:33 FW2 pf: 483218 rule 104/0(match): block in on ng0: (tos 0x0, ttl 47, id 26629, offset 0, flags [none], proto UDP (17), length 122) 99.180.11.164.61891 public ip.19296: UDP, length 94 Jun 8 00:38:33 FW2 pf: 000821 rule 104/0(match): block in on ng0: (tos 0x0, ttl 47, id 5213, offset 0, flags [none], proto UDP (17), length 122) 99.180.11.164.61891 2public ip.19295: UDP, length 94 Jun 8 00:38:33 FW2 pf: 507076 rule 104/0(match): block in on ng0: (tos 0x0, ttl 47, id 39985, offset 0, flags [none], proto UDP (17), length 122) 99.180.11.164.61891 public ip.19296: UDP, length 94 Jun 8 00:38:33 FW2 pf: 000403 rule 104/0(match): block in on ng0: (tos 0x0, ttl 47, id 53069, offset 0, flags [none], proto UDP (17), length 122) 99.180.11.164.61891 public ip.19295: UDP, length 94 - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] New blocked traffic
Lyle Giese wrote: I am seeing alot of the messages below. Is this any thing special I need to watch out for? These seemed to start recently and just want to see if this is something new or ??? I like to know what I am up against when I see increases in certain traffic and googling this(I may not know what to look for in this case) is not giving me a concrete answer as to what this is about. I am also seeing various source ip addresses. The ones I have checked have reverse lookups indicating DSL service. This is from a Soekris net4801 running pfSense 1.2.3rc1. Thanks, Lyle Giese LCR Computer Services, Inc. Jun 8 00:38:32 FW2 pf: 000410 rule 104/0(match): block in on ng0: (tos 0x0, ttl 47, id 53817, offset 0, flags [none], proto UDP (17), length 122) 99.180.11.164.61891 public ip.19295: UDP, length 94 Jun 8 00:38:33 FW2 pf: 483218 rule 104/0(match): block in on ng0: (tos 0x0, ttl 47, id 26629, offset 0, flags [none], proto UDP (17), length 122) 99.180.11.164.61891 public ip.19296: UDP, length 94 Jun 8 00:38:33 FW2 pf: 000821 rule 104/0(match): block in on ng0: (tos 0x0, ttl 47, id 5213, offset 0, flags [none], proto UDP (17), length 122) 99.180.11.164.61891 2public ip.19295: UDP, length 94 Jun 8 00:38:33 FW2 pf: 507076 rule 104/0(match): block in on ng0: (tos 0x0, ttl 47, id 39985, offset 0, flags [none], proto UDP (17), length 122) 99.180.11.164.61891 public ip.19296: UDP, length 94 Jun 8 00:38:33 FW2 pf: 000403 rule 104/0(match): block in on ng0: (tos 0x0, ttl 47, id 53069, offset 0, flags [none], proto UDP (17), length 122) 99.180.11.164.61891 public ip.19295: UDP, length 94 I have another soekris running 2.0-BETA2 and seeing the following in the logs from it(it's not logging source or destination). Be nice to have the source ip address... Lyle Giese LCR Computer Services, Inc. Jun 8 21:47:21 proxy pf: 00:00:00.000350 rule 2/0(match): block in on sis0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 243) Jun 8 21:47:21 proxy pf: 00:00:00.000302 rule 2/0(match): block in on sis0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 235) Jun 8 21:47:21 proxy pf: 00:00:00.000290 rule 2/0(match): block in on sis0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 243) Jun 8 21:47:21 proxy pf: 00:00:00.000289 rule 2/0(match): block in on sis0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 243) J - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] New blocked traffic
I have another soekris running 2.0-BETA2 and seeing the following in the logs from it(it's not logging source or destination). Be nice to have the source ip address... Lyle Giese LCR Computer Services, Inc. Jun 8 21:47:21 proxy pf: 00:00:00.000350 rule 2/0(match): block in on sis0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 243) Jun 8 21:47:21 proxy pf: 00:00:00.000302 rule 2/0(match): block in on sis0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 235) Jun 8 21:47:21 proxy pf: 00:00:00.000290 rule 2/0(match): block in on sis0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 243) Jun 8 21:47:21 proxy pf: 00:00:00.000289 rule 2/0(match): block in on sis0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 243) On 2.0 the pf logs are split into two lines. You need the line after this to see the remainder of the log info. As for the ports you are seeing, they don't look familiar to me, but going by the list here: https://isc.sans.org/port.html They aren't common in terms of source or destination ports seen. https://isc.sans.org/port.html?port=19295 https://isc.sans.org/port.html?port=19296 https://isc.sans.org/port.html?port=61891 Jim - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] New blocked traffic
Jim Pingle wrote: I have another soekris running 2.0-BETA2 and seeing the following in the logs from it(it's not logging source or destination). Be nice to have the source ip address... Lyle Giese LCR Computer Services, Inc. Jun 8 21:47:21 proxy pf: 00:00:00.000350 rule 2/0(match): block in on sis0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 243) Jun 8 21:47:21 proxy pf: 00:00:00.000302 rule 2/0(match): block in on sis0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 235) Jun 8 21:47:21 proxy pf: 00:00:00.000290 rule 2/0(match): block in on sis0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 243) Jun 8 21:47:21 proxy pf: 00:00:00.000289 rule 2/0(match): block in on sis0: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 243) On 2.0 the pf logs are split into two lines. You need the line after this to see the remainder of the log info. That bytes! How does a simple syslog parser handle that to match the two lines together? How can you guarentee that the next line is the matching line and not from some other process sending stuff to syslog? As for the ports you are seeing, they don't look familiar to me, but going by the list here: https://isc.sans.org/port.html They aren't common in terms of source or destination ports seen. https://isc.sans.org/port.html?port=19295 https://isc.sans.org/port.html?port=19296 https://isc.sans.org/port.html?port=61891 Jim - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
Re: [pfSense Support] New blocked traffic
On 6/9/2010 9:35 AM, Lyle Giese wrote: On 2.0 the pf logs are split into two lines. You need the line after this to see the remainder of the log info. That bytes! How does a simple syslog parser handle that to match the two lines together? How can you guarentee that the next line is the matching line and not from some other process sending stuff to syslog? I don't like it either, but it's due to the way tcpdump parses things now when printing verbose information. I had to change the parser a lot to handle these lines locally. Remotely would be worse, but you could match on host pf: It's even trickier because not every line is split in two. You can look at the log parsing code in 2.0 for some insight into what was needed to overcome this. Jim - To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org