Linux EA/ACL manual pages
http://acl.bestbits.at/man/man.html
sexta-feira, 29 de abril de 2011
Ramblings: Lack Of IT Security Professionals, University Courses and Unqualified Penetration Testers « Adam On Security:
Today I want to talk to you about my reasoning why the Security Industry is desperate for staff, and explain a little bit about my self as I'm trying to break into the security industry as a network penetration tester, I also have a solid dig at universities, and i'm probably going to offend a lot of people with this, but it needs to be said and this is what freedom of speech is all about.
The State Of The Industry
The UK IT Security Industry is reported to be about 50,000 people short, why is this? In my opinion it's because there is no where for security professionals to practice legitimate hacking techniques outside of spending thousands on various different systems and building networks. This results in there being a large amount of Security staff that don't know how to think like an attacker and a business wondering why their network keeps getting broken into. This in turn creates fear and a greater demand for more security staff creating a vacuum
The Blame Game
I personally blame the state of security education for this shortage. In short you can't teach someone how to hack and how to audit networks without them at some point auditing a real, secure servers in the wild. Even if you could create an environment to train security staff in attack methods, it would no way be as diverse as the array of internet connected business that they will be presented with in the field. The person in training could only ever leave education with a very narrow skill set based on the budget size of the institute where they learnt.
Universities - The Root Of All Evil?
So what happens is Universities pump out thousands of 'security' students that don't know anything about the real security practices or attack methods they will be expected to defend against. I have done my security degree for 2 years now, and I can tell you, I haven't learn a thing about security that I didn't know before I went or that i have learnt in my spare time, and that's not an exaggeration.
Universities in the UK work at the speed of the worst student on the course, so all security students get is repetitious explanations of the basics of computing causing long drawn out tutorials that leave no time for more in depth security concepts.
If your a prospective security student reading this you might think that you'll be challenged with all this useful information that is relevant to your career. Instead all you get for your £9000 a year is watered down and censored horse sh*t. The closest I have come to real security talk is chatting to lecturers outside of lessons because they're not under pressure of talking about "taboo" subjects.
To be blunt universities just don't have the time or balls to teach security students REAL security that they can actually use in the field, they can't talk about things like buffer overflows in detail, they can't step by step explain concepts like SQL injection. This is for two reasons, firstly its like giving students a loaded shotgun, they can't control what you do with that information, and they don't want to be liable. Secondly they don't want it to go over anyone's heads, god forbid a student might actually have to do some extra reading at home to understand something, even worse god forbid a student actually fail! So instead students come out with a piece of paper that says they are qualified to work in IT Security when in fact they have been taught very little about it, instead we have been repetitively spoon fed the basics of computing with a light glance at how one might approach the topic of security, because its less likely to cause a fuss and to go over students heads.
These students then hit the field knowing very little about real security, and it falls to business owners to spend time and money training them from the ground up, or they simply get jobs securing business without a clue about what there doing from an attackers perspective. So what did we just spend 9000 a year on?
Here is what you get for your 9000 a year on a security course each week in the UK
3 Hours of Cisco - Cisco fund a large portion of my University so we don't have a free choice like other courses and are forced to spend 3 years learning a qualification that expires in 3 years (CCNA), oh and did I mention we have to pay them to actually take the certification test ontop of our fees and the end of the 3 years?
1.5 Hours of business studies - Group work making a marketing plan for a product I will never make that isn't really anything to do with my course.
3 Hours of Open systems (linux technologies) quite interesting but I have used linux for 3 years and the things explained are basic even5 months into the module, 90% talking about licensing, 10% actually using linux.
3 Hours of watered down and heavily censored security, for example one way hashing, key exchanges, file systems.
2.5 Hours of Visual Basic programming RFID tags because the Uni is backed by Micro$oft so we have no choice about learning anything other than VB.Net .
(This also assumes the lecturers show up and your lecturer knows what he is talking about. Which isn't always the case)
Now does that sound like someone you want to hire for a network penetration tester position? How about if I told you that these people are being hired to secure databases with your credit card details in ? Scared now - you should be.
Me as a Hacker
I don't hesitate to say I have dabbled in the less legal sides of hacking and security, but ONLY to learn and explore. I don't think you can work in security unless you have done at some point, if you haven't, how do you know if the things you have read about actually work? You haven't practiced anything to do with real auditing, you have just read the books. If you are working in penetration testing and have never dabbled, then at some point your company hired you for a job you were unequipped to do, and it probably cost them more to train you than if they hired someone with a greater skill set.
The Interview
I'll put this to you, If I turned up to a job interview for a penetration tester 'year in industry' tomorrow and there was an equally qualified person applying at the same time for the same position. The person standing next to me has the same degree and the same qualifications, but he has never looked into hacking because he never had the equipment or outlet to practice the skills he could only read about in his spare time.
Then there is me who could root a corporate file server in minutes, social engineer my way through you're companies head quarters with a smile on my face and read your CEO's emails from the coffee shop across the road. Does the interviewer ask me where I learnt these things? Would he even ask if i possessed them as a skill? Or does he look at the piece of paper in front of him and go by the fact that Joe Blogs next to me gets the job because his suit is shinier and he can talk the talk? Then 6 months later the company wonders why they are struggling to explain simple port scanning and network mapping to Joe Blogs and wonders why there is no good quality security staff to be had.
If Kevin Mitnick showed up at your door asking for a job at your network security company, would you turn him down because the origin of his skills is a little dubious? Of course you wouldn't, he is one of the greatest minds in the security (in my opinion) and he doesn't have an LPT or a CEH and his degree is a little out dated, but he has the skills and the mind set.
Security is an industry where you can't just recruit someone because of the papers they hold, anyone can revise and memorize information to pass a course, you need to put the skills they say they have to the test. I'd kill to show up to an interview and the company have an easily compromisable server running in the room to test their applicants. I bet half of the applicants wouldn't know where to start, despite there Security Degree and CCNA emblazoned all over their CV.
Here Is My Challenge
I have learnt all my skill security/penetration skill base on my own, I'm doing my degree because I do need the piece of paper for Penetration Testing firms to even look twice at my CV.
If there is one thing I can tell you, and I tell people time and time again is this: I eat sleep and breath this, I don't stop, Computer Security isn't just a career for me, its a way of life (avoiding cliches). That's not something I can get across on 2 sides of A4 and not something anyone can get with a 3 year course and a light dusting of certifications.
I challenge any UK Penetration Testing Firm or (companies that need an in house penetration tester), If you call me in for an interview for a year in industry placement (September 2011 - 2012), give me 30 minutes of your time with a my laptop, I will show you more penetration testing related skill than any applicant you have seen, and that is a promise. My email is adam@adamonsecurity.com if you want to take me up on that.
Happy Hacking
The State Of The Industry
The UK IT Security Industry is reported to be about 50,000 people short, why is this? In my opinion it's because there is no where for security professionals to practice legitimate hacking techniques outside of spending thousands on various different systems and building networks. This results in there being a large amount of Security staff that don't know how to think like an attacker and a business wondering why their network keeps getting broken into. This in turn creates fear and a greater demand for more security staff creating a vacuum
The Blame Game
I personally blame the state of security education for this shortage. In short you can't teach someone how to hack and how to audit networks without them at some point auditing a real, secure servers in the wild. Even if you could create an environment to train security staff in attack methods, it would no way be as diverse as the array of internet connected business that they will be presented with in the field. The person in training could only ever leave education with a very narrow skill set based on the budget size of the institute where they learnt.
Universities - The Root Of All Evil?
So what happens is Universities pump out thousands of 'security' students that don't know anything about the real security practices or attack methods they will be expected to defend against. I have done my security degree for 2 years now, and I can tell you, I haven't learn a thing about security that I didn't know before I went or that i have learnt in my spare time, and that's not an exaggeration.
Universities in the UK work at the speed of the worst student on the course, so all security students get is repetitious explanations of the basics of computing causing long drawn out tutorials that leave no time for more in depth security concepts.
If your a prospective security student reading this you might think that you'll be challenged with all this useful information that is relevant to your career. Instead all you get for your £9000 a year is watered down and censored horse sh*t. The closest I have come to real security talk is chatting to lecturers outside of lessons because they're not under pressure of talking about "taboo" subjects.
To be blunt universities just don't have the time or balls to teach security students REAL security that they can actually use in the field, they can't talk about things like buffer overflows in detail, they can't step by step explain concepts like SQL injection. This is for two reasons, firstly its like giving students a loaded shotgun, they can't control what you do with that information, and they don't want to be liable. Secondly they don't want it to go over anyone's heads, god forbid a student might actually have to do some extra reading at home to understand something, even worse god forbid a student actually fail! So instead students come out with a piece of paper that says they are qualified to work in IT Security when in fact they have been taught very little about it, instead we have been repetitively spoon fed the basics of computing with a light glance at how one might approach the topic of security, because its less likely to cause a fuss and to go over students heads.
These students then hit the field knowing very little about real security, and it falls to business owners to spend time and money training them from the ground up, or they simply get jobs securing business without a clue about what there doing from an attackers perspective. So what did we just spend 9000 a year on?
Here is what you get for your 9000 a year on a security course each week in the UK
3 Hours of Cisco - Cisco fund a large portion of my University so we don't have a free choice like other courses and are forced to spend 3 years learning a qualification that expires in 3 years (CCNA), oh and did I mention we have to pay them to actually take the certification test ontop of our fees and the end of the 3 years?
1.5 Hours of business studies - Group work making a marketing plan for a product I will never make that isn't really anything to do with my course.
3 Hours of Open systems (linux technologies) quite interesting but I have used linux for 3 years and the things explained are basic even5 months into the module, 90% talking about licensing, 10% actually using linux.
3 Hours of watered down and heavily censored security, for example one way hashing, key exchanges, file systems.
2.5 Hours of Visual Basic programming RFID tags because the Uni is backed by Micro$oft so we have no choice about learning anything other than VB.Net .
(This also assumes the lecturers show up and your lecturer knows what he is talking about. Which isn't always the case)
Now does that sound like someone you want to hire for a network penetration tester position? How about if I told you that these people are being hired to secure databases with your credit card details in ? Scared now - you should be.
Me as a Hacker
I don't hesitate to say I have dabbled in the less legal sides of hacking and security, but ONLY to learn and explore. I don't think you can work in security unless you have done at some point, if you haven't, how do you know if the things you have read about actually work? You haven't practiced anything to do with real auditing, you have just read the books. If you are working in penetration testing and have never dabbled, then at some point your company hired you for a job you were unequipped to do, and it probably cost them more to train you than if they hired someone with a greater skill set.
The Interview
I'll put this to you, If I turned up to a job interview for a penetration tester 'year in industry' tomorrow and there was an equally qualified person applying at the same time for the same position. The person standing next to me has the same degree and the same qualifications, but he has never looked into hacking because he never had the equipment or outlet to practice the skills he could only read about in his spare time.
Then there is me who could root a corporate file server in minutes, social engineer my way through you're companies head quarters with a smile on my face and read your CEO's emails from the coffee shop across the road. Does the interviewer ask me where I learnt these things? Would he even ask if i possessed them as a skill? Or does he look at the piece of paper in front of him and go by the fact that Joe Blogs next to me gets the job because his suit is shinier and he can talk the talk? Then 6 months later the company wonders why they are struggling to explain simple port scanning and network mapping to Joe Blogs and wonders why there is no good quality security staff to be had.
If Kevin Mitnick showed up at your door asking for a job at your network security company, would you turn him down because the origin of his skills is a little dubious? Of course you wouldn't, he is one of the greatest minds in the security (in my opinion) and he doesn't have an LPT or a CEH and his degree is a little out dated, but he has the skills and the mind set.
Security is an industry where you can't just recruit someone because of the papers they hold, anyone can revise and memorize information to pass a course, you need to put the skills they say they have to the test. I'd kill to show up to an interview and the company have an easily compromisable server running in the room to test their applicants. I bet half of the applicants wouldn't know where to start, despite there Security Degree and CCNA emblazoned all over their CV.
Here Is My Challenge
I have learnt all my skill security/penetration skill base on my own, I'm doing my degree because I do need the piece of paper for Penetration Testing firms to even look twice at my CV.
If there is one thing I can tell you, and I tell people time and time again is this: I eat sleep and breath this, I don't stop, Computer Security isn't just a career for me, its a way of life (avoiding cliches). That's not something I can get across on 2 sides of A4 and not something anyone can get with a 3 year course and a light dusting of certifications.
I challenge any UK Penetration Testing Firm or (companies that need an in house penetration tester), If you call me in for an interview for a year in industry placement (September 2011 - 2012), give me 30 minutes of your time with a my laptop, I will show you more penetration testing related skill than any applicant you have seen, and that is a promise. My email is adam@adamonsecurity.com if you want to take me up on that.
Happy Hacking
quinta-feira, 28 de abril de 2011
Seguraça extrema com LIDS
Autor: Anderson L Tamborim
Data: 21/02/2004
Introdução ao LIDS
1.0 - O que é o LIDS?
LIDS é um patch de melhorias para a kernel do Linux escrita por Xie Huagang e Philippe Biondi. Este patch adiciona esquemas de segurança extrema ao kernel e que não são possíveis apenas com as funções nativas da kernel.
Entre algumas destas funções temos:
Mandatory Access Controls (MACs)
Detecção de Port Scanners
Proteção de acesso a arquivos e pastas (incluindo pelo root)
Proteção de processos, módulos e interfaces.
1.1 - Porque utilizar o LIDS?
LIDS é um conjunto indispensável de ferramentas que vem sofrendo muitas melhorias nos últimos anos e me arrisco a dizer que ele está no auge do seu potencial com a versão 2.4.24 e 2.6 do kernel do Linux.
As ferramentas que acompanham o LIDS são muito fáceis de utilizar e configurar. Quem trabalha com segurança e deseja alcançar um nível superior de segurança dentro do seu sistema NECESSITA conhecer LIDS.
O LIDS, como vocês verão, não é uma ferramenta para se utilizar em micros de usuários devido a robustez de sua configuração, o que causaria uma série de problemas que o tornam de certa forma inviável, sendo que também temos ótimas ferramentas de IDS para Linux que usuários podem utilizar, como Snort, Portsentry, entre outras.
Com o LIDS podemos restringir qualquer acesso ao nosso sistema e ele nos manterá totalmente informado de tudo que esta havendo no sistema, qualquer tentativa de burlar sistemas protegidos pelo LIDS é documentada em emails e nos logs.
1.2 - Onde posso conseguir o LIDS?
Bom, o LIDS é uma atualização FREE para a kernel. Pode ser encontrada em http://www.lids.org e também nesta lista de mirrors: http://www.lids.org/mirrors.html.
1.3 - Direitos e Copyright
This software is copyright(c) 2000, 2001, 2002 for Steve Bremer - 2002, 2003 for Sander Klein and it is a FREE document. You may redistribute it under the terms of the GNU General Public License. The information herein this document is, to the best of Sander's knowledge, correct. However, LIDS and the LIDS-FAQ is written by humans and thus, the chance of mistakes, bugs, etc. might occur from time to time. No person, group, or other body is responsible for any damage on your computer(s) and any other losses by using the information on this document. i.e. "THE AUTHORS AND ALL MAINTAINERS ARE NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION IN THIS DOCUMENT."
Instalando o LIDS
2.1 - Como aplicar o patch do LIDS ao meu kernel?
A primeira coisa que devemos fazer é entrar em www.lids.org e baixar a versão de LIDS que corresponde ao kernel que iremos compilar, recomendo o kernel 2.4.24.
Se você não possui a versão deste kernel, poderá baixa-lo em www.kernel.org. Não entrarei em detalhes de como recompilar o kernel, se caso você que esteja lendo não possui tal habilidade, procure documentação antes de prosseguir.
Vamos descompactar o arquivo:
$ tar -zxvf lids-lids_version-kernel_version.tar.gz
Agora vamos entrar na pasta do nosso kernel:
$ cd /usr/src/linux
Agora aplicar o patch:
# patch -p1 < /path/to/lids/patch/lids-lids_version-kernel_version.patch Agora que o patch está aplicado, configure o seu kernel normalmente com o "make menuconfig". Você verá que apareceu um menu a mais na lista com o nome de Linux Intrusion Detection System. Para que o LIDS funcione, você deverá ter selecionados os seguintes esquemas: [*] Prompt for development and/or incomplete code/drivers [*] Sysctl Support General setup --->
[*] Networking support
[*] PCI support
(Any) PCI access mode
[*] PCI quirks
[ ] PCI bridge optimization (experimental)
[*] Backward-compatible /proc/pci
[ ] MCA support
[ ] SGI Visual Workstation support
[*] System V IPC
[ ] BSD Process Accounting
[*] Sysctl support
<*> Kernel support for a.out binaries
<*> Kernel support for ELF binaries
<*> Kernel support for MISC binaries
Kernel support for JAVA binaries (obsolete)
< > Parallel port support
[ ] Advanced Power Management BIOS support
Networking options ---> *(Personalize de acordo com suas
necessidades)
<*> Packet socket
[*] Kernel/User netlink socket
[*] Routing messages
<*> Netlink device emulation
[*] Network firewalls
[ ] Socket Filtering
<*> Unix domain sockets
[*] TCP/IP networking
[ ] IP: multicasting
[*] IP: advanced router
[ ] IP: policy routing
[*] IP: equal cost multipath
[ ] IP: use TOS value as routing key
[*] IP: verbose route monitoring
[*] IP: large routing tables
[ ] IP: kernel level autoconfiguration
[*] IP: firewalling
[*] IP: firewall packet netlink device
[ ] IP: transparent proxy support
[*] IP: masquerading
--- Protocol-specific masquerading support will be built as
modules.
[*] IP: ICMP masquerading
--- Protocol-specific masquerading support will be built as
modules.
[*] IP: masquerading special modules support
IP: ipautofw masq support (EXPERIMENTAL)
IP: ipportfw masq support (EXPERIMENTAL)
IP: ip fwmark masq-forwarding support (EXPERIMENTAL)
[*] IP: optimize as router not host
< > IP: tunneling
< > IP: GRE tunnels over IP
[*] IP: aliasing support
[ ] IP: ARP daemon support (EXPERIMENTAL)
[*] IP: TCP syncookie support (not enabled per default)
--- (it is safe to leave these untouched)
< > IP: Reverse ARP
[*] IP: Allow large windows (not recommended if <16Mb of memory) < > The IPv6 protocol (EXPERIMENTAL)
opções do lids no kernel -->
Linux Intrusion Detection System --->
[*] Linux Intrusion Detection System support (EXPERIMENTAL)
--- LIDS features
(1024) Maximum protected objects to manage
(1024) Maximum ACL subjects to manage
(1024) Maximum ACL objects to manage
(1024) Maximum protected proceeds
[ ] Hang up console when raising a securit alert
[ ] Security alert when execing unprotected programs before
sealing LIDS
[*] Try not to flood logs
(60)Authorised time between two identic logs (seconds)
[*] Allow switching LIDS protections
(3)Number of attempts to submit password
(3) Time to wait after a fail (seconds)
[ ] Allow remote users to switch LIDS protections
[ ] Allow any program to switch LIDS protections
[*] Allow reloading config. File
[*] Port Scanner Detector in kernel
[*] Send security alerts through network
[ ] Hide klids kernel thread
(3) Number of connection tries before giving up
(30)Sleep time after a failed connection
(16)Message queue size
Muito bem, agora recompile seu kernel normalmente como sempre faz. Adicione a imagem no seu gerenciador de inicialização e tudo mais. Pronto, seu kernel tem suporte ao LIDS.
2.2 - Instalando Lidsadm & Lidsconf
Entre na pasta onde você descompactou o LIDS:
$ tar -zvxf lidstools-version.tar.gz
$ cd lidstools-version
$ ./configure
$ make
$ su -
# make install
Junto ao LIDS, a versão que vem do lidstools já é antiga, puxe a versão 0.5.1 na página do LIDS e compile ela.
Muito bem, depois que terminar de compilar ele vai pedir uma senha, coloque uma que se lembre depois, porque ela será muito importante.
Depois que você instalar poderá ver se está tudo rodando perfeitamente:
$ lidsadm -v
Ele retornará a versão do lidsadm.
Bom... Primeira DICA: não reinicie seu sistema ainda ou então ele estará totalmente bloqueado. Recomendo-lhe limpar todas as funções do LIDS antes de reiniciar.
Se você olhar em /etc/lids/, teremos 2 arquivos:
Lids.cap -> Arquivo com as funções de capabilities
Lids.conf -> com as Entradas de configuração que editaremos
São os principais que usaremos.
Conhecendo o LIDS
3.1 - /sbin/lidsadm & /sbin/lidsconf
O lidsadm é um software que usaremos para administrar nosso LIDS. Vamos dar uma analisada básica nele:
# lidsadm -h
lidsadm version 0.4.1 for LIDS project
Huagang Xie
Philippe Biondi
Usage: lidsadm -[S|I] -- [+|-][LIDS_FLAG] [...]
lidsadm -V
lidsadm -h
Commands:
-S To submit a password to switch some protections
-I To switch some protections without submitting
password (sealing time)
-V To view current LIDS state (caps/flags)
-v To show the version
-h To list this help
Available capabilities:
CAP_CHOWN chown(2)/chgrp(2)
CAP_DAC_OVERRIDE DAC access
CAP_DAC_READ_SEARCH DAC read
CAP_FOWNER owner ID not equal user ID
CAP_FSETID effective user ID not equal owner ID
CAP_KILL real/effective ID not equal process ID
CAP_SETGID set*gid(2)
CAP_SETUID set*uid(2)
CAP_SETPCAP transfer capability
CAP_LINUX_IMMUTABLE immutable and append file attributes
CAP_NET_BIND_SERVICE binding to ports below 1024
CAP_NET_BROADCAST broadcasting/listening to multicast
CAP_NET_ADMIN interface/firewall/routing changes
CAP_NET_RAW raw sockets
CAP_IPC_LOCK locking of shared memory segments
CAP_IPC_OWNER IPC ownership checks
CAP_SYS_MODULE insertion and removal of kernel modules
CAP_SYS_RAWIO ioperm(2)/iopl(2) access
CAP_SYS_CHROOT chroot(2)
CAP_SYS_PTRACE ptrace(2)
CAP_SYS_PACCT configuration of process accounting
CAP_SYS_ADMIN tons of admin stuff
CAP_SYS_BOOT reboot(2)
CAP_SYS_NICE nice(2)
CAP_SYS_RESOURCE setting resource limits
CAP_SYS_TIME setting system time
CAP_SYS_TTY_CONFIG tty configuration
CAP_MKNOD mknod operation
CAP_LEASE taking leases on files
CAP_HIDDEN hidden process
CAP_KILL_PROTECTED kill protected programs
CAP_PROTECTED Protect the process from signals
Available flags:
LIDS de-/activate LIDS locally (the shell & childs)
LIDS_GLOBAL de-/activate LIDS entirely
RELOAD_CONF reload config. file and inode/dev of
protected programs
Temos a lista de todos os "capabilities".
Com o lidsconf faremos as configurações do LIDS no nosso sistema, ou seja, o que iremos bloquear e o que iremos liberar. O lidsconf na sua instalação gera uma configuração padrão que podemos analizar assim:
# lidsconf -h
lidsconf version 0.4.1 for the LIDS project
Huagang Xie
Philippe Biondi
Usage: lidsconf -A [-s subject] -o object [-d] [-t from-to]
[-i level] -j ACTION
lidsconf -D [-s file] [-o file]
lidsconf -Z
lidsconf -U
lidsconf -L [-e]
lidsconf -P
lidsconf -v
lidsconf -[h|H]
Commands:
-A,--add To add an entry
-D,--delete To delete an entry
-Z,--zero To delete all entries
-U,--update To update dev/inode numbers
-L,--list To list all entries
-P,--passwd To encrypt a password with RipeMD-160
-v,--version To show the version
-h,--help To list this help
-H,--morehelp To list this help with CAP/SOCKET name
subject: -s,--subject subj
can be any program, must be a file
object: -o,--object [obj]
can be a file, directory or Capability, Socket Name
ACTION: -j,--jump
DENY deny access
READONLY read only
APPEND append only
WRITE writable
GRANT grant capability to subject
IGNORE ignore any permissions set on this object
DISABLE disable some extersion feature
OPTION:
-d,--domain The object is an EXEC Domain
-i,--inheritance Inheritance level
-t,--time Time dependency
-e,--extended Extended list
Os comandos principais que usaremos serão:
lidsconf -L: lista as configurações atuais.
lidsconf -Z: zera as configurações.
lidsconf -U: Atualiza as configurações, sempre deve-se atualizar quando se acrescenta uma nova regra.
Como posso setar uma nova password:
# lidsconf -P
MAKE PASSWD
enter new password:
reenter new password:
wrote password to /etc/lids/lids.pw
A senha ficará escrita nesse arquivo com criptografia de 185 bits.
3.2 - Como dizer ao LIDS para recarregar minha configuração?
Bom, para que isso ocorra você deve ter selecionado esses esquemas no seu menuconfig:
[*] Allow switching LIDS protections
(3) Number of attempts to submit password
(30) Time to wait after a fail (seconds)
[ ] Allow remote users to switch LIDS protections
[ ] Allow any program to switch LIDS protections
[*] Allow reloading config. file <-----------
# lidsadm -S -- +RELOAD_CONF
Isso irá recarregar o seu LIDS com as novas configurações sem precisar reiniciar o kernel.
3.3 - Socorro meu sistema esta totalmente bloqueado
Bom, se isso acontecer você deverá bootar seu linux pelo kernel antigo (sem LIDS) e retirar todos os atributos de configurações existentes para deixar tudo zerado:
# /sbin/lidsconf -Z
# /sbin/lidsconf -U
Porque rebootar por outro kernel?
Por que provavelmente você não conseguirá acessar as configurações do LIDS pelo kernel rodando ele. Ele estará bloqueado por padrão.
3.4 - Sem rebootar a máquina como posso desabilitar o LIDS?
Para conseguir essa façanha, utilize este comando:
# lidsadm -S -- -LIDS_GLOBAL
Agora você terá o LIDS desabilitado e seu sistema estará totalmente desprotegido por ele, caso queira ligá-lo novamente utilize:
# lidsadm -S -- +LIDS_GLOBAL
3.4 - Como ver o status do meu LIDS?
O comando abaixo nos trará uma saída com as funções que estão em uso pelo kernel:
# lidsadm -V
VIEW
CAP_CHOWN 0
CAP_DAC_OVERRIDE 0
CAP_DAC_READ_SEARCH 0
CAP_FOWNER 0
CAP_FSETID 0
CAP_KILL 0
CAP_SETGID 0
CAP_SETUID 0
CAP_SETPCAP 0
CAP_LINUX_IMMUTABLE 0
CAP_NET_BIND_SERVICE 0
CAP_NET_BROADCAST 0
CAP_NET_ADMIN 0
CAP_NET_RAW 0
CAP_IPC_LOCK 0
CAP_IPC_OWNER 0
CAP_SYS_MODULE 0
CAP_SYS_RAWIO 0
CAP_SYS_CHROOT 0
CAP_SYS_PTRACE 0
CAP_SYS_PACCT 0
CAP_SYS_ADMIN 0
CAP_SYS_BOOT 1
CAP_SYS_NICE 0
CAP_SYS_RESOURCE 1
CAP_SYS_TIME 0
CAP_SYS_TTY_CONFIG 0
CAP_MKNOD 0
CAP_LEASE 0
CAP_HIDDEN 1
CAP_KILL_PROTECTED 0
CAP_PROTECTED 0
LIDS 0
LIDS_GLOBAL 1
RELOAD_CONF 0
Configurando o LIDS
4.1 - Protegendo um arquivo/pasta como "somente leitura"
Essa configuração não irá permitir que nenhum usuário consiga escrever nos arquivos protegidos. Essa atitude é muito útil em caso de arquivos binários como o /bin/login, /bin/su para evitar o trabalho de rootkits.
Devemos frisar que quando digo nenhum usuário, me refiro a nenhum mesmo, nem mesmo o root. Portanto cuidado com os arquivos que irá proteger.
# lidsconf -A -o /path/to/file -j READONLY
Isso será necessário para proteger o arquivo como somente leitura. Se quisermos proteger uma pasta toda, basta colocarmos a pasta que queremos:
# lidsconf -A -o /pasta -j READONLY
E todas subpastas e arquivos de dentro estarão protegidos.
4.2 - Protegendo um arquivo/pasta tornando-o oculto e inacessível por usuários
Essa configuração tornará o arquivo protegido como invisível e inacessível para os usuários e para o sistema. Assim ele se tornará quase que algo não existente.
Raramente usaremos esses parâmetros sozinhos e sim em conjuntos para obter um controle em que softwares poderão escrever em determinados arquivos e tudo mais.
# lidsconf -A -o /path/file -j DENY
Com isso o arquivo ficará totalmente inacessível.
Isso e muito útil quando temos um servidor em que não se adiciona usuários, daí faremos o seguinte esquema para proteger o /etc/shadow:
# lidsconf -A -o /etc/shadow -j DENY
# lidsconf -A -o /bin/login -j READONLY
# lidsconf -A -s /bin/login -j READONLY
Isso faria com que nós conseguíssemos logar no sistema, mesmo o /etc/shadow estando totalmente inacessível ao sistema. Somente o /bin/login interage com ele.
4.3 - Como proteger meus arquivos de logs?
Bom, com certeza que arquivos de logs são os alvos mais previsíveis durante uma invasão, todo usuário iria querer sumir com suas entradas de dentro deles. Portanto, protegendo os logs como APPEND eles podem apenas ser adicionados, nunca apagados.
# lidsconf -A -o /var/log -j APPEND
Assim o invasor mesmo com root no sistema não conseguiria eliminar seus vestígios no sistema.
Bom, isso é o básico que todos devem saber sobre o LIDS. Vou passar agora umas regras básicas de proteção para o sistema, como por exemplo, proteger determinador daemons.
Configurações básicas para o sistema
Configuração de proteção para o Sistema:
# Protect System Binaries
#
/sbin/lidsconf -A -o /sbin -j READONLY
/sbin/lidsconf -A -o /bin -j READONLY
# Protect all of /usr and /usr/local
# (This assumes /usr/local is on a separate file system).
#
/sbin/lidsconf -A -o /usr -j READONLY
/sbin/lidsconf -A -o /usr/local -j READONLY
# Protect the System Libraries
#(/usr/lib is protected above since /usr/lib generally isn't
# on a separate file system than /usr)
#
/sbin/lidsconf -A -o /lib -j READONLY
# Protect /opt
#
/sbin/lidsconf -A -o /opt -j READONLY
# Protect System Configuration files
#
/sbin/lidsconf -A -o /etc -j READONLY
/sbin/lidsconf -A -o /usr/local/etc -j READONLY
/sbin/lidsconf -A -o /etc/shadow -j DENY
/sbin/lidsconf -A -o /etc/lilo.conf -j DENY
# Enable system authentication
#
/sbin/lidsconf -A -s /bin/login -o /etc/shadow -j READONLY
/sbin/lidsconf -A -s /usr/bin/vlock -o /etc/shadow -j READONLY
/sbin/lidsconf -A -s /bin/su -o /etc/shadow -j READONLY
/sbin/lidsconf -A -s /bin/su -o CAP_SETUID -j GRANT
/sbin/lidsconf -A -s /bin/su -o CAP_SETGID -j GRANT
# Protect the boot partition
#
/sbin/lidsconf -A -o /boot -j READONLY
# Protect root's home dir, but allow bash history
#
/sbin/lidsconf -A -o /root -j READONLY
/sbin/lidsconf -A -s /bin/bash -o /root/.bash_history -j WRITE
# Protect system logs
#
/sbin/lidsconf -A -o /var/log -j APPEND
/sbin/lidsconf -A -s /bin/login -o /var/log/wtmp -j WRITE
/sbin/lidsconf -A -s /bin/login -o /var/log/lastlog -j WRITE
/sbin/lidsconf -A -s /sbin/init -o /var/log/wtmp -j WRITE
/sbin/lidsconf -A -s /sbin/init -o /var/log/lastlog -j WRITE
/sbin/lidsconf -A -s /sbin/halt -o /var/log/wtmp -j WRITE
/sbin/lidsconf -A -s /sbin/halt -o /var/log/lastlog -j WRITE
/sbin/lidsconf -A -s /etc/rc.d/rc.sysinit -o /var/log/wtmp -i 1 -j WRITE
/sbin/lidsconf -A -s /etc/rc.d/rc.sysinit -o /var/log/lastlog -i 1 -j WRITE
# Startup
#
/sbin/lidsconf -A -s /sbin/hwclock -o /etc/adjtime -j WRITE
# Shutdown
#
/sbin/lidsconf -A -s /sbin/init -o CAP_INIT_KILL -j GRANT
/sbin/lidsconf -A -s /sbin/init -o CAP_KILL -j GRANT
# Give the following init script the proper privileges to kill
# processes and unmount the file systems. However, anyone who can
# execute these scripts by themselves can effectively kill your
# processes. It's better than the alternative, however.
#
# Any ideas on how to get around this are welcome!
#
/sbin/lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_INIT_KILL -i 1 -j GRANT
/sbin/lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_KILL -i 1 -j GRANT
/sbin/lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_NET_ADMIN -i 1 -j GRANT
/sbin/lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_SYS_ADMIN -i 1 -j GRANT
# Other
#
/sbin/lidsconf -A -s /sbin/update -o CAP_SYS_ADMIN -j GRANT
Segurança para Apache:
/sbin/lidsconf -A -s /usr/local/apache/bin/httpd -o CAP_SETUID -j GRANT
/sbin/lidsconf -A -s /usr/local/apache/bin/httpd -o CAP_SETGID -j GRANT
# Config files
/sbin/lidsconf -A -o /etc/httpd -j DENY
/sbin/lidsconf -A -s /usr/local/apache/bin/httpd -o /etc/httpd -j READONLY
# Server Root
/sbin/lidsconf -A -o /usr/local/apache -j DENY
/sbin/lidsconf -A -s /usr/local/apache/bin/httpd -o /usr/local/apache -j READONLY
# Log Files
/sbin/lidsconf -A -o /var/log/httpd -j DENY
/sbin/lidsconf -A -s /usr/local/apache/bin/httpd -o /var/log/httpd -j APPEND
/sbin/lidsconf -A -s /usr/local/apache/bin/httpd -o /usr/local/apache/logs -j WRITE
Segurança para MySQL:
/sbin/lidsconf -A -o /usr/local/mysql/var -j APPEND
/sbin/lidsconf -A -o /usr/local/mysql -j DENY
/sbin/lidsconf -A -s /usr/local/mysql/libexec/mysqld -o /usr/local/mysql -j READONLY
/sbin/lidsconf -A -s /usr/local/mysql/libexec/mysqld -o /usr/local/mysql/var -j WRITE
Segurança para Snort:
/sbin/lidsconf -A -s /usr/sbin/snort -o CAP_DAC_OVERRIDE -j GRANT
/sbin/lidsconf -A -s /usr/sbin/snort -o CAP_NET_RAW -j GRANT
/sbin/lidsconf -A -s /usr/sbin/snort -o CAP_HIDDEN -j GRANT
/sbin/lidsconf -A -s /usr/sbin/snort -o CAP_SETUID -j GRANT
/sbin/lidsconf -A -s /usr/sbin/snort -o CAP_SETGID -j GRANT
Segurança para Postfix:
/sbin/lidsconf -A -o /etc/postfix -j DENY
/sbin/lidsconf -A -o /var/spool/postfix -j DENY
/sbin/lidsconf -A -s /etc/init.d/postfix -o /etc/postfix -j READONLY -i 1
/sbin/lidsconf -A -s /etc/init.d/postfix -o /var/spool/postfix -j WRITE -i 1
/sbin/lidsconf -A -s /usr/sbin/postfix -o /etc/postfix -j READONLY -i 4
/sbin/lidsconf -A -s /usr/sbin/postfix -o /var/spool/postfix -j WRITE -i 4
/sbin/lidsconf -A -s /usr/lib/postfix/master -o CAP_SETGID -j GRANT -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o CAP_SETUID -j GRANT -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o CAP_HIDDEN -j GRANT -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o CAP_DAC_OVERRIDE -j GRANT -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o CAP_SYS_CHROOT -j GRANT -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o /etc/aliases.db -j READONLY -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o /var/spool/postfix -j WRITE -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o /etc/postfix -j READONLY -i 1
/sbin/lidsconf -A -s /usr/sbin/postdrop -o /etc/postfix -j READONLY
/sbin/lidsconf -A -s /usr/sbin/postdrop -o /var/spool/postfix -j WRITE
/sbin/lidsconf -A -s /usr/sbin/sendmail -o /etc/postfix -j READONLY
/sbin/lidsconf -A -s /usr/sbin/sendmail -o /var/spool/postfix -j WRITE
Considerações finais
Espero que este texto possa ajudar muita gente a melhorar a segurança de seus servidores e se aprofundar no mundo da segurança digital.
Em www.lids.org temos um FAQ completo onde podemos encontrar muito mais exemplos.
Obrigado por ler meu trabalho, espero que aproveitem bem.
Anderson Luiz Tamborim.
Y2h4ck@linuxmail.org
Fontes: http://www.lids.org
http://www.linuxsecurity.org
- eof --
Data: 21/02/2004
Introdução ao LIDS
1.0 - O que é o LIDS?
LIDS é um patch de melhorias para a kernel do Linux escrita por Xie Huagang e Philippe Biondi. Este patch adiciona esquemas de segurança extrema ao kernel e que não são possíveis apenas com as funções nativas da kernel.
Entre algumas destas funções temos:
Mandatory Access Controls (MACs)
Detecção de Port Scanners
Proteção de acesso a arquivos e pastas (incluindo pelo root)
Proteção de processos, módulos e interfaces.
1.1 - Porque utilizar o LIDS?
LIDS é um conjunto indispensável de ferramentas que vem sofrendo muitas melhorias nos últimos anos e me arrisco a dizer que ele está no auge do seu potencial com a versão 2.4.24 e 2.6 do kernel do Linux.
As ferramentas que acompanham o LIDS são muito fáceis de utilizar e configurar. Quem trabalha com segurança e deseja alcançar um nível superior de segurança dentro do seu sistema NECESSITA conhecer LIDS.
O LIDS, como vocês verão, não é uma ferramenta para se utilizar em micros de usuários devido a robustez de sua configuração, o que causaria uma série de problemas que o tornam de certa forma inviável, sendo que também temos ótimas ferramentas de IDS para Linux que usuários podem utilizar, como Snort, Portsentry, entre outras.
Com o LIDS podemos restringir qualquer acesso ao nosso sistema e ele nos manterá totalmente informado de tudo que esta havendo no sistema, qualquer tentativa de burlar sistemas protegidos pelo LIDS é documentada em emails e nos logs.
1.2 - Onde posso conseguir o LIDS?
Bom, o LIDS é uma atualização FREE para a kernel. Pode ser encontrada em http://www.lids.org e também nesta lista de mirrors: http://www.lids.org/mirrors.html.
1.3 - Direitos e Copyright
This software is copyright(c) 2000, 2001, 2002 for Steve Bremer - 2002, 2003 for Sander Klein and it is a FREE document. You may redistribute it under the terms of the GNU General Public License. The information herein this document is, to the best of Sander's knowledge, correct. However, LIDS and the LIDS-FAQ is written by humans and thus, the chance of mistakes, bugs, etc. might occur from time to time. No person, group, or other body is responsible for any damage on your computer(s) and any other losses by using the information on this document. i.e. "THE AUTHORS AND ALL MAINTAINERS ARE NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION IN THIS DOCUMENT."
Instalando o LIDS
2.1 - Como aplicar o patch do LIDS ao meu kernel?
A primeira coisa que devemos fazer é entrar em www.lids.org e baixar a versão de LIDS que corresponde ao kernel que iremos compilar, recomendo o kernel 2.4.24.
Se você não possui a versão deste kernel, poderá baixa-lo em www.kernel.org. Não entrarei em detalhes de como recompilar o kernel, se caso você que esteja lendo não possui tal habilidade, procure documentação antes de prosseguir.
Vamos descompactar o arquivo:
$ tar -zxvf lids-lids_version-kernel_version.tar.gz
Agora vamos entrar na pasta do nosso kernel:
$ cd /usr/src/linux
Agora aplicar o patch:
# patch -p1 < /path/to/lids/patch/lids-lids_version-kernel_version.patch Agora que o patch está aplicado, configure o seu kernel normalmente com o "make menuconfig". Você verá que apareceu um menu a mais na lista com o nome de Linux Intrusion Detection System. Para que o LIDS funcione, você deverá ter selecionados os seguintes esquemas: [*] Prompt for development and/or incomplete code/drivers [*] Sysctl Support General setup --->
[*] Networking support
[*] PCI support
(Any) PCI access mode
[*] PCI quirks
[ ] PCI bridge optimization (experimental)
[*] Backward-compatible /proc/pci
[ ] MCA support
[ ] SGI Visual Workstation support
[*] System V IPC
[ ] BSD Process Accounting
[*] Sysctl support
<*> Kernel support for a.out binaries
<*> Kernel support for ELF binaries
<*> Kernel support for MISC binaries
< > Parallel port support
[ ] Advanced Power Management BIOS support
Networking options ---> *(Personalize de acordo com suas
necessidades)
<*> Packet socket
[*] Kernel/User netlink socket
[*] Routing messages
<*> Netlink device emulation
[*] Network firewalls
[ ] Socket Filtering
<*> Unix domain sockets
[*] TCP/IP networking
[ ] IP: multicasting
[*] IP: advanced router
[ ] IP: policy routing
[*] IP: equal cost multipath
[ ] IP: use TOS value as routing key
[*] IP: verbose route monitoring
[*] IP: large routing tables
[ ] IP: kernel level autoconfiguration
[*] IP: firewalling
[*] IP: firewall packet netlink device
[ ] IP: transparent proxy support
[*] IP: masquerading
--- Protocol-specific masquerading support will be built as
modules.
[*] IP: ICMP masquerading
--- Protocol-specific masquerading support will be built as
modules.
[*] IP: masquerading special modules support
[*] IP: optimize as router not host
< > IP: tunneling
< > IP: GRE tunnels over IP
[*] IP: aliasing support
[ ] IP: ARP daemon support (EXPERIMENTAL)
[*] IP: TCP syncookie support (not enabled per default)
--- (it is safe to leave these untouched)
< > IP: Reverse ARP
[*] IP: Allow large windows (not recommended if <16Mb of memory) < > The IPv6 protocol (EXPERIMENTAL)
opções do lids no kernel -->
Linux Intrusion Detection System --->
[*] Linux Intrusion Detection System support (EXPERIMENTAL)
--- LIDS features
(1024) Maximum protected objects to manage
(1024) Maximum ACL subjects to manage
(1024) Maximum ACL objects to manage
(1024) Maximum protected proceeds
[ ] Hang up console when raising a securit alert
[ ] Security alert when execing unprotected programs before
sealing LIDS
[*] Try not to flood logs
(60)Authorised time between two identic logs (seconds)
[*] Allow switching LIDS protections
(3)Number of attempts to submit password
(3) Time to wait after a fail (seconds)
[ ] Allow remote users to switch LIDS protections
[ ] Allow any program to switch LIDS protections
[*] Allow reloading config. File
[*] Port Scanner Detector in kernel
[*] Send security alerts through network
[ ] Hide klids kernel thread
(3) Number of connection tries before giving up
(30)Sleep time after a failed connection
(16)Message queue size
Muito bem, agora recompile seu kernel normalmente como sempre faz. Adicione a imagem no seu gerenciador de inicialização e tudo mais. Pronto, seu kernel tem suporte ao LIDS.
2.2 - Instalando Lidsadm & Lidsconf
Entre na pasta onde você descompactou o LIDS:
$ tar -zvxf lidstools-version.tar.gz
$ cd lidstools-version
$ ./configure
$ make
$ su -
# make install
Junto ao LIDS, a versão que vem do lidstools já é antiga, puxe a versão 0.5.1 na página do LIDS e compile ela.
Muito bem, depois que terminar de compilar ele vai pedir uma senha, coloque uma que se lembre depois, porque ela será muito importante.
Depois que você instalar poderá ver se está tudo rodando perfeitamente:
$ lidsadm -v
Ele retornará a versão do lidsadm.
Bom... Primeira DICA: não reinicie seu sistema ainda ou então ele estará totalmente bloqueado. Recomendo-lhe limpar todas as funções do LIDS antes de reiniciar.
Se você olhar em /etc/lids/, teremos 2 arquivos:
Lids.cap -> Arquivo com as funções de capabilities
Lids.conf -> com as Entradas de configuração que editaremos
São os principais que usaremos.
Conhecendo o LIDS
3.1 - /sbin/lidsadm & /sbin/lidsconf
O lidsadm é um software que usaremos para administrar nosso LIDS. Vamos dar uma analisada básica nele:
# lidsadm -h
lidsadm version 0.4.1 for LIDS project
Huagang Xie
Philippe Biondi
Usage: lidsadm -[S|I] -- [+|-][LIDS_FLAG] [...]
lidsadm -V
lidsadm -h
Commands:
-S To submit a password to switch some protections
-I To switch some protections without submitting
password (sealing time)
-V To view current LIDS state (caps/flags)
-v To show the version
-h To list this help
Available capabilities:
CAP_CHOWN chown(2)/chgrp(2)
CAP_DAC_OVERRIDE DAC access
CAP_DAC_READ_SEARCH DAC read
CAP_FOWNER owner ID not equal user ID
CAP_FSETID effective user ID not equal owner ID
CAP_KILL real/effective ID not equal process ID
CAP_SETGID set*gid(2)
CAP_SETUID set*uid(2)
CAP_SETPCAP transfer capability
CAP_LINUX_IMMUTABLE immutable and append file attributes
CAP_NET_BIND_SERVICE binding to ports below 1024
CAP_NET_BROADCAST broadcasting/listening to multicast
CAP_NET_ADMIN interface/firewall/routing changes
CAP_NET_RAW raw sockets
CAP_IPC_LOCK locking of shared memory segments
CAP_IPC_OWNER IPC ownership checks
CAP_SYS_MODULE insertion and removal of kernel modules
CAP_SYS_RAWIO ioperm(2)/iopl(2) access
CAP_SYS_CHROOT chroot(2)
CAP_SYS_PTRACE ptrace(2)
CAP_SYS_PACCT configuration of process accounting
CAP_SYS_ADMIN tons of admin stuff
CAP_SYS_BOOT reboot(2)
CAP_SYS_NICE nice(2)
CAP_SYS_RESOURCE setting resource limits
CAP_SYS_TIME setting system time
CAP_SYS_TTY_CONFIG tty configuration
CAP_MKNOD mknod operation
CAP_LEASE taking leases on files
CAP_HIDDEN hidden process
CAP_KILL_PROTECTED kill protected programs
CAP_PROTECTED Protect the process from signals
Available flags:
LIDS de-/activate LIDS locally (the shell & childs)
LIDS_GLOBAL de-/activate LIDS entirely
RELOAD_CONF reload config. file and inode/dev of
protected programs
Temos a lista de todos os "capabilities".
Com o lidsconf faremos as configurações do LIDS no nosso sistema, ou seja, o que iremos bloquear e o que iremos liberar. O lidsconf na sua instalação gera uma configuração padrão que podemos analizar assim:
# lidsconf -h
lidsconf version 0.4.1 for the LIDS project
Huagang Xie
Philippe Biondi
Usage: lidsconf -A [-s subject] -o object [-d] [-t from-to]
[-i level] -j ACTION
lidsconf -D [-s file] [-o file]
lidsconf -Z
lidsconf -U
lidsconf -L [-e]
lidsconf -P
lidsconf -v
lidsconf -[h|H]
Commands:
-A,--add To add an entry
-D,--delete To delete an entry
-Z,--zero To delete all entries
-U,--update To update dev/inode numbers
-L,--list To list all entries
-P,--passwd To encrypt a password with RipeMD-160
-v,--version To show the version
-h,--help To list this help
-H,--morehelp To list this help with CAP/SOCKET name
subject: -s,--subject subj
can be any program, must be a file
object: -o,--object [obj]
can be a file, directory or Capability, Socket Name
ACTION: -j,--jump
DENY deny access
READONLY read only
APPEND append only
WRITE writable
GRANT grant capability to subject
IGNORE ignore any permissions set on this object
DISABLE disable some extersion feature
OPTION:
-d,--domain The object is an EXEC Domain
-i,--inheritance Inheritance level
-t,--time Time dependency
-e,--extended Extended list
Os comandos principais que usaremos serão:
lidsconf -L: lista as configurações atuais.
lidsconf -Z: zera as configurações.
lidsconf -U: Atualiza as configurações, sempre deve-se atualizar quando se acrescenta uma nova regra.
Como posso setar uma nova password:
# lidsconf -P
MAKE PASSWD
enter new password:
reenter new password:
wrote password to /etc/lids/lids.pw
A senha ficará escrita nesse arquivo com criptografia de 185 bits.
3.2 - Como dizer ao LIDS para recarregar minha configuração?
Bom, para que isso ocorra você deve ter selecionado esses esquemas no seu menuconfig:
[*] Allow switching LIDS protections
(3) Number of attempts to submit password
(30) Time to wait after a fail (seconds)
[ ] Allow remote users to switch LIDS protections
[ ] Allow any program to switch LIDS protections
[*] Allow reloading config. file <-----------
# lidsadm -S -- +RELOAD_CONF
Isso irá recarregar o seu LIDS com as novas configurações sem precisar reiniciar o kernel.
3.3 - Socorro meu sistema esta totalmente bloqueado
Bom, se isso acontecer você deverá bootar seu linux pelo kernel antigo (sem LIDS) e retirar todos os atributos de configurações existentes para deixar tudo zerado:
# /sbin/lidsconf -Z
# /sbin/lidsconf -U
Porque rebootar por outro kernel?
Por que provavelmente você não conseguirá acessar as configurações do LIDS pelo kernel rodando ele. Ele estará bloqueado por padrão.
3.4 - Sem rebootar a máquina como posso desabilitar o LIDS?
Para conseguir essa façanha, utilize este comando:
# lidsadm -S -- -LIDS_GLOBAL
Agora você terá o LIDS desabilitado e seu sistema estará totalmente desprotegido por ele, caso queira ligá-lo novamente utilize:
# lidsadm -S -- +LIDS_GLOBAL
3.4 - Como ver o status do meu LIDS?
O comando abaixo nos trará uma saída com as funções que estão em uso pelo kernel:
# lidsadm -V
VIEW
CAP_CHOWN 0
CAP_DAC_OVERRIDE 0
CAP_DAC_READ_SEARCH 0
CAP_FOWNER 0
CAP_FSETID 0
CAP_KILL 0
CAP_SETGID 0
CAP_SETUID 0
CAP_SETPCAP 0
CAP_LINUX_IMMUTABLE 0
CAP_NET_BIND_SERVICE 0
CAP_NET_BROADCAST 0
CAP_NET_ADMIN 0
CAP_NET_RAW 0
CAP_IPC_LOCK 0
CAP_IPC_OWNER 0
CAP_SYS_MODULE 0
CAP_SYS_RAWIO 0
CAP_SYS_CHROOT 0
CAP_SYS_PTRACE 0
CAP_SYS_PACCT 0
CAP_SYS_ADMIN 0
CAP_SYS_BOOT 1
CAP_SYS_NICE 0
CAP_SYS_RESOURCE 1
CAP_SYS_TIME 0
CAP_SYS_TTY_CONFIG 0
CAP_MKNOD 0
CAP_LEASE 0
CAP_HIDDEN 1
CAP_KILL_PROTECTED 0
CAP_PROTECTED 0
LIDS 0
LIDS_GLOBAL 1
RELOAD_CONF 0
Configurando o LIDS
4.1 - Protegendo um arquivo/pasta como "somente leitura"
Essa configuração não irá permitir que nenhum usuário consiga escrever nos arquivos protegidos. Essa atitude é muito útil em caso de arquivos binários como o /bin/login, /bin/su para evitar o trabalho de rootkits.
Devemos frisar que quando digo nenhum usuário, me refiro a nenhum mesmo, nem mesmo o root. Portanto cuidado com os arquivos que irá proteger.
# lidsconf -A -o /path/to/file -j READONLY
Isso será necessário para proteger o arquivo como somente leitura. Se quisermos proteger uma pasta toda, basta colocarmos a pasta que queremos:
# lidsconf -A -o /pasta -j READONLY
E todas subpastas e arquivos de dentro estarão protegidos.
4.2 - Protegendo um arquivo/pasta tornando-o oculto e inacessível por usuários
Essa configuração tornará o arquivo protegido como invisível e inacessível para os usuários e para o sistema. Assim ele se tornará quase que algo não existente.
Raramente usaremos esses parâmetros sozinhos e sim em conjuntos para obter um controle em que softwares poderão escrever em determinados arquivos e tudo mais.
# lidsconf -A -o /path/file -j DENY
Com isso o arquivo ficará totalmente inacessível.
Isso e muito útil quando temos um servidor em que não se adiciona usuários, daí faremos o seguinte esquema para proteger o /etc/shadow:
# lidsconf -A -o /etc/shadow -j DENY
# lidsconf -A -o /bin/login -j READONLY
# lidsconf -A -s /bin/login -j READONLY
Isso faria com que nós conseguíssemos logar no sistema, mesmo o /etc/shadow estando totalmente inacessível ao sistema. Somente o /bin/login interage com ele.
4.3 - Como proteger meus arquivos de logs?
Bom, com certeza que arquivos de logs são os alvos mais previsíveis durante uma invasão, todo usuário iria querer sumir com suas entradas de dentro deles. Portanto, protegendo os logs como APPEND eles podem apenas ser adicionados, nunca apagados.
# lidsconf -A -o /var/log -j APPEND
Assim o invasor mesmo com root no sistema não conseguiria eliminar seus vestígios no sistema.
Bom, isso é o básico que todos devem saber sobre o LIDS. Vou passar agora umas regras básicas de proteção para o sistema, como por exemplo, proteger determinador daemons.
Configurações básicas para o sistema
Configuração de proteção para o Sistema:
# Protect System Binaries
#
/sbin/lidsconf -A -o /sbin -j READONLY
/sbin/lidsconf -A -o /bin -j READONLY
# Protect all of /usr and /usr/local
# (This assumes /usr/local is on a separate file system).
#
/sbin/lidsconf -A -o /usr -j READONLY
/sbin/lidsconf -A -o /usr/local -j READONLY
# Protect the System Libraries
#(/usr/lib is protected above since /usr/lib generally isn't
# on a separate file system than /usr)
#
/sbin/lidsconf -A -o /lib -j READONLY
# Protect /opt
#
/sbin/lidsconf -A -o /opt -j READONLY
# Protect System Configuration files
#
/sbin/lidsconf -A -o /etc -j READONLY
/sbin/lidsconf -A -o /usr/local/etc -j READONLY
/sbin/lidsconf -A -o /etc/shadow -j DENY
/sbin/lidsconf -A -o /etc/lilo.conf -j DENY
# Enable system authentication
#
/sbin/lidsconf -A -s /bin/login -o /etc/shadow -j READONLY
/sbin/lidsconf -A -s /usr/bin/vlock -o /etc/shadow -j READONLY
/sbin/lidsconf -A -s /bin/su -o /etc/shadow -j READONLY
/sbin/lidsconf -A -s /bin/su -o CAP_SETUID -j GRANT
/sbin/lidsconf -A -s /bin/su -o CAP_SETGID -j GRANT
# Protect the boot partition
#
/sbin/lidsconf -A -o /boot -j READONLY
# Protect root's home dir, but allow bash history
#
/sbin/lidsconf -A -o /root -j READONLY
/sbin/lidsconf -A -s /bin/bash -o /root/.bash_history -j WRITE
# Protect system logs
#
/sbin/lidsconf -A -o /var/log -j APPEND
/sbin/lidsconf -A -s /bin/login -o /var/log/wtmp -j WRITE
/sbin/lidsconf -A -s /bin/login -o /var/log/lastlog -j WRITE
/sbin/lidsconf -A -s /sbin/init -o /var/log/wtmp -j WRITE
/sbin/lidsconf -A -s /sbin/init -o /var/log/lastlog -j WRITE
/sbin/lidsconf -A -s /sbin/halt -o /var/log/wtmp -j WRITE
/sbin/lidsconf -A -s /sbin/halt -o /var/log/lastlog -j WRITE
/sbin/lidsconf -A -s /etc/rc.d/rc.sysinit -o /var/log/wtmp -i 1 -j WRITE
/sbin/lidsconf -A -s /etc/rc.d/rc.sysinit -o /var/log/lastlog -i 1 -j WRITE
# Startup
#
/sbin/lidsconf -A -s /sbin/hwclock -o /etc/adjtime -j WRITE
# Shutdown
#
/sbin/lidsconf -A -s /sbin/init -o CAP_INIT_KILL -j GRANT
/sbin/lidsconf -A -s /sbin/init -o CAP_KILL -j GRANT
# Give the following init script the proper privileges to kill
# processes and unmount the file systems. However, anyone who can
# execute these scripts by themselves can effectively kill your
# processes. It's better than the alternative, however.
#
# Any ideas on how to get around this are welcome!
#
/sbin/lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_INIT_KILL -i 1 -j GRANT
/sbin/lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_KILL -i 1 -j GRANT
/sbin/lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_NET_ADMIN -i 1 -j GRANT
/sbin/lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_SYS_ADMIN -i 1 -j GRANT
# Other
#
/sbin/lidsconf -A -s /sbin/update -o CAP_SYS_ADMIN -j GRANT
Segurança para Apache:
/sbin/lidsconf -A -s /usr/local/apache/bin/httpd -o CAP_SETUID -j GRANT
/sbin/lidsconf -A -s /usr/local/apache/bin/httpd -o CAP_SETGID -j GRANT
# Config files
/sbin/lidsconf -A -o /etc/httpd -j DENY
/sbin/lidsconf -A -s /usr/local/apache/bin/httpd -o /etc/httpd -j READONLY
# Server Root
/sbin/lidsconf -A -o /usr/local/apache -j DENY
/sbin/lidsconf -A -s /usr/local/apache/bin/httpd -o /usr/local/apache -j READONLY
# Log Files
/sbin/lidsconf -A -o /var/log/httpd -j DENY
/sbin/lidsconf -A -s /usr/local/apache/bin/httpd -o /var/log/httpd -j APPEND
/sbin/lidsconf -A -s /usr/local/apache/bin/httpd -o /usr/local/apache/logs -j WRITE
Segurança para MySQL:
/sbin/lidsconf -A -o /usr/local/mysql/var -j APPEND
/sbin/lidsconf -A -o /usr/local/mysql -j DENY
/sbin/lidsconf -A -s /usr/local/mysql/libexec/mysqld -o /usr/local/mysql -j READONLY
/sbin/lidsconf -A -s /usr/local/mysql/libexec/mysqld -o /usr/local/mysql/var -j WRITE
Segurança para Snort:
/sbin/lidsconf -A -s /usr/sbin/snort -o CAP_DAC_OVERRIDE -j GRANT
/sbin/lidsconf -A -s /usr/sbin/snort -o CAP_NET_RAW -j GRANT
/sbin/lidsconf -A -s /usr/sbin/snort -o CAP_HIDDEN -j GRANT
/sbin/lidsconf -A -s /usr/sbin/snort -o CAP_SETUID -j GRANT
/sbin/lidsconf -A -s /usr/sbin/snort -o CAP_SETGID -j GRANT
Segurança para Postfix:
/sbin/lidsconf -A -o /etc/postfix -j DENY
/sbin/lidsconf -A -o /var/spool/postfix -j DENY
/sbin/lidsconf -A -s /etc/init.d/postfix -o /etc/postfix -j READONLY -i 1
/sbin/lidsconf -A -s /etc/init.d/postfix -o /var/spool/postfix -j WRITE -i 1
/sbin/lidsconf -A -s /usr/sbin/postfix -o /etc/postfix -j READONLY -i 4
/sbin/lidsconf -A -s /usr/sbin/postfix -o /var/spool/postfix -j WRITE -i 4
/sbin/lidsconf -A -s /usr/lib/postfix/master -o CAP_SETGID -j GRANT -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o CAP_SETUID -j GRANT -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o CAP_HIDDEN -j GRANT -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o CAP_DAC_OVERRIDE -j GRANT -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o CAP_SYS_CHROOT -j GRANT -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o /etc/aliases.db -j READONLY -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o /var/spool/postfix -j WRITE -i 1
/sbin/lidsconf -A -s /usr/lib/postfix/master -o /etc/postfix -j READONLY -i 1
/sbin/lidsconf -A -s /usr/sbin/postdrop -o /etc/postfix -j READONLY
/sbin/lidsconf -A -s /usr/sbin/postdrop -o /var/spool/postfix -j WRITE
/sbin/lidsconf -A -s /usr/sbin/sendmail -o /etc/postfix -j READONLY
/sbin/lidsconf -A -s /usr/sbin/sendmail -o /var/spool/postfix -j WRITE
Considerações finais
Espero que este texto possa ajudar muita gente a melhorar a segurança de seus servidores e se aprofundar no mundo da segurança digital.
Em www.lids.org temos um FAQ completo onde podemos encontrar muito mais exemplos.
Obrigado por ler meu trabalho, espero que aproveitem bem.
Anderson Luiz Tamborim.
Y2h4ck@linuxmail.org
Fontes: http://www.lids.org
http://www.linuxsecurity.org
- eof --
Inserindo data e hora no comando history
Para adicionar a data e hora no comando history você precisa inserir o conteúdo "%h/%d - %H:%M:%S " na variável HISTTIMEFORMAT, então faça:
# export HISTTIMEFORMAT="%h/%d - %H:%M:%S "
Quando reiniciar sua máquina, ou fizer o logoff com o seu usuário, a variável automaticamente será desativada, ou melhor, não terá conteúdo, então você precisa adicionar no .bashrc do seu usuário.
Se você estiver utilizando o usuário root, acesse:
# vim /root/.bashrc
E adicione ao final do arquivo a exportação da variável:
export HISTTIMEFORMAT="%h/%d - %H:%M:%S "
# export HISTTIMEFORMAT="%h/%d - %H:%M:%S "
Quando reiniciar sua máquina, ou fizer o logoff com o seu usuário, a variável automaticamente será desativada, ou melhor, não terá conteúdo, então você precisa adicionar no .bashrc do seu usuário.
Se você estiver utilizando o usuário root, acesse:
# vim /root/.bashrc
E adicione ao final do arquivo a exportação da variável:
export HISTTIMEFORMAT="%h/%d - %H:%M:%S "
Symbian development on Linux and OS X (Como emular symbian no Linux e MAC OS X)
Neste link:http://www.martin.st/symbian/ há uma breve explicação de como fazer isso, mas estou escrevendo um paper melhorado voltado para pentest/análise de malware.
Introduction
Since version 1.03 of my gnupoc package, I've combined SDK patches, updated tool sources and gcc patches into one (slighly larger) package, instead of distributing lots of patches separately. People interested in the old approach can read the old version of this page.
The main goal of this gnupoc patch collection is to be able to build symbian projects on unix-like systems with as little changes as possible to the actual projects. This means that it e.g. uses the same mmp files and external makefiles for icons as on Windows.
My patches and tools are based on the original GnuPoc project.
Using this package, you can build applications for S60 1st, 2nd, 3rd ed and 5th ed, Symbian^3, and UIQ 3, on Linux and OS X. The SDKs can be unpacked and binaries and sis packages be built completely without wine.
The latest, unreleased version is available on GitHub. If you're having problems, you may want to check whether it already has been fixed here.
News/changes
Version 1.20 (March 10, 2010) - Support for Qt 4.7.2 and Qt Mobility 1.1.1, support for installing CodeSourcery GCC 2009q1 (4.3) and 4.4-172, support for the symbian/linux-gcce mkspec in Qt 4.7.x, installing SDK headers with the canonical capitalization (keeping lowercase names via symlinks), support for replacing carbide style environment variables in pkg files in makesis, support for bitmaps in mifconv
Version 1.19 (November 17, 2010) - A critical fix for a bug in 1.18, where elf2e32 was unable to create binaries with UIDs in the unprotected range, on some OSes
Version 1.18 (November 15, 2010) - Bug fixes for Qt 4.7.0, support for Qt 4.7.1, a script for installing Qt Mobility, some improvments to elf2e32 and elftran, support for the new Symbian^3 SDK version
Version 1.17 (September 24, 2010) - Support for installing Open C 1.7.5 (thanks to Tero Hasu), support for installing Qt 4.7.0, in addition to Qt 4.6.3. See the gnupoc-package/sdks/README.qt file for instructions on setting up the Qt SDK.
Version 1.16 (August 12, 2010) - Initial support for using the Qt for Symbian SDKs for building Qt applications, preliminary support for the Symbian^3 SDK beta. See the gnupoc-package/sdks/README.qt file for instructions on setting up the Qt SDK. Additionally, assorted fixes and updates to the toolchain.
Version 1.15 (January 18, 2010) - Added support for some more parameters to elf2e32, fixed a crash in extmake, fixed a problem in one of the installer scripts, as pointed out by Anderson Lizardo.
Version 1.14 (December 1, 2009) - Added support for RVCT, based on patches by Anderson Lizardo, added support for both armv5 and armv5_abiv2. Added an installer script for the Open C/C++ plugins. Updated the bundled unshield source (fixing some 64 bit issues). Fix compilation of CSL GCC on newer linux distributions (newer versions of bison). Large updates to the elf2e32 replacement, fixing handling of some more uncommon combinations. Initial replacements for the elftran, gendirective, genstubs and getexports tools (needed for building armv5 binaries).
Version 1.13 (March 31, 2009) - Updated the S60 5.0 SDK scripts and patches to the 1.0 version of the SDK, recently released, some minor fixes.
Version 1.12 (January 22, 2009) - Fixed compilation with gcc 4.3, integrated a fix for ar in both EKA1 and EKA2 gcc (needed on e.g. Ubuntu 8.10), fixed building DLLs on the S60 3.2 SDK (thanks to Jean-Yves Baudy for pointing this out), assorted fixes for S60 5.0, fix building of the EKA1 gcc on x86_64/linux, initial support for compiling context-sensitive help (requires wine), other misc fixes
Version 1.11 (October 3, 2008) - Initial support for S60 5.0
Version 1.10 (September 4, 2008) - compilation fixes for g++ 4.3 (thanks to Mrinal Kalakrishnan and Jakob Kemi for sending patches!), some minor new features implemented in signsis
Version 1.09 (March 31, 2008) - adds support for S60 3.2, and has some minor bugfixes and new features for the included tools
Version 1.08 (February 27, 2008) - fixes a lot of issues on OS X Leopard. Seems to work fine on most Leopard machines, if you experience problems please let me know.
Version 1.07 (December 04, 2007) - fixes a regression in compiling the EKA1 gcc
Version 1.06 (November 26, 2007) - fixed a bug in elf2e32 which prevented it from working on S60 3.1, fixed some compilation problems on FreeBSD, added an initial patch for the S60 3.2 SDK beta (but no installer script yet, since I haven't found a tool able to unpack the installer). Thanks to all who reported problems and helped solve them!
Version 1.05 (September 14, 2007) - a bugfix for signsis, deflate compression support for petran and elf2e32, build elf2e32 by default, an initial version of a svgt-binary encoder
Version 1.04 (September 2, 2007) - fixes for rcomp, petran and makesis for running on 64-bit linux, small bugfixes in mifconv and elf2e32, better error reporting in the new rcomp, completely new makesis for Symbian 9 SIS files, use unshield instead of i6comp.exe for extracting S60 SDKs
Version 1.03 (August 13, 2007) - support for UIQ 3.0 and 3.1, added most tools except gcc into the package, support for symbian 9 resources in rcomp, elf2e32 replacement, mifconv replacement, support for building the old GCC toolchain on OSX/intel
Version 1.02 (April 7, 2007) - calls external makefiles using wine, some more assorted bugfixes
Version 1.01 (March 5, 2007) - clarified the license, added instructions on doing a read-only installation of the SDKs, some other slight bugfixes
Version 1.0 (October 15, 2006) - initial release
Download the latest package above. First you'll have to install a toolchain for the SDK you want to use. For S60 1st and 2nd ed, you need the EKA1 toolchain, for S60 3rd ed and UIQ 3, you need the EKA2 toolchain.
Installing the EKA1 toolchain
Refer to the tools/README file for more details on this process.
In addition to the GnuPoc archive, you need the source to the modified gcc release (local copy).
Unpack the GnuPoc archive, enter the tools directory, and compile gcc using the install_gcc_539 script:
tar -zxvf gnupoc-package-1.03.tar.gz
cd gnupoc-package-1.03
cd tools
./install_gcc_539 ../../gcc-539-2aeh-source.tar.bz2 ~/symbian-gcc
If you want to have a compiler for the THUMB target, build that with the isntall_gcc_539_thumb script similarly.
Then you can install the rest of the tools. These aren't strictly necessary if wine is available, but recommended. (If omitted, the build scripts uses the exe versions in the SDK instead.)
./install_eka1_tools ~/symbian-gcc
Installing the EKA2 toolchain
Refer to the tools/README file for more details on this process.
In addition to the GnuPoc archive, you need CodeSourcery's GCC. For Linux, you can choose to download the binaries, for other platforms you can compile it from source. (There's also local copies of the Linux binaries and the source.)
To install the binaries, just unpack them (in your home directory):
mkdir csl-gcc
cd csl-gcc
tar -jxvf ../gnu-csl-arm-2005Q1C-arm-none-symbianelf-i686-pc-linux-gnu.tar.bz2
To compile it from source instead, unpack the GnuPoc archive and use the install_csl_gcc script:
tar -zxvf gnupoc-package-1.03.tar.gz
cd gnupoc-package-1.03
cd tools
./install_csl_gcc ../../gnu-csl-arm-2005Q1C-arm-none-symbianelf.src.tar.bz2 ~/csl-gcc
Then you can install the rest of the tools. These aren't strictly necessary if wine is available. (If omitted, the build scripts uses the exe versions in the SDK instead.)
cd gnupoc-package-1.03
cd tools
./install_eka2_tools ~/csl-gcc
Note, this requires openssl libraries to be installed.
SDKs
Refer to the sdks/README file for more details on this process.
After downloading the GnuPoc package above, you still need to get the SDK you want to use from Forum Nokia. (The UIQ SDKs were available from http://developer.uiq.com earlier, but are no longer available.) The following versions are supported at the moment:
Version File name Install script Comments
S60 1st Edition, FP1, WINS nS60_sdk_v1_2.zip install_gnupoc_s60_12
S60 2nd Edition, WINS s60_sdk_v2_0.zip install_gnupoc_s60_20 Working emulator
S60 2nd Edition, FP1, WINS S60_SDK_2_1_NET.zip install_gnupoc_s60_21
S60 2nd Edition, FP1, CW S60_SDK_v21c_CW.zip install_gnupoc_s60_21_cw Working emulator
S60 2nd Edition, FP2, WINS s60_2nd_fp2_sdk_msb.zip install_gnupoc_s60_26 Working emulator
S60 2nd Edition, FP2, CW s60_2nd_fp2_sdk.zip install_gnupoc_s60_26_cw Working emulator
S60 2nd Edition, FP3 s60_2nd_sdk_fp3.zip install_gnupoc_s60_28
S60 3rd Edition, Maintenance Release S60-SDK-0616-3.0-mr.3.749.zip install_gnupoc_s60_30
S60 3rd Edition, FP 1 S60-SDK-200634-3.1-Cpp-f.1090b.zip install_gnupoc_s60_31
S60 3rd Edition, FP 2 S60-3.2-SDK-f.inc3.2130.zip install_gnupoc_s60_32
S60 5th Edition S60_5th_Edition_SDK_v1_0_en.zip install_gnupoc_s60_50
N97 SDK Nokia_N97_SDK_v1_0_en.zip install_gnupoc_s60_50
Symbian^3 Symbian_3_SDK_v0_9_en.zip install_gnupoc_symbian3
UIQ 3.0 UIQ3.0SDK.exe install_gnupoc_uiq_30
UIQ 3.1 UIQ3.1SDK.exe install_gnupoc_uiq_31
(Everything is tested using Wine 0.9.15 and remote X to X11.app on OS X, things might work better or worse on other setups.)
The installation script uses included prebuild binaries of p7zip and a specially patched version of unshield for linux/x86. If you can't run these, see sdks/unshield/README and sdks/7z/README for instructions on compiling native versions of them.
Example on installing an SDK:
tar -zxvf gnupoc-package-1.03.tar.gz
cd gnupoc-package-1.03
cd sdks
./install_gnupoc_s60_26 ../../s60_2nd_fp2_sdk_msb.zip ~/symbian-sdks/s60_26
The install scripts makes almost all files lowercase and patches the build scripts. The exception to the lowercase rule is the GLES include directory and libGLES_CM.lib, for compatibility reasons.
In order to use the SDK, you'll have to set the EPOCROOT environment variable to point to your SDK and add the toolchain directory and the epoc32/tools directory of the SDK to your PATH. This might be cumbersome if frequently switching between different SDKs. To ease that situation, you can install some wrapper scripts:
./install_wrapper ~/gnupoc
If you've installed the toolchains to other directories than mentioned here, edit ~/gnupoc/gnupoc-common.sh and set EKA1TOOLS and EKA2TOOLS to point to where you've installed them. With these wrappers, you only have to have this single directory in your PATH, and depending on the EPOCROOT variable, the correct toolchain is included and scripts from the current SDK are called.
Wine setup
If you're going to use some tools through wine, you have to copy uidcrc.exe from the epoc32/tools directory in the SDK to a directory in the wine path, e.g. ~/.wine/drive_c/windows. By default, wine is only needed for using the windows compilers, but you might use it to run the original tools instead of the native replacements, if you have problems with the native ones.
If using external makefiles (as for building icons in 3rd edition) with wine, copy make.exe and mifconv.exe, too. make.exe probably can be used from any SDK version, but you'll need mifconv.exe from the 3.0 SDK, since mifconv.exe in 3.1 has some problems starting within wine. Note, this is only needed if omitting the extra EKA2 tools above.
In order to build binaries for the emulator, you'll need a windows compiler. Unfortunately, these have to be copied from a real installation. (Perhaps it's possible to do the complete installation of them within wine?)
For the WINS compiler, I've used Visual C++ Toolkit 2003, set up according to this page. Just copy over the C:\Program Files\Microsoft Visual C++ Toolkit 2003 directory to e.g. ~/.wine/drive_c/msvcpp2003.
For the WINSCW compiler, you can install Carbide C++ from Forum Nokia. These instructions apply to Carbide C++ 1.0, for newer versions you might need to use slightly different paths. Copy C:\Program Files\Carbide\plugins\com.nokia.carbide.cpp.support_1.0.0 to e.g. ~/.wine/drive_c/codewarrior.
These have to be added to the wine path. Edit ~/.wine/user.reg, and add this after the WINE REGISTRY Version 2 line:
[Environment]
"Path"="c:\\msvcpp2003\\bin;c:\\codewarrior\\Symbian_Tools\\Command_Line_Tools;c:\\windows;c:\\windows\\system"
(Of course, if you've already got a similar environment definition in that file, add it there instead.)
When using the CW compiler, you'll also need to add these variables to your unix environment (the perl build scripts need them, adding them to the wine environment isn't enough, and if set in the unix environment, they're also automatically available in wine):
export MWCSym2Includes="c:\\codewarrior\\symbian_support\\MSL\\MSL_C\\MSL_Common\\include;c:\\codewarrior\\symbian_support\\MSL\\MSL_C++\\MSL_Common\\include;c:\\codewarrior\\symbian_support\\MSL\\MSL_Extras\\MSL_Common\\include"
export MWSym2Libraries="+c:\\codewarrior\\symbian_support"
export MWSym2LibraryFiles="MSL_All_MSE_Symbian.lib;gdi32.lib;user32.lib;kernel32.lib"
Using it
After installing everything, you're able to compile things in the same way as on windows.
In order to compile most projects, the usage of upper/lowercase for filenames must be cleaned up somewhat. The install scripts clean up the usage of lower/upper case in the bundled examples (by forcing them to lowercase), so the should all be buildable directly. (Or at least it tries to, it might not work reliably in stranger examples.)
To build the hello world example on a S60 3rd edition SDK, do the following:
export PATH=~/gnupoc:${PATH}
export EPOCROOT=~/symbian-sdks/s60_30/
cd ${EPOCROOT}/s60ex/helloworldbasic/group
bldmake bldfiles
abld build gcce urel
cd ../sis
makesis helloworldbasic_gcce.pkg helloworldbasic.sis
For 1st and 2nd edition, use the paths for those SDKs and build using abld build armi urel instead. The .pkg files for those examples are written for the THUMB target. Either update the .pkg file and replace all occurrances of thumb with armi or build them using abld build thumb urel (which requires that you built a thumb compiler).
On 3rd edition, all sis files must be signed before they can be installed. If you haven't already got a key and certificate pair, generate them:
makekeys -cert -expdays 3650 -password mykey.key mycert.cer
This will prompt for information to enter into the certificate, and create a certificate valid for 10 years. (To create a certificate without a password, just leave out -password. The makekeys tool included in this package has a similar but not identical syntax compared to the makekeys tool in the real SDKs.) Then sign the sis file using this certificate:
signsis helloworldbasic.sis helloworldbasic.sisx mycert.cer mykey.key
The newly generated .sisx file can then be installed on a device.
The version of makesis for Symbian 9 included in this package is also able to sign the package directly when creating it, using a built-in certificate. To use this feature, just add the command line parameter -c.
Contact
// Martin Storsjö
Introduction
Since version 1.03 of my gnupoc package, I've combined SDK patches, updated tool sources and gcc patches into one (slighly larger) package, instead of distributing lots of patches separately. People interested in the old approach can read the old version of this page.
The main goal of this gnupoc patch collection is to be able to build symbian projects on unix-like systems with as little changes as possible to the actual projects. This means that it e.g. uses the same mmp files and external makefiles for icons as on Windows.
My patches and tools are based on the original GnuPoc project.
Using this package, you can build applications for S60 1st, 2nd, 3rd ed and 5th ed, Symbian^3, and UIQ 3, on Linux and OS X. The SDKs can be unpacked and binaries and sis packages be built completely without wine.
The latest, unreleased version is available on GitHub. If you're having problems, you may want to check whether it already has been fixed here.
News/changes
Version 1.20 (March 10, 2010) - Support for Qt 4.7.2 and Qt Mobility 1.1.1, support for installing CodeSourcery GCC 2009q1 (4.3) and 4.4-172, support for the symbian/linux-gcce mkspec in Qt 4.7.x, installing SDK headers with the canonical capitalization (keeping lowercase names via symlinks), support for replacing carbide style environment variables in pkg files in makesis, support for bitmaps in mifconv
Version 1.19 (November 17, 2010) - A critical fix for a bug in 1.18, where elf2e32 was unable to create binaries with UIDs in the unprotected range, on some OSes
Version 1.18 (November 15, 2010) - Bug fixes for Qt 4.7.0, support for Qt 4.7.1, a script for installing Qt Mobility, some improvments to elf2e32 and elftran, support for the new Symbian^3 SDK version
Version 1.17 (September 24, 2010) - Support for installing Open C 1.7.5 (thanks to Tero Hasu), support for installing Qt 4.7.0, in addition to Qt 4.6.3. See the gnupoc-package/sdks/README.qt file for instructions on setting up the Qt SDK.
Version 1.16 (August 12, 2010) - Initial support for using the Qt for Symbian SDKs for building Qt applications, preliminary support for the Symbian^3 SDK beta. See the gnupoc-package/sdks/README.qt file for instructions on setting up the Qt SDK. Additionally, assorted fixes and updates to the toolchain.
Version 1.15 (January 18, 2010) - Added support for some more parameters to elf2e32, fixed a crash in extmake, fixed a problem in one of the installer scripts, as pointed out by Anderson Lizardo.
Version 1.14 (December 1, 2009) - Added support for RVCT, based on patches by Anderson Lizardo, added support for both armv5 and armv5_abiv2. Added an installer script for the Open C/C++ plugins. Updated the bundled unshield source (fixing some 64 bit issues). Fix compilation of CSL GCC on newer linux distributions (newer versions of bison). Large updates to the elf2e32 replacement, fixing handling of some more uncommon combinations. Initial replacements for the elftran, gendirective, genstubs and getexports tools (needed for building armv5 binaries).
Version 1.13 (March 31, 2009) - Updated the S60 5.0 SDK scripts and patches to the 1.0 version of the SDK, recently released, some minor fixes.
Version 1.12 (January 22, 2009) - Fixed compilation with gcc 4.3, integrated a fix for ar in both EKA1 and EKA2 gcc (needed on e.g. Ubuntu 8.10), fixed building DLLs on the S60 3.2 SDK (thanks to Jean-Yves Baudy for pointing this out), assorted fixes for S60 5.0, fix building of the EKA1 gcc on x86_64/linux, initial support for compiling context-sensitive help (requires wine), other misc fixes
Version 1.11 (October 3, 2008) - Initial support for S60 5.0
Version 1.10 (September 4, 2008) - compilation fixes for g++ 4.3 (thanks to Mrinal Kalakrishnan and Jakob Kemi for sending patches!), some minor new features implemented in signsis
Version 1.09 (March 31, 2008) - adds support for S60 3.2, and has some minor bugfixes and new features for the included tools
Version 1.08 (February 27, 2008) - fixes a lot of issues on OS X Leopard. Seems to work fine on most Leopard machines, if you experience problems please let me know.
Version 1.07 (December 04, 2007) - fixes a regression in compiling the EKA1 gcc
Version 1.06 (November 26, 2007) - fixed a bug in elf2e32 which prevented it from working on S60 3.1, fixed some compilation problems on FreeBSD, added an initial patch for the S60 3.2 SDK beta (but no installer script yet, since I haven't found a tool able to unpack the installer). Thanks to all who reported problems and helped solve them!
Version 1.05 (September 14, 2007) - a bugfix for signsis, deflate compression support for petran and elf2e32, build elf2e32 by default, an initial version of a svgt-binary encoder
Version 1.04 (September 2, 2007) - fixes for rcomp, petran and makesis for running on 64-bit linux, small bugfixes in mifconv and elf2e32, better error reporting in the new rcomp, completely new makesis for Symbian 9 SIS files, use unshield instead of i6comp.exe for extracting S60 SDKs
Version 1.03 (August 13, 2007) - support for UIQ 3.0 and 3.1, added most tools except gcc into the package, support for symbian 9 resources in rcomp, elf2e32 replacement, mifconv replacement, support for building the old GCC toolchain on OSX/intel
Version 1.02 (April 7, 2007) - calls external makefiles using wine, some more assorted bugfixes
Version 1.01 (March 5, 2007) - clarified the license, added instructions on doing a read-only installation of the SDKs, some other slight bugfixes
Version 1.0 (October 15, 2006) - initial release
Download the latest package above. First you'll have to install a toolchain for the SDK you want to use. For S60 1st and 2nd ed, you need the EKA1 toolchain, for S60 3rd ed and UIQ 3, you need the EKA2 toolchain.
Installing the EKA1 toolchain
Refer to the tools/README file for more details on this process.
In addition to the GnuPoc archive, you need the source to the modified gcc release (local copy).
Unpack the GnuPoc archive, enter the tools directory, and compile gcc using the install_gcc_539 script:
tar -zxvf gnupoc-package-1.03.tar.gz
cd gnupoc-package-1.03
cd tools
./install_gcc_539 ../../gcc-539-2aeh-source.tar.bz2 ~/symbian-gcc
If you want to have a compiler for the THUMB target, build that with the isntall_gcc_539_thumb script similarly.
Then you can install the rest of the tools. These aren't strictly necessary if wine is available, but recommended. (If omitted, the build scripts uses the exe versions in the SDK instead.)
./install_eka1_tools ~/symbian-gcc
Installing the EKA2 toolchain
Refer to the tools/README file for more details on this process.
In addition to the GnuPoc archive, you need CodeSourcery's GCC. For Linux, you can choose to download the binaries, for other platforms you can compile it from source. (There's also local copies of the Linux binaries and the source.)
To install the binaries, just unpack them (in your home directory):
mkdir csl-gcc
cd csl-gcc
tar -jxvf ../gnu-csl-arm-2005Q1C-arm-none-symbianelf-i686-pc-linux-gnu.tar.bz2
To compile it from source instead, unpack the GnuPoc archive and use the install_csl_gcc script:
tar -zxvf gnupoc-package-1.03.tar.gz
cd gnupoc-package-1.03
cd tools
./install_csl_gcc ../../gnu-csl-arm-2005Q1C-arm-none-symbianelf.src.tar.bz2 ~/csl-gcc
Then you can install the rest of the tools. These aren't strictly necessary if wine is available. (If omitted, the build scripts uses the exe versions in the SDK instead.)
cd gnupoc-package-1.03
cd tools
./install_eka2_tools ~/csl-gcc
Note, this requires openssl libraries to be installed.
SDKs
Refer to the sdks/README file for more details on this process.
After downloading the GnuPoc package above, you still need to get the SDK you want to use from Forum Nokia. (The UIQ SDKs were available from http://developer.uiq.com earlier, but are no longer available.) The following versions are supported at the moment:
Version File name Install script Comments
S60 1st Edition, FP1, WINS nS60_sdk_v1_2.zip install_gnupoc_s60_12
S60 2nd Edition, WINS s60_sdk_v2_0.zip install_gnupoc_s60_20 Working emulator
S60 2nd Edition, FP1, WINS S60_SDK_2_1_NET.zip install_gnupoc_s60_21
S60 2nd Edition, FP1, CW S60_SDK_v21c_CW.zip install_gnupoc_s60_21_cw Working emulator
S60 2nd Edition, FP2, WINS s60_2nd_fp2_sdk_msb.zip install_gnupoc_s60_26 Working emulator
S60 2nd Edition, FP2, CW s60_2nd_fp2_sdk.zip install_gnupoc_s60_26_cw Working emulator
S60 2nd Edition, FP3 s60_2nd_sdk_fp3.zip install_gnupoc_s60_28
S60 3rd Edition, Maintenance Release S60-SDK-0616-3.0-mr.3.749.zip install_gnupoc_s60_30
S60 3rd Edition, FP 1 S60-SDK-200634-3.1-Cpp-f.1090b.zip install_gnupoc_s60_31
S60 3rd Edition, FP 2 S60-3.2-SDK-f.inc3.2130.zip install_gnupoc_s60_32
S60 5th Edition S60_5th_Edition_SDK_v1_0_en.zip install_gnupoc_s60_50
N97 SDK Nokia_N97_SDK_v1_0_en.zip install_gnupoc_s60_50
Symbian^3 Symbian_3_SDK_v0_9_en.zip install_gnupoc_symbian3
UIQ 3.0 UIQ3.0SDK.exe install_gnupoc_uiq_30
UIQ 3.1 UIQ3.1SDK.exe install_gnupoc_uiq_31
(Everything is tested using Wine 0.9.15 and remote X to X11.app on OS X, things might work better or worse on other setups.)
The installation script uses included prebuild binaries of p7zip and a specially patched version of unshield for linux/x86. If you can't run these, see sdks/unshield/README and sdks/7z/README for instructions on compiling native versions of them.
Example on installing an SDK:
tar -zxvf gnupoc-package-1.03.tar.gz
cd gnupoc-package-1.03
cd sdks
./install_gnupoc_s60_26 ../../s60_2nd_fp2_sdk_msb.zip ~/symbian-sdks/s60_26
The install scripts makes almost all files lowercase and patches the build scripts. The exception to the lowercase rule is the GLES include directory and libGLES_CM.lib, for compatibility reasons.
In order to use the SDK, you'll have to set the EPOCROOT environment variable to point to your SDK and add the toolchain directory and the epoc32/tools directory of the SDK to your PATH. This might be cumbersome if frequently switching between different SDKs. To ease that situation, you can install some wrapper scripts:
./install_wrapper ~/gnupoc
If you've installed the toolchains to other directories than mentioned here, edit ~/gnupoc/gnupoc-common.sh and set EKA1TOOLS and EKA2TOOLS to point to where you've installed them. With these wrappers, you only have to have this single directory in your PATH, and depending on the EPOCROOT variable, the correct toolchain is included and scripts from the current SDK are called.
Wine setup
If you're going to use some tools through wine, you have to copy uidcrc.exe from the epoc32/tools directory in the SDK to a directory in the wine path, e.g. ~/.wine/drive_c/windows. By default, wine is only needed for using the windows compilers, but you might use it to run the original tools instead of the native replacements, if you have problems with the native ones.
If using external makefiles (as for building icons in 3rd edition) with wine, copy make.exe and mifconv.exe, too. make.exe probably can be used from any SDK version, but you'll need mifconv.exe from the 3.0 SDK, since mifconv.exe in 3.1 has some problems starting within wine. Note, this is only needed if omitting the extra EKA2 tools above.
In order to build binaries for the emulator, you'll need a windows compiler. Unfortunately, these have to be copied from a real installation. (Perhaps it's possible to do the complete installation of them within wine?)
For the WINS compiler, I've used Visual C++ Toolkit 2003, set up according to this page. Just copy over the C:\Program Files\Microsoft Visual C++ Toolkit 2003 directory to e.g. ~/.wine/drive_c/msvcpp2003.
For the WINSCW compiler, you can install Carbide C++ from Forum Nokia. These instructions apply to Carbide C++ 1.0, for newer versions you might need to use slightly different paths. Copy C:\Program Files\Carbide\plugins\com.nokia.carbide.cpp.support_1.0.0 to e.g. ~/.wine/drive_c/codewarrior.
These have to be added to the wine path. Edit ~/.wine/user.reg, and add this after the WINE REGISTRY Version 2 line:
[Environment]
"Path"="c:\\msvcpp2003\\bin;c:\\codewarrior\\Symbian_Tools\\Command_Line_Tools;c:\\windows;c:\\windows\\system"
(Of course, if you've already got a similar environment definition in that file, add it there instead.)
When using the CW compiler, you'll also need to add these variables to your unix environment (the perl build scripts need them, adding them to the wine environment isn't enough, and if set in the unix environment, they're also automatically available in wine):
export MWCSym2Includes="c:\\codewarrior\\symbian_support\\MSL\\MSL_C\\MSL_Common\\include;c:\\codewarrior\\symbian_support\\MSL\\MSL_C++\\MSL_Common\\include;c:\\codewarrior\\symbian_support\\MSL\\MSL_Extras\\MSL_Common\\include"
export MWSym2Libraries="+c:\\codewarrior\\symbian_support"
export MWSym2LibraryFiles="MSL_All_MSE_Symbian.lib;gdi32.lib;user32.lib;kernel32.lib"
Using it
After installing everything, you're able to compile things in the same way as on windows.
In order to compile most projects, the usage of upper/lowercase for filenames must be cleaned up somewhat. The install scripts clean up the usage of lower/upper case in the bundled examples (by forcing them to lowercase), so the should all be buildable directly. (Or at least it tries to, it might not work reliably in stranger examples.)
To build the hello world example on a S60 3rd edition SDK, do the following:
export PATH=~/gnupoc:${PATH}
export EPOCROOT=~/symbian-sdks/s60_30/
cd ${EPOCROOT}/s60ex/helloworldbasic/group
bldmake bldfiles
abld build gcce urel
cd ../sis
makesis helloworldbasic_gcce.pkg helloworldbasic.sis
For 1st and 2nd edition, use the paths for those SDKs and build using abld build armi urel instead. The .pkg files for those examples are written for the THUMB target. Either update the .pkg file and replace all occurrances of thumb with armi or build them using abld build thumb urel (which requires that you built a thumb compiler).
On 3rd edition, all sis files must be signed before they can be installed. If you haven't already got a key and certificate pair, generate them:
makekeys -cert -expdays 3650 -password mykey.key mycert.cer
This will prompt for information to enter into the certificate, and create a certificate valid for 10 years. (To create a certificate without a password, just leave out -password. The makekeys tool included in this package has a similar but not identical syntax compared to the makekeys tool in the real SDKs.) Then sign the sis file using this certificate:
signsis helloworldbasic.sis helloworldbasic.sisx mycert.cer mykey.key
The newly generated .sisx file can then be installed on a device.
The version of makesis for Symbian 9 included in this package is also able to sign the package directly when creating it, using a built-in certificate. To use this feature, just add the command line parameter -c.
Contact
// Martin Storsjö
Mobile Phone Platform Researcher
Veja o perfil deste profissional
Mobile Phone Platform Researcher
Job Description:
The mobile phone platform researcher will perform as a hands-on specialist in the identification, discovery, evaluation and in-depth analysis of security issues of the various mobile phone software platforms.
Primary Responsibilities:
Research and Analysis of mobile phone software.
Minimum Requirement:
Good knowledge of the Apple iOS, Windows Mobile, Symbian and/or Blackberry internals.
Experienced in developing and reverse engineering embedded applications for mobile devices.
Good understanding of Wireless Data Link Layer, including WLAN, Wi-Fi and WiMAX.
Good understanding of mobile network protocols, including GSM, 2.5G and 3G.
Mobile Phone Platform Researcher
Job Description:
The mobile phone platform researcher will perform as a hands-on specialist in the identification, discovery, evaluation and in-depth analysis of security issues of the various mobile phone software platforms.
Primary Responsibilities:
Research and Analysis of mobile phone software.
Minimum Requirement:
Good knowledge of the Apple iOS, Windows Mobile, Symbian and/or Blackberry internals.
Experienced in developing and reverse engineering embedded applications for mobile devices.
Good understanding of Wireless Data Link Layer, including WLAN, Wi-Fi and WiMAX.
Good understanding of mobile network protocols, including GSM, 2.5G and 3G.
Análise de Malware em Mobile
Particulamente, sempre gostei de mobile, mas por um tempo dei um tempo neste segmento. Agora como hobby estou voltando a estudar sobre isso. No passo em 2004/2005 desevolvia para Palm (hoje comprado pela HP).
Tenho um mobile symbian, smartphone Nokia e63, qual vou fazer uns testes e postar aqui no blog.
Por enquanto estou instalando a plataforma e tambem vou postar o HowTo aqui.
Tenho um mobile symbian, smartphone Nokia e63, qual vou fazer uns testes e postar aqui no blog.
Por enquanto estou instalando a plataforma e tambem vou postar o HowTo aqui.
Vim Commands Cheat Sheet
VI/VIM
http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html
http://www.fprintf.net/vimCheatSheet.html
http://media.smashingmagazine.com/cdn_smash/wp-content/uploads/2010/05/VI-Help-Sheet-011.pdf
http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html
http://www.fprintf.net/vimCheatSheet.html
http://media.smashingmagazine.com/cdn_smash/wp-content/uploads/2010/05/VI-Help-Sheet-011.pdf
quarta-feira, 27 de abril de 2011
Análise Forense: TCHunt como Aplicação de Código Aberto para Detectar Volumes Criptografados TrueCrypt
Sendo do conhecimento de algumas pessoas, o TrueCrypt é um software open-source de criptografia de disco para Windows 7/Vista/XP, Mac OS X e Linux. Ele faz isso criando um disco virtual criptografado dentro de um arquivo, e monta-o como um disco real. A razão da abordagem em torno do TrueCrypt é por causa de TCHunt - uma aplicação de código aberto para detectar a maioria de volumes criptografados TrueCrypt.
TrueCrypt é muito estável e faz seu trabalho como ele mesmo se propõe: ele é utilizado por quase todos os que querem impedir o acesso não autorizado aos seus dados. Além disso, permite que você use keyfiles voltados para stop keyloggers basics, suporta desmontagem automática após timeouts, etc... No entanto, isso também traz os "bad guys" que se escondem por trás do software legítimo, para se proteger. Ele torna realmente difícil quando uma investigação forense está sendo feita em um drive criptografado TC; este é o lugar onde TCHunt vem a calhar.
TCHunt lhe permite procurar arquivos com os seguintes atributos:
- O modulo de tamanho de arquivo suspeito 512 deve ser igual a zero.
- O tamanho do arquivo suspeito é de pelo menos 19 KB de tamanho (embora na prática isso seja definido como 5 MB).
- O conteúdo do arquivo suspeito passa por um teste de distribuição chi-square.
- O arquivo suspeito não deve conter um cabeçalho de arquivo comum.
Saiba Mais:
[1] http://www.pentestit.com/category/forensics/
TrueCrypt é muito estável e faz seu trabalho como ele mesmo se propõe: ele é utilizado por quase todos os que querem impedir o acesso não autorizado aos seus dados. Além disso, permite que você use keyfiles voltados para stop keyloggers basics, suporta desmontagem automática após timeouts, etc... No entanto, isso também traz os "bad guys" que se escondem por trás do software legítimo, para se proteger. Ele torna realmente difícil quando uma investigação forense está sendo feita em um drive criptografado TC; este é o lugar onde TCHunt vem a calhar.
TCHunt lhe permite procurar arquivos com os seguintes atributos:
- O modulo de tamanho de arquivo suspeito 512 deve ser igual a zero.
- O tamanho do arquivo suspeito é de pelo menos 19 KB de tamanho (embora na prática isso seja definido como 5 MB).
- O conteúdo do arquivo suspeito passa por um teste de distribuição chi-square.
- O arquivo suspeito não deve conter um cabeçalho de arquivo comum.
Saiba Mais:
[1] http://www.pentestit.com/category/forensics/
View and Change bash history
Always wanted to know what you have been doing via bash? Did you know bash keeps a history of that? Here is a quick way to check it and an easy way to change the history limit.
First open up a terminal by going to Applications > Accessories > Terminal (in Ubuntu) or press Alt + F2 and type in terminal. Now that you have a terminal open, let’s get down to viewing your history.
To view your history via the terminal, type:
history
This will show the whole list.
To view your history in a editor (to save for later), just type:
history -w ~/history.txt
gedit ~/history.txt
What history -w ~/history.txt does is save the history to a file named history.txt on your home folder (cd ~/). The next command opens up the file for viewing in gedit.
Note: For more information about history be sure to use the man pages by doing:
man history
Now to change your bash history length, just open up your .bashrc by doing so:
gedit ~/.bashrc
Once open, at the top add.
export HISTFILESIZE=3000
As you can see, the limit can be changed.
Bash keeps it’s own history in a file. You can view that file as stated before, or by opening ~/.bash_history
First open up a terminal by going to Applications > Accessories > Terminal (in Ubuntu) or press Alt + F2 and type in terminal. Now that you have a terminal open, let’s get down to viewing your history.
To view your history via the terminal, type:
history
This will show the whole list.
To view your history in a editor (to save for later), just type:
history -w ~/history.txt
gedit ~/history.txt
What history -w ~/history.txt does is save the history to a file named history.txt on your home folder (cd ~/). The next command opens up the file for viewing in gedit.
Note: For more information about history be sure to use the man pages by doing:
man history
Now to change your bash history length, just open up your .bashrc by doing so:
gedit ~/.bashrc
Once open, at the top add.
export HISTFILESIZE=3000
As you can see, the limit can be changed.
Bash keeps it’s own history in a file. You can view that file as stated before, or by opening ~/.bash_history
Hardening bash_history
[==============================================================================]
[---------------------------[ Hacking Bash History ]---------------------------]
[==============================================================================]
-------------[ Table of Contents ]-------------
i. Preface
ii. Hardening bash_history
iii. Attacking the logging mechanism
iv. Hacking bash - interfacing with syslog
v. Conclusion
vi. References
[ i. Preface ]
==============
Bash is probably the most widely used shell in the *nix world and one of it's
features is the history mechanism. The history mechanism is mainly used for the
user's convenience - less typing -> work done faster. However, it has been
discussed that bash_history can also be used as a logging mechanism to monitor
users' activity. This article covers the arguments against the above and why the
mechanism is useless against someone who thinks out of the box. We are going
to see that every defensive measure taken for protecting the history file can
be subverted with little or no difficulty. The discussion will be increasive
in the strictness of the methods applied but that doesn't meant they will be
increasingly difficult to implement. Most of them are no-brainers. In the end,
we are going to meddle with the bash source code to make the logging mechanism
(at first sight) "invincible" and we are going to see why even that can fail.
[ ii. Hardening bash_history ]
==============================
Suppose you are an administrator of a shell-providing box and there is a really
pesky user whose activities you would like to monitor, since you are really
suspicious about what he does late at night with the precious CPU power and
system resources that you have pledged to protect against malicious (or other)
usage. Let's call the user Bob - enough of using Trinity as the "bad" one all
the time. Since all users use bash as their default shell in the server, you
start making a few changes to the bash configuration files.
// Step 1 //
-- Make the bash history and relevant files undeletable/unchangeable.
The first thing Bob would probably do would be to symlink his history to
/dev/null.
bob$ rm ~/.bash_history
bob$ ln -s /dev/null ~/.bash_history
That can be prevented by making that file append-only. This can be accomplished
by issuing the following command:
# chattr +a /home/bob/.bash_history
This will use file system extended attributes to mark the file as append only.
Most filesystems (ext2/3, XFS, JFS) support this. On FreeBSD the same
would be done by issuing:
# sappnd /home/bob/.bash_history
You might also want to apply this to all the bash configuration files that
are read during bash startup:
# chattr +a /home/bob/.bash_profile
# chattr +a /home/bob/.bash_login
# chattr +a /home/bob/.profile
# chattr +a /home/bob/.bash_logout
# chattr +a /home/bob/.bashrc
The first three are read by bash in that order (after reading /etc/profile
which applies to all users) when an interactive login bash shell (or a
non-interactive shell with the --login option) is invoked.
.bashrc is only read when a non-login interactive shell is invoked. That means
the case when the user has already logged in and invokes a new bash shell by
himself like:
bob$ bash
Note that .bashrc is the *only* configuration file that is read in this case.
The other 3 conf files are *not* read again.
After doing the above changes, it's time to move on to some more "hardening".
One more step towards (futile) protection.
// Step 2 //
-- Configure .bash* configuration files
All changes will be made to .bashrc. It is assumed the other three
configuration files mention reading .bashrc in their body. This means that
.bashrc is read in *every* case (whether the user just logins or invokes a new
bash shell after he has logged in).
By making all changes to .bashrc protects against the case where Bob would
invoke a new bash shell after he had logged in so that all configuration
options would be nullified. If the options were only at the three main
configuration files (.bash_profile, .bash_login, .profile) then the above would
happen. On the other hand, these files must read .bashrc in their body so that
the options mentioned to .bashrc are actually applied in the first login shell
as well.
# cat >> /home/bob/.bashrc << EOF > shopt -s histappend
> readonly PROMPT_COMMAND="history -a"
> EOF
The option histappend orders bash to append the last $HISTSIZE lines to the
$HISTFILE file (normally ~/.bash_history) whenever an interactive shell exits.
By default, bash overwrites $HISTFILE each time so that only one session is
kept to save space.
The enviromental variable PROMPT_COMMAND holds a command that is to be executed
prior to issuing each prompt. This means that "history -a" is executed prior
to every command the user issues. This ensures that whatever command was typed
just before the current one, is immediately appended to $HISTFILE. This ensures
more robustness in the logging mechanism, as bash doesn't wait until the whole
session is finished to transfer to the disk the history lines from the memory.
The readonly attribute is used so that this variable is marked as non-writeable
in case Bob wants to ovewrite it and most probably nullify it.
One last substep to the above changes would be to mark as readonly all the
environment variables associated with bash_history:
readonly HISTFILE
readonly HISTFILESIZE
readonly HISTSIZE
readonly HISTCMD
readonly HISTCONTROL
readonly HISTIGNORE
// Step 3 //
- Disable all access to all other out of the box shells of the system. Usually,
these will be csh, tcsh and maybe ksh.
# chmod 750 csh
# chmod 750 tcsh
# chmod 750 ksh
This will prevent Bob from changing his shell from bash to another one.
Now, the astute administrator will complain that the above are *not*
the only shells out of the box! This is both true and false. But before you jump
to quantum theory conclusions based on the above statement, let's clear some
things up.
A long time ago ...(you know the rest), there was only the Bourne shell or sh.
Nowadays, /bin/sh is actually a symbolic link to /bin/bash. Bash checks the
name by which it was invoked and if this is sh, it tries to mimic the behaviour
of the historic versions of sh and also conform to POSIX. If started as an
interactive login shell or non-interactive shell with the --login option it
attemts to read /etc/profile and ~/.profile for startup configuration. If it is
invoked as an interactive shell, then it tries to expand the variable $ENV and
if it is not empty, uses its value as the configuration file to read and
execute. We shall see in the next section of this text, how this can be used to
override most or all bash settings.
[ iii. Attacking the logging mechanism ]
========================================
It is time to see the whole thing from Bob's perspective. We are going to
examine how each of the above steps can be subverted. In practice, the
possibilities are endless. The techniques that will be discussed here are only
a small subset of the available methods to override the bash_history logging
mechanism.
// Method 1 //
-- Use the Bourne shell /bin/sh as an escape mechanism
$ /bin/sh
Invoking sh will result in bash mimicing the historic version of sh and as
mentioned above will not read any configuration files directly related to bash.
Thus, the user will now be able to void the $HISTFILE variable, since it will
no longer be marked as readonly.
$ unset HISTFILE
This will make the logging mechanism inactive for the current session, as the
variable controlling the file where the commands are logged, will be empty.
Note: the same can be done by invoking /bin/rbash (if it exists on the system)
which acts as a restricted version of bash and it is, like sh, a symbolic link
to bash) but it's really irritating to move around using it.
// Method 2 //
-- Order bash to not read the .bashrc configuration file
This can be done by invoking bash like this:
$ /bin/bash --norc
This will inhibit bash from reading .bashrc and thus the variables marked as
readonly will be writeable. Then you can type something like:
$ HISTFILE=
which will clear the $HISTFILE variable -> no history
[ iv. Hacking bash - interfacing with syslog ]
==============================================
We can clearly deduce from the above that any conventional means to secure
the bash_history is actually futile. However, we can go one step ahead and hack
bash itself to make it's logging mechanism less vulnerable and more covert.
Note that even this can be subverted. Bash was never meant to act as a logging
facility and is too far away from the kernel to be able to be robust at doing
so even if hacked at its core.
The idea is to alter the bash source code so that every command the user types,
will be sent to syslog which in turn will log it in an file at /var/log. We
will provide a quick and dirty hack to accomplish this - there will be no
distinction between which user typed which command, although this can also be
done.
The best place to put our interface is the parse.y file which consists of the
yacc grammar for bash. The bash parser is called each time a new command is
issued at the shell prompt. Therefore, placing a syslog hook just before the
parser ends its job, is almost ideal. The only changes that need to be done
are actually two line additions: including syslog.h and making syslog(3) call.
The alterations were made to bash-3.2 source code:
---------------------------------------------------------------------------
[ithilgore@fitz]$diff -E -b -c ~/bash-3.2/parse.y ~/hacked_bash/parse.y
*** ../../bash-3.2/bash-3.2/parse.y Tue Sep 19 13:37:21 2006
--- parse.y Sat Jul 12 18:32:26 2008
***************
*** 19,24 ****
--- 19,25 ----
Foundation, 59 Temple Place, Suite 330, Boston, MA 02111 USA. */
%{
+ #include
#include "config.h"
#include "bashtypes.h"
***************
*** 1979,1984 ****
--- 1980,1986 ----
shell_input_line_len = i; /* == strlen (shell_input_line) */
set_line_mbstate ();
+ syslog(LOG_LOCAL0 | LOG_CRIT, "%s", shell_input_line);
#if defined (HISTORY)
if (remember_on_history && shell_input_line && shell_input_line[0])
---------------------------------------------------------------------------
The above call generates a log message that will be distributed by syslogd
with a priority of LOG_CRIT to the facility specified as local0. For this
to work, /etc/syslog.conf *must* include a line like the following:
local0.crit /var/log/hist.log
Every command issued by a user using the bash shell will now end up in the
/var/log/hist.log file which will normally be readable only by root.
Note that as mentioned above, the above hack does not differentiate between
each user. More work needs to be done for that. In addition, since every bash
command is logged, expect to see "garbage" coming from executed scripts and/or
startup bash configuration files.
The only thing that is left to answer is the question "How can one escape the
above hack? " It is fairly simple:
----> Compile/transfer and use your own *clean* version of bash (or any other
shell).
Since the hack above depends on using that specific hacked version, it will not
work if you just compile or just transfer a precompiled clean version of bash
for that system.
[ v. Conclusion ]
=================
Bash is a shell, not a logging mechanism and bash_history was only meant to
provide the user with the convenience of less retyping. Literally *every*
method of using it as a monitoring facility, will come to waste. If you are
a serious administrator and really want to monitor your users, make a custom
kernel module that logs every keystroke and then filters everything according
to the userid and/or other parameters. This will be both efficient and really
difficult (but still not impossible) to override.
Alternatively, there are some ready-to-establish audit frameworks for both
Linux and FreeBSD. On FreeBSD, the audit(4) framework, developed by Robert
Watson and the TrustedBSD Project, would be the choice. More info at
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html . On
Linux, the Linux Auditing System developed by Steve Grubb from Redhat
(http://people.redhat.com/sgrubb/audit/) would be the way to go.
[ vi. References ]
==================
a. bash & syslog man pages
b. bash-3.2 source code -http://ftp.gnu.org/gnu/bash/bash-3.2.tar.gz
[---------------------------[ Hacking Bash History ]---------------------------]
[==============================================================================]
-------------[ Table of Contents ]-------------
i. Preface
ii. Hardening bash_history
iii. Attacking the logging mechanism
iv. Hacking bash - interfacing with syslog
v. Conclusion
vi. References
[ i. Preface ]
==============
Bash is probably the most widely used shell in the *nix world and one of it's
features is the history mechanism. The history mechanism is mainly used for the
user's convenience - less typing -> work done faster. However, it has been
discussed that bash_history can also be used as a logging mechanism to monitor
users' activity. This article covers the arguments against the above and why the
mechanism is useless against someone who thinks out of the box. We are going
to see that every defensive measure taken for protecting the history file can
be subverted with little or no difficulty. The discussion will be increasive
in the strictness of the methods applied but that doesn't meant they will be
increasingly difficult to implement. Most of them are no-brainers. In the end,
we are going to meddle with the bash source code to make the logging mechanism
(at first sight) "invincible" and we are going to see why even that can fail.
[ ii. Hardening bash_history ]
==============================
Suppose you are an administrator of a shell-providing box and there is a really
pesky user whose activities you would like to monitor, since you are really
suspicious about what he does late at night with the precious CPU power and
system resources that you have pledged to protect against malicious (or other)
usage. Let's call the user Bob - enough of using Trinity as the "bad" one all
the time. Since all users use bash as their default shell in the server, you
start making a few changes to the bash configuration files.
// Step 1 //
-- Make the bash history and relevant files undeletable/unchangeable.
The first thing Bob would probably do would be to symlink his history to
/dev/null.
bob$ rm ~/.bash_history
bob$ ln -s /dev/null ~/.bash_history
That can be prevented by making that file append-only. This can be accomplished
by issuing the following command:
# chattr +a /home/bob/.bash_history
This will use file system extended attributes to mark the file as append only.
Most filesystems (ext2/3, XFS, JFS) support this. On FreeBSD the same
would be done by issuing:
# sappnd /home/bob/.bash_history
You might also want to apply this to all the bash configuration files that
are read during bash startup:
# chattr +a /home/bob/.bash_profile
# chattr +a /home/bob/.bash_login
# chattr +a /home/bob/.profile
# chattr +a /home/bob/.bash_logout
# chattr +a /home/bob/.bashrc
The first three are read by bash in that order (after reading /etc/profile
which applies to all users) when an interactive login bash shell (or a
non-interactive shell with the --login option) is invoked.
.bashrc is only read when a non-login interactive shell is invoked. That means
the case when the user has already logged in and invokes a new bash shell by
himself like:
bob$ bash
Note that .bashrc is the *only* configuration file that is read in this case.
The other 3 conf files are *not* read again.
After doing the above changes, it's time to move on to some more "hardening".
One more step towards (futile) protection.
// Step 2 //
-- Configure .bash* configuration files
All changes will be made to .bashrc. It is assumed the other three
configuration files mention reading .bashrc in their body. This means that
.bashrc is read in *every* case (whether the user just logins or invokes a new
bash shell after he has logged in).
By making all changes to .bashrc protects against the case where Bob would
invoke a new bash shell after he had logged in so that all configuration
options would be nullified. If the options were only at the three main
configuration files (.bash_profile, .bash_login, .profile) then the above would
happen. On the other hand, these files must read .bashrc in their body so that
the options mentioned to .bashrc are actually applied in the first login shell
as well.
# cat >> /home/bob/.bashrc << EOF > shopt -s histappend
> readonly PROMPT_COMMAND="history -a"
> EOF
The option histappend orders bash to append the last $HISTSIZE lines to the
$HISTFILE file (normally ~/.bash_history) whenever an interactive shell exits.
By default, bash overwrites $HISTFILE each time so that only one session is
kept to save space.
The enviromental variable PROMPT_COMMAND holds a command that is to be executed
prior to issuing each prompt. This means that "history -a" is executed prior
to every command the user issues. This ensures that whatever command was typed
just before the current one, is immediately appended to $HISTFILE. This ensures
more robustness in the logging mechanism, as bash doesn't wait until the whole
session is finished to transfer to the disk the history lines from the memory.
The readonly attribute is used so that this variable is marked as non-writeable
in case Bob wants to ovewrite it and most probably nullify it.
One last substep to the above changes would be to mark as readonly all the
environment variables associated with bash_history:
readonly HISTFILE
readonly HISTFILESIZE
readonly HISTSIZE
readonly HISTCMD
readonly HISTCONTROL
readonly HISTIGNORE
// Step 3 //
- Disable all access to all other out of the box shells of the system. Usually,
these will be csh, tcsh and maybe ksh.
# chmod 750 csh
# chmod 750 tcsh
# chmod 750 ksh
This will prevent Bob from changing his shell from bash to another one.
Now, the astute administrator will complain that the above are *not*
the only shells out of the box! This is both true and false. But before you jump
to quantum theory conclusions based on the above statement, let's clear some
things up.
A long time ago ...(you know the rest), there was only the Bourne shell or sh.
Nowadays, /bin/sh is actually a symbolic link to /bin/bash. Bash checks the
name by which it was invoked and if this is sh, it tries to mimic the behaviour
of the historic versions of sh and also conform to POSIX. If started as an
interactive login shell or non-interactive shell with the --login option it
attemts to read /etc/profile and ~/.profile for startup configuration. If it is
invoked as an interactive shell, then it tries to expand the variable $ENV and
if it is not empty, uses its value as the configuration file to read and
execute. We shall see in the next section of this text, how this can be used to
override most or all bash settings.
[ iii. Attacking the logging mechanism ]
========================================
It is time to see the whole thing from Bob's perspective. We are going to
examine how each of the above steps can be subverted. In practice, the
possibilities are endless. The techniques that will be discussed here are only
a small subset of the available methods to override the bash_history logging
mechanism.
// Method 1 //
-- Use the Bourne shell /bin/sh as an escape mechanism
$ /bin/sh
Invoking sh will result in bash mimicing the historic version of sh and as
mentioned above will not read any configuration files directly related to bash.
Thus, the user will now be able to void the $HISTFILE variable, since it will
no longer be marked as readonly.
$ unset HISTFILE
This will make the logging mechanism inactive for the current session, as the
variable controlling the file where the commands are logged, will be empty.
Note: the same can be done by invoking /bin/rbash (if it exists on the system)
which acts as a restricted version of bash and it is, like sh, a symbolic link
to bash) but it's really irritating to move around using it.
// Method 2 //
-- Order bash to not read the .bashrc configuration file
This can be done by invoking bash like this:
$ /bin/bash --norc
This will inhibit bash from reading .bashrc and thus the variables marked as
readonly will be writeable. Then you can type something like:
$ HISTFILE=
which will clear the $HISTFILE variable -> no history
[ iv. Hacking bash - interfacing with syslog ]
==============================================
We can clearly deduce from the above that any conventional means to secure
the bash_history is actually futile. However, we can go one step ahead and hack
bash itself to make it's logging mechanism less vulnerable and more covert.
Note that even this can be subverted. Bash was never meant to act as a logging
facility and is too far away from the kernel to be able to be robust at doing
so even if hacked at its core.
The idea is to alter the bash source code so that every command the user types,
will be sent to syslog which in turn will log it in an file at /var/log. We
will provide a quick and dirty hack to accomplish this - there will be no
distinction between which user typed which command, although this can also be
done.
The best place to put our interface is the parse.y file which consists of the
yacc grammar for bash. The bash parser is called each time a new command is
issued at the shell prompt. Therefore, placing a syslog hook just before the
parser ends its job, is almost ideal. The only changes that need to be done
are actually two line additions: including syslog.h and making syslog(3) call.
The alterations were made to bash-3.2 source code:
---------------------------------------------------------------------------
[ithilgore@fitz]$diff -E -b -c ~/bash-3.2/parse.y ~/hacked_bash/parse.y
*** ../../bash-3.2/bash-3.2/parse.y Tue Sep 19 13:37:21 2006
--- parse.y Sat Jul 12 18:32:26 2008
***************
*** 19,24 ****
--- 19,25 ----
Foundation, 59 Temple Place, Suite 330, Boston, MA 02111 USA. */
%{
+ #include
#include "config.h"
#include "bashtypes.h"
***************
*** 1979,1984 ****
--- 1980,1986 ----
shell_input_line_len = i; /* == strlen (shell_input_line) */
set_line_mbstate ();
+ syslog(LOG_LOCAL0 | LOG_CRIT, "%s", shell_input_line);
#if defined (HISTORY)
if (remember_on_history && shell_input_line && shell_input_line[0])
---------------------------------------------------------------------------
The above call generates a log message that will be distributed by syslogd
with a priority of LOG_CRIT to the facility specified as local0. For this
to work, /etc/syslog.conf *must* include a line like the following:
local0.crit /var/log/hist.log
Every command issued by a user using the bash shell will now end up in the
/var/log/hist.log file which will normally be readable only by root.
Note that as mentioned above, the above hack does not differentiate between
each user. More work needs to be done for that. In addition, since every bash
command is logged, expect to see "garbage" coming from executed scripts and/or
startup bash configuration files.
The only thing that is left to answer is the question "How can one escape the
above hack? " It is fairly simple:
----> Compile/transfer and use your own *clean* version of bash (or any other
shell).
Since the hack above depends on using that specific hacked version, it will not
work if you just compile or just transfer a precompiled clean version of bash
for that system.
[ v. Conclusion ]
=================
Bash is a shell, not a logging mechanism and bash_history was only meant to
provide the user with the convenience of less retyping. Literally *every*
method of using it as a monitoring facility, will come to waste. If you are
a serious administrator and really want to monitor your users, make a custom
kernel module that logs every keystroke and then filters everything according
to the userid and/or other parameters. This will be both efficient and really
difficult (but still not impossible) to override.
Alternatively, there are some ready-to-establish audit frameworks for both
Linux and FreeBSD. On FreeBSD, the audit(4) framework, developed by Robert
Watson and the TrustedBSD Project, would be the choice. More info at
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/audit.html . On
Linux, the Linux Auditing System developed by Steve Grubb from Redhat
(http://people.redhat.com/sgrubb/audit/) would be the way to go.
[ vi. References ]
==================
a. bash & syslog man pages
b. bash-3.2 source code -http://ftp.gnu.org/gnu/bash/bash-3.2.tar.gz
Five Tips for Working with GNU Bash History on Linux
They say that those who don't know history are doomed to repeat it — but if you don't know how to use your history in Bash, you're just not making the most of your system. But this is simple to overcome with five tips on working with history on GNU Bash.
If you spend any time at all at the shell, you've probably noticed that Bash keeps a "history" of the commands you've run — much like Web browsers keep a history of pages you've visited. Of course, the history feature in Bash (and other shells) predates browser history.
Most users are aware that they can access the history by using the history command, or just scroll through the history using the arrow keys or Ctrl-p (previous) or Ctrl-n (next). That, in and of itself, is really useful. But you're not making full use of the Bash history. Let's look at a few less-used tricks for making use (or not) of Bash's history command and features.
By the Numbers
When you run history you see a list of the commands that have been run (as long as they've been logged — more on that in a second) and a number to the left of the command.
You can re-run a command by using !n where n is the number of a command. So !50 will run the 50th command in the history. Or you can run a command by using !-n where that's the current command minus n. More clearly — !-3 will run the third-last command in your history. If the output of history looks like this:
1 sudo su
2 exit
3 sudo apt-get update
Then running !-3 would run sudo su.
A Little Twist
How many times have you run a command and then realized, I meant to use sudo in front of that!? I do it all the time. One way to recover would be simply to scroll back in your history (up arrow, or Ctrl-p and then hit Ctrl-a to move to the front of the line and then type sudo. Another, even easier, way, is to do this:
sudo !!
That will run the last command (!!) with sudo. Nice, eh?
You probably already know that !command will run the most recent command that begins with "command. So if you've recently run a really long command string, all you really need to do in order to repeat it is to run !command.
But did you know that Bash wasn't looking for a command, it's looking for a string? That means it's looking for a match to the characters, not a match to the full command. Let's say your last command using git was something like this:
git commit -a -m "Various and sundry notes"
Most users will type !git to run the command — but all you really need to type is !gi or even !g if no other commands are going to match the leading string.
Now, what if you've run a lot of commands but wanted to match based on the second string in the command — the command that you used with git instead? Then you could use !?command? and the history built-in would match "command" in the string.
More Recycling
Another tiny tip, use Esc-. (that's Escape and period) to get the last word (string) to a command. Hit it once and you'll get the word for the last command. Hit it again, and you'll get the last word for the command before that. For example, if you run cp filename1 filename2 hitting Esc-. will add filename2 at the cursor. Try it and see how it works — it's very useful.
But what if you want, say, the third word? Or all of the words? For example, if you've run this:
ls file1.txt file2.txt file3.txt file4.txt
You might want to quickly just get the middle two filenames. You can do that by running:
ls !:2-3
If you want all the arguments/words passed to a command without the command itself, run:
ls !:*
Search
Another useful, perhaps most useful, trick is to use Ctrl-r to search through the history for a command that matches a search string.
For instance, run Ctrl-r and type "hi" — it will bring up the first command with "hi" in the string (such as history). Hit Ctrl-r again, and it will bring up the second most recent command, and so on. When you find the command you want, then just hit Enter and it will run again.
If you want to modify the command, hit the right or left arrow and then Bash will leave you at the prompt with the command to edit it before running the command.
Privacy and Security
The Bash history is really useful, but there may be times when you don't want to save commands to your history. For instance, if you're using a shared machine you may not want your command history to be visible to the system's administrators — who could just log in as root and read your ~/.bash_history. If it's not a shared machine, there's always a chance the system could be compromised — so if you're doing anything you want to keep really private, then you might want to exercise some controls. Finally, you might just want to keep from logging certain commands because it's just not useful to have them clogging up your history. You might use ls all the time, but why retain something like that when it's more useful to keep longer commands that are a pain to type?
Let's take a look at ways to keep commands from being saved in history, whatever the reason.
One way to do this is to set HISTCONTROL=ignorespace:ignoredups in your .bashrc. The ignoredups does what it sounds like — it won't log duplicates to your history, so if you run ls twice in a row, or something like that, it won't be saved more than once.
The ignorespace works like this: Type a space before a command, and it won't be logged to your history. So if you want to run a super-secret command, start it off with a space.
Some distros add this by default, but you can add it yourself by adding the line above to your .bashrc.
You could also use the HISTIGNORE environment variable to tell Bash to ignore certain commands or parameters. Let's say you don't want to log any commands that have the name of a private server. You can set HISTIGNORE="*myserver*" and then use the name with impunity.
Well, sort-of impunity. The usual caveats apply &mdas; if you're on a shared server, there may be ways for other users to see what's in memory or use ps aux or something to see what commands are being run. So, these measures are useful — but may not be 100% bulletproof. Don't do really sensitive work on machines that you don't trust, mmkay?
I hope that this has provided a few tips that you will find useful. But it's not everything you can do — be sure to check out the man page for history to learn more.
If you spend any time at all at the shell, you've probably noticed that Bash keeps a "history" of the commands you've run — much like Web browsers keep a history of pages you've visited. Of course, the history feature in Bash (and other shells) predates browser history.
Most users are aware that they can access the history by using the history command, or just scroll through the history using the arrow keys or Ctrl-p (previous) or Ctrl-n (next). That, in and of itself, is really useful. But you're not making full use of the Bash history. Let's look at a few less-used tricks for making use (or not) of Bash's history command and features.
By the Numbers
When you run history you see a list of the commands that have been run (as long as they've been logged — more on that in a second) and a number to the left of the command.
You can re-run a command by using !n where n is the number of a command. So !50 will run the 50th command in the history. Or you can run a command by using !-n where that's the current command minus n. More clearly — !-3 will run the third-last command in your history. If the output of history looks like this:
1 sudo su
2 exit
3 sudo apt-get update
Then running !-3 would run sudo su.
A Little Twist
How many times have you run a command and then realized, I meant to use sudo in front of that!? I do it all the time. One way to recover would be simply to scroll back in your history (up arrow, or Ctrl-p and then hit Ctrl-a to move to the front of the line and then type sudo. Another, even easier, way, is to do this:
sudo !!
That will run the last command (!!) with sudo. Nice, eh?
You probably already know that !command will run the most recent command that begins with "command. So if you've recently run a really long command string, all you really need to do in order to repeat it is to run !command.
But did you know that Bash wasn't looking for a command, it's looking for a string? That means it's looking for a match to the characters, not a match to the full command. Let's say your last command using git was something like this:
git commit -a -m "Various and sundry notes"
Most users will type !git to run the command — but all you really need to type is !gi or even !g if no other commands are going to match the leading string.
Now, what if you've run a lot of commands but wanted to match based on the second string in the command — the command that you used with git instead? Then you could use !?command? and the history built-in would match "command" in the string.
More Recycling
Another tiny tip, use Esc-. (that's Escape and period) to get the last word (string) to a command. Hit it once and you'll get the word for the last command. Hit it again, and you'll get the last word for the command before that. For example, if you run cp filename1 filename2 hitting Esc-. will add filename2 at the cursor. Try it and see how it works — it's very useful.
But what if you want, say, the third word? Or all of the words? For example, if you've run this:
ls file1.txt file2.txt file3.txt file4.txt
You might want to quickly just get the middle two filenames. You can do that by running:
ls !:2-3
If you want all the arguments/words passed to a command without the command itself, run:
ls !:*
Search
Another useful, perhaps most useful, trick is to use Ctrl-r to search through the history for a command that matches a search string.
For instance, run Ctrl-r and type "hi" — it will bring up the first command with "hi" in the string (such as history). Hit Ctrl-r again, and it will bring up the second most recent command, and so on. When you find the command you want, then just hit Enter and it will run again.
If you want to modify the command, hit the right or left arrow and then Bash will leave you at the prompt with the command to edit it before running the command.
Privacy and Security
The Bash history is really useful, but there may be times when you don't want to save commands to your history. For instance, if you're using a shared machine you may not want your command history to be visible to the system's administrators — who could just log in as root and read your ~/.bash_history. If it's not a shared machine, there's always a chance the system could be compromised — so if you're doing anything you want to keep really private, then you might want to exercise some controls. Finally, you might just want to keep from logging certain commands because it's just not useful to have them clogging up your history. You might use ls all the time, but why retain something like that when it's more useful to keep longer commands that are a pain to type?
Let's take a look at ways to keep commands from being saved in history, whatever the reason.
One way to do this is to set HISTCONTROL=ignorespace:ignoredups in your .bashrc. The ignoredups does what it sounds like — it won't log duplicates to your history, so if you run ls twice in a row, or something like that, it won't be saved more than once.
The ignorespace works like this: Type a space before a command, and it won't be logged to your history. So if you want to run a super-secret command, start it off with a space.
Some distros add this by default, but you can add it yourself by adding the line above to your .bashrc.
You could also use the HISTIGNORE environment variable to tell Bash to ignore certain commands or parameters. Let's say you don't want to log any commands that have the name of a private server. You can set HISTIGNORE="*myserver*" and then use the name with impunity.
Well, sort-of impunity. The usual caveats apply &mdas; if you're on a shared server, there may be ways for other users to see what's in memory or use ps aux or something to see what commands are being run. So, these measures are useful — but may not be 100% bulletproof. Don't do really sensitive work on machines that you don't trust, mmkay?
I hope that this has provided a few tips that you will find useful. But it's not everything you can do — be sure to check out the man page for history to learn more.
The Definitive Guide to Bash Command Line History
bash readline emacs editing mode default keyboard shortcut cheat sheet
Let me teach you how to work efficiently with command line history in bash.
This tutorial comes with a downloadable cheat sheet that summarizes (and expands on) topics covered here (scroll to the end for a download link).
In case you are a first time reader, this is the 3rd part of the article series on working efficiently in bourne again shell. Previously I have written on how to work efficiently in vi and emacs command editing modes by using predefined keyboard shortcuts (both articles come with cheat sheets of predefined shortcuts).
First, lets review some basic keyboard shortcuts for navigating around previously typed commands.
As you remember, bash offers two modes for command editing - emacs mode and vi mode. In each of these editing modes the shortcuts for retrieving history are different.
Suppose you had executed the following commands:
$ echo foo bar baz
$ iptables -L -n -v -t nat
$ ... lots and lots more commands
$ echo foo foo foo
$ perl -wle 'print q/hello world/'
$ awk -F: '{print$1}' /etc/passwd
$
and you wanted to execute the last command (awk -F ...).
You could certainly hit the up arrow and live happily along, but do you really want to move your hand that far away?
If you are in emacs mode just try CTRL-p which fetches the previous command from history list (CTRL-n for the next command).
In vi mode try CTRL-[ (or ESC) (to switch to command mode) and 'h' ('j' for the next command).
There is another, equally quick, way to do that by using bash's history expansion mechanism - event designators. Typing '!!' will execute the previous command (more about event designators later).
Now, suppose that you wanted to execute 'iptables -L -n -v -t nat' command again without retyping it.
A naive user would, again, just keep hitting up-arrow key until he/she finds the command. But that's not the way hackers work. Hackers love to work quickly and efficiently. Forget about arrow keys and page-up, page-down, home and end keys. They are completely useless and, as I said, they are too far off from the main part of the keyboard anyway.
In emacs mode try CTRL-r and type a few first letters of 'iptables', like 'ipt'. That will display the last iptables command you executed. In case you had more than one iptables commands executed in between, hitting CTRL-r again will display older entries. In case you miss the right command and move too deep into history list, you can reverse the search direction by hitting CTRL-s (don't forget that by default CTRL-s stops the output to the terminal and you'll get an effect of "frozen" terminal (hit CTRL-q to "unfreeze"), see stty command to change this behavior).
In vi mode the same CTRL-r and CTRL-s still work but there is another way more specific to vi mode.
Switch to command mode by hitting CTRL-[ or ESC and hit '/', then type a first few characters of 'iptables' command, like 'ipt' and hit return. Bash will display the most recent match found in history. To navigate around use 'n' or just plain '/' to repeat the search in the same direction, and 'N' or '?' to repeat the search in opposite direction!
With event designators you may execute only the most recently executed command matching (or starting with) 'string'.
Try '!iptables' history expansion command which refers to the most recent command starting with 'iptables'.
Another way is to use bash's built in 'history' command then grep for a string of interest and finally use an event designator in form '!N', where N is an integer which refers to N-th command in command history list.
For example,
$ history | grep 'ipt'
2 iptables -L -n -v -t nat
$ !2 # will execute the iptables command
I remembered another way to execute N-th command in history list in vi editing mode. Type 'N' (command number) and then 'G', in this example '2G'
Listing and Erasing Command History
Bash provides a built-in command 'history' for viewing and erasing command history.
Suppose that we are still working with the same example:
$ echo foo bar baz
$ iptables -L -n -v -t nat
$ ... lots and lots more commands
$ echo foo foo foo
$ perl -wle 'print q/hello world/'
$ awk -F: '{print$1}' /etc/passwd
$
Typing 'history' will display all the commands in bash history alongside with line numbers:
1 echo foo bar baz
2 iptables -L -n -v -t nat
... lots and lots more commands
568 echo foo foo foo
569 perl -wle 'print q/hello world/'
570 awk -F: '{print$1}' /etc/passwd
Typing 'history N', where N is an integer, will display the last N commands in the history.
For example, 'history 3' will display:
568 echo foo foo foo
569 perl -wle 'print q/hello world/'
570 awk -F: '{print$1}' /etc/passwd
history -c will clear the history list and history -d N will delete a history entry N.
By default, the history list is kept in user's home directory in a file '.bash_history'.
History Expansion
History expansion is done via so-called event designators and word designators. Event designators can be used to recall previously executed commands (events) and word designators can be used to extract command line arguments from the events. Optionally, various modifiers can be applied to the extracted arguments.
Event designators are special commands that begin with a '!' (there is also one that begins with a '^'), they may follow a word designator and one or more modifiers. Event designators, word designators and modifiers are separated by a colon ':'.
Event Designators
Lets look at a couple of examples to see how the event designators work.
Event designator '!!' can be used to refer to the previous command, for example,
$ echo foo bar baz
foo bar baz
$ !!
foo bar baz
Here the '!!' executed the previous 'echo foo bar baz' command.
Event designator '!N' can be used to refer to the N-th command.
Suppose you listed the history and got the following output:
1 echo foo foo foo
2 iptables -L -n -v -t nat
... lots and lots more commands
568 echo bar bar bar
569 perl -wle 'print q/hello world/'
570 awk -F: '{print$1}' /etc/passwd
Then the event designator '!569' will execute 'perl ...' command, and '!1' will execute 'echo foo foo foo' command!
Event designator '!-N' refers to current command line minus N. For example,
$ echo foo bar baz
foo bar baz
$ echo a b c d e
a b c d e
$ !-2
foo bar baz
Here the event designator '!-2' executed a one before the previous command, or current command line minus 2.
Event designator '!string' refers to the most recent command starting with 'string'. For example,
$ awk --help
$ perl --help
Then the event designator '!p' or '!perl' or '!per' will execute the 'perl --help' command. Similarly, '!a' will execute the awk command.
An event designator '!?string?' refers to a command line containing (not necessarily starting with) 'string'.
Perhaps the most interesting event designator is the one in form '^string1^string2^' which takes the last command, replaces string1 with string2 and executes it. For example,
$ ehco foo bar baz
bash: ehco: command not found
$ ^ehco^echo^
foo bar baz
Here the '^ehco^echo^' designator replaced the incorrectly typed 'ehco' command with the correct 'echo' command and executed it.
Word Designators and Modifiers
Word designators follow event designators separated by a colon. They are used to refer to some or all of the parameters on the command referenced by event designator.
For example,
$ echo a b c d e
a b c d e
$ echo !!:2
b
This is the simplest form of a word designator. ':2' refers to the 2nd argument of the command (3rd word). In general ':N' refers to Nth argument of the command ((N+1)-th word).
Word designators also accept ranges, for example,
$ echo a b c d e
a b c d e
$ echo !!:3-4
c d
There are various shortcuts, such as, ':$' to refer to the last argument, ':^' to refer to the first argument, ':*' to refer to all the arguments (synonym to ':1-$'), and others. See the cheat sheet for a complete list.
Modifiers can be used to modify the behavior of a word designators. For example:
$ tar -xvzf software-1.0.tgz
software-1.0/file
...
$ cd !!:$:r
software-1.0$
Here the 'r' modifier was applied to a word designator which picked the last argument from the previous command line. The 'r' modifier removed the trailing suffix '.tgz'.
The 'h' modifier removes the trailing pathname component, leaving the head:
$ echo /usr/local/apache
/usr/local/apache
$ echo !!:$:h
/usr/local
The 'e' modifier removes all but the trailing suffix:
$ ls -la /usr/src/software-4.2.messy-Extension
...
$ echo /usr/src/*!!:$:e
/usr/src/*.messy-Extension # ls could have been used instead of echo
Another interesting modifier is the substitute ':s/old/new/' modifier which substitutes new for old. It can be used in conjunction with 'g' modifier to do global substitution. For example,
$ ls /urs/local/software-4.2 /urs/local/software-4.3
/usr/bin/ls: /urs/local/software-4.2: No such file or directory
/usr/bin/ls: /urs/local/software-4.3: No such file or directory
$ !!:gs/urs/usr/
...
This example replaces all occurances of 'urs' to 'usr' and makes the command correct.
There are a few other modifiers, such as 'p' modifier which prints the resulting command after history expansion but does not execute it. See the cheat sheet for all of the modifiers.
Modifying History Behavior
Bash allows you to modify which commands get stored in the history list, the file where they get stored, the number of commands that get stored, and a few other options.
These options are controlled by setting HISTFILE, HISTFILESIZE, HISTIGNORE and HISTSIZE environment variables.
HISTFILE, as the name suggests, controls where the history file gets saved.
For example,
$ export HISTFILE=/home/pkrumins/todays_history
will save the commands to a file /home/pkrumins/todays_history
Set it to /dev/null or unset it to avoid getting your history list saved.
HISTFILESIZE controls how many history commands to keep in HISTFILE.
For example,
$ export HISTFILESIZE=1000
will keep the last 1000 history commands.
HISTSIZE controls how many history commands to keep in the history list of current session.
For example,
$ export HISTSIZE=42
will keep 42 last commands in the history of current session.
If this number is less than HISTFILESIZE, only that many commands will get written to HISTFILE.
HISTIGNORE controls the items which get ignored and do not get saved. This variable takes a list of colon separated patterns. Pattern '&' (ampersand) is special in a sense that it matches the previous history command.
There is a trick to make history ignore the commands which begin with a space. The pattern for that is "[ ]*"
For example,
$ export HISTIGNORE="&:[ ]*:exit"
will make bash ignore duplicate commands, commands that begin with a space, and the 'exit' command.
There are several other options of interest controlled by the built-in 'shopt' command.
The options may be set by specifying '-s' parameter to the 'shopt' command, and may be unset by specifying '-u' parameter.
Option 'histappend' controls how the history list gets written to HISTFILE, setting the option will append history list of current session to HISTFILE, unsetting it (default) will make HISTFILE get overwritten each time.
For example, to set this option, type:
$ shopt -s histappend
And to unset it, type:
$ shopt -u histappend
Option 'histreedit' allows users to re-edit a failed history substitution.
For example, suppose you had typed:
$ echo foo bar baz
and wanted to substitute 'baz' for 'test' with the ^baz^test^ event designator , but you made a mistake and typed ^boo^test^. This would lead to a substitution failure because the previous command does not contain string 'boo'.
If you had this option turned on, bash would put the erroneous ^baz^test^ event designator back on the command line as if you had typed it again.
Finally, option 'histverify' allows users to verify a substituted history expansion.
Based on the previous example, suppose you wanted to execute that 'echo' command again by using the '!!' event designator. If you had this option on, bash would not execute the 'echo' command immediately but would first put it on command line so that you could see if it had made the correct substitution.
Tuning the Command Prompt
Here is how my command prompt looks:
Wed Jan 30@07:07:03
pkrumins@catonmat:1002:2:~$
The first line displays the date and time the command prompt was displayed so I could keep track of commands back in time.
The second line displays username, hostname, global history number and current command number.
The global history number allows me to quickly use event designators.
My PS1, primary prompt display variable looks like this:
PS1='\d@\t\n\u@\h:\!:\#:\w$ '
Bash History Cheat Sheet
Here is a summary cheat sheet for working effectively with bash history.
This cheat sheet includes:
History editing keyboard shortcuts (emacs and vi mode),
History expansion summary - event designators, word designators and modifiers,
Shell variables and `shopt' options to modify history behavior,
Examples
Let me teach you how to work efficiently with command line history in bash.
This tutorial comes with a downloadable cheat sheet that summarizes (and expands on) topics covered here (scroll to the end for a download link).
In case you are a first time reader, this is the 3rd part of the article series on working efficiently in bourne again shell. Previously I have written on how to work efficiently in vi and emacs command editing modes by using predefined keyboard shortcuts (both articles come with cheat sheets of predefined shortcuts).
First, lets review some basic keyboard shortcuts for navigating around previously typed commands.
As you remember, bash offers two modes for command editing - emacs mode and vi mode. In each of these editing modes the shortcuts for retrieving history are different.
Suppose you had executed the following commands:
$ echo foo bar baz
$ iptables -L -n -v -t nat
$ ... lots and lots more commands
$ echo foo foo foo
$ perl -wle 'print q/hello world/'
$ awk -F: '{print$1}' /etc/passwd
$
and you wanted to execute the last command (awk -F ...).
You could certainly hit the up arrow and live happily along, but do you really want to move your hand that far away?
If you are in emacs mode just try CTRL-p which fetches the previous command from history list (CTRL-n for the next command).
In vi mode try CTRL-[ (or ESC) (to switch to command mode) and 'h' ('j' for the next command).
There is another, equally quick, way to do that by using bash's history expansion mechanism - event designators. Typing '!!' will execute the previous command (more about event designators later).
Now, suppose that you wanted to execute 'iptables -L -n -v -t nat' command again without retyping it.
A naive user would, again, just keep hitting up-arrow key until he/she finds the command. But that's not the way hackers work. Hackers love to work quickly and efficiently. Forget about arrow keys and page-up, page-down, home and end keys. They are completely useless and, as I said, they are too far off from the main part of the keyboard anyway.
In emacs mode try CTRL-r and type a few first letters of 'iptables', like 'ipt'. That will display the last iptables command you executed. In case you had more than one iptables commands executed in between, hitting CTRL-r again will display older entries. In case you miss the right command and move too deep into history list, you can reverse the search direction by hitting CTRL-s (don't forget that by default CTRL-s stops the output to the terminal and you'll get an effect of "frozen" terminal (hit CTRL-q to "unfreeze"), see stty command to change this behavior).
In vi mode the same CTRL-r and CTRL-s still work but there is another way more specific to vi mode.
Switch to command mode by hitting CTRL-[ or ESC and hit '/', then type a first few characters of 'iptables' command, like 'ipt' and hit return. Bash will display the most recent match found in history. To navigate around use 'n' or just plain '/' to repeat the search in the same direction, and 'N' or '?' to repeat the search in opposite direction!
With event designators you may execute only the most recently executed command matching (or starting with) 'string'.
Try '!iptables' history expansion command which refers to the most recent command starting with 'iptables'.
Another way is to use bash's built in 'history' command then grep for a string of interest and finally use an event designator in form '!N', where N is an integer which refers to N-th command in command history list.
For example,
$ history | grep 'ipt'
2 iptables -L -n -v -t nat
$ !2 # will execute the iptables command
I remembered another way to execute N-th command in history list in vi editing mode. Type 'N' (command number) and then 'G', in this example '2G'
Listing and Erasing Command History
Bash provides a built-in command 'history' for viewing and erasing command history.
Suppose that we are still working with the same example:
$ echo foo bar baz
$ iptables -L -n -v -t nat
$ ... lots and lots more commands
$ echo foo foo foo
$ perl -wle 'print q/hello world/'
$ awk -F: '{print$1}' /etc/passwd
$
Typing 'history' will display all the commands in bash history alongside with line numbers:
1 echo foo bar baz
2 iptables -L -n -v -t nat
... lots and lots more commands
568 echo foo foo foo
569 perl -wle 'print q/hello world/'
570 awk -F: '{print$1}' /etc/passwd
Typing 'history N', where N is an integer, will display the last N commands in the history.
For example, 'history 3' will display:
568 echo foo foo foo
569 perl -wle 'print q/hello world/'
570 awk -F: '{print$1}' /etc/passwd
history -c will clear the history list and history -d N will delete a history entry N.
By default, the history list is kept in user's home directory in a file '.bash_history'.
History Expansion
History expansion is done via so-called event designators and word designators. Event designators can be used to recall previously executed commands (events) and word designators can be used to extract command line arguments from the events. Optionally, various modifiers can be applied to the extracted arguments.
Event designators are special commands that begin with a '!' (there is also one that begins with a '^'), they may follow a word designator and one or more modifiers. Event designators, word designators and modifiers are separated by a colon ':'.
Event Designators
Lets look at a couple of examples to see how the event designators work.
Event designator '!!' can be used to refer to the previous command, for example,
$ echo foo bar baz
foo bar baz
$ !!
foo bar baz
Here the '!!' executed the previous 'echo foo bar baz' command.
Event designator '!N' can be used to refer to the N-th command.
Suppose you listed the history and got the following output:
1 echo foo foo foo
2 iptables -L -n -v -t nat
... lots and lots more commands
568 echo bar bar bar
569 perl -wle 'print q/hello world/'
570 awk -F: '{print$1}' /etc/passwd
Then the event designator '!569' will execute 'perl ...' command, and '!1' will execute 'echo foo foo foo' command!
Event designator '!-N' refers to current command line minus N. For example,
$ echo foo bar baz
foo bar baz
$ echo a b c d e
a b c d e
$ !-2
foo bar baz
Here the event designator '!-2' executed a one before the previous command, or current command line minus 2.
Event designator '!string' refers to the most recent command starting with 'string'. For example,
$ awk --help
$ perl --help
Then the event designator '!p' or '!perl' or '!per' will execute the 'perl --help' command. Similarly, '!a' will execute the awk command.
An event designator '!?string?' refers to a command line containing (not necessarily starting with) 'string'.
Perhaps the most interesting event designator is the one in form '^string1^string2^' which takes the last command, replaces string1 with string2 and executes it. For example,
$ ehco foo bar baz
bash: ehco: command not found
$ ^ehco^echo^
foo bar baz
Here the '^ehco^echo^' designator replaced the incorrectly typed 'ehco' command with the correct 'echo' command and executed it.
Word Designators and Modifiers
Word designators follow event designators separated by a colon. They are used to refer to some or all of the parameters on the command referenced by event designator.
For example,
$ echo a b c d e
a b c d e
$ echo !!:2
b
This is the simplest form of a word designator. ':2' refers to the 2nd argument of the command (3rd word). In general ':N' refers to Nth argument of the command ((N+1)-th word).
Word designators also accept ranges, for example,
$ echo a b c d e
a b c d e
$ echo !!:3-4
c d
There are various shortcuts, such as, ':$' to refer to the last argument, ':^' to refer to the first argument, ':*' to refer to all the arguments (synonym to ':1-$'), and others. See the cheat sheet for a complete list.
Modifiers can be used to modify the behavior of a word designators. For example:
$ tar -xvzf software-1.0.tgz
software-1.0/file
...
$ cd !!:$:r
software-1.0$
Here the 'r' modifier was applied to a word designator which picked the last argument from the previous command line. The 'r' modifier removed the trailing suffix '.tgz'.
The 'h' modifier removes the trailing pathname component, leaving the head:
$ echo /usr/local/apache
/usr/local/apache
$ echo !!:$:h
/usr/local
The 'e' modifier removes all but the trailing suffix:
$ ls -la /usr/src/software-4.2.messy-Extension
...
$ echo /usr/src/*!!:$:e
/usr/src/*.messy-Extension # ls could have been used instead of echo
Another interesting modifier is the substitute ':s/old/new/' modifier which substitutes new for old. It can be used in conjunction with 'g' modifier to do global substitution. For example,
$ ls /urs/local/software-4.2 /urs/local/software-4.3
/usr/bin/ls: /urs/local/software-4.2: No such file or directory
/usr/bin/ls: /urs/local/software-4.3: No such file or directory
$ !!:gs/urs/usr/
...
This example replaces all occurances of 'urs' to 'usr' and makes the command correct.
There are a few other modifiers, such as 'p' modifier which prints the resulting command after history expansion but does not execute it. See the cheat sheet for all of the modifiers.
Modifying History Behavior
Bash allows you to modify which commands get stored in the history list, the file where they get stored, the number of commands that get stored, and a few other options.
These options are controlled by setting HISTFILE, HISTFILESIZE, HISTIGNORE and HISTSIZE environment variables.
HISTFILE, as the name suggests, controls where the history file gets saved.
For example,
$ export HISTFILE=/home/pkrumins/todays_history
will save the commands to a file /home/pkrumins/todays_history
Set it to /dev/null or unset it to avoid getting your history list saved.
HISTFILESIZE controls how many history commands to keep in HISTFILE.
For example,
$ export HISTFILESIZE=1000
will keep the last 1000 history commands.
HISTSIZE controls how many history commands to keep in the history list of current session.
For example,
$ export HISTSIZE=42
will keep 42 last commands in the history of current session.
If this number is less than HISTFILESIZE, only that many commands will get written to HISTFILE.
HISTIGNORE controls the items which get ignored and do not get saved. This variable takes a list of colon separated patterns. Pattern '&' (ampersand) is special in a sense that it matches the previous history command.
There is a trick to make history ignore the commands which begin with a space. The pattern for that is "[ ]*"
For example,
$ export HISTIGNORE="&:[ ]*:exit"
will make bash ignore duplicate commands, commands that begin with a space, and the 'exit' command.
There are several other options of interest controlled by the built-in 'shopt' command.
The options may be set by specifying '-s' parameter to the 'shopt' command, and may be unset by specifying '-u' parameter.
Option 'histappend' controls how the history list gets written to HISTFILE, setting the option will append history list of current session to HISTFILE, unsetting it (default) will make HISTFILE get overwritten each time.
For example, to set this option, type:
$ shopt -s histappend
And to unset it, type:
$ shopt -u histappend
Option 'histreedit' allows users to re-edit a failed history substitution.
For example, suppose you had typed:
$ echo foo bar baz
and wanted to substitute 'baz' for 'test' with the ^baz^test^ event designator , but you made a mistake and typed ^boo^test^. This would lead to a substitution failure because the previous command does not contain string 'boo'.
If you had this option turned on, bash would put the erroneous ^baz^test^ event designator back on the command line as if you had typed it again.
Finally, option 'histverify' allows users to verify a substituted history expansion.
Based on the previous example, suppose you wanted to execute that 'echo' command again by using the '!!' event designator. If you had this option on, bash would not execute the 'echo' command immediately but would first put it on command line so that you could see if it had made the correct substitution.
Tuning the Command Prompt
Here is how my command prompt looks:
Wed Jan 30@07:07:03
pkrumins@catonmat:1002:2:~$
The first line displays the date and time the command prompt was displayed so I could keep track of commands back in time.
The second line displays username, hostname, global history number and current command number.
The global history number allows me to quickly use event designators.
My PS1, primary prompt display variable looks like this:
PS1='\d@\t\n\u@\h:\!:\#:\w$ '
Bash History Cheat Sheet
Here is a summary cheat sheet for working effectively with bash history.
This cheat sheet includes:
History editing keyboard shortcuts (emacs and vi mode),
History expansion summary - event designators, word designators and modifiers,
Shell variables and `shopt' options to modify history behavior,
Examples
Bash History: Display Date And Time For Each Command
Bash History: Display Date And Time For Each Command
How do I display shell command history with date and time under UNIX or Linux operating systems?
If the HISTTIMEFORMAT is set, the time stamp information associated with each history entry is written to the history file, marked with the history comment character. Defining the environment variable as follows:
$ HISTTIMEFORMAT="%d/%m/%y %T "
OR
$ echo 'export HISTTIMEFORMAT="%d/%m/%y %T "' >> ~/.bash_profile
Where,
%d - Day
%m - Month
%y - Year
%T - Time
To see history type
$ history
Sample outputs:
....
..
986 11/03/10 04:31:36 memcached-tool 10.10.28.22:11211 stats
987 11/03/10 04:31:36 w
988 11/03/10 04:31:37 iostat
989 11/03/10 04:31:37 top
990 11/03/10 04:31:37 at
991 11/03/10 04:31:38 atop
992 11/03/10 04:31:40 collectl
993 11/03/10 04:31:41 grep CPU /proc/cpuinfo
994 11/03/10 04:31:45 vmstat 3 100
995 11/03/10 04:31:55 sar -W -f /var/log/sa/sa12
....
..
References:
For more info type the following commands:
man bash
help history
man 3 strftime
How do I display shell command history with date and time under UNIX or Linux operating systems?
If the HISTTIMEFORMAT is set, the time stamp information associated with each history entry is written to the history file, marked with the history comment character. Defining the environment variable as follows:
$ HISTTIMEFORMAT="%d/%m/%y %T "
OR
$ echo 'export HISTTIMEFORMAT="%d/%m/%y %T "' >> ~/.bash_profile
Where,
%d - Day
%m - Month
%y - Year
%T - Time
To see history type
$ history
Sample outputs:
....
..
986 11/03/10 04:31:36 memcached-tool 10.10.28.22:11211 stats
987 11/03/10 04:31:36 w
988 11/03/10 04:31:37 iostat
989 11/03/10 04:31:37 top
990 11/03/10 04:31:37 at
991 11/03/10 04:31:38 atop
992 11/03/10 04:31:40 collectl
993 11/03/10 04:31:41 grep CPU /proc/cpuinfo
994 11/03/10 04:31:45 vmstat 3 100
995 11/03/10 04:31:55 sar -W -f /var/log/sa/sa12
....
..
References:
For more info type the following commands:
man bash
help history
man 3 strftime
Código decompilado do Stuxnet que está disponível
código decompilado do Stuxnet que está disponível para download no seguinte site: https://github.com/Laurelai/decompile-dump
OBS: Este blog apenas cita como forma de uso e aprendizado acadêmico, não de forma ilegal.
OBS: Este blog apenas cita como forma de uso e aprendizado acadêmico, não de forma ilegal.
terça-feira, 26 de abril de 2011
Scanner de Hardening - HardeningOne
HardeningOne is a fork lynis. Hardening is an auditing tool for Unix (specialists). It scans the system and available software, to detect security issues. His have 280 new features.
HardeningOne é um fork do lynis. HardeningOne é uma ferramenta de auditoria para Unix (especialistas). Ele examina o software do sistema e outros, para detectar problemas de segurança. Neste fork tem +280 novas funcionalidades.
Este projeto foi desenvolvido e adaptado por Mauro Risonho de Paula Assumpção a.k.a firebits
link: http://sourceforge.net/projects/hardeningone/
segunda-feira, 25 de abril de 2011
Detect if you are Running a Virtual Machine (para Pentest ou Análise de Malware)
Would you like to know if your server’s OS is running on bare-metal or on a virtual machine. imvirt and virt-what are 2 Linux scripts that allow you to do so easily. Both are open source and can be downloaded from their websites and Ubuntu’s Synaptic Package Manager as well.
virt-what
virt-what is a shell script maintained by Red Hat that does the same thing. It prints more details about the VM than imvirt if a VM was found. Otherwise it exits with code 0 (no error) and does not print anything.
To download it visit virt-what
http://people.redhat.com/~rjones/virt-what/
imvirt
imvirt was developed in Perl by Thomas Liske. It does its job by looking for wellknown boot messages, directories and reading DMI (Desktop Management Interface) data. It prints one line. These are the tool’s outputs and what they mean:
HVM: - signature of an unknown hypervisor
VirtualBox - VirtualBox
Virtual Machine - Microsoft Virtual PC/Virtual Server
VMware - VMware Virtual Platform
VMware (Express|ESX Server|GSX Server|Workstation) - VMware Virtual Platform
OpenVZ - OpenVZ/Virtuosso
Physical - This is a physical machine or a not detected container.
QEMU - QEMU/KVM (based)
UML - User Mode Linux
Xen - Xen hypervisor
Xen 3.x (PV|HVM) - Xen hypervisor
To download it visit imvirt’s SourceForge page.
http://sourceforge.net/projects/imvirt/
virt-what
virt-what is a shell script maintained by Red Hat that does the same thing. It prints more details about the VM than imvirt if a VM was found. Otherwise it exits with code 0 (no error) and does not print anything.
To download it visit virt-what
http://people.redhat.com/~rjones/virt-what/
imvirt
imvirt was developed in Perl by Thomas Liske. It does its job by looking for wellknown boot messages, directories and reading DMI (Desktop Management Interface) data. It prints one line. These are the tool’s outputs and what they mean:
HVM: - signature of an unknown hypervisor
VirtualBox - VirtualBox
Virtual Machine - Microsoft Virtual PC/Virtual Server
VMware - VMware Virtual Platform
VMware (Express|ESX Server|GSX Server|Workstation) - VMware Virtual Platform
OpenVZ - OpenVZ/Virtuosso
Physical - This is a physical machine or a not detected container.
QEMU - QEMU/KVM (based)
UML - User Mode Linux
Xen - Xen hypervisor
Xen 3.x (PV|HVM) - Xen hypervisor
To download it visit imvirt’s SourceForge page.
http://sourceforge.net/projects/imvirt/
quarta-feira, 20 de abril de 2011
Software Assurance Maturity Model
Download: http://www.opensamm.org/downloads/SAMM-1.0.pdf
The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. The resources provided by SAMM will aid in:
◊ Evaluating an organization’s existing
software security practices
◊ Building a balanced software security program
in well-defined iterations
◊ Demonstrating concrete improvements
to a security assurance program
◊ Defining and measuring security-related activities
within an organization
SAMM was defined with flexibility in mind such that it can be utilized by small, medium, and large organizations using any style of development. Additionally, this model can be applied organization-wide, for a single line-of-business, or even for an individual project.
As an open project, SAMM content shall always remain vendor-neutral and freely available for all to use.
Apesar de ser feito com ajuda e idéias do OWASP, pode-se com um pouco de adaptação utilizar em ambientes não-web.
@firebitsbr
The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. The resources provided by SAMM will aid in:
◊ Evaluating an organization’s existing
software security practices
◊ Building a balanced software security program
in well-defined iterations
◊ Demonstrating concrete improvements
to a security assurance program
◊ Defining and measuring security-related activities
within an organization
SAMM was defined with flexibility in mind such that it can be utilized by small, medium, and large organizations using any style of development. Additionally, this model can be applied organization-wide, for a single line-of-business, or even for an individual project.
As an open project, SAMM content shall always remain vendor-neutral and freely available for all to use.
Apesar de ser feito com ajuda e idéias do OWASP, pode-se com um pouco de adaptação utilizar em ambientes não-web.
@firebitsbr
Reverse Engineering Malware on Linux with IDA Pro
The brief method. If I get good response to this post, I will put up a more detailed and in-depth look at malware reversing on Linux.
Steps:
* Download IDA Pro (freeware)
* Install wine
* Install IDA Pro
* Start reversing
Download IDA Pro (freeware):
$ cd /tmp
$ wget http://85.17.201.4/files/idafree49.exe
Install wine:
$ sudo aptitude install wine
Install IDA Pro:
$ wine /tmp/idafree49.exe
Start reversing:
$ wine "~/.wine/drive_c/Program Files/IDA Free/idag.exe"
-> Now open the malware binary and select the option for ELF executables
This post is a stub for a future longer version if anyone shows interest. I don't even know how many Linux Journal readers actually reverse malware on Linux...
Steps:
* Download IDA Pro (freeware)
* Install wine
* Install IDA Pro
* Start reversing
Download IDA Pro (freeware):
$ cd /tmp
$ wget http://85.17.201.4/files/idafree49.exe
Install wine:
$ sudo aptitude install wine
Install IDA Pro:
$ wine /tmp/idafree49.exe
Start reversing:
$ wine "~/.wine/drive_c/Program Files/IDA Free/idag.exe"
-> Now open the malware binary and select the option for ELF executables
This post is a stub for a future longer version if anyone shows interest. I don't even know how many Linux Journal readers actually reverse malware on Linux...
Malware Analysis Tools
Most of anti virus developer has their own technique and skill to get rid of mal-ware content. Making analysis for the captured mal-ware is very important before deciding whether it is harmful or not. Anti virus or security company with Malware Analyst job has their own & useful tools to trace malware like behaviour. Well, here it is some basic tools for Reverse Code Engineering. Click on each list for detail:
PE Editor/Memory Dump:
LordPE Deluxe
OllyDump
Explorer Suite (Combine with all the tools we need).
Packer/ID Detector:
TrID
PEiD
ExeInfo PE
Protection ID
AT4RE FastScanner
DiE (Detect it Easy)
RDG Packer Detector
Jim Clausing’s Malware Packer Signatures
Neil’s Collection of Packer Signatures
packerid.py (Python)
Sometime, one packed detector is not enough. Not all detector can detect all packer.
Disassembly/Debugger Tools:
OllyDebugger, OllyScript
Interactive Disassembler (IDA)
Resource Viewer:
PE Explorer
ResHacker
Process Monitor:
Sysinternals Process Explorer
File & Folder Watcher:
SpyMe Tools
Registry Snapshot:
RegShot
Network Tools:
WireShark
NMap
Snort
Honeypot:
HiHAT (Website)
Sandbox:
Sandboxie
Other Miscellanous tools:
Sandboxie
VMWare
Microsoft Virtual PC
Online tools:
VirusTotal
ThreatExpert
PE Editor/Memory Dump:
LordPE Deluxe
OllyDump
Explorer Suite (Combine with all the tools we need).
Packer/ID Detector:
TrID
PEiD
ExeInfo PE
Protection ID
AT4RE FastScanner
DiE (Detect it Easy)
RDG Packer Detector
Jim Clausing’s Malware Packer Signatures
Neil’s Collection of Packer Signatures
packerid.py (Python)
Sometime, one packed detector is not enough. Not all detector can detect all packer.
Disassembly/Debugger Tools:
OllyDebugger, OllyScript
Interactive Disassembler (IDA)
Resource Viewer:
PE Explorer
ResHacker
Process Monitor:
Sysinternals Process Explorer
File & Folder Watcher:
SpyMe Tools
Registry Snapshot:
RegShot
Network Tools:
WireShark
NMap
Snort
Honeypot:
HiHAT (Website)
Sandbox:
Sandboxie
Other Miscellanous tools:
Sandboxie
VMWare
Microsoft Virtual PC
Online tools:
VirusTotal
ThreatExpert
Assinar:
Postagens (Atom)