Interesting... my "attacks" seem to come from botnets... I'm surprised that this is a deterrent, unless you mostly see single-host attacks...
Funny nonetheless...
On Sat, Dec 29, 2012 at 12:34 PM, <sampsa at mac.com> wrote:
> I usually just ignore that stuff. There is constant probing of my web server on MIM. It's kindof fun to see all kind of stuff they are trying. Also a good reference to see all kind of problems and exploits that exists on Unix and Windows web servers...
>
> (I *think* my RSX web server is actually pretty safe, but who knows...)
>
> Trying to retaliate would be an endless battle which I don't care about anyway...
>
But attacking them back is kinda funny, oh here's one more script in case there's no HTTP:
--- gohydra ---
#p1 = host, p2 = port, p3 = service
hydra -P ~/words -l fuckyou -s $2 $1 $3
--- end gohydra ---
On 2012-12-29 20:55, Peter Lothberg wrote:
But it is fun to see people fail. :-)
It is definitely fun to watch people try to break in to VMS. ;)
On Sol.Stupi.Se (59.10) they think it understands X.86 binaries..
I'm sure tehey don't even understand the stackpointer moves UP not
down on a DEC20/PDP10.
You are giving them way too much credit, Peter. I'm sure most of them would not even know what a stack pointer is... The stack is a magic object that keeps information around in your Java virtual machine...
Johnny
But it is fun to see people fail. :-)
It is definitely fun to watch people try to break in to VMS. ;)
On Sol.Stupi.Se (59.10) they think it understands X.86 binaries..
I'm sure tehey don't even understand the stackpointer moves UP not
down on a DEC20/PDP10.
-P
On Dec 29, 2012, at 2:34 PM, Johnny Billquist wrote:
On 2012-12-29 20:29, Paul_Koning at Dell.com wrote:
On Dec 28, 2012, at 4:44 PM, Johnny Billquist wrote:
...
Yes, VMS can route packets. Yes, all ethernet interfaces under DECnet phase IV will have the same MAC address. No, VMS have no idea of the concept of a bridge. And if you bridge two ethernet segments together, and VMS sits on both those segments, bad juju happens.
Actually, DEC nodes are quite aware of bridging -- DEC after all invented LAN bridging. The thing that you have to get right is that the multiple DECnet phase IV interfaces *must* be on distinct extended LANs. The changed MAC addresses are the reason why.
And I still claim that they are not bridging, but routing.
They do not ignorantly repeat any packets received on one interface out on other interfaces, which is what a bridge does.
I'd happily discuss this further, if you really disagree with me. :-)
I quite agree with you. "Routing" nodes are routing... I just disagreed with the comment that VMS nodes don't understand bridging. They don't DO it, but they understand it...
This changes with Phase V, since that doesn't change the MAC address (if it doesn't have to be Phase IV compatible, that is). Also, unlike Phase IV, Phase V supports end nodes with more than one interface.
Right. Phase V is a different story again. And I assume you mean endnodes with more than one active interface, as phase IV endnodes can also have more than one interface, but only one can be active.
Johnny
Yes, that's what I meant.
paul
On 2012-12-29 20:29, Paul_Koning at Dell.com wrote:
On Dec 28, 2012, at 4:44 PM, Johnny Billquist wrote:
...
Yes, VMS can route packets. Yes, all ethernet interfaces under DECnet phase IV will have the same MAC address. No, VMS have no idea of the concept of a bridge. And if you bridge two ethernet segments together, and VMS sits on both those segments, bad juju happens.
Actually, DEC nodes are quite aware of bridging -- DEC after all invented LAN bridging. The thing that you have to get right is that the multiple DECnet phase IV interfaces *must* be on distinct extended LANs. The changed MAC addresses are the reason why.
And I still claim that they are not bridging, but routing.
They do not ignorantly repeat any packets received on one interface out on other interfaces, which is what a bridge does.
I'd happily discuss this further, if you really disagree with me. :-)
This changes with Phase V, since that doesn't change the MAC address (if it doesn't have to be Phase IV compatible, that is). Also, unlike Phase IV, Phase V supports end nodes with more than one interface.
Right. Phase V is a different story again. And I assume you mean endnodes with more than one active interface, as phase IV endnodes can also have more than one interface, but only one can be active.
Johnny
On 29 Dec 2012, at 14:29, <Paul_Koning at Dell.com> wrote:
On Dec 28, 2012, at 4:44 PM, Johnny Billquist wrote:
...
Yes, VMS can route packets. Yes, all ethernet interfaces under DECnet phase IV will have the same MAC address. No, VMS have no idea of the concept of a bridge. And if you bridge two ethernet segments together, and VMS sits on both those segments, bad juju happens.
Actually, DEC nodes are quite aware of bridging -- DEC after all invented LAN bridging. The thing that you have to get right is that the multiple DECnet phase IV interfaces *must* be on distinct extended LANs. The changed MAC addresses are the reason why.
OpenVPN just became touchy and disallowed the MAC address change in my case.
This changes with Phase V, since that doesn't change the MAC address (if it doesn't have to be Phase IV compatible, that is). Also, unlike Phase IV, Phase V supports end nodes with more than one interface.
Can you have different addresses per interface in Phase V?
paul
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
On Dec 28, 2012, at 4:44 PM, Johnny Billquist wrote:
...
Yes, VMS can route packets. Yes, all ethernet interfaces under DECnet phase IV will have the same MAC address. No, VMS have no idea of the concept of a bridge. And if you bridge two ethernet segments together, and VMS sits on both those segments, bad juju happens.
Actually, DEC nodes are quite aware of bridging -- DEC after all invented LAN bridging. The thing that you have to get right is that the multiple DECnet phase IV interfaces *must* be on distinct extended LANs. The changed MAC addresses are the reason why.
This changes with Phase V, since that doesn't change the MAC address (if it doesn't have to be Phase IV compatible, that is). Also, unlike Phase IV, Phase V supports end nodes with more than one interface.
paul
Sampsa, the bridge is now quiet on my site as well. It was like you said just spitting out hash entries left and right. Now it's quiet and just sitting at:
Found match: sampsacom == sampsacom
Host table:
0: local 0.0.0.0:0 (Rx: 0 Tx: 0 (Drop rx: 0)) Active: 1 Throttle: 0(000)
1: sampsacom XX.XX.XX.XX:4711 (Rx: 0 Tx: 0 (Drop rx: 0)) Active: 1 Throttle: 0(000)
Hash of known destinations:
I think all is well. I'll need to get the apps on here next right?
Petar
From: Johnny Billquist <bqt at softjar.se>
To: hecnet at Update.UU.SE
Cc: sampsa at mac.com
Sent: Saturday, December 29, 2012 9:58 AM
Subject: Re: [HECnet] Node renamings
On 2012-12-29 15:54, sampsa at mac.com wrote:
> Debug output:
>
> Setting existing hash to bridge 1
> Setting existing hash to bridge 1
> Setting existing hash to bridge 1
> Setting existing hash to bridge 1
> Setting existing hash to bridge 1
> Setting existing hash to bridge 1
> Setting existing hash to bridge 1
> Setting existing hash to bridge 1
> Setting existing hash to bridge 1
> Setting existing hash to bridge 1
> Setting existing hash to bridge 1
> Setting existing hash to bridge 1
>
> 20-30 / sec, at least.
>
> Didn't use to be this rapid.
That is, I'd say, just an expected effect of having many machines and
routers on the bridge... Any time a packet comes in, this message is
output. And every router is regularly broadcasting packets. Add more
routers, and you'll get more packets.
Johnny
>
> Sampsa
>
>
>
> ---
> Sampsa Laine <sampsa at mac.com>
>
>
>
>
>
>
>
> On 29 Dec 2012, at 16:53, Johnny Billquist <bqt at softjar.se> wrote:
>
>> On 2012-12-29 15:42, sampsa at mac.com wrote:
>>> Johnny,
>>>
>>> Is everything ok on the bridge - whenever I turn mine on I get about 10-20 hashes / sec from your side and it kills my routing totally.
>>
>> What do you mean by "get about 10-20 hashes / sec"?
>>
>> Johnny
>>
>
On 2012-12-29 18:57, Dave McGuire wrote:
On 12/29/2012 10:00 AM, sampsa at mac.com wrote:
type nikkel::info.txt
%TYPE-W-SEARCHFAIL, error searching for NIKKEL::INFO.TXT;
-RMS-E-FND, ACP file or directory lookup failed
-SYSTEM-F-INVLOGIN, login information invalid at remote node
Won't work until there's a default FAL user and an INFO.TXT...
So what's supposed to be in this INFO.TXT file that everyone's been
talking about lately? I think I may be too much of a newcomer here to
know about it. Where should it be, and what should it contain?
Actually, thanks for reminding me. This is something someone should write up a page about. I'll happily put a link to that on the hecnet webpage... (Or host it, if needed.)
Johnny
On 29 Dec 2012, at 13:11, sampsa at mac.com wrote:
Nah, that stuff is like pre-alpha stuff, was just a demo.
Want me to add your nodes to the HELP scanner?
For my area, scan GEWT::INFO.TXT
I'll get around to updating it once I remember where all my nodes are.
On 29 Dec 2012, at 20:08, Dan Williams <williams.dan at gmail.com> wrote:
Hi,
Area 51 now has an info.txt on every node.
I am not showing up in the map you did the other day should I be worried ?
Dan
On 29 December 2012 10:36, <sampsa at mac.com> wrote:
If you don't want to send me a HLP file I can now automatically generate one from your INFO.TXT file.
Let me know if you want your node added to the automatically generated help file list.
Sampsa
--
Cory Smelosky
http://gewt.net/ Personal stuff!
http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.
