HUP

HUP

[Brent Clark]

Hi

I performed a netstat-nat on my fw.

And there is a entry that I dont like.

This is my employer working from home, probally left the remote desktop 
session open.

tcp   host81-153-16-165.range81-153.btcen:3191 
resmanager.eccotours.local:3389          ESTABLISHED

anyone know how I can just this kill this NATTED connection.

Any advice would be most appreciated.

Kind Regards
Brent Clark

RE: HUP

[Sietse van Zanen]

 Logon to the server.

Start Terminal Services manager and kill the connection


So far for stating the obvious.

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Brent Clark
Sent: 16 March 2005 15:15
To: iptables
Subject: HUP

Hi

I performed a netstat-nat on my fw.

And there is a entry that I dont like.

This is my employer working from home, probally left the remote desktop
session open.

tcp   host81-153-16-165.range81-153.btcen:3191 
resmanager.eccotours.local:3389          ESTABLISHED

anyone know how I can just this kill this NATTED connection.

Any advice would be most appreciated.

Kind Regards
Brent Clark

Re: HUP

[Steven M Campbell]

netstat --inet -p  will show you the attached process and you can kill 
that process.

scampbell@linux:~> netstat --inet -p -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         
State       PID/Program name
tcp        0      0 10.8.178.10:33819       22.33.44.123:22         
ESTABLISHED 8083/ssh
tcp        0      0 10.8.178.10:32795       64.12.165.101:5190      
ESTABLISHED 6984/gaim
tcp        0      0 10.8.178.10:33083       207.46.107.52:1863      
ESTABLISHED 6984/gaim

If I want to terminate that ssh connection I just  kill 8083

Brent Clark wrote:

> Hi
>
> I performed a netstat-nat on my fw.
>
> And there is a entry that I dont like.
>
> This is my employer working from home, probally left the remote 
> desktop session open.
>
> tcp   host81-153-16-165.range81-153.btcen:3191 
> resmanager.eccotours.local:3389          ESTABLISHED
>
> anyone know how I can just this kill this NATTED connection.
>
> Any advice would be most appreciated.
>
> Kind Regards
> Brent Clark
>
   

Re: HUP

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 16 Mar 2005, Brent Clark wrote:

> Hi
>
> I performed a netstat-nat on my fw.
>
> And there is a entry that I dont like.
>
> This is my employer working from home, probally left the remote desktop 
> session open.
>
> tcp   host81-153-16-165.range81-153.btcen:3191 
> resmanager.eccotours.local:3389          ESTABLISHED
>
> anyone know how I can just this kill this NATTED connection.
>

silly boy, yer trying to make this out to be something much more difficult 
then it is, cause you are forgetting admin basics.  ps -auxwww|grep bash. 
Yer trying to find the login shell and kill that process.

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com

...Love is the ultimate outlaw.  It just won't adhere to rules.
The most any of us can do is sign on as it's accomplice.  Instead
of vowing to honor and obey, maybe we should swear to aid and abet.
That would mean that security is out of the question.  The words
"make" and "stay" become inappropriate.  My love for you has no
strings attached.  I love you for free...
                         -Tom Robins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCOKLEst+vzJSwZikRAjPrAJ4zPEKuc9FE3tCZPFMdIhc+RqQmxgCgi8rm
CH18qN4NpHZtO8dber05foE=
=g4tg
-----END PGP SIGNATURE-----

Re: HUP

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



I've often found that killing the attached process can often leave the 
state of the connection in a funky way for sometime. and that it most the 
time serves better to kill the login shell.  Course, I tend to not kill as 
sweetly these busy days then I used to back a few years ago, and this 
might indeed have something to do with state left in limbo for timeout 
periods.

Thanks,

Ron DuFresne

On Wed, 16 Mar 2005, Steven M Campbell wrote:

> netstat --inet -p  will show you the attached process and you can kill that 
> process.
>
> scampbell@linux:~> netstat --inet -p -n
> Active Internet connections (w/o servers)
> Proto Recv-Q Send-Q Local Address           Foreign Address         State 
> PID/Program name
> tcp        0      0 10.8.178.10:33819       22.33.44.123:22 
> ESTABLISHED 8083/ssh
> tcp        0      0 10.8.178.10:32795       64.12.165.101:5190 
> ESTABLISHED 6984/gaim
> tcp        0      0 10.8.178.10:33083       207.46.107.52:1863 
> ESTABLISHED 6984/gaim
>
> If I want to terminate that ssh connection I just  kill 8083
>
> Brent Clark wrote:
>
>> Hi
>> 
>> I performed a netstat-nat on my fw.
>> 
>> And there is a entry that I dont like.
>> 
>> This is my employer working from home, probally left the remote desktop 
>> session open.
>> 
>> tcp   host81-153-16-165.range81-153.btcen:3191 
>> resmanager.eccotours.local:3389          ESTABLISHED
>> 
>> anyone know how I can just this kill this NATTED connection.
>> 
>> Any advice would be most appreciated.
>> 
>> Kind Regards
>> Brent Clark
>> 
>

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com

...Love is the ultimate outlaw.  It just won't adhere to rules.
The most any of us can do is sign on as it's accomplice.  Instead
of vowing to honor and obey, maybe we should swear to aid and abet.
That would mean that security is out of the question.  The words
"make" and "stay" become inappropriate.  My love for you has no
strings attached.  I love you for free...
                         -Tom Robins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCOKVgst+vzJSwZikRAtsiAJwIN9YEcGcpb70X5RHcnCHFXFPAJACcDd/9
yv9SoQijvEiajlSpfooL+qM=
=a34B
-----END PGP SIGNATURE-----

Re: HUP

[Brent Clark]

Sietse van Zanen wrote:
>  Logon to the server.
> 
> Start Terminal Services manager and kill the connection
> 
> 
> So far for stating the obvious.

Hi

Thanks for this, but I acctually had first tried this.

On logging on, I have found that with the Terminal Services manager, 
there literally no connections (no even disconnected sessions ) at the 
present time .

So im not sure if this is an old entry on the ip_conntrack or what, but 
it is been displayed when I try

conntrack-viewer.pl and / or  netstat-nat

weird.

Thanks
Kind Regards

Brent Clark

RE: HUP

[Sietse van Zanen]

Then indeed ip_conntrack must have a faulty connection in a bucket
somewhere. You might be able to get rid of it by flushing your tables
(reloading the firewall). Or rmmod the iptables modules.

I wouldn't worry too much about it though. It's probably the M$ client
behaving badly, not sending FINs correctly, or something like that. Many M$
clients are known to not close their connections correctly. It could
ofcourse also be a network hick-up, causing the client to forcably
disconnect but never closing the connection on TCP/IP level.

A reboot or reloading of the ip_conntrack module should fix it. Again, don't
worry too much about it. Better make sure your Terminal Services are
configured with idle session time-out limits etc.

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Brent Clark
Sent: 17 March 2005 08:08
To: iptables
Subject: Re: HUP

Sietse van Zanen wrote:
>  Logon to the server.
> 
> Start Terminal Services manager and kill the connection
> 
> 
> So far for stating the obvious.

Hi

Thanks for this, but I acctually had first tried this.

On logging on, I have found that with the Terminal Services manager, there
literally no connections (no even disconnected sessions ) at the present
time .

So im not sure if this is an old entry on the ip_conntrack or what, but it
is been displayed when I try

conntrack-viewer.pl and / or  netstat-nat

weird.

Thanks
Kind Regards

Brent Clark

Re: HUP

[Brent Clark]

Sietse van Zanen wrote:
> Then indeed ip_conntrack must have a faulty connection in a bucket
> somewhere. You might be able to get rid of it by flushing your tables
> (reloading the firewall). Or rmmod the iptables modules.
> 
> I wouldn't worry too much about it though. It's probably the M$ client
> behaving badly, not sending FINs correctly, or something like that. Many M$
> clients are known to not close their connections correctly. It could
> ofcourse also be a network hick-up, causing the client to forcably
> disconnect but never closing the connection on TCP/IP level.
> 
> A reboot or reloading of the ip_conntrack module should fix it. Again, don't
> worry too much about it. Better make sure your Terminal Services are
> configured with idle session time-out limits etc.

HI Sietse

A big thanks for this. Suppose im been a bit looney about this.

Suppose I should wait for the TTL to kick in (Wonder why its so high though)
192.168.10.100,3389                            tcp     ESTABLISHED 
70:09:29

Thanks again.

Brent Clark