[pfSense Support] New blocked traffic

2010-06-09 Thread Lyle Giese
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

2010-06-09 Thread Lyle Giese
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

2010-06-09 Thread Jim Pingle
 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

2010-06-09 Thread Lyle Giese
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

2010-06-09 Thread Jim Pingle
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