Re: some attack to fedora machine .

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2008-04-13 at 11:48 -0400, max wrote:
> Da Rock wrote:
> > On Sat, 2008-04-12 at 16:46 +0300, Antti J. Huhtala wrote:
> >> la, 2008-04-12 kello 08:16 +1000, Da Rock kirjoitti:
> >>> On Fri, 2008-04-11 at 17:57 +0300, Antti J. Huhtala wrote:
> >>>> Your tip about not allowing username/password combinations is a good
> >>>> one. Any examples of an implementation of eg. key pairs?
> >>> Yes, that would be good to see. 
> >> Mikkel already answered this one in another post.
> > 
> > Yeah I noticed that- I'll get back to that shortly.
> > 
> >>> May I also ask if any of you guys having
> >>> these attacks are behind a firewall and/or NAT? 
> >> At present, no separate router or other firewall, just the one Fedora 8
> >> provides. I've only briefly tried NAT in my LAN but not long enough to
> >> observe whether invasion attempts were extended to the LAN.
> >>> I use ssh but so far I
> >>> don't believe I've had any trouble- I'd like to be a little better
> >>> informed on this though: ie symptoms etc.
> >>>
> >> The problem with describing the various symptoms an intrusion may cause
> >> is that it is difficult to avoid getting a little paranoid watching eg.
> >> unexpected and rather frequent hard disk activity. That's why I had to
> >> remove beagled from my F7 installation. The hard disk light was on all
> >> the time - or so it seemed.
> >> There are plenty of knowledgeable people on this list who could tell you
> >> much more than I can. Anyway, I monitor my system for intrusion attacks
> >> by having the Network Monitor (or whatever the English term is) icon
> >> permanently on my lower panel. Another icon I have there is the System
> >> Status (or whatever..). If either of these shows high activity that I
> >> have not caused myself, I look at top in terminal window to see what's
> >> going on. Usually it is yum-updatesd or makewhatis - sort of household
> >> chores.
> >> It may be worthwhile to occasionally click on Network Monitor icon to
> >> see how many packages have gone in and out the Internet interface. If I
> >> haven't updated or downloaded anything, the input/output ratio is
> >> usually well over 100:1. Most of this traffic is ARP broadcast packets -
> >> but of course the 10-minute-interval e-mail traffic is there also. Some
> >> of it is rejections from my box to whoever is trying to connect, ie,
> >> rejections of potential intruders.
> >> As I said before, an almost sure sign of a compromised box is that
> >> logwatch messages suddenly stop coming. Then it is time to run Wireshark
> >> for some length of time to see what is going *out* of your box. 'Whois'
> >> is another friend you probably need then.
> > 
> > Sounds like its not so much an attack on the machine as much as using it
> > as a platform to initiate other attacks- would this be correct?
> > 
> > IF this is the case, then a NAT would be a major hindrance to this. If
> > an attacker can't gain direct access to the machine, then ssh would
> > probably not possible- at worst would be a very good deterent as the
> > attacker would look for an easier target because he's not interested in
> > the machine itself.
> > 
> > Please, correct me if I'm wrong here. I'd love to see some log entries
> > for this attack too. In some ways I'm a bit green on security, but I
> > have been making some major progress in my education on how the attacks
> > work. But then, with security everybody has something to learn, don't
> > they?
> > 
> I doubt any one person knows it all. One of the  facts is that most of 
> the interesting information isn't owned by root at all but by the users. 
> Its very true as most informed people don't run as root, however you 
> gotta be root to delete,modify, or even look at the logs. Someone who 
> wants to make sure you don't catch on will try to modify the log files, 
> after all the longer they can keep you from noticing the longer they 
> will have the run of the machine. You can send your logs to a remote 
> machine. Now they have two machines to compromise, assuming of course 
> your actually checking the logs regularly. As I have pointed out you 
> have to be root to look at the logs. So protect root at all costs 
> because yes the user information might be interesting but if they own 
> root your gonna have to go to extremes to feel secure again. Keep the 
> list of installed programs to a minimum. If you don't use it on a semi 
> regular basis uninstall it. If your not programming then why do you need 
> a compiler? If you use samba once a month then you may want to leave it 
> installed but you might as well close the ports on the firewall and open 
> them manually when you need them. Same thing for the services. In the 
> end it all depends on how paranoid you want to get. How important is the 
> information your protecting? Most of the things I have said are easy to 
> do if your root and the local user but if your System Admin for even a 
> medium sized network it can get to be a pain to go around making sure 
> these things are done and of course even if your users only use Samba 
> once or twice a month you probably aren't going to turn it off till they 
> ask or whine about why it doesn't work in the first place. Now your 
> talking something like directory services and a root user that 
> potentially can access everyone's files in the directory and modify 
> their settings as well. Now root is more important than the user again. 
> The more I learn about security the greener I feel. Often I have noticed 
> that it really depends on your perspective, user vs. sys admin. A sys 
> admin will have to make trade offs to ensure people can get their work 
> done but a saavy user can often get around things because its a trade 
> off, instead of outright denial. The sys admin is also often at the 
> mercy of a computer illiterate boss who only cares that he can get 
> things done when he feels like it and doesn't realize the potential 
> dangers of what he's asking for and even after its explained to him, he 
> still doesn't care and forces the sys admin into a bad spot because he's 
> signing the paycheck. Ultimately the user has to be responsible for 
> his/her own security. The sys admin has bigger fish to fry than any one 
> user's concerns. Of course this is only a tiny portion of a much bigger 
> picture. Someday system security will get solved but until then....let's 
> hope as the studies suggest that you or one of your coworkers won't sell 
> their password for a frozen Snickers bar. Frozen Snickers 
> mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmaggggggggggghhhhhhhhhh. Whoa easy 
> Homer!! New Castle.......you guessed it , I just gave up my password.
> 
> Max
> 

But then, thats why you don't give root access to a run of the mill
user- or anyone unless you REALLY trust them. I don't trust anybody, so
I have a real problem...

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux