On 8/4/2014 9:33 AM, merc1...@f-m.fm wrote:
> 
> On Sun, Aug 3, 2014, at 11:52, Tom Eastep wrote:
>> On 8/3/2014 10:48 AM, Tom Eastep wrote:
>>> On 8/3/2014 10:03 AM, merc1...@f-m.fm wrote:
>>>>
>>>> Lately I've been noticing that something is hammering away trying to get
>>>> out ports 25 and 110.  Since I don't use those and they are closed, I am
>>>> suspicious.  https://pastee.org/k73u8  The destination IP isn't running
>>>> POP or SMTP either.
>>>>
>>>> Unfortunately, Shorewall doesn't have a mechanism to associate a PID to
>>>> an attempt, maybe because the info just isn't there.  I do find that it
>>>> is possible to turn on UID reporting, so I added (uid) to each INFO in
>>>> the policy file and restarted Shorewall, but I'm still not getting the
>>>> UID.
>>>> #SOURCE DEST    POLICY          LOG             LIMIT:         
>>>> CONNLIMIT:
>>>> #                               LEVEL           BURST           MASK
>>>> net     $FW     DROP            info(uid)
>>>> net     local   DROP            info(uid)
>>>> $FW     net     DROP            info(uid)
>>>> $FW     local   DROP            info(uid)
>>>> local   net     DROP            info(uid)
>>>> local   $FW     DROP            info(uid)
>>>> #
>>>> # THE FOLLOWING POLICY MUST BE LAST
>>>> #       
>>>> net     all     DROP            info(uid)
>>>> all     all     DROP            info(uid)
>>>> #LAST LINE -- DO NOT REMOVE
>>>>
>>>>
>>>> I need to put these 25 and 110 accesses with a PID to try and identify
>>>> this trojan.  I'm trying # netstat -apn|grep -w DPT=25 but that hasn't
>>>> caught anything yet, and it's not a real solution long-term.
>>>>
>>>> Any suggestions?
>>>>
>>
>> But your command is wrong. Should be:
>>
>>      netstat -tnap | fgrep :25
> 
> Thanks, but this isn't coming up with anything either, just like mine.
> 
> Surely this isn't the only solution?  In the future a trojan may try
> 3333 or 80.  My machines are very secure and run Debian, but somehow I
> got this bug.  I do use Tor for everything and run i2p.  But I need to
> trace this to find out what's going on.  Shorewall's console messages
> are the only evidence I have that this is happening, and I wish it would
> identify the process.

You can allow the connection in the NEW section but DROP the traffic in
the ESTABLISHED section. That way, the connection will be made and you
will be able to see it with netstat or ss, but no data will be sent.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to