[lug] outgoing port 220 exploit?

[rm at fabula.de]

On Mon, Jan 19, 2004 at 09:24:07AM -0700, David Anselmi wrote:
> As you've noticed, you can't sniff the packets if they are blocked by 
> ipchains.  

Depends? The OP most likely blocks these ports on his _outgoing_
interface (let's call it eth0 for now).  You can still sniff on 
the incomming interface (unless the packet is generated on the filtering host.

> They wouldn't tell you anything more than the ipchains logs 
> tell you anyway - src/dst ip/port - since they aren't actually going 
> out.  If you want to find out what the session is trying to do, open the 
> firewall and let it out.  Then you can capture the whole session and 
> probably figure out quite a bit.

Autsch. I'd hate to open up my firewall for debugging. Esp. when i have
the suspicion that something is rotten ...
How about:

 ifconfig lo:1 192.168.n.n 

(pick some network that the outgoing connection is trying to reach).
Then you can use 'tcpdump -i lo:1 -w dumpfile' to study the packets ...


> It is also problematic to figure out which process is trying to open the 
> connection.  strace would tell you, if you knew which program to trace. 
>  lsof will tell you, if you manage to run it while the socket it open. 
>  Looking below the IP stack (where ipchains and tcpdump operate) won't 
> tell you.  I don't see anything in /proc that connects processes to 
> sockets (not that I know what everything there means).

'netstat -paunte' should show you the pid of the process ...
(Does here, just tested it)

 Ralf Mattes

> D. Stimits wrote:
> [...]
> >
> >Ok I found out a pattern people might find interesting. More than one 
> >KRUD machine (so far KRUD 7.3 and 8.0) are both doing this. One after 
> >the other, as one tries an outbound port 220 from local port 6129, the 
> >other will also try the SAME outbound IP. So someone is doing something 
> >like a port scan that is triggering the port 220 relay attempt on 
> >separate machines. I am beginning to think the inbound trigger is some 
> >sort of broadcast or non-tcp trigger. Not sure yet.
> 
> You said these are SYN packets being blocked, right?  Is the interval 
> regular?  What destination IPs are there?  Posting the relevant logs 
> might get you better answers.
> 
> As for both machines doing this, what is the timing?  And what is the 
> difference between their clocks.  You mentioned mozilla, could this be 
> the "check for new mail every 10 minutes" feature?  Mozilla is an imap 
> client so maybe some built-in or misconfiguration is trying to use imap 
> (do you have any accounts set up in it that use imap?)
> 
> You can use tcpdump/ethereal to catch inbound traffic that triggers the 
> imap response but I doubt you'll see any.  And if there is any it would 
> be to a port that you listen on (if the machine has been rooted you 
> can't trust it to show you the truth, obviously).
> 
> Dave
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug