Hey,

Anyone know how to clear the memory of a hack attempt determined by Synchronet? Basically I'm trying to write OSSEC rules, /and/ test them by repeatedly hammering the server with random usernames (pulled from /usr/share/dict/words randomly).

So far, I'm getting very close to finishing up a decoder and alert responce action, but as I keep testing, it keeps slowing down because of the slowdown options Synchronet has in sbbs.ini for this.

I just want to clear the attempts (it's not being blocked/canned specifically), and let it start back over from scratch as if it's the first time ever. :)


And if anyone is interested in this afterwards, I'll be offering it to anyone, probably via my Wiki or BBS website, so people can make use of it, since OSSEC can be a rather "fun" product to use. hehe

)))[Psi-Jack -//- Decker]

... One fifth of the people are against everything all the time.

---
þ Synchronet þ Decker's Heaven -//- bbs.deckersheaven.com

Re: Hack Attempt Log -- How to purge that..
By: Psi-Jack to All on Sun Jul 26 2015 10:52 am

Anyone know how to clear the memory of a hack attempt determined by Synchronet?

Just editing the hack log and logging in with the correct password should do the trick.


---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Hack Attempt Log -- How to purge that..
By: Psi-Jack to All on Sun Jul 26 2015 10:52 am

Hey,

Anyone know how to clear the memory of a hack attempt determined by Synchronet? Basically I'm trying to write OSSEC rules, /and/ test them by repeatedly hammering the server with random usernames (pulled from /usr/share/dict/words randomly).

So far, I'm getting very close to finishing up a decoder and alert responce action, but as I keep testing, it keeps slowing down because of the slowdown options Synchronet has in sbbs.ini for this.

I just want to clear the attempts (it's not being blocked/canned specifically), and let it start back over from scratch as if it's the first time ever. :)

Stopping and restarting sbbs will clear the login attempt counters. Also, logging in with a valid username/password will clear that IP address from the login attempt counters.

digital man

Synchronet "Real Fact" #16:
"Vertrauen" (ver-trow-en) translates to "trust" in German, and was a band name. Norco, CA WX: 63.5øF, 92.0% humidity, 3 mph SE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Hack Attempt Log -- How to purge that..
By: Deuce to Psi-Jack on Sun Jul 26 2015 10:35 pm

Anyone know how to clear the memory of a hack attempt determined by
Synchronet?

Just editing the hack log and logging in with the correct password should do the trick.

Heh. I seemed to have been caught between a chicken and egg problem. While I had truncated the hack.log, restarted sbbs, ossec, I didn't realize, was also performing auto-responce by blocking the IP for a time frame.

Which is perfect, and what I wanted, I just didn't know it did that at level 9, or at all by default. :)

Either way. I now have it setup so that OSSEC handles it more directly, and Synchronet is configured to only account for 2 nick attempts that are unique before reporting. The 5th failed attempt of course will yield a firm iptables response.

Now, if only Synchronet logged the actual IP address of an Unknown user in the syslog, on the same line as the unknown user, username, etc. OSSEC has very minimal log parsing functionality, and so long as it can find all its details it needs to match on on a single line, it can be useful. hack.log was a special case since it's a multiline with a specific number of lines, which is also plausible with OSSEC.

)))[Psi-Jack -//- Decker]

... The house of Lords is the British Outer Mongolia for retired politicians.

---
þ Synchronet þ Decker's Heaven -//- bbs.deckersheaven.com

Re: Hack Attempt Log -- How to purge that..
By: Psi-Jack to Deuce on Mon Jul 27 2015 09:12 am

Re: Hack Attempt Log -- How to purge that..
By: Deuce to Psi-Jack on Sun Jul 26 2015 10:35 pm

Anyone know how to clear the memory of a hack attempt determined by
Synchronet?

Just editing the hack log and logging in with the correct password should do the trick.

Heh. I seemed to have been caught between a chicken and egg problem. While I had truncated the hack.log, restarted sbbs, ossec, I didn't realize, was also performing auto-responce by blocking the IP for a time frame.

Truncating the hack.log won't actually change the behavior of sbbs at all.

Which is perfect, and what I wanted, I just didn't know it did that at level 9, or at all by default. :)

Either way. I now have it setup so that OSSEC handles it more directly, and Synchronet is configured to only account for 2 nick attempts that are unique before reporting. The 5th failed attempt of course will yield a firm iptables response.

Now, if only Synchronet logged the actual IP address of an Unknown user in the syslog, on the same line as the unknown user, username, etc. OSSEC has very minimal log parsing functionality, and so long as it can find all its details it needs to match on on a single line, it can be useful. hack.log was a special case since it's a multiline with a specific number of lines, which is also plausible with OSSEC.

So, is that a feature request or is parsing the hack.log sufficient for your needs?

digital man

Synchronet "Real Fact" #58:
Synchronet apparel and merchandise can be purchased at cafepress.com/synchronet Norco, CA WX: 80.5øF, 51.0% humidity, 12 mph SE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Hack Attempt Log -- How to purge that..
By: Digital Man to Psi-Jack on Mon Jul 27 2015 04:59 pm

Anyone know how to clear the memory of a hack attempt determined by
Synchronet?

Just editing the hack log and logging in with the correct password
should do the trick.

Heh. I seemed to have been caught between a chicken and egg problem.
While I had truncated the hack.log, restarted sbbs, ossec, I didn't
realize, was also performing auto-responce by blocking the IP for a
time frame.

Truncating the hack.log won't actually change the behavior of sbbs at all.

Yeah, I thought it might not, but in my rapid testing, I couldn't see much of a difference in it. I think mostly just restarting sbbs allowed me to progress faster, and adjusting sbbs.ini settings for the settings involved.

Which is perfect, and what I wanted, I just didn't know it did that at
level 9, or at all by default. :)

Either way. I now have it setup so that OSSEC handles it more
directly, and Synchronet is configured to only account for 2 nick
attempts that are unique before reporting. The 5th failed attempt of
course will yield a firm iptables response.

Now, if only Synchronet logged the actual IP address of an Unknown
user in the syslog, on the same line as the unknown user, username,
etc. OSSEC has very minimal log parsing functionality, and so long as
it can find all its details it needs to match on on a single line, it
can be useful. hack.log was a special case since it's a multiline with
a specific number of lines, which is also plausible with OSSEC.

So, is that a feature request or is parsing the hack.log sufficient for your needs?

Actually... I have 2 feature requests. Both very small and minor, but for the purpose of log analysis (and some limitations in them too).

Synchronet itself logs unknown login attempts, but does not provide any more details on the same line. I'd honestly prefer OSSEC to watch that, specifically, but I need more details. Specifically what would be nice on that is three key parts. The username being attempted, which is already there. The ip address (or dns.name [ip.add.ress]), and the port number being failed on
(23 for telnet, 22 for ssh, etc etc). OSSEC as it is sadly can't/won't parse named ports, but will work with numerical ports.

The reason I'd rather use the UNKNOWN user, is those are obviously 90% going to be bots or real hack attempt events, and would specifically allow identification of a series of attempts, even if to the same username with different password.

Second would be on the FAILED password attempts, the same information. And in some ways, I'd prefer that the actual password not be logged, though the attempted password is fine. I know at the sysop level, watching the logs and seeing that, you could tell if someone is just making a typo, but I can also do that by directly using the user editor and looking at their password there and comparing. Not logging the actual password itself would be preferred, but not specifically what I'm asking for, though. Just origin IP address and destination port (source port could be tracked too, but I usually find that's less relevant, however /sometimes/ useful even still.)

If these were added I could work with OSSEC a little further, making it monitor both srcip, dstport, dstuser, and should it be a simple matter of a user typoing their password, I could both account for multiple failed attempts to the same user, multiple users, and escelate to auto-responce or de-escelate upon successful login (which also adds, the need for those srcip, dstport, dstuser on successful Logon too, which is a 3rd feature request. :)


There was one feature/bug I noticed too in the hack.log, in the case of the AUT LOGIN type being used, if \n existed in the username (maybe password field too, not sure)., where that was treated literally and printed as such in the hack.log, causing:

SUSPECTED RLogin LOGIN HACK ATTEMPT for user 'blah
' on Mon Jul 27 2015 09:35pm
Using port 53978 at hostname [ip.add.re.ss]
Details: blah

As OSSEC can only do specific multiline parsing on consistent line numbers, this breaks that consistency by outputting 5, or even potentially 6 with the Details line if that's not accounted for there too.

)))[Psi-Jack -//- Decker]

... If it was a bet, you wouldn't take it.

---
þ Synchronet þ Decker's Heaven -//- bbs.deckersheaven.com

Re: Hack Attempt Log -- How to purge that..
By: Psi-Jack to Digital Man on Mon Jul 27 2015 09:46 pm

Now, if only Synchronet logged the actual IP address of an Unknown
user in the syslog, on the same line as the unknown user, username,
etc. OSSEC has very minimal log parsing functionality, and so long as
it can find all its details it needs to match on on a single line, it
can be useful. hack.log was a special case since it's a multiline with
a specific number of lines, which is also plausible with OSSEC.

So, is that a feature request or is parsing the hack.log sufficient for your needs?

Actually... I have 2 feature requests. Both very small and minor, but for the purpose of log analysis (and some limitations in them too).

Synchronet itself logs unknown login attempts, but does not provide any more details on the same line.

When you say 'Synchronet', I think you might be referring specifically to the terminal server and not all Synchronet servers and services. The method and form of the logging failed login attempts in the non-terminal servers/services is varied. The only common log (to all servers/services) is the hack.log.

I'd honestly prefer OSSEC to watch that,
specifically, but I need more details. Specifically what would be nice on that is three key parts. The username being attempted, which is already there. The ip address (or dns.name [ip.add.ress]), and the port number being failed on
(23 for telnet, 22 for ssh, etc etc). OSSEC as it is sadly can't/won't parse named ports, but will work with numerical ports.

So you want to add the source IP (or hostname) and the destination TCP port to all failed login attempts? That would make those specific log entries pretty long. I'll give it some thought.

The reason I'd rather use the UNKNOWN user, is those are obviously 90% going to be bots or real hack attempt events, and would specifically allow identification of a series of attempts, even if to the same username with different password.

Second would be on the FAILED password attempts, the same information. And in some ways, I'd prefer that the actual password not be logged, though the attempted password is fine.

If you don't want the password logged, set SCFG->System->Toggle Options->Echo Passwords Locally to "No".

I know at the sysop level, watching the logs and
seeing that, you could tell if someone is just making a typo, but I can also do that by directly using the user editor and looking at their password there and comparing. Not logging the actual password itself would be preferred, but not specifically what I'm asking for, though. Just origin IP address and destination port (source port could be tracked too, but I usually find that's less relevant, however /sometimes/ useful even still.)

With the "Echo Password Locally" option to set "No", neither the correct password nor the attempted password are logged.

If these were added I could work with OSSEC a little further, making it monitor both srcip, dstport, dstuser, and should it be a simple matter of a user typoing their password, I could both account for multiple failed attempts to the same user, multiple users, and escelate to auto-responce or de-escelate upon successful login (which also adds, the need for those srcip, dstport, dstuser on successful Logon too, which is a 3rd feature request. :)

I think parsing the hack.log might be a better plan. If you lower the LoginAttemptHackThreshold value to "1", all failed login attempts will be logged in the hack.log and it sounds like it has all the information you need except for the destination port number (which could be derived from the protocol name which is logged).

There was one feature/bug I noticed too in the hack.log, in the case of the AUT LOGIN type being used, if \n existed in the username (maybe password field too, not sure)., where that was treated literally and printed as such in the hack.log, causing:

SUSPECTED RLogin LOGIN HACK ATTEMPT for user 'blah
' on Mon Jul 27 2015 09:35pm
Using port 53978 at hostname [ip.add.re.ss]
Details: blah

As OSSEC can only do specific multiline parsing on consistent line numbers, this breaks that consistency by outputting 5, or even potentially 6 with the Details line if that's not accounted for there too.

Yes, I made a note of it.

digital man

Synchronet "Real Fact" #53:
The Synchronet source code consists of over 500,000 lines of C and C++.
Norco, CA WX: 68.8øF, 74.0% humidity, 5 mph SE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Hack Attempt Log -- How to purge that..
By: Digital Man to Psi-Jack on Mon Jul 27 2015 09:53 pm

Now, if only Synchronet logged the actual IP address of an Unknown
user in the syslog, on the same line as the unknown user, username,
etc. OSSEC has very minimal log parsing functionality, and so long
as it can find all its details it needs to match on on a single
line, it can be useful. hack.log was a special case since it's a
multiline with a specific number of lines, which is also plausible
with OSSEC.

So, is that a feature request or is parsing the hack.log
sufficient for your needs?

Actually... I have 2 feature requests. Both very small and minor, but
for the purpose of log analysis (and some limitations in them too).

Synchronet itself logs unknown login attempts, but does not provide
any more details on the same line.

When you say 'Synchronet', I think you might be referring specifically to the terminal server and not all Synchronet servers and services. The method and form of the logging failed login attempts in the non-terminal servers/services is varied. The only common log (to all servers/services) is the hack.log.

Well, honestly, it's mostly just limitations of OSSEC that I'd like to get around. OSSEC is still pretty much the #1 OpenSource HIDS, but it has it's limitations even still.

In short, since SyncTERM dropped connection last time I tried to reply, what I really would like is the hack.log to report just a little more details.

For UNKNOWN users, I'd like it to specifically say UNKNOWN somewhere on the
log entry. Along with that, the service port number attempted on. With those two specific details I could setup OSSEC to handle UNKNOWN users and known users differently and detect port variations as well.

In example:

SUSPECTED RLogin LOGIN HACK ATTEMPT for UNKNOWN user 'blah' on Mon Jun 27 2015 09:35pm
Using port 53978 at myhostname.com:513 [123.145.167.189:513]
Details: pass

Something as simple as that would allow for OSSEC to account for an unknown user more accurately, as well as a known user just typing in their password wrong, without the UNKNOWN part.

Along with that however, the actual successful login of a user as well, I would need details just the same.

Say user X types their password wrong once, maybe twice. No big deal, it happends. But they've already got OSSEC watching, preparing to respond with brute firewall force. ;)

On the actual /successful/ login, either by way of the hack.log, or by the standard syslog, I need an IP address, a destination port, a means to tell specifically that it was successful, and of course the username that logged in, so that I can get OSSEC to de-escelate the alert level down. Otherwise the only thing left is letting the interval time pass on which is ~10 minutes.

With all the above logged, I could respond to a single port, and escelate further of the occurance continues on multiple ports and take more lethal reactions, instead of just outright banning the IP entirely.

So you want to add the source IP (or hostname) and the destination TCP port to all failed login attempts? That would make those specific log entries pretty long. I'll give it some thought.

syslog spec itself is 1KiB (1024 bytes), however, most distros come with rsyslog installed standard, which defaults to 2KiB (2048 bytes). Of course that can be longer than even that, but that's more for special cases.

The important factor overall is, OSSEC cannot parse string port-names. It will actually fail silently than attempt to guess at what it means. Likewise, for DNS names it will not parse those either. Both of those things are handy for people visually reading the log, but not for parsing analysis anyway.

)))[Psi-Jack -//- Decker]

... Black holes are outa sight!

---
þ Synchronet þ Decker's Heaven -//- bbs.deckersheaven.com

Re: Hack Attempt Log -- How to purge that..
By: Psi-Jack to Digital Man on Tue Jul 28 2015 10:35 am

For UNKNOWN users, I'd like it to specifically say UNKNOWN somewhere on the log entry. Along with that, the service port number attempted on. With
those two specific details I could setup OSSEC to handle UNKNOWN users and known users differently and detect port variations as well.

In example:

SUSPECTED RLogin LOGIN HACK ATTEMPT for UNKNOWN user 'blah' on Mon Jun 27 2015 09:35pm
Using port 53978 at myhostname.com:513 [123.145.167.189:513]
Details: pass

Something as simple as that would allow for OSSEC to account for an unknown user more accurately, as well as a known user just typing in their password wrong, without the UNKNOWN part.

Along with that however, the actual successful login of a user as well, I would need details just the same.

Say user X types their password wrong once, maybe twice. No big deal, it

are you really getting attacked this bad or is this your assburger's syndrome showing itself?
---
þ Synchronet þ ::: BBSES.info - free BBS services :::

Re: Hack Attempt Log -- How to purge that..
By: Mro to Psi-Jack on Tue Jul 28 2015 14:49:48

are you really getting attacked this bad or is this your assburger's

I dont know about him, but I am. Logon prompt node 1, then logon prompt node 2, and node 1 stops, ad infinitum. All day long. Nobody ever logs in, and the ip address is untraceable.
--- SBBSecho 2.27-Win32
* Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

29 Jul 15 22:18, you wrote to Mro:

Re: Hack Attempt Log -- How to purge that..
By: Mro to Psi-Jack on Tue Jul 28 2015 14:49:48

are you really getting attacked this bad or is this your assburger's

I dont know about him, but I am. Logon prompt node 1, then logon prompt node 2, and node 1 stops, ad infinitum. All day long. Nobody ever logs in,

they're bots running dictionary attacks with lists of stolen usernames...

and the ip address is untraceable.

IP addresses are never untracable... if they are not returning a domain name, that's no problem at all... you can still find out who owns the address with the proper tools... whois is the first that comes to mind... in a short one can
simply plug the IP into uncle google's search and find all kinds of data about it...

)\/(ark

... I like long walks, especially when taken by people who annoy me.
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Hack Attempt Log -- How to purge that..
By: Joe Delahaye to Mro on Wed Jul 29 2015 10:18 pm

I dont know about him, but I am. Logon prompt node 1, then logon prompt node 2, and node 1 stops, ad infinitum. All day long. Nobody ever logs
in, and the ip address is untraceable.

well you have the ip address, so you know where it's coming from. i get
those types of port scanners that sit on the bbs all day too. i'm not sure what they are using but it doesnt close connections properly.

best thing to do is block entire countries like china.
i have a bbs capcha script that catches and blocks a lot of those guys but i still need them to drop the connection or they just sit there. they are written to my ip can file even if they sit, though.

ipdeny is a good website that will allow you to generate blocklists by country ---
þ Synchronet þ ::: BBSES.info - free BBS services :::

Subject: Re: Hack Attempt Log -- How to purge that..
@MSGID: <55BA81F9.39192.sync@wastelands-bbs.net>
@REPLY: <55BA0472.67891.sync@vert.synchro.net>
@TZ: c1e0

Re: Hack Attempt Log -- How to purge that..
By: Mro to Psi-Jack on Tue Jul 28 2015 14:49:48

are you really getting attacked this bad or is this your assburger's

I dont know about him, but I am. Logon prompt node 1, then logon prompt node 2, and node 1 stops, ad infinitum. All day long. Nobody ever logs

in,

and the ip address is untraceable.

I've had the same.... sometimes all my nodes at login prompt. Always probing passwords and users.... Sometimes just hanging.... Gets old....

---
þ Synchronet þ The Wastelands BBS - wastelands-bbs.net

Re: Hack Attempt Log -- How to purge that..
By: mark lewis to Joe Delahaye on Thu Jul 30 2015 13:14:52

IP addresses are never untracable... if they are not returning a domain name, that's no problem at all... you can still find out who owns the address with the proper tools... whois is the first that comes to mind... in a short one can
simply plug the IP into uncle google's search and find all kinds of data about it...

I assume they can spoof IP addresses as well as phone numbers? Never thought of using Google for that though.



... Death, when unnecessary, is a tragic thing.
--- SBBSecho 2.27-Win32
* Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Hack Attempt Log -- How to purge that..
By: Joe Delahaye to mark lewis on Fri Jul 31 2015 10:11 am

I assume they can spoof IP addresses as well as phone numbers? Never thought of using Google for that though.

they can use a proxy. still, you can block that ip or a range of ip ranges and that helps.
---
þ Synchronet þ ::: BBSES.info - free BBS services :::

31 Jul 15 10:11, you wrote to me:

IP addresses are never untracable... if they are not returning a
domain name, that's no problem at all... you can still find out who
owns the address with the proper tools... whois is the first that
comes to mind... in a short one can simply plug the IP into uncle
google's search and find all kinds of data about it...

I assume they can spoof IP addresses as well as phone numbers? Never thought of using Google for that though.

TCP connections cannot spoof IPs and work... the connection has to be solid... there's a three-way handshake to set this up... UDP connections, on the other hand, are stateless and can have spoofed IPs... the difference here is that there's no such thing as a UDP telnet or ssh or rlogin or similar connection...
they cannot be spoofed...

)\/(ark

... Bald spot? No - solar panel for brain power.
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Hack Attempt Log -- How to purge that..
By: mark lewis to Joe Delahaye on Fri Jul 31 2015 22:45:20

I assume they can spoof IP addresses as well as phone numbers?
Never thought of using Google for that though.

TCP connections cannot spoof IPs and work... the connection has to be solid... there's a three-way handshake to set this up... UDP connections, on the other hand, are stateless and can have spoofed IPs... the difference here is that there's no such thing as a UDP telnet or ssh or rlogin or similar connection...
they cannot be spoofed...

Oh, OK
--- SBBSecho 2.27-Win32
* Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net