I have been hacked (WAS: Have I been hacked or is nmap wrong?)
On Wednesday 18 January 2006 14:34, Ken Stevenson pondered: Is there any chance you have a router that's forwarding the ports in question to another computer? Not that I know of. The setup is quite simple: wireless ethernet(PPPoE) ethernet ISP---Modem--FreeBSD gateway---LAN FreeBSD is my router with ppp -ddial -nat and a custom ipfw script that blocks all incoming connections while allowing legitimate traffic out (with keep-state rules). Check this out: ftp my_server gives 220 Frox transparent ftp proxy. Login with [EMAIL PROTECTED]:port]] Name (...) I have never even heard of frox before, but after some googling it turns out that it's a GPL'ed transparent ftp proxy... Also, I said smtp ports were open on the machines in question, I just verified that I can send emails via BOTH these systems even though no sendmail/exim/whatever was ever installed by me and sendmail_enable=None on both. My servers have been compromised, fantastic. And that with an initial firewall'ed setup that left NO open ports (I verified that a while ago with nmap). So much for my impression that FreeBSD was secure. How could this have happened? ipfw buffer overflow? Some other unknown vulnerability? I really wanna find out how they got in (syslog offers no clues btw, I've been rootkitted after all :-( Any suggestions other than format/reinstall/tripwire? -- Kilian Hagemann Climate Systems Analysis Group University of Cape Town Republic of South Africa Tel(w): ++27 21 650 2748 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I have been hacked (WAS: Have I been hacked or is nmap wrong?)
On Wed, Jan 18, 2006 at 03:56:32PM +0200, Kilian Hagemann wrote:
I have never even heard of frox before, but after some googling
it turns out that it's a GPL'ed transparent ftp proxy...
Where's it pointing?
Also, I said smtp ports were open on the machines in question, I
just verified that I can send emails via BOTH these systems even
though no sendmail/exim/whatever was ever installed by me and
sendmail_enable=None on both.
What do you see when you connect to the SMTP ports? Are they really
mail servers, or just rogue services running on 25?
My servers have been compromised, fantastic. And that with an
initial firewall'ed setup that left NO open ports (I verified that
a while ago with nmap). So much for my impression that FreeBSD was
secure.
My condolences; what you describe, though, doesn't really suggest
that /FreeBSD/ is insecure. In the vast majority of these situations
(and yes, I have found myself in your shoes before), the operator
(you or I) is to blame.
How could this have happened? ipfw buffer overflow? Some other
unknown vulnerability?
Ockham's razor: the simplest is also the most likely solution.
You're running Samba; is there any chance that that service or your
configuration of it could have opened a hole? How many people have
user accounts on that box? Do you allow
ChallengeResponseAuthentication on SSH? Key only?
I really wanna find out how they got in (syslog offers no clues
btw, I've been rootkitted after all :-(
You'll need to do a more sophisticated forensic analysis, then, to
figure out what happened. Some basic questions: were you running a
file integrity monitor? What did it say? Do you have logs that were
remotely backed up (and, therefore, likely still accurate)? What do
they say? Do you have any network monitoring that might have
recorded an intrusion? What services /should/ be running on the box
(I don't think this was ever actually listed -- it would be useful
to know)? Do you have dumps of the traffic leaving or entering the
box?
Again, this is a tough and very unfortunate position to be in -- I
sympathize. It may very well not be worth the time it takes to fully
investigate the source of the compromise. Real forensic analysis is
outside most of our job descriptions; I know that my skillset
doesn't cover it well enough. An inept investigation can be much
worse than no investigation at all: consider (if you can afford it)
bringing in someone who can do a quick, good job of it.
Any suggestions other than format/reinstall/tripwire?
I can't think of any better ideas. Certainly, I'd add updating the
system to your list. Even if the Security Alerts don't seem to
effect your set up, I find it's good practice to apply them in a
reasonable amount of time. At the very least, it keeps me in touch
with my boxes and lets me develop a routine in case an alert does
effect me.
Good luck!
--
o--{ Will Maier }--o
| jabber:[EMAIL PROTECTED] | email:[EMAIL PROTECTED] |
| [EMAIL PROTECTED] | [EMAIL PROTECTED] |
*--[ BSD Unix: Live Free or Die ]--*
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I have been hacked (WAS: Have I been hacked or is nmap wrong?)
Also, I said smtp ports were open on the machines in question, I just verified that I can send emails via BOTH these systems even though no sendmail/exim/whatever was ever installed by me and sendmail_enable=None on both. For what it's worth, to disable senmail on 5.0 and later, you need: sendmail_enable=NO sendmail_submit_enable=NO sendmail_outbound_enable=NO sendmail_msp_queue_enable=NO All those lines need to go in your /etc/rc.conf file, just the top line on it's own will only stop mail coming into your system and I think it has to be NO not None, but I'm not 100% on that. The above is from the Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mail-changingmta.html -- Paul ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I have been hacked (WAS: Have I been hacked or is nmap wrong?)
sendmail_enable=NONE would do the same as all that other crap mentioned i find it a waste of time trying to figure out how a hacker got in just format the machine reinstall freebsd and secure the box up a bit and try updating it when vulnerabilitie are out. And this shouldnt happen again Also, I said smtp ports were open on the machines in question, I just verified that I can send emails via BOTH these systems even though no sendmail/exim/whatever was ever installed by me and sendmail_enable=None on both. For what it's worth, to disable senmail on 5.0 and later, you need: sendmail_enable=NO sendmail_submit_enable=NO sendmail_outbound_enable=NO sendmail_msp_queue_enable=NO All those lines need to go in your /etc/rc.conf file, just the top line on it's own will only stop mail coming into your system and I think it has to be NO not None, but I'm not 100% on that. The above is from the Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mail-changingmta.html -- Paul ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I have been hacked (WAS: Have I been hacked or is nmap wrong?)
On Wednesday 18 January 2006 16:25, Will Maier pondered: On Wed, Jan 18, 2006 at 03:56:32PM +0200, Kilian Hagemann wrote: I have never even heard of frox before, but after some googling it turns out that it's a GPL'ed transparent ftp proxy... Where's it pointing? No idea, I only went as far as trying to login anonymously using a console based ftp client. How could I find out? Also, I said smtp ports were open on the machines in question, I just verified that I can send emails via BOTH these systems even though no sendmail/exim/whatever was ever installed by me and sendmail_enable=None on both. What do you see when you connect to the SMTP ports? Are they really mail servers, or just rogue services running on 25? They are really mail servers, at least smtp for outgoing mails (don't know about incoming though). I used kmail to configure them as standard outgoing smtp mail servers and successfully sent myself two emails, one via each server. Surely a default, out of the box, unconfigured and sendmail_enable=None sendmail process wouldn't allow for something like that, never mind the fact that the firewall is supposed to block ANY access from the outside (output of ipfw show is attached) My servers have been compromised, fantastic. And that with an initial firewall'ed setup that left NO open ports (I verified that a while ago with nmap). So much for my impression that FreeBSD was secure. My condolences; what you describe, though, doesn't really suggest that /FreeBSD/ is insecure. In the vast majority of these situations (and yes, I have found myself in your shoes before), the operator (you or I) is to blame. Alright, I guest that's a fair assumption. But that's what this thread is about: What (if anything) did I do wrong? How could this have happened? ipfw buffer overflow? Some other unknown vulnerability? Ockham's razor: the simplest is also the most likely solution. You're running Samba; is there any chance that that service or your configuration of it could have opened a hole? How many people have user accounts on that box? Do you allow ChallengeResponseAuthentication on SSH? Key only? Well, I didn't worry about samba because it's firewalled to the outside(unless some Windows virus on one of the LAN machines exploited a samba hole, is that likely?). There is only one single normal user account with an uncommon name and an impossible password(16 characters randomly generated from ASCII charset). ChallengeResponseAuthentication is commented out in sshd which I guess means it uses the standard PAM authentication. It also allows password/interactive authentication in addition to public key, I always use the former. I do admit that I have set PermitRootLogin yes but my root password is 9 characters with numbers and non-alphanumeric characters, so hard to brute-force. In any case, it's important to note that the only access from the outside via ssh/rsync is firewalled in such a way that it only allows access from a single IP address which my institution assigns me statically via DHCP (see attachment). They would have had to a) find out what this one and only trusted IP address is b) spoof it successfully c) attack ssh brute force? I really wanna find out how they got in (syslog offers no clues btw, I've been rootkitted after all :-( You'll need to do a more sophisticated forensic analysis, then, to figure out what happened. Some basic questions: were you running a file integrity monitor? What did it say? Do you have logs that were remotely backed up (and, therefore, likely still accurate)? What do they say? Do you have any network monitoring that might have recorded an intrusion? What services /should/ be running on the box (I don't think this was ever actually listed -- it would be useful to know)? Do you have dumps of the traffic leaving or entering the box? Well, I thought my setup was secure enough for a very basic router/gateway/firewall for a couple of Windows machines using a sucky internet connection which is not worth stealing. So I didn't go through the effort of using a file integrity monitor, remote logging, traffic dumps or network monitors (jeez, sysadmins lives are really difficult these days :-( ) The services that should be running on the box are: LAN only: samba, dnsmasq LAN and WAN: ssh/rsync I wanted to use rsync with ssh authentication/remote shell to sync my /etc and /usr/etc to my workstation and then comparing the update with a static copy to find out if anything had changed. But before I could do that, the one server mysteriously had its ssh/rsync disabled and I didn't take a healthy copy of /etc of the other one to begin with :-( Again, this is a tough and very unfortunate position to be in -- I sympathize. It may very well not be worth the time it takes to fully investigate the source of the compromise. Real forensic analysis is outside most of our job descriptions; I know that my
Re: I have been hacked (WAS: Have I been hacked or is nmap wrong?)
On Wednesday 18 January 2006 17:13, [EMAIL PROTECTED] pondered: sendmail_enable=NONE would do the same as all that other crap mentioned i find it a waste of time trying to figure out how a hacker got in just format the machine reinstall freebsd and secure the box up a bit and try updating it when vulnerabilitie are out. And this shouldnt happen again Yeah, I'll have to look into that NONE vs all NO individually because it gave me hassles from the beginning (STILL sendmail stuff in /var/log/messages after disabling with NONE), but the important thing here is outside sendmail access was firewalled (see my other post and its attachment for ipfw rules). Anyway, I guess you're right, reinstalling and beefing up security will be easier. I just thought that if they didn't get in through brute-forcing my sshd (the only vulnerability I can think of so far), and the attack came from the internet (not some worm/virus on one of the Windows machines), it's some unpublished vulnerability in some part of FreeBSD that I'm sure others would like to know about. But hey, from what you guys are telling me that seems unlikely... -- Kilian Hagemann ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I have been hacked (WAS: Have I been hacked or is nmap wrong?)
On Wed, Jan 18, 2006 at 05:38:50PM +0200, Kilian Hagemann wrote: On Wednesday 18 January 2006 16:25, Will Maier pondered: On Wed, Jan 18, 2006 at 03:56:32PM +0200, Kilian Hagemann wrote: I have never even heard of frox before, but after some googling it turns out that it's a GPL'ed transparent ftp proxy... Where's it pointing? No idea, I only went as far as trying to login anonymously using a console based ftp client. How could I find out? Connect to it and watch the packets in tcpdump(8) or similar. this may not give you the full answer, but it'll help. What banners do the FTP servers have? Is there a domain listed? Who owns that domain? What do you see when you connect to the SMTP ports? Are they really mail servers, or just rogue services running on 25? They are really mail servers, at least smtp for outgoing mails (don't know about incoming though). I used kmail to configure them as standard outgoing smtp mail servers and successfully sent myself two emails, one via each server. Surely a default, out of the box, unconfigured and sendmail_enable=None sendmail process wouldn't allow for something like that, never mind the fact that the firewall is supposed to block ANY access from the outside (output of ipfw show is attached) So these are running, functioning sendmail servers that /you/ didn't configure (on purpose)? What do you see when you 'talk' to them via nc(1)? If you're firewall was dropping incoming packets destined to those ports, you wouldn't have been able to send a mail through them (or connect on 25 with nc(1))... Well, I didn't worry about samba because it's firewalled to the outside(unless some Windows virus on one of the LAN machines exploited a samba hole, is that likely?). I don't know Samba that well, but it's possible it could be exploited (check the web for recent advisories pertaining to it). How much do you trust the users on the 'green' side? Could one of their boxes have been compromised and then used as a platform to attack your border servers? This sort of (nightmare) scenario is why people have been whining about 'defense in depth' for the last few years; it turns out that your crunchy, impermeable outside actually can be as squishy as your inside. There is only one single normal user account with an uncommon name and an impossible password(16 characters randomly generated from ASCII charset). ChallengeResponseAuthentication is commented out in sshd which I guess means it uses the standard PAM authentication. It also allows password/interactive authentication in addition to public key, I always use the former. I do admit that I have set PermitRootLogin yes but my root password is 9 characters with numbers and non-alphanumeric characters, so hard to brute-force. Having a kickass, long username with an 'impossible' 16 char password and an open root account with a password 9 chars long is like putting a heavy steel door on a cardboard box. Allowing PermitRootLogin is a mistake in almost every scenario; disable it in the next generation of your servers (if possible). It's a 'weakest link' sort of situation, I guess. In any case, it's important to note that the only access from the outside via ssh/rsync is firewalled in such a way that it only allows access from a single IP address which my institution assigns me statically via DHCP (see attachment). That's good. They would have had to a) find out what this one and only trusted IP address is b) spoof it successfully c) attack ssh brute force? Assuming the firewall works, they would certainly have to complete steps a, b and c; unless, that is, they compromised /your/ box, too. Unlikely, though, I suspect. Well, I thought my setup was secure enough for a very basic router/gateway/firewall for a couple of Windows machines using a sucky internet connection which is not worth stealing. Unfortunately, the asset you should be protecting might not be your bandwidth or data or whatever it is you've been assuming. When you set up a firewall, you're protecting something -- in your case, what is it? Have you defined that for yourself? It's hard to do a good job defending something you haven't or can't define. While it probably sounds pedantic or silly, take a moment to ask yourself what it is you want to protect. If there are several things, rank them by priority. _Then_ go about designing a defense. Securing your stuff may not be a terribly high priority at all; if so, accept the fact that something bad will happen once in a while. Your security plan might just be deal with it when the shit hits the fan. No problem. That can make sense. Having clarified that for yourself, though, makes things easier. So I didn't go through the effort of using a file integrity monitor, remote logging, traffic dumps or network monitors (jeez, sysadmins lives are really difficult these days :-( ) Like I said above, those sorts of defenses might be overkill for you. That's fine --
