Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 8 replies
  • Subscribers 0 subscribers
  • Views 2396 views
  • Users 0 members are here
Options
Suggested

[8.270][BUG][FIXED] Snort continuously restarts

BAlfson
Roughly every three minutes yesterday until 18:06, which was right after I did shutdown -r now at the console.  Not seeing the problem now.

Any log info I could show?

Cheers - Bob
  • 0 
    Astaro Beta Report
    --------------------------------
    Version: 8.270
    Type: BUG
    State: RESOLVED/FIXED
    Reporter: BAlfson+
    Contributor: 
    MantisID: 19614
    Target version: 8.301
    Fixed in version: 
    --------------------------------

  • 0
    Here are selected lines from the IPS and Kernal logs meged together in chronometric order: 
    2011:11:18-00:33:00 post snort[5311]: *** Caught Term-Signal

    2011:11:18-00:33:41 post kernel: [164854.541086] mdw.plx[5093]: segfault at c ip b7419f50 sp bfc07640 error 4 in libperl.so[b7341000+150000]

    2011:11:18-00:36:36 post snort[7630]: *** Caught Term-Signal

    2011:11:18-00:36:20 post kernel: [165014.178319] mdw.plx[7201]: segfault at c ip b7489f50 sp bfff8360 error 4 in libperl.so[b73b1000+150000]

    2011:11:18-00:39:36 post snort[9988]: *** Caught Term-Signal

    2011:11:18-00:39:44 post kernel: [165217.850044] red_server.plc[9418]: segfault at 65c ip b755a472 sp bfeff5a0 error 4 in libperl.so[b74c9000+150000]

    2011:11:18-00:42:27 post snort[12077]: *** Caught Term-Signal

    2011:11:18-00:42:30 post kernel: [165383.893715] red_server.plc[11352]: segfault at 44 ip b74a248f sp bffdda70 error 6 in libperl.so[b7411000+150000]

    2011:11:18-00:45:17 post snort[14673]: *** Caught Term-Signal

    2011:11:18-00:48:15 post snort[16613]: *** Caught Term-Signal

    2011:11:18-00:51:12 post snort[18856]: *** Caught Term-Signal

    2011:11:18-00:53:58 post snort[20776]: *** Caught Term-Signal

    2011:11:18-00:56:51 post snort[22681]: *** Caught Term-Signal

    2011:11:18-00:59:37 post snort[24641]: *** Caught Term-Signal

    2011:11:18-01:05:20 post snort[28632]: *** Caught Term-Signal

    2011:11:18-01:07:57 post snort[30326]: *** Caught Term-Signal

    2011:11:18-01:10:58 post snort[32254]: *** Caught Term-Signal

    2011:11:18-01:14:04 post snort[1441]: *** Caught Term-Signal

    2011:11:18-01:16:20 post kernel: [167413.594071] mdw.plx[2092]: segfault at c ip b7453f50 sp bfaf26c0 error 4 in libperl.so[b737b000+150000]

    2011:11:18-01:16:59 post snort[3863]: *** Caught Term-Signal

    2011:11:18-01:19:55 post snort[6025]: *** Caught Term-Signal

    2011:11:18-01:22:31 post kernel: [167785.072064] red_server.plc[6392]: segfault at b7510430 ip b7510430 sp bf8f3d1c error 4

    2011:11:18-01:22:43 post snort[7992]: *** Caught Term-Signal

    2011:11:18-01:25:32 post snort[9925]: *** Caught Term-Signal

    2011:11:18-01:28:03 post kernel: [168117.452250] red_server.plc[10217]: segfault at 44 ip b744348f sp bfa69e70 error 6 in libperl.so[b73b2000+150000]

    2011:11:18-01:28:22 post snort[11831]: *** Caught Term-Signal

    2011:11:18-01:31:13 post snort[13797]: *** Caught Term-Signal

    2011:11:18-01:34:12 post snort[15620]: *** Caught Term-Signal

    2011:11:18-01:36:57 post snort[17709]: *** Caught Term-Signal

    2011:11:18-01:39:26 post kernel: [168799.795079] mdw.plx[17946]: segfault at c ip b743df50 sp bfe899d0 error 4 in libperl.so[b7365000+150000]

    2011:11:18-01:39:53 post snort[19655]: *** Caught Term-Signal

    2011:11:18-01:39:58 post kernel: [168832.157038] red_server.plc[18195]: segfault at 44 ip b744948f sp bfbcc690 error 6 in libperl.so[b73b8000+150000]


    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    This began again Sunday morning and didn't stop until I restored a backup from 2011-11-16.  The Kernal, IPS, Wireless Security asnd Middleware logs were clean through the end of the day on the 19th.  There was no one on the Astaro either locally or remotely at midnight.

    The Kernal log first indicates segaults: 
    2011:11:20-00:25:48 astaro kernel: [122637.884080] mdw.plx[20128]: segfault at c ip b7558f50 sp bf9c9db0 error 4 in libperl.so[b7480000+150000]

    2011:11:20-00:58:49 astaro kernel: [124618.998065] red_server.plc[11291]: segfault at 65c ip b747f472 sp bfbcffb0 error 4 in libperl.so[b73ee000+150000]


    Intrusion Prevention begins showing Term-Signals beginning with the following - there were 393 more restarts on the 20th, and that continued apace until I restored today from backup: 
    2011:11:20-00:23:04 astaro snort[7452]: Run time for packet processing was 122280.210347 seconds

    2011:11:20-00:26:10 astaro snort[20926]: Run time for packet processing was 107.25724 seconds


    Although I have no Access Point connected at present, Wireless Security is active, and the following appears at the beginning of that log on the 20th.  The last five lines are repeated for the rest of the day 

    2011:11:20-00:21:38 astaro awed[6106]: received termination signal

    2011:11:20-00:21:39 astaro awed[6106]: terminating.

    2011:11:20-00:21:46 astaro awed[18849]: Awed version 1.4.2.57.2.19 starting

    2011:11:20-00:21:46 astaro awed[18849]: access point firmware available: AP10:2013 AP50:2013 AP30:2013

    2011:11:20-00:22:02 astaro awed[18849]: configuration: 0 APs, 4 networks, 0 network groups

    2011:11:20-00:24:18 astaro awed[18849]: received termination signal

    2011:11:20-00:24:18 astaro awed[18849]: terminating.


    Middleware begins as attached, and then repeats all but the first four lines continuously.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    I checked your attached mdw log file (mdw-2011-11-20-beginning.txt) and am a bit stuck about the fact that you see this error at all.  Can you please state what you specified in the DNAT rule in the 'Destination:' entry box?  If this an autogenerated DNAT rule (rare, but possible) we may need some debugging.
  • 0
    I'm not sure which DNAT interests you.  The 'Destination Translation' in each active DNAT is one of the Host definitions for our SBS. Not one Host/Network definition in this Astaro or any other I work on is bound to an interface.  No DNAT has changed since upgrading from 7.511 in October.

    What's strange is that this problem started shortly after midnight each time; once under 8.270 and once under 8.281.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    You have a couple of errors 

    2011:11:20-00:23:04 astaro middleware[18226]: E Failed: /sbin/ip -f inet route add table 252 to local default/0 dev lo ..........
    and
    2011:11:20-00:25:43 astaro middleware[20128]: E Failed: /sbin/ip -f inet route add table 252 to local default/0 dev lo

    but I don't see the relevance either since snort listens on an interface and doesn't care about the routes.

    Regards
    Bill
  • 0 in reply to BAlfson
    I'm not sure which DNAT interests you.  The 'Destination Translation' in each active DNAT is one of the Host definitions for our SBS. Not one Host/Network definition in this Astaro or any other I work on is bound to an interface.  No DNAT has changed since upgrading from 7.511 in October.

    Cheers - Bob


    Yes, but changes within ASG could trigger this, esp. because it's happening after the up2date.

    I'm talking about the error 'Can't locate object method "NetmaskBits" via package "modules::Set" at /modules/IPTables/Rule/Nat.pm line 545'.  It is unclear why you see this error at all, as 'Destination Translation' does not use Sets.  I tried to reproduce this with several DNAT rules, but didn't succeed.  Very strange this is.

    Please attach a mdw.log if this error happens again.  Until then I'll postpone it because being unreproducible here.
  • 0
    The issue in mdw.log has been reproducible after all, a fixed has been queued for 8.300.
Unfiltered HTML